fredag 31 december 2010

Icke-ASCII blir '?' i lösenord hos Gawker

Jag har ägnat ett par dagar åt att rota i vettiga lösningar på lösenordshantering i kölvattnet av Gawker-hacket och alla de knäckta lösenordshasharna.

Individuell saltning av varje lösenord löser rainbow table-problemet. Men så länge användare tillåts ha korta lösenord (Amazon och Apple tillåter exempelvis sex tecken) så är ren brute force fullt möjligt. Och det blir inte bättre i takt med att datorer blir snabbare.

Bästa alternativen verkar vara Secure Remote Password protocol som jag skrev om i förrgår eller att nyttja maximal långsamhet i Blowfish, det vill säga bcrypt à la OpenBSD. Olle Segerdahl kommenterade bloggen med dessa tips i februari i år under mitt inlägg om genererade toString().

ДДДДДДДД == 簡簡簡簡簡簡簡簡 == ©©©©©©©©?
Joseph Bonneau, doktorand vid Cambridge, upptäckte att Gawker tolkar alla icke-ASCII-tecken i lösenord som likvärdiga. Dvs du kan logga in på ett konto som har lösenordet "ДДДДДДДД" med valfritt annat icke-ASCII-lösenord med samma antal tecken, t ex "簡簡簡簡簡簡簡簡" och "©©©©©©©©".

Problemet visade sig vara en bugg i jBCrypt innan v 0.3 där alla icke-ASCII-tecken byttes ut mot '?' innan hashning. Det finns beskrivet i en advisory från februari i år.

Fyra slutsatser:
  1. Uppgradera om ni använder jBCrypt < 0.3.
  2. Använd bara ASCII-tecken i era lösenord och låt istället längden ge er säkerhet mot brute force. Det är bra när ni är utomlands också.
  3. Gawker kör åtminstone nu bcrypt vilket trots allt hedrar dem. Alla ni med vanliga lösenordshashar i databasen bör ta en funderare.
  4. Om Gawker körde bcrypt redan i våras så var det särdeles dumt att inte uppgradera jBCrypt till 0.3 när patchen kom i februari. Om de driftsatte jBCrypt 0.2 efter hacket så var det ännu dummare. Men det sätter återigen fingret på ramverks- och bibliotekspatchning. Vem håller koll på alla säkerhetsuppdateringar i olika lib man har länkat in? "Ingen" är min gissning i de flesta fall.
Gott nytt år!

onsdag 29 december 2010

Secure Remote Password Protocol

Du ska logga in och etablera en symmetrisk sessionsnyckel.

Attackeraren känner till autentiseringsalgoritmen.
Attackeraren har ordbok och topplista på lösenord.
Attackeraren kan avlyssna all klient/server-trafik tills du har din symmetriska nyckel.
Attackeraren kan avbryta, ändra och förfalska klient/server-trafik.
Det finns ingen betrodd tredje part.
Du vill ha något säkrare än SSH och snabbare än ren Diffie-Hellman.
Du vill ha zero-knowledge password proof, dvs du visar aldrig lösenordet utan bevisar bara att du har lösenordet.
Du vill inte att en SQL injection ska ge attackeraren en vanlig lösenordshash (MD/SHA) att knäcka. Inte ens en statiskt saltad hash duger för dig.
Du vill använda ett enkelt lösenord.

Du vill ha ...
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Version 6, hårdgranskat, från Stanford. Så coolt att jag baxnar.

Avlyssna GSM med 4 billiga mobiler + laptop

GSM, eller 2G, har ju fått en hel del stryk på sistone, inte minst i somras på Defcon. Nu verkar spelet slutligen vara över för GSM-säkerheten. Åtminstone tills operatörerna gör förändringar.

Med hjälp av fyra stycken enkla mobiltelefoner för ca 100 kr styck och en laptop så visade man lajv att man kunde avlyssna GSM-samtal och sms på Chaos Computer Clubs (CCC) årliga kongress. Wired skriver om det här.

Steg 0 – lokalisera offrets geografiska område
Om vi tänker oss att vi ska avlyssna någon så börjar det hela med att komma tillräckligt nära geografiskt. Presentatörerna visade hur man med vanliga anrop på Internet kan ta reda på i vilken stad eller vilket område en mobil befinner sig. Det sker genom att operatörerna är ganska öppna med routing-information för att slussa samtal och sms rätt.

