AppSec Research 2010 Challenge 6

Utmaning sex är nu publicerad på konferenswikin. Den handlar om att designa en logga för konferensen. Första pris är en gratisbiljett till AppSec Research 2010. Ta chansen och visa på dina artistiska talanger!

Påverka nya OWASP Top 10

Jag gissar att ingen missat att nya OWASP Top 10 (release candidate) presenterades i fredags. Nu har vi i communityn fram till sista december på oss att komma med kommentarer. OWASP Top 10 är alltså listan som PCI refererar till och som idag utgör riktlinjer hos väldigt många utvecklingsorganisationer. Ta chansen att påverka den!

Onsdag 2/12 bjuder Omegapoint in till en diskussionskväll med lussefika.

Agenda

17.30 Välkomna, mingel

18.00 Genomgång OWASP Top 10 2010 rc1, fokus på det som är nytt (John Wilander)

18.40 Bensträckare

18.50 Diskussion (gemensam feedback skickas in till OWASP):

- Är det rätt hot och risker på listan? Är det det här vi ser hos kunder?

- Är listan i rätt ordning? Observera att den numer är riskbaserad.

- Är listan bra formulerad? Fungerar den som underlag för pentester och PCI-granskningar? Förstår kunderna?

- Hur når vi ut med listan? Listan i sig gör ju ingen glad. Kort sagt, hur gör vi världen bättre?

- Ska vi översätta den till svenska (förslagsvis två-och-två per punkt under dec-jan)?

Anmäl er genom att mejla john.wilander [at] owasp.org senast måndag 23/11 (begränsat antal platser)

Vi ses!

Microsoft dödar kodpolicy i .Net 4

Jag har skrivit tidigare om eländet med Javas Security Manager och att alla applikationsservrar stänger av den som default. Nu har Microsoft tagit samma beslut om sin Code Access Security. I .Net Framework 4 gäller:

"(...) all unhosted managed code runs as fully trusted by default."

och motiveringen får alla Javamänniskor att le igenkännande:

"While CAS policy was very powerful and allowed for very granular controls, it was extremely difficult to get right and could hinder more than help. (...) many people wondered why their applications suddenly stopped working"

Microsoft skriver om det och ersättningen i form av en säkerhetspolicy för en hel applikationsdomän där du delar upp dina applikationer i partial trust och full trust. Undrar just när Sun/Oracle ska göra något åt policy-problemen i Java?

Java Enterprise Rootkits

Allvarligt talat så vill jag inte skriva det här blogginlägget. Jeff Williams presentation om Java-rootkits fick mig nämligen att må dåligt. Om du inte riktigt har koll på vem som utvecklar dina applikationer (eller alla open source-bibliotek ni använder) så kommer du också må dåligt.

Vad kan en elak Javautvecklare åstadkomma på en vecka? Vad kan han/hon smyga in i koden? Det frågade sig Jeff och ägnade en vecka åt att göra rootkits i Java. De presenterar det i en 40-sidig rapport med tillhörande Eclipse-projekt (zip) men här kommer några godbitar.

Vad är ett rootkit?

Rootkits är gömda bakdörrar. Att bara göra en bakdörr i Java är inte svårt (servlet som lyssnar dina instruktioner). Att gömma dem är utmaningen.

Default: Ingen Security Manager

De flesta bakdörrar stoppas av en konfigurerad Security Manager. Men eftersom ingen kör med en Security Manager (avstängd som default i Tomcat, Websphere ...) så får all egenutvecklad kod göra vad som helst på maskinen. Alltså kommer rootkit-koden fungera bra i produktion.

Hur gömmer vi kod?

Det finns flera sätt att gömma sin bakdörr. Grundtricket är att göra data till bytekod i JVM:en. Så vi behöver bara kunna gömma data och några kodrader som omvandlar vår data till kod.

Lämpliga ställen för att gömma data är i en byte-array någonstans, i en åsidosatt toString()-metod som returnerar vår kod som en sträng, eller i databasen för att sen fiska upp den med SQL.

Skapa bytekod

För att skapa bytekod ur data så skriver vi ner den direkt på på class path:en och kör den, ungefär så här:

new File(getDirOnClasspath(), "Attack.class");

Class.forName("Attack").newInstance();

Vi kan också kompilera direkt i koden eftersom kompilatorn är tillgänglig i JDKn:

ToolProvider.getSystemJavaCompiler();

Om produktionssytemet körs på en JRE utan kompilator så finns alltid JSP-kompilatorn.

Eller så skapa vi en ny klassladdare (new ClassLoader()) åsidosätter defineClass() i den och skickar in vår Base64-kodade bytearray och den laddas och exekveras.

Lura kodgranskaren

Vi kan behöva lura kodgranskaren så han/hon inte förstår vad vi gör. Det görs bäst med förvillande kodkommentarer och genom att skriva svår kod med inspiration från javapuzzlers.com.

En riktigt elak grej är att skapa enhetstester som körs på byggservern och där injicerar skadlig kod. Vem kodgranskar enhetstesterna?

Andra slimmade bakdörrar

Som alternativ till data-till-bytekod så kan vi införa ett vanligt servletfilter som åsidosätter isUserInRole och kollar ifall en förvald parameter (typ 'backdoor') finns i requestet. Om den förvalda parametern finns så returnerar isUserInRole sant. Visst vi får lägga till det i web.xml men vem kommer hitta det?

