Sammanfattning Black Hat och Defcon

Tillbaka till Sverige.
Tillbaka till jobbet.
Tillbaka till verkligheten.
Eller var det verkligheten vi lämnade i Vegas och bubblan vi återkommit till?

Här är mina intryck från världens största säkerhetskonferenser – Black Hat USA och Defcon.

Allt kan och ska hackas
Mina kollegor Michael Boman, Marcus Hartwig, Peter Swedin och jag träffade en hel del intressanta människor under de två konferenserna. En av dem – Jesse Ou från Cigital – sammanfattade intrycken väl: – It's all depressing, isn't it?! Everything gets hacked.

Black Hat är tämligen kommersiellt medan Defcon känns som en gräsrotsrörelse. Samtidigt har de ett gemensamt tema – allt kan och ska hackas. Känslan på Black Hat var att hacken syftade till att höja medvetenheten och på sikt säkerheten. Känslan på Defcon var snarare att det var coolt att knäcka system, punkt.

Hur som helst så är listan på de säkerhetshack som presenterades tämligen deprimerande:

• Bankomater hackades (video)
  
• Kerberos på Windows hackades
• Android hackades ... flera gånger om
• iPhone:s och Androids webbläsare hackades (video)
  
• GSM hackades
• IBM WebSphere hackades
• PHP hackades
• Diverse network management-protokoll hackades
• Smarta kort med Atmel-chip hackades
• Så kallade Grade 1-säkerhetslås knäcktes, t ex finska ILOQ (video)
  
• Privata RSA-nycklar hackades ... på veckor med en desktopdator! Jag har jagat presentatören som tusan eftersom det nog var det mest skrämmande vi såg. Men det var en presentation i ett separat rum utanför den vanliga agendan. Hittills inga svar.
  

Säkerhet i två världar
Det bestående intrycket är att IT-säkerhet är uppdelat i två världar.

Värld nummer ett där de flesta av oss arbetar. I den världen så betyder säkerhetsfunktioner, säkerhetsregler, säkerhetsrutiner och säkerhetsprinciper allt. Under sådan flagg säljer vi kunskap och system för att bygga och upprätthålla säkerhet.

Värld nummer två där en del av oss tillbringar fritiden men de flesta är åskådare. I den världen så kringgås säkerhetsfunktioner, säkerhetsregler, säkerhetsrutiner och säkerhetsprinciper konsekvent. Men där finns inga pengar att tjäna om man vill vara på rätt sida om lagen.

Vilken säkerhet efterfrågas?
Den säkerhet som kunder efterfrågar och säkerhetsföretag säljer har ganska lite att göra med hur system hackas. Hackerkulturen går ut på att inte acceptera specifikationer och garantier utan istället undersöka sanningen och röka ut säkerhetshålen som alltid finns där.

OWASP befinner sig i ett mellanläge. Med säkerhet i applikationsutveckling försöker man undvika att utgöra lågt hängande frukt. OWASP Top 10 ger tips om vanliga risker och misstag. OWASP ESAPI ger byggklossar för bättre säkerhetsfunktioner i webbsystem.

Men om vi efterfrågar riktig säkerhet så finns i dagsläget ingen annan väg framåt än tidskrävande, explorativ säkerhetstestning. Och det är det ingen som håller på med.

Förutom de som presenterar på hackerkonferenser förstås.

Fortfarande ingen patchad Struts 2

Apache-folket har skippat Struts 2.2.0 och röstar sen 17 juli om version 2.2.1 och ingen har sagt något där på 2,5 veckor. Under tiden är hundratals svenska webbapplikationer antagligen vidöppna för hack. Testbygge för 2.2.1 finns. Temporär fix har jag publicerat här.

Senaste releasen av Struts 2 är från september 2009. Kanske har den långa tiden kastat grus i release-maskineriet? Philip Luppens i teamet kommenterar det i alla fall så här:

"Guys, can we please get some more votes in? I cannot understand we cannot push out a simple release when all the work has been done ..."

Android-malware utan permissions

Anthony Lineberry, David Richardson och Tim Wyatt höll en grymt intressant presentation och demo om Android-säkerhet. Otroligt hur de kunde kringå alla begränsningar som egentligen ska finnas för appar.