Steg 1 – hitta nätverks-id för offrets telefon
De fyra avlyssningsmobilerna uppdaterades med ny firmware för att kunna vidarebefordra den fullständiga GSM-trafiken till laptopen. Sen skickas trasiga sms till det telefonnummer man vill avlyssna. De trasiga sms:en kommer inte synas på offrets telefon men ger attackeraren chansen att ta reda på vilket nätverks-id offrets telefon har fått tilldelat av operatören. Det i sin tur är nyckeln till att veta vilken trafik som ska avlyssnas i GSM-nätet, nämligen all trafik till och från det nätverks-id:t.

Steg 2 – knäck kryptot
När nu offrets krypterade mobiltrafik kan avlyssnas så gäller att knäcka GSM-kryptot. Det görs genom att utnyttja brister i operatörens systemkommunikation med sina kunders mobiltelefoner. Den kommunikationen är nämligen känd hur den ser ut, t ex regelbundna "Är du där?"-meddelanden.

Attackeraren vet att meddelandet i klartext är "Är du där?" och har avlyssnat hur det ser ut i krypterad form (kryptotexten). Sen används en regnbågstabell (rainbow table) på 2 TB med förberäknade kryptotexter för olika nycklar. Inom 20 sekunder hittar man vilken kryptonyckel som används för offret och vips så kan man avlyssna trafiken. Observera att man utan besvär kan spela in den trafik som försiggår under de 20 sekunder man letar efter rätt nyckel. Varje kryptonyckel används typiskt för flera samtal eller sms i rad.

Åtgärder
Presentatörena på CCC gick igenom några enkla åtgärder som mobiloperatörerna bör vidta:
  • Se till att routing-information inte är så enkelt tillgänglig via nätet
  • Implementera den redan standardiserade ändringen att lägga till slump ("salta") systemkommunkationen till mobilerna så att kryptot blir svårare att knäcka
  • Byt kryptonyckel varje samtal och sms istället för att återanvända den

måndag 27 december 2010

Nytt om EMV-hacket

Ni minns säkert vårens snackis om Cambridge-hacket mot chipförsedda betal- och kreditkort och standarden EMV. Jag bloggade i alla fall om det:
Cambridge-gruppen har förstås forskat vidare och i somras publicerades "The Smart Card Detective: a hand-held EMV interceptor" (pdf).

Delar av bankvärlden gillade inte den publikationen och skrev ett uppfordrande brev till universitetet. Nu har Ross Anderson svarat, punkt för punkt, under rubriken "Responsible disclosure and academic freedom" (pdf). Läsvärt.

söndag 26 december 2010

Årskrönika 2010

Det är mellandagsrea och dags att summera ännu ett år inom applikationssäkerhetsscenen.

Jag börjar självklart med ...

OWASP AppSec Research 2010
Den stora händelsen för OWASP Sweden var förstås värdskapet för OWASP AppSec, den globala konferensen inom applikationssäkerhet. Två dagar med fem olika kurser och två dagar med tre parallella spår och en blandning av akademiska presentationer och industripresentationer.

Ärligt talat så höll det hela på att knäcka mig. Jag uppskattar min egen arbetsinsats till ~1000 timmar. Därtill kommer kommitténs hårda arbete – tack Mattias, Stefan, Martin, Alan, Carl-Johan, Michael, Kåre, Ulf och Predrag! Kate och Sebastien från OWASP är också väl värda sitt tack. På upploppet så drog jag in min flickvän Johanna och hennes kompis Marie också.

Men det var värt det. Att se det hela fungera och med 270 nöjda deltagare är en stor känsla. Dave Wichers, ansvarig för konferensfrågor i OWASP-styrelsens mejl efteråt var ännu större:

"I just wanted to thank you and your team for doing an AMAZING job at the OWASP Sweden conference. This was the best organized conference ever.
(...)
And financially it was outstanding as well! Looks like close to $100K to the good, which blows away any other European conference by far. OWASP really needs the funds as things have been very tight the past two years and this is extremely helpful to us."

Så, sponsorer, alla som var där och alla som hjälpte till – sträck på er! Vi gjorde det och vi har gjort något riktigt bra för OWASP-stiftelsen!

Applikationssäkerhet 2010
År 2010 har varit spännande på applikationssäkerhetsscenen. Min summering ...

