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
måndag 20 december 2010
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!)
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.
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.
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
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.
Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-'
... här:
- http://www.net-security.org/secworld.php?id=10230 (om boken)
- http://www.amazon.com/exec/obidos/ASIN/1597496049/helpnetsecuri-20 (beställning)
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.
onsdag 17 november 2010
Phrack #67 ute
Kulttidningen Phrack Magazine har precis kommit i nytt nummer. Förra numret kom för 1,5 år sen. Håll till godo, #67:
http://phrack.org/issues.html?issue=67
http://phrack.org/issues.html?issue=67
Prenumerera på:
Inlägg (Atom)