Labels

dinsdag 30 augustus 2011

Vals *.google.com certificaat uitgegeven.

Het lijkt erop dat de Nederlandse Certificate Autority diginotar.nl een vals/verkeerd certificaat voor het domein *.google.com heeft uitgegeven.
Hoewel in de gehele wereld hier niemand over klaagt gebeurt dit in Iran wel. Lees de volgende berichten op deze site: http://www.google.com/support/forum/p/gmail/thread?tid=2da6158b094b225a

Het lijkt er dus op dat de Iraanse overheid, en enkel de Iraanse overheid, voor gedurende slechts enkele uren even een 'ander' geldig certificaat van google.com online heeft gegooit om zo de nodige gegevens binnen te harken.
De reden dat bovenstaande gebruikers een foutmelding kregen is omdat zij Google Chrome gebruiken. Chrome gebruikt nog een andere manier om de certificaten te controleren, en gaf daarom de foutmelding, waarna deze gebruikers begonnen te klagen.

Inmiddels is het certificaat ingetrokken door Diginotar.nl op zijn CRL list. En schijnen de nodige mensen van Diginotar zelf in paniek te zijn.

In de tussen tijd heeft de Iraanse regering waarschijnlijk al een schat aan informatie buitgemaakt...

Ik zal proberen bovenstaand probleem in simpele woorden uit te leggen.
Op internet heb je een protocol wat ervoor zorgt dat je op een beveiligde manier met een andere partij kan communiceren. Dit zorgt ervoor dat wat jij verzend naar deze ontvangende partij alleen door deze partij kan worden gelezen, en dat wat de ontvangende partij naar jouw verstuurd alleen door jou gelezen kan worden.
De regels voor deze communicatie liggen er al, dit gaat namelijk via een public key, waarmee jij jouw gegevens encrypt en deze versleuteld naar de ontvangende partij verstuurd. Deze ontvangende partij heeft vervolgens een zogenaamde 'private' key waarmee hij deze gegevens weer kan ontsleutelen. Zo lang alleen de ontvangende partij deze sleutel bezit kan alleen de ontvangende partij deze gegevens lezen. Echter kan jij nooit weten of je nu rechtstreeks met de juiste ontvangende partij aan het praten bent, of dat je met iemand aan het praten bent die zich voordoet als deze ontvangende partij.
Om die reden zijn Certificate Autorithies in het leven geroepen. Kort gezegd vertrouwen wij allemaal deze partijen en zorgen deze partijen ervoor dat ze een zeer strikte regel geving hebben op het identificeren van hun klanten. Op dit moment, wanneer een Certificate Autorithy zegt dat een ontvangende partij de 'echte' is, gaan we daar ook maar gewoon vanuit.
Wat is nu het geval, als je in Iran naar een website met *.google.com surft, waaronder dus ook Gmail valt, zegt deze server "Vraag maar aan diginotar.nl of ik echt ben" het antwoord van diginotar is in dit geval "Ja *.google.com is de juiste persoon, ik vertrouw hem". En vervolgens begin jij al je vertrouwelijke informatie aan deze server te vertellen. Waaronder jouw email adres + jouw wachtwoord. Nadat je hebt ingelogd laat je deze server ook nog even al je mail lezen. En de Iraanse overheid is dus nu mogelijk in het bezit van al deze gegevens. En zoals je weet in Iran, kan dat in het slechtste geval je je kop kosten.

De aanval die hier gebruikt wordt is een Man-in-the-Middle attack. De aanvaller plaatst zichzelf tussen de 2 partijen, jij verstuurd jouw gegevens naar de Man-in-the-Middle, deze leest jouw gegevens en slaat ze op, en verstuurd vervolgens jouw gegevens door naar de ontvangende partij. De ontvangende partij verstuurd vervolgens het antwoord weer naar de Man-in-the-Middle, deze slaat weer alle gegevens op, en verstuurd het antwoord vervolgens ook weer door naar de ontvangende partij zodat deze totaal niets door heeft verder.

zaterdag 27 augustus 2011

Security zwakheden tweakers.net - UPDATED

Kleine uitdaging van @Schellevis. Zie zijn tweet:
En uiteraard lichtelijk geprikkeld door alle reacties onder de verscheidene - nieuws - berichten (chronologische volgorde) betreffende mijn persoon.

Even kort door de bocht enkele zwakheden binnen de security van tweakers.net.
Allereerst bij het creëren van een account op deze pagina kun je keurig je gewenste wachtwoord invullen. Hieraan zijn enkele eisen gesteld, copy/paste van tweakers: "Voorzie je wachtwoord van minimaal 8 karakters, waaronder in ieder geval één hoofdletter, één kleine letter en een cijfer of speciaal teken." Hier wordt actief op gecontroleerd. (Uhuuuu, kom hier nog op terug.) Echter wordt wanneer je op "registeren" klikt je wachtwoord in plaintext over poortje 80 gejaagd. Zie onderstaand screenshot, in dit geval, user:securityleak & pass:N13tt3sn1ff3n.

Vervolgens is tweakers niet de beroerdste om je nog even te herinneren aan je wachtwoord. En wel via email! Let wel, je wachtwoord, welke je mogelijk op meerdere websites gebruikt, wordt in plaintext in je mailbox geplaatst. Langs hoeveel hop's het mailtje gaat zullen we maar niet gaan tellen, en dat jij je mail direct uitleest via je mail client waarbij wederom talloze hops gepasseert worden slaan we ook even over. Feit blijft dat al deze stations jouw wachtwoord in plaintext voorbij zien komen. En dus makkelijk kunnen sniffen.
Voor een persoon met toegang tot jouw mailbox is het een koud kunstje om je wachtwoord tevoorschijn te halen, de search string "wachtwoord" voldoet. Et voila, het unencrypted wachtwoord welke je mogelijk nog op veel meer sites gebruikt verschijnt op het beeldscherm.