Ny OWASP Top 10
Vi var med och spikade en ny OWASP Top 10. Många frågade sig varför den är så lik listan från 2007. Det frågar vi alla oss :/. Men jag känner faktiskt att nummer 1 – Injection – är på väg att blekna. Ett i många fall lätt problem att undvika och något som utvecklare har tagit till sig.

Största smällen enligt mig
Men jag tycker inte att OWASP Top 10 2010 har varit mest spännande utan faktiskt något som var på väg in på topp-tio-listan men som till slut ansågs sortera under det flummiga "A6. Security Misconfiguration". Vad? Jo, ramverkssäkerhet. Under 2010 så small det rejält i tre stora webbramverk:
Sanning och säga, det rörde sig ju om säkerhetsbuggar i ramverken och inget som de lokala utvecklarna kunde hållas ansvariga för. Samtidigt så satte det fingret på hur applikationslagret har blivit en allt viktigare komponent att hålla koll på. Ovanstående problem gick inte att lösa med någon normal patchhantering. Nej, utvecklarna fick kallas in oavsett tid på dygnet eller semesterplanering för att patcha, regressionstesta och driftsätta. Jag tror många säkerhetsansvariga har fått en del att fundera på sen dess. Vilka teknikval görs och av vem? Ska vi ha rutiner för "patchning" i applikationslagret? Vilka versioner av webbramverken (ofta flera) är i drift?

Säkerhetssansvariga + applikationssäkerhet = falskt?
I samband med ovanstående säkerhetsproblem i ramverk blev jag ganska ledsen över att vårt OWASP AppSec-erbjudande till SIG Securitys medlemmar bara lockade en enda person. Om någon förstår varför så får ni gärna berätta. Applikationssäkerhet och engagemang i utvecklingsavdelningen är en av säkerhetsfolkets viktigaste arenor när vi nu går mot 2011. Brandväggar, patchhantering, nätverkskonfiguration och policys i all ära men man måste också intressera sig för de applikationer som organisationen utvecklar och förvaltar.

SDLC till Sverige
2010 var också året då vi (= företaget jag arbetar på) började få flera frågor om hjälp med Security Development Lifecycle (SDLC). Flera stora svenska organisationer håller på att införa en SDLC och jag tror det kommer prägla 2011. Frågan är hur väl SDLC gifter sig med agila metoder och om säkerhets- eller utvecklingsavdelningen ska ha hand om SDLC-införandet och -förvaltandet?

Alla väntar på Internet Explorer 9
Microsoft gav sig återigen in i webbkriget med Internet Explorer 9 (än så länge beta). Kanske skönjer vi ett slut på ökenvandringen där webbutvecklare ägnade manmånader åt att få en i övrigt utmärkt app eller sajt att fungera i IE6-8. Om vi bara kan få alla stora organisationer att uppgradera till Windows 7 + Internet Explorer 9 under 2011 så går vi en lysande framtid till mötes, med stöd för HTML 5 och CSS 3.


Men är inte HTML 5 och CSS 3 en abyss av säkerhetshot? Jo, det finns mycket elände längs vägen framåt. Mario Heiderich underhåller en tämligen diger lista på problem som kan relateras till webbens sentida utveckling. Och den växer typ dagligen.

Samtidigt så är ju webben framtiden. Vi inom applikations- och webbsäkerhet ska baske mig se till att alla utvecklare kan skapa nya, grymma tjänster utan att behöva tänka på säkerhet 25 % av tiden. Webbläsar- och RFC-makarna är viktiga komponenter. Engagera er i de nya teknikerna. Läs specarna, ifrågasätt och rota runt. Sånt är vi bra på och bör bidra med.

Säkerhet 2010
Om vi blickar utanför applikationslagret så finns förstås en hel del intressanta säkerhetshändelser 2010.

Cyberkrig 1: Stuxnet
Stuxnet har goda chanser att gå till historien som 2010 års stora säkerhetshändelse. Kanske får vi aldrig reda på dess bakgrund eller syfte men bara det faktum att vi på allvar tror att en eller flera stater låg bakom det och att syftet var att sänka en kärnkrafts/-vapenindustri är nog för en Bondfilm. Cyberkrigföring har varit känt länge inom säkerhetskretsar men nu är det ett allmänt känt fenomen och något som försvarsmakter, politiker, industrier och polismyndigheter måste förhålla sig till.