I Servlet 3.0-API:et kan man dessutom lägga till och ta bort servlets och filter programmatiskt, dvs utan att ändra i web.xml.

Eller mygla in din skadliga jar i ext-katalogen så hamnar du direkt på classpath:en

Rootkits i open source

Tänk er nu att någon lägger en trojan i Log4J. Kanske inte ens i källkoden utan genom att ändra direkt i klassfilen/jaren som du laddar hem. Hur många skulle åka dit på den? Typ alla större Javasystem i världen.

Några andra mjukvaror som du kanske använder bygger på mycket öppen källkod:

• Hudson core innehåller 103 open source-projekt
• Maven core innehåller 15 open source-projekt
• Subversion innehåller 3 open source-projekt

Vad göra åt det?

Det som får mig att må dåligt över allt det här är att jag inte riktigt vet vad vi ska göra åt det. Jeff och Bruce Schneier har tillsammans skrivit ihop råd till den som är orolig:

• Begränsa antalet utvecklare
• Se till att du har pålitliga utvecklare
• Begränsa vilken kod du litar på (begränsa vilka api:er som får användas, t ex inte reflection)
• Begränsa beroenden under byggprocessen (kör vanliga javac istället för magiska saker som Maven när du bygger release)
• Begränsa antalet personer du är beroende av i produktion/drift
• Leta aktivt efter skadlig kod

Listan ovan får mig bara att tänka -- "Det kommer aldrig hända.". Så vi får väl lugnt vänta på de första avslöjandena om stora, hemska rootkits istället. :(

OWASP Top 10 2010 (rc1)

OWASPs välkända topp tio-lista kommer i en ny version 2010. Dave Wichers presenterar just nu rc1 av den. OWASP Top 10 2010 är riskbaserad, dvs graderad utifrån sannolikhet och konsekvens.

• A1 (A2) Injection
• A2 (A1) Cross-Site Scripting (XSS)
• A3 (A7) Broken Authentication and Session Management
• A4 (A4) Insecure Direct Object References
• A5 (A5) Cross-Site Request Forgery (CSRF)
• A6 (Ny) Security Misconfiguration (utvecklare använder ramverk men konfigurerar dem fel och sannolikheten att en attackerare hittar såna fel är större än att han/hon hittar applikationsspecifika fel)
• A7 (A10) Failure to Restrict URL Access
• A8 (Ny) Unvalidated Redirects and Forwards (destinationsadressen för en redirect eller en forward ligger i en parameter som klienten kan ändra, ganska vanligt och mycket farligt)
• A9 (A8) Insecure Cryptographic Storage
• A10 (A9) Insufficient Transport Layer Protection
• (Borttagen) A3 Malicious File Execution (mest ett php-problem)
• (Borttagen) A6 Information Leakage and Improper Error Handling (ej hög risk)

Planen är att låta communityn kommentera fram till sista december och sen fastställa det hela i början av 2010. Därför ska vi försöka ha en OWASP Sweden-kväll i december där vi diskuterar igenom listan och kommer med gemensam feedback.

[Uppdatering] Nu finns nya listan på wikin.

Säkra J2EE-mönster

Ett mycket intressant OWASP-projekt är OWASP Security Analysis of Core J2EE Design Patterns. Det handlar inte om säkerhetsmönster utan om säkra mönster. Helt enkelt -- hur man skriver säkra applikationer med de vanliga J2EE-mönstren.

Jag kan inte återge alltihop här utan hänvisar till wikin. Där går man igenom säkra mönster för presentationslagret, affärslogiken och informations-/persistenslagret.

Men som en liten aptitretare så kan jag nämna att Synchronization Token i Struts är ett utmärkt skydd mot Cross-Site Request Forgery (CSRF). Use it!

Pentesta WCF web services

Brian Holyfield gav en del konkreta tips för pentestning av WCF-webbtjänster.

Proxy för binär SOAP?

Windows Communication Foundation (WCF) har försökt göra något åt storleksexplosionen med SOAP genom att införa ett packat, binärt SOAP-format. Bra för prestanda, dåligt för pentestare.

Hur ska vi nu kunna fuzza eller pentesta våra web services? Microsoft har turligt nog publicerat formatet och some-guy-on-the-internet har implementerat en codec.

Brian gjorde plugins till Burp-proxyn men kunde bara antingen avkoda inkommande trafik eller koda utgående, inte både och. Så han fick utveckla två plugins och köra dubbla proxies, en på invägen och en på utvägen (med varsin port förstås). På det viset fick han möjlighet att titta på och manipulera SOAP:en.

Hitta WSDL:en

Pentestare gillar att hitta WSDL-filer för att snabbt se hur gränssnittet ser ut. Microsoft har å andra sidan bestämt sig för secure by default och publicerar in WSDL-filer som default. Men om du använder templates i Visual Studio så slås det på.

Ett alternativ är att anropa en så kallad MEX-tjänst som ofta publiceras i .Net-sammanhang och ger metadata om webbtjänsten. Det visar sig att den mest klär in WSDL:en med lite mex-taggar och är ett utmärkt sätt att få tag på WSDL:en.

Ytterligare ett alternativ finns om det rör sig om Silverlight enabled WCF services. Då kan du ladda hem klienten (.xap-fil), packa upp den (det är en zip) och om klienten är gjord i Visual Studio så har den skapat metodstubbar för alla ändpunkter i webbtjänsten, inte bara dem som klienten faktiskt anropar. Bara att rota igenom klasserna för att hitta information motsvarande WSDL:en med andra ord.