Firesheep, så funkar det

Jag blev idag intervjuad av TV4-nyheterna om cookie-sniffaren Firesheep, en plug-in till Firefox som sniffar upp sessionskakor för populära tjänster på det nätverk man är kopplad till. Intervjun var med som ett inslag i 19-nyheterna också.

Installera och testa Firesheep
Det var lite trassel att få Firesheep att funka så jag tänkte jag postar det här för er som vill testa. Observera att jag inte går i god för programmet. Det kan visa sig vara en elak bakdörr.

1. Se till att du har Firefox 3.6.* och minst 3.6.10, t ex 3.6.11. Inte 4 beta om du inte vill experimentera.
2. Ladda hem Firesheep från GitHub.
3. Öppna xpi-filen med Firefox och installera.
4. Starta om Firefox om den kräver det.
5. Nu ska du ha en Firesheep-vy som en kolumn i vänsterkanten. Om inte så Visa -> Sidofält -> Firesheep.
6. Under Inställningar -> Sekretess: Stäng av ev privat surfningsläge, tillåt cookies och tilllåt tredjeparts-cookies.
7. Slå på Firesheep med knappen "Start Capturing".
8. Öppna en annan webbläsare, t ex Chrome.
9. Logga in på Facebook, Twitter eller Flickr i Chrome.
10. Kolla Firesheep-vyn i Firefox. Där ska dina olika konton ha dykt upp.
11. Dubbelklicka på något av dina konton i Firesheep och vips så har du genomfört en session hijacking.

Om du nu suttit på ett öppet trådlöst nät så hade alla andra aktiva sessioner dykt upp i din Firesheep-kolumn. Notera att det är olagligt att utnyttja andras sessioner utan tillstånd. Att avlyssna nätverket och titta på listan är dock helt OK.

Förkonfigurerade tjänster som Firesheep sniffar

Följande tjänster/domäner är förkonfigurerade i Firesheep:

• Amazon.com
• Basecamp
• bit.ly
• Cisco
• CNET
• Dropbox
• Enom
• Evernote
• Facebook
• Flickr
• Foursquare
• GitHub
• Google (dock ej GMail numer)
• Gowalla
• Hacker News
• Harvest
• Windows Live
• New York Times
• Pivotal Tracker
• ToorCon: San Diego
• Slicehost SliceManager
• tumblr.com
• Twitter
• Wordpress
• Yahoo
• Yelp

Den underliggande sårbarheten
Vad är då sårbarheten? Jo, tjänster såsom Facebook krypterar bara trafiken vid inloggning (ditt lösenord är alltså skyddat). Efter det så går Facebook tillbaka till okrypterad trafik. Din sessions-cookie är det som Facebook identifierar dig med efter inloggning och den skickas i klartext vid varje anrop till Facebook. Det är den trafiken som Firesheep avlyssnar och plockar upp sessions-info från.

Med din sessions-cookie i min webbläsare så är jag lika inloggad som du är.


PS.
Eftersom det valsat runt så mycket felaktig information så vill jag poängtera två saker:

1. Firesheep är en plugin till Firefox, dvs ett tilläggsprogram. Det hela handlar alltså inte om något säkerhetshål i Firefox. Det vore lika dumt som att påstå att Windows har problem för att någon skrivit en nätverksskanner som körs på Windows.
2. Offret kan surfa med valfri webbläsare – Safari, Internet Explorer, Opera, Firefox, Chrome och så vidare. Session hijacking med hjälp av cookies är inte begränsat till en viss webbläsare.

DS.

/John Wilander, chapter co-leader

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.