Intressant nog så har Stuxnet inte på ett nog tydligt sätt väckt frågan om den många gånger skandalöst dåliga IT-säkerheten i vår infrastruktur, t ex elförsörjningen.

Cyberkrig 2: DoS mot Wikileaks
Alla denial-of-service-attacker mot Wikileaks och hur de flyttade runt sajten är en tekniskt och affärsmässigt mycket intressant resa. De jag pratat med tror Amazon primärt tänkte på alla förlorade dollar som låg i en upprörd amerikansk allmänhet mitt i julhandeln.

Inom OWASP har dessa attacker väckt frågan om hur man effektivast skyddar sig mot DoS-attacker. För det är betydligt fler än Wikileaks som utsätts för DoS och DDos. Många gånger handlar det om utpressning men som i fallet med The Jester så är det hacktivism det handlar om. En enskild person med en politisk agenda kan få för sig att attackera valfria sajter och vi borde hjälpas åt att ta fram praxis för hur man skyddar sig.

Cyberkrig 3: DDoS mot Visa och MasterCard
Sen har vi ju LOIC-attackerna mot exempelvis Visa och MasterCard. Det kan närmast liknas vid massdemonstrationer på nätet som Richard Stallman skrev. Att kalla det för intrång eller attacker blir svårt. Det blir förstås en uppsåtsfråga eftersom samma typ av belastning uppstår under extrema nyhetshändelser såsom 9/11-bombningarna och tsunamin. Är man kriminell för att man hämtar en jpg med HTTP GET flera gånger? Kanske. Godtycke är dock det första jag vill bli av med i den frågan.

Gräv och du skall finna
Under 2010 skedde ett antal uppmärksammade hack som i princip byggde på att någon börjat gräva i ett hörn av tekniken och förstås hittat en massa säkerhetshål. Exempel:
Hela stämningen i hackervärlden är ju just sådan. "Börja gräv någonstans och du skall finna säkerhetshål!" Black Hat och Defcon inspirerade mig till just det så jag har ägnat den senaste tiden åt att implementera lite ny säkerhetsteknik och köra den med webbläsare som påstår sig ha stöd. Mycket riktigt så hittar man problem. Allt sådant kan ni följa på min nya, engelskspråkiga blogg "Apps and Security".

Nya tag hos bankerna
Jag känner också av ett omtag hos de svenska bankerna. Sverige brukar framhållas som säkert jämfört med stora delar av omvärlden och jag är böjd att hålla med. Men för att hålla den ställningen så krävs omtag. Trojaner, man-in-the-browser och hack som det mot chipkort knackar på dörren konstant. Det skulle inte förvåna mig om de svenska bankerna lanserar nya säkerhetslösningar under 2011.

John 2010-2011
Jag brukar ju nämna några personliga saker i krönikan också. Sist skrev jag om planer på ett singelsläpp under våren men någon singel har ni nog inte sett till. AppSec-konferensen slukade mig helt och hållet. Men jag ger inte upp utan har tagit tjänstledigt i tre månader för att primärt arbeta med musiken. Jag ska också försöka ta tag i min sista forskningsartikel inför doktorsavhandlingen. Lustigt nog så vill chefer och bekanta gärna nämna det där doktorsarbetet som orsaken till min ledighet. För inte kan väl en vuxen man ta ledigt i tre månader för att hålla på med musik? Jo, det kan han. Och jag står för det också. Jag ska primärt ägna mig åt musik i tre månader. Read it and weep ;).

Men jag kommer ju inte lämna OWASP under dessa månader. T ex så är jag ansvarig för spåret "Browser Security" vid OWASP Global Summit 2011 som går av stapeln i Portugal 8-11 februrari. Workshop med Chromes, Firefox och IEs säkerhetsfolk plus en massa grymma webbsäkerhetsmänniskor inom och utanför OWASP. Vill ni haka på? Bara ni kan ordna €590 till boende och mat plus en flygresa till Portugal så är ni välkomna. OWASP är som vanligt helt öppet – det är bara att dyka upp och göra sin röst hörd! Hör av er så hjälper jag till med det praktiska.

OWASP Sweden 2011
OK, jag har varit rätt slutkörd under hösten och inte mäktat med att fixa alla de där seminariekvällarna som vi vill ha. Men kraften börjar komma åter och tillsammans med mina co-leaders Mattias och Robert samt ledningsrådet så har vi några event på gång i närtid. Om allt går som jag vill så kör vi "HTTP-säkerhet" med undertecknad, Daniel "Haxx" Stenberg och Martin Holst-Swende på programmet i slutet av januari. Sen har vi kontaktat Mario Heiderich (typ bäst i världen på HTML5-säkerhet) och kommer flyga in honom februari/mars.

Vi kommer också att ta in ett par nya personer i ledningsrådet precis som lovat tidigare. Fundera på om du vill vara med och planera vad som ska hända framöver. Eller kanske din kollega?

Sist men inte minst så öppnar vi som första chapter dörrarna till en ny diskussionslista – OWASP Sweden Discuss. Där kan man skicka lästips, diskutera applikationssäkerhet, bjuda in till intressanta event och till och med skicka ut jobberbjudanden. Det enda vi inte vill ha där är reklam eller gnäll över särskilda leverantörer och varumärken. Anmäl er bums.


Med det så önskar jag och OWASP ett gott nytt år. Vi ses 2011!

måndag 20 december 2010

Hänglåset borta i FF4

Mozilla har tagit bort hänglåset som symbol för https i Firefox 4. Istället lanserar de en site identity button. Bra eller dåligt? Diskussionen går varm på mejlinglistor och bloggar.

Läs om det hela här:
https://support.mozilla.com/en-US/kb/Site%20Identity%20Button

fredag 17 december 2010

Book Injection (helt otroligt)

Böcker om hacking innehåller förstås ... elak kod. Så boken "XSS Attacks: Cross Site Scripting Exploits and Defense" innehåller förstås cross-site scripting-kod. Vad händer när amazon.com vill visa lite av innehållet i sådana böcker och glömmer att html-koda det hela? Det kan ni ta reda på genom följande enkla steg (inget farligt sker så vitt jag vet):

1. Logga in på amazon.com (man måste vara inloggad för att få söka i böcker)
2. Sök efter "XSS Attacks"
3. Boken ska dyka upp som första träff, välj den (eller om du är inloggad så klicka här direkt)
4. Klicka på "search inside this book"
5. Sök efter '1000' (utan fnuttar)
6. Hovra muspekaren över första sökträffen (sidan 28)

Eller läs om det hela på http://drwetter.eu/amazon/.

(Bloggpost 100 i år – tjoho!)

söndag 12 december 2010

CSRF via POST

Jag håller på att förbereda mig för en presentation på OWASP IBWAS'10 i veckan. En av sakerna jag tänkt visa är CSRF mot POST-metoder och det sessionslösa CSRF-skyddet "double submit".

CSRF
CSRF (cross-site request forgery) innebär att en attacksajt som lurar till sig icke ont anande surfare gör anrop in till en annan sajt och därigenom utnyttjar att offrets webbläsare automatiskt lägger till sessions-/autentiseringskakor i request:et. Det blir alltså ett legitimt anrop till servern utan att offret vet eller ser något.

CSRF mot GET
Normalt snackas det ju om CSRF mot GET-metoder. Dessa kan göras med enkla img-taggar, typ:

<img src="http://www.google.com/search?q=OWASP" border="0" height="0" width="0" />

Den taggen på attacksajten kommer alltså att göra en Google-sökning på "OWASP" med offrets Google-identitet och inget syns. Skälet till att detta fungerar är att bilder får hämtas cross-domain och att webbläsaren inte har en aning om att den URL:en inte kommer returnera en bild.

Men de flesta känsliga requesten är POST (eller PUT/DELETE i dessa REST-tider) och kan alltså inte anropas med en img-tagg. En riktig formulär-POST skickar ju dessutom inparametrar i request-kroppen och kan därför inte ha dem uppradade på URL:en som i fallet ovan med ?q=OWASP.

CSRF mot POST
Kan man då göra CSRF mot POST-metoder? Japp. Tänk er en URL owasp.org/ws/oneliners som tar emot enradskommentarer av användare autentiserade till owasp.org. Då skulle attacksajten kunna innehålla följande formulär:

<form id="target" method="POST" action="https://owasp.org/ws/oneliners" style="visibility:hidden">
<input type="text" value="I hate OWASP!" name="oneLiner"/>
<input type="submit" value="Go" />
</form>

... och sen har följande JavaScript, i det här fallet byggt på JQuery:

<script type="text/javascript">
$(document).ready(function() {
$('#target').submit();
});
</script>

... vilket innebär att så fort ett offer surfar in på attacksajten så postar han/hon "I hate OWASP!" till one liners-URL:en.

POST-CSRF mot Twitter?
Går denna attack att genomföra mot stora kommersiella tjänster? Ja, det har gått men tjänsteleverantörerna har lärt sig och implementerat skydd, ofta det så kallade double submit-skyddet.

Ett CSRF-formulär som twittrar åt offret skulle se ut så här:

<form id="target" method="POST" action="https://twitter.com/status/update" style="visibility:hidden">
<input type="text" value="74691c4d14f2c70d0936e2478fb09f68d532282" name="authenticity_token"/>
<input type="text" value="This was sent via POST CSRF" name="status"/>
<input type="text" value="true" name="twttr"/>
<input type="text" value="true" name="return_rendered_status"/>
<input type="text" value="" name="lat"/>
<input type="text" value="" name="lon"/>
<input type="text" value="" name="place_id"/>
<input type="text" value="false" name="display_coordinates"/>
<input type="submit" value="Go" />
</form>

Som ni ser så finns det en intressant parameter authenticity_token. Utan att ha avkodat Twitters alla cookies så förmodar jag att det är ett double submit-skydd. För varje request till Twitter-sidan så skickas en kaka med ett slumpgenererat värde med. För att en POST ska godkännas så ska denna kaka ha samma värde som POST-parametern authenticity_token. Eftersom attacksidan aldrig kan läsa offrets Twitter-kakor innan requestet så kan den heller inte inkludera en korrekt authenticity_token. Svaret från Twitter blir:

403 Forbidden: The server understood the request, but is refusing to fulfill it.

lördag 11 december 2010

Modern DoS för och emot Wikileaks

Wikileaks, #cablegate och hacktivism. Känsliga ämnen som jag undviker att ha en åsikt om, åtminstone med OWASP- eller konsulthatten på ;). Men det finns förstås en massa intressant säkerhetsteknik att titta på. I det här fallet belastningsattacker både för och emot Wikileaks (och Julian Assange).

De senaste två veckorna har världen i stort fått bekanta sig med två moderna former av denial-of-service – XerXeS och LOIC. Jag håller mig ju normalt till applikationslagret men det är klart att sånt här är intressant.

th3j35st3r (DoS emot)
Hacktivisten The Jester (th3j35t3r på Twitter) påpekade att hans/hennes belastningsattacker mot Wikileaks i samband med senaste släppet inte var en DDoS-attack, dvs inte en distribuerad belastningsattack med hjälp av zombie-datorer eller botnät:


Det var istället en DoS från en enda dator. Jag har alltid försökt skilja DoS och DDoS eftersom en bugg i ett protokoll, en webbserver eller en applikation kan möjliggöra en DoS-attack helt utan zombies.

The Jester – En hacktivist
The Jesters bio på Twitter lyder:
"Hacktivist for good. Obstructing the lines of communication for terrorists, sympathizers, fixers, facilitators, oppressive regimes and other general bad guys."

... och Jester omnämns typiskt "the infamous patriot hacker The Jester (th3j35t3r)".

Han (kan vara hon men hädanefter han) intervjuades av ethicalhack3r i somras. Mycket intressant att höra vad som driver en sådan här vigilant: http://www.ethicalhack3r.co.uk/security/interview-the-jester/

Jesters DoS-verktyg XerXeS
Så hur utför The Jester sina icke-distribuerade DoS-attacker? Jo, han har utvecklat ett verktyg kallat XerXeS. Jag fick tips av Pontus Engblom (tack!) om ett par videoklipp där Jester visar hur han mha XerXeS sänker två sajter han ogillar:


XerXeS DoS-attack från Infosec Island.


Nästa version av XerXeS från Infosec Island.

Att döma av dessa videoklipp så utnyttjar han buggar i webbservrar som Apache och IIS för att med en enda maskin sänka hela sajter.

XerXeS inspirerat av Slowloris?
RSnake och John Kinsella skrev ett verktyg kallat Slowloris som presenterades på Defcon 2009:



Slowloris gör partiella anrop till en webbserver och håller kopplingarna öppna, dvs avslutar inte anropet. Då och då fyller den på med nya HTTP-headrar för att hålla kopplingen öppen. På det viset konsumerar den sockets på servern. Över tid så kommer Slowloris få tag på fler och fler av webbserverns sockets och till slut tömma trådpoolen. Bam! Denial-of-service utan zombies. Pontus misstänker att XerXeS är byggt på Slowloris och jag håller med honom.