Enfin, je activeert je accountje, en begint met inloggen. De mogelijkheid om te kiezen voor "versleutel mijn wachtwoord" wordt geboden. TOP!. Echter wordt je wachtwoord lokaal gehashed en vervolgens onversleuteld wederom over poortje 80 verstuurd. Firesheep kan daar leuke dingen mee.
Deze hash bestaat uit een aantal waarden. Zo wordt als eerste de MD5 hash van je wachtwoord gebruikt, vervolgens wordt jouw username in kleine letters er tussen geplakt, waar vervolgens jouw SID achter geplakt wordt. Van deze 3 dingen samen wordt vervolgens weer een MD5 hash gegenereerd. Een voorbeeld met voor gedefinieerde waarden.
SID: 0_BwFXMBymUJxGj-GGc-20KvjpmZV1_I
PWD: password
UID: Arthy
md5(password) = 5f4dcc3b5aa765d61d8327deb882cf99
p = md5(md5(PWD) + lowercase(UID) + SID)
md5(5f4dcc3b5aa765d61d8327deb882cf99arthy0_BwFXMBymUJxGj-GGc-20KvjpmZV1_I) = 9aa0d7305d8d73da8d12e2628659f23c
Te zien in onderstaand screenshot.
Er wordt dus een samen gestelde hash richting de server van tweakers gestuurd. Goed gedaan, aangezien je uit deze hash niet de md5 hash van jouw wachtwoord kan destilleren.
Hieruit kunnen wij echter wel concluderen dat tweakers alle wachtwoorden van alle gebruikers in md5 opslaat in de database. Dat md5 inmiddels als niet meer veilig beschouwd kan worden lezen we in dit artikel van tweakers zelf. Misschien niet geheel relevant omdat het om wachtwoorden gaat. Maar een combinatie hash wordt in ieder geval niet in de database opgeslagen.
Mocht de tweakers database ooit eens gehacked worden en de MD5 hashen geleaked worden denk je misschien: "Ik ben veilig, heb geen common password en zo'n 30 karakters gebruikt." Then you WRONG! Immers, het "beveiligd" inloggen, gaat helemaal niet via jouw wachtwoord, maar via de HASH van jouw wachtwoord. Voor een aanvaller is het dus een peulenschil om de juiste login hash te creëren, daar is jouw gedecrypte wachtwoord helemaal niet voor nodig.


We gaan verder, (reeds ingelogd) terug naar deze pagina: http://tweakers.net/my.tnet/account#tab:account
En gaan we ons wachtwoord aanpassen. We zien de tekst: "Voorzie je wachtwoord van minimaal 8 karakters, waaronder in ieder geval één hoofdletter, één kleine letter en een cijfer of speciaal teken." nogmaals staan. Maar zo stout als we zijn voeren we even de volgende string in: "password". En zoals tweakers al goed aangeeft, kwaliteit: zwak

"Ach het is maar tekst", denk ik als gebruiker. En we passen ons wachtwoordje aan! Met succes, want controle op het wachtwoord wordt er deze keer niet uitgevoerd. Pakken we nog even ons sniffertje erbij en zien we wederom keurig ons oude wachtwoord inclusief nieuwe wachtwoord voorbij komen. Errug handig!

Waarom tweakers.net überhaupt de optie biedt je wachtwoord in plaintext te versturen op de inlog pagina is me geheel onduidelijk. Aangezien het inloggen met een versleuteld wachtwoord even snel en even gecompliceerd is als wanneer je dat niet doet. Vaak bieden sites dergelijke opties wanneer de versleuteling plaats vind door het opzetten van een HTTPS verbinding, en soms HTTPS geblokkeerd wordt of in ieder geval problemen kan geven. Echter is dat hier niet het geval omdat de communicatie altijd over poort 80 gaat. Javascript die dermate oud is dat het een md5 hash niet aan kan ben ik nog niet tegen gekomen..

Tot zo ver het member gedeelte.

ps.
Het zijn kleine dingen, maar voor een tweakerttt...

UPDATE

Even nog enkele minuutjes hier aan gewijdt. En de volgende aspecten ontbreken ook nog binnen de website van Tweakers.net:
- X-Frame Options om ClickJacking tegen te gaan. De opties DENY en SAMEORIGIN kunnen worden toegevoegd. Sinds IE8 is dit mogelijk.
- HttpOnly flags tegen Cross Site Scripting. Sinds 2002 beschikbaar in IE6 SP1.

Ik laat het hierbij.

zaterdag 20 augustus 2011

Steganografie hidden message, who dares?

Al enige tijd is dit mijn twitter avatar:
De naam zegt het al "hiddenmsg" Er zit een bestand in verstopt met een verborgen berichtje.
Nee geen shellcode of iets dergelijks, maar dat had zomaar gekund.
Eigenlijk had ik wel verwacht dat iemand er redelijk snel achter zou komen. Daar de gebruikte technieken een combinatie zijn van redelijk simpele technieken.
Steganografie in combinatie met (soort van) cryptografie, standaard technieken, dus ik heb niets zelf verzonnen. Doe ik dat, wordt het natuurlijk alleen maar nóg lastiger.

Bovenstaande technieken vormen een grote bedreiging in de bestrijding van kinderporno. Een browser ontwikkeld door pedofielen welke prachtig ogende websites omtovert tot kinderporno paradijzen. Het zou zomaar kunnen.

Who dares?

woensdag 3 augustus 2011

De totale vernedering: Vitrociset.it

Ik ga er geen woorden aan vuil maken, het plaatje zegt genoeg:

Hoop dat Fox-IT gespaard blijft.