Lite om Androids säkerhets- och processmodell
Varje Android-app har en AndroidManifest.xml som deklarerar
pakettillhörighet, komponenter och tillstånd (permissions) som appen behöver på mobilen.

En körande app är en aktivitet som ligger på aktivitetsstacken. Aktiviteten på toppen är den som kör, de andra är i pausläge.

En applikation kan starta andra appar som då körs i appens process. Anroparen har dock inte alltid tillgång till den startade aktivitetens data eller tillstånd.

När man laddar ner en app från Google Market så får man först reda på vilka tillstånd den kräver. På det viset kan användaren undvika skumma appar. Men om appen inte kräver några tillstånd så laddas den hem direkt. Det låter intressant – vad kan en attackerare göra med noll tillstånd?

En hel del!

Reboot utan tillstånd
En app utan tillstånd får inte anropa REBOOT. Men det går att tömma ut Androids minnesresurser och tvinga fram en ombootning. Genom att skapa osynliga views. Efter 2001 st views som alla skapar globala referenser så får telefonen en SIGSEGV och bootar om.

Starta automatiskt vid boot utan tillstånd
Applikationer får inte begära att de ska startas vid omstart av telefonen. Specifikt så krävs receive_boot_complete-tillstånd. Men det tillståndet kollas inte!

Starta efter installation utan tillstånd
Applikationer får allmänt inte starta automatiskt efter nedladdning. Därför förväntar sig inte användaren det utan kommer att tolka det som att Android OS:et ber om uppmärksamhet om något händer direkt efter att han/hon laddat ner en app.

Tänk dig att du installerar en app från Google Market som automatiskt startar en phising-attack som begär ditt lösenord. Det kan man åstadkomma genom att utnyttja hur Google Analytics används. Analytics ska nämligen få logga vad och hur du har laddat ner. Kolla Googles dokumentation, kopiera koden och peka ut din egen phising-app.

Internetaccess utan tillstånd
En applikation måste be om tillstånd för att få kommunicera med Internet. Så kan attackerarens app göra det utan tillstånd? Jajamen. Låt oss börja med uppladdning av data.

Appen har inte uppladdningstillstånd själv. Men det har webbläsaren och appen har rätt att öppna sidor via webbläsaren. Risken är dock att användaren upptäcker det och stänger av ("Ehh ... varför drogs webbläsaren igång och gick till den där skumma sidan?"). Så hur gör attackeraren? Jo, han/hon gör alla uppladdningar när telefonens skärm är släckt! Och så fort uppladdningen är klar så går webbläsaren vidare till exempelvis google.com så att det inte ser skumt ut när användaren startar skärmen igen.

Nedladdning då?

Ja, det går ju att hämta med webbläsaren. Alla filer lagras då på SD-kortet och där får appen läsa utan tillstånd. Men det skapar en massa notifieringar som användaren kommer se i en lista plus att det blir skumma filer som skräpar.

Istället utnyttjar Androids funktionalitet för att mappa specialprotokoll med appar. T ex så startar geo:-protkollet Google Maps direkt. Attackeraren kan deklarera och mappa sitt eget protokoll (android:scheme="nethack" adroid:host="data") och anger sen bara nethack: istället för http i URL:en. Voilà -- nedladdning som skickar data direkt till appen!

Remote execution på WebSphere

Ed Schaller höll en intressant presentation om remote execution på IBM WebSphere (WAS).

WAS frontas typiskt av en webbserver såsom Apache eller IIS. Webbservern används för lastbalasering och felhantering. Den kommunicerar i sin tur med WAS via en webbserver-plugin över http. Men inte alla request skickas vidare.

Webservern utgår från url-mappnignar i web.xml och ibm-web-ext.xmi. Om en match hittas så skickas requestet vidare, annars hanteras det av webbservern själv.

JSP:er och null
WAS och andra applikationsservrar översätter jsp till Java, kompilerar och kör det som en servlet. Det fungerar normalt även runtime och jsp:er komplieras först när de efterfrågas.

Det gör att webbservern alltid skickar jsp-request vidare eftersom appservern måste få en chans att kolla om den finns och kompilera den.

Så hur tolkas null i den här översättningen från jsp till Java till bytekod? Jo, det visar sig att WAS accepterar null men i accessen till det underliggande filsystemet så termineras strängen vid null. På det viset kan man fejka att man vill nå en jsp men i själva verket peka ut en annan fil. Så här:

ctxroot/path_till_filen%00.jsp

Det kommer läsa upp den fil attackeraren har anget så länge den finns i den exploderade war:en. Det måste dessutom vara en korrekt jsp. Jobbigt? Nja, i princip allt som inte innehåller <% är en korrekt jsp. T ex textfiler, html, xml, de flesta zip-filer och så vidare. Intressant nog visare det sig att om attackeraren anger en katalog istället för en fil så får han/hon en kataloglistning. Så här:

ctxroot/dir/%00.jsp
ctxroot/.%00.jsp (extra punkt för att komma åt kontextroten)

Web Server Plugin
OK, null gick bra att att skicka till WAS:en men hur går det med den framförliggande webbservern? Pluginen är skriven i C och terminerar därför vid null, dvs text.txt.jsp blir text.txt. Tillbaka på ruta null så att säga.

Men vi kanske kan lura webbservern med teckenkodning? Java lagrar strängar i UTF-16 internt men tolkar inkommande strängar som UTF-8. Men web server-pluginen förstår inte lång UTF-8. Därtill har IBMs jvm haft en allvarlig bugg i hantering av så kallad overly long UTF-8 som är fixad i de senaste patcharna. På det viset kan man injicera UTF-8 som webbserver-pluginen inte förstår och som jvm:en sen misstolkar som null. Tecknet är %C0%80 vilket tolkas som ASCII null.

Med dubbelpunkt kan man dessutom komma åt WEB-INF-katalogen och kodningen för dubbelpunkt i UTF-8 är %C0%AE. Totalt sett så här:

ctxroot/%C0%AE/WEB-INF/web.xml%C0%80.jsp

… för att komma åt web.xml.

Axis och bilagor
Men attackeraren vill inte bara läsa filer utan också få till remote execution. Så han/hon måste få in en jsp-fil i den exploderade war:en. Här vänder vi oss till det populära Axis-ramverket för web services.

Man kan nämligen ha bilagor (attachments) i sin SOAP. Om man lägger bilagan före SOAP:en och dessutom refererar den i SOAP:en, t ex med en href, så kommer Axis ladda bilagan som fil och cache:a den … i war:en!

Men då måste attackeraren kunna kommunicera med en web service väl? Nej. Web services tillåter att klienten skickar ett SOAP Fault det första den gör. Och då kommer Axis hantera det oavsett om det finns någon web service som det kan ha gått fel i. SOAP Fault är kodade på samma sätt som vanlig SOAP så tricket med bilagan funkar bra.

Bilagan rensas av cache-hanteraren så det uppstår en så kallad race condition där attackeraren måste hinna använda den uppladdade jsp:n innan den tas bort.

Allt det här demade Ed på plats. Japp, skal med användaren wasadmin blev det.

Fix?
Alla moderna versioner av WebSphere (6 och framåt) har så kallade fixpack för det här problemet. Ed har varit noga med att rapportera det på rätt sätt. Coolast var att IBM ordnade en patch på två veckor för alla de 60 varianter som var sårbara. Det är respekt.

Men om man kör en opatchad WebSphere så är man alltså sårbar.

Ed tyckte också man skulle överväga att stänga av runtime-kompilering och omladdning av jsp:er (disableJspRuntimeCompilation).

Säkerhet i GWT

Google Web Toolkit (GWT) låter utvecklare bygga klienttunga webbapplikationer i Java. De kompileras sen till effektiv JavaScript. Frågan är dock om utvecklare känner till vad som händer under huven och hur det påverkar säkerheten? Spider Labs har rotat i den frågan.

Genererad JavaScript
GWT kan generera JavaScript i tre varianter – pretty, detailed och obfuscated. Pretty är helt enkelt trevlig, läsbar kod lämplig under utveckling. Detailed är JavaScript med identifierare som återger exakt vad det var i Java, t ex klassnamn med hela pakettillhörigheten. Inte lätt att läsa men väldigt informativt.

Obfuskering är påslaget default (stäng inte av det för produktionskod) och görs på följande sätt:

• Variabel-, klass- och metodnamn är förkortade (aa, ab, ac, … zx, zy, zz …)
• Statiska strängar flyttas till globala variabler
• Onödig whitespace tas bort
• Alla funktioner sorteras i storleksordning. Det är oklart varför men enligt Google kan det ge bättre kompression när koden skickas över nätet.

Relativ kodstorlek:
100 % obfuscated
200 % pretty
700 % detailed

Inga privata metoder
En liten detalj värd att notera är att privata metoder inte längre är privata i den genererade JavaScript-koden. Det har inga egentliga säkerhetsimplikationer men pekar på det faktum att Google har prioriterat prestanda och komprimerad kod framför att bibehålla maximalt med egenskaper i konverteringen till JavaScript. Det verkar alltså inte använda Crockfords designmönster Module Pattern som möjliggör privata metoder JavaScript.

Enligt Spider Labs så hittas de flesta säkerhetsfelen i webbappar i rpc-gränssnitt (remote procedure call). Se därför dina rpc-anrop som http-request och säkra dem på samma sätt (autentisering, csrf-skydd …).

Deobfuskering av genererad JavaScript
För en attackerare eller pentestare är det naturligtvis intressant att få klientkoden i ett läsbart skick. Spider Labs har därför byggt en deobfuskator – REGWT – utifrån Mozilla Rhino. Den intressantaste delen i deobfuskeringsprocessen är hur de återskapar metodnamn genom metodsignaturer. De döper alla variabler till numrerade standardnamn (field_3 osv), formatterar koden och beräknar sen en hash på det hela. Den kan jämföras med hashen för kända Java-metoder och på så sätt kan man återskapa en hel del av koden.

Verktyget ska släppas till helgen. Kolla efter REGWT på deras webbsida.

PHP-sessioner sårbara

Samy Kamkar, killen bakom MySpace-masken och XSS håller precis en väldigt underhållande presentation. Han har bland annat slaktat PHP-sessioner ...

Målet för attacken är att ta över en inloggad persons session i en webbapplikation skriven i PHP.

session_start() initialiserar en PHP-session. Samy har analyserat entropin i sessions-idt:

• 32 bitar från din IP-adress
• 32 bitar från sekunder sen 1/1 1970
• 32 bitar från nuvarande antal mikrosekunder
• 64 bitar från pseudoslumpgeneratorn (PRNG, pseudo random number generator)
  

Totalt 160 bitar, dvs jobbigt att brute force:a

Men …

• 0 bitar från din IP-adress eftersom den knappast kan anses hemlig.
• 0 bitar från sekunder sen 1/1 1970 eftersom man kan polla tjänsten en gång i sekunden för att se exakt när du loggar på (typiskt sociala nätverk där din kompis loggar in)
• 20 bitar från nuvarande antal mikrosekunder eftersom det bara finns en miljon mikrosekunder!
• 64 bitar från PRNG

Totalt 84 bitar, inte lika jobbigt att brute force:a

Men …

Den enda slump som finns i en PRNG kommer från fröet. Resten är en predikterbar sekvens av siffror, lika varje gång fröet är lika. Just därför är det så allvarligt att PHP-utvecklarna har tabbat sig i fröberäkningen.

Fröberäkningen XOR:ar tidpunkten för serverstarten i antalet sekunder sen 1/1 1970 med antalet mikrosekunder. Felet är att man mixar det helt slumpmässiga antalet mikrosekunder med den del av antalet sekunder sen 1/1 1970 som är variabelt (dvs den del som är någorlunda slumpmässig). Och eftersom det bara finns en miljon mikrosekunder så är fröet nu nere i 20 bitar entropi.

Total entropi: 40 bitar

Vidare med time-space-tradeoff så behöver vi bara brute force:a hälften, dvs 20 bitar. Genomförbart inom sekunder med i snitt en halv miljon request till den sårbara tjänsten.

Sen är PHP-sessionen övertagen.

Historien om buffer overflows

Haroon Meer har tillbringat fantastiskt mycket tid åt att gå igenom historien bakom buffer overflows, formatsträngsattacker och andra minnesattacker. Istället för att ens försöka återge hans snabba och underhållande presentation så länkar jag till hans interaktiva tidslinje.