The Jester gripen?
Den 30 november så publicerade The Jester en bloggpost där han berättade att polisen har tagit sig in hos honom och beslagtagit hans utrustning och program vilket fanns beskrivet här:
http://www.th3j35t3r.net/2010/11/30/mondays-raid-search-and-seizure/

... men den sidan har tagits bort och går inte att komma åt via Googles cache heller. Oklart varför.


Low Orbit Ion Cannon, LOIC (DDoS för)
Belastningsattackerna för Wikileaks och Julian Assange (såsom de har tolkats i media i alla fall) har varit traditionella i bemärkelsen att de varit distribuerade, så kallade DDoS. Det moderna med dem har dock varit att de byggt på frivilligt deltagande mha systemet Low Orbit Ion Cannon, LOIC:


Du kan ställa in din LOIC att använda hivemind (ungefär flockbeteende) där du upplåter din LOIC till en central administratör och på så sätt kan ingå i distribuerade attacker. Din maskin kommer då att på administratörens begäran skicka en flod HTTP-, TCP- och UDP-anrop till offret och tillsammans blir det för mycket. Gizmondo har en bra genomgång av LOIC.

LOIC finns tillgängligt för Windows, MacOS och Linux. Jag skulle dock råda er att kolla upp vilken version ni laddar ner eftersom det har funnits infekterade varianter ute. Självklart kan LOIC användas för belastnings-/lasttester mot egna sajter så jag ser det inte som ett verktyg skilt från fuzzers och liknande. Men snacket kring LOIC har starka drag av hacktivism. Ett exempel är följande YouTube-reklam för att delta i veckans attacker mot Visa/MasterCard:


(OBS, ovårdat språk och en uppmaning till hacktivism i en känslig fråga)



Vad leder detta till?
Vad leder denna nya tidens hacktivism till? Ptja, det är förstås både en fråga om det öppna, fria, halvanonyma Internet och en fråga om säkerhet. För hur man än ser på Wikileaks och de aktuella DoS-attackerna så har människan gått en lång, krokig väg fram till de rättssamhällen och demokratier som finns i den fysiska världen idag (låt vara alla de skavanker som fortfarande behöver rättas till). Motsvarande rättsäkerhet och demokrati finns ännu inte på nätet. Istället är det en ganska oigenomtränglig kamp mellan stater, storföretag och aktivister. Samtidigt blir mer och mer information tillgänglig på gott och ont (integritet vs information wants to be free).

Personligen hoppas jag åtminstone att få slippa "logga in" på Internet i framtiden.

tisdag 7 december 2010

WebSockets får stryk, stängs av i FF och Safari?

Det har uppstått problem med HTML5 WebSockets vilket har fått Mozilla och Apple att droppa det tills vidare, åtminstone i default-inställningarna för Firefox och Safari.

Mozilla: "Combining the impact of the risk with the fact that the protocol is going to evolve and invalidate any shipped implementation anyhow, we intend to disable by default our Websockets implementation for Firefox 4.0 via a new configuration item."
http://www.ietf.org/mail-archive/web/hybi/current/msg04986.html

Apple: "Given the security issues identified by the paper from Adam and company, we would even consider disabling WebSocket entirely in future releases until there is a more robust handshake."
http://www.ietf.org/mail-archive/web/hybi/current/msg04782.html

Problemen beskrivs i artikeln "Transparent Proxies: Threat or Menace?"
Sammanfattning: Browsers limit how web sites can access the network. Historically, the web platform has limited web sites to HTTP, but HTTP is inefficient for a number of applications—including chat and multiplayer games—for which raw socket access is more appropriate. Java, Flash Player, and HTML5 provide socket APIs to web sites, but we discover and experimentally verify attacks that exploit the interaction between these APIs and transparent proxies. Our attacks poison the proxy’s cache, causing all clients of the proxy to receive malicious content supplied by the attacker. We then propose a revised version of the HTML5 WebSocket handshake that resists these (and other) attacks.
http://www.adambarth.com/experimental/websocket.pdf

onsdag 1 december 2010

Ny intressant säkerhetsbok

Nu är den nya boken ...
Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-'
... här:


Den är på min önskelista för julen och på min att-läsa-lista för mellandagarna. Jag är bekant med författarna och de kan sina grejer.