Labels

vrijdag 30 december 2011

NFI ronselt mensen via sherlock.holmes.nl

Begin deze maand was het nog hip nieuws dat de Britse inlichtingendienst GCHQ mensen probeerde te ronselen door ze een code te laten kraken. Nu blijkt ons eigen NFI er ook zo'n soort strategie op na te houden.

Aangezien deze veroordeeld crimineel ook een project bij het NFI heeft gedaan (gevalletje figuurlijk werkverbod uitdelen, maar zelf lekker de vruchten plukken), zat ik laatst wat in mijn mail conversaties te pluizen. En mijn oog viel op iets grappigs.

Eenmaal dieper gravend in de manier waarop het NFI zijn mail afhandelt kwam ik namelijk bij deze mail server terecht: sherlock.holmes.nl -> 195.169.99.99. Mijn oog viel hier natuurlijk in eerste instantie op omdat het vooral een heel grappig domein is. Daarbij verwacht je van een serieuze instantie als het NFI niet snel dat ze zo'n domein naam gebruiken. Maar niets is minder waar.

Sterker nog, het domein holmes.nl is hét domein van de afdeling Digitale Technologie. En bezoeken we die website: http://www.holmes.nl. Juist! dan komen we op de vacature pagina van het NFI terecht.

Of het geheel serieus bedoeld is weet ik niet, want... zie onderstaande:

Ohja, hier slaat het NFI al zijn gevoelige informatie over misdaden op: https://nlbds.net
De afdeling intelligente data-analyse zoekt blijkbaar ook nog personeel: www.kecida.nl
En verder:
Statistieken: stats.holmes.nl
Downloads: downloads.holmes.nl
Repository: repository.holmes.nl
Verder durf ik niet te kijken. Wil oud en nieuw graag nog buiten kunnen mee maken.

dinsdag 27 december 2011

AnonymouSabu aka Xavier de Leon?

Could you call it remarkable when someone specifically remembers a local root exploit of more than 6 years ago? A local root exploit that doesn't mean any thing at the time of writing. (At least for us...)


It is what catched my eye during this conversation between @anonymouSabu and @mikko. In this tweet anonymouSabu mentions this exploit. Author of the exploit is Xavier de Leon, xavier@tigerteam.se.
The connection between Xavier the Leon has been long suggested and this tweet of anonymouSabu could just be adding value to the smokescreen that keeps him from getting arrested. But for the trained eye, this must be of great value and a serious suggestion pointing towards the identity of anonymouSabu.

But let's never forget anonymouSabu is smart, and aware of this suggestion.

donderdag 22 december 2011

Twitter.com serving wrong certificate

Here's a blog post about twitter serving the wrong certificate on one of its domain. This could be a classic example of a government sniffing username's and passwords with a compromised private key of the domain twitter.com. Although the whole set-up just suggests someone at twitter made a mistake.

The problem is with the domain https://fr.twitter.com. For some reason it popped-up in my time-line yesterday and I was automatically forwarded to it several times. I have no idea why, but apparently I'm not the only one, see the twitter search results: https://twitter.com/#!/search/fr.twitter.com
The domain is providing you with the certificate for the domain twitter.com and not, as it should in this case fr.twitter.com. See below the certificate fr.twitter.com is serving, note the issuer.

I have to mention this wouldn't have been notified by me if the certificate was a wildcard certificate for *.twitter.com because then the certificate would be valid, and I would have probably ignored it.
The domainname fr.twitter.com is resolving to 199.59.149.230, 199.59.149.198 and 199.59.148.82, while twitter.com is resolving to 199.59.148.10, 199.59.148.82 and 199.59.149.230. Both are within the TWITTER-NETWORK. But as we all know, governments can redirect any traffic if they want to.

Another funny thing is this: the ip adres 199.59.149.198 is also hosting this website: itgovportal.net. Visit that website and take a look. Is it just @sfkassab redirecting the traffic of his website?

Let's wait for twitter to respond.

UPDATE:
No response from twitter yet. But I've had a closer look.
There are 4 twitter DNS servers that serve the domains twitter.com and fr.twitter.com.
2 DNS servers (ns1.p34.dynect.net & ns4.p34.dynect.net) serve these records:
Name: twitter.com
Addresses: 199.59.149.230, 199.59.149.198, 199.59.148.82
Aliases: fr.twitter.com

And the other 2 (ns2.p34.dynect.net & ns3.p34.dynect.net) serve:
Name: twitter.com
Addresses: 199.59.148.10, 199.59.148.82, 199.59.149.230
Aliases: fr.twitter.com
That explains the IP difference I saw at first, and had rung my bells.

But then again, twitter shouldn't use that CNAME, because the SSL certificate is only valid for twitter.com. They should have used *.twitter.com instead. Or better delete (or auto forward) the usage of fr.twitter.com.

Another thing: I found out de.twitter.com is also a CNAME. So you would expect it to be country codes, but nl. uk. pl. es.twitter.com are no CNAME's.
de.twitter.com doesn't show up in the search results: https://twitter.com/#!/search/de.twitter.com
Like fr.twitter.com does show up by many users. Strange situation going on here.

The last thing I have to mention is the twitter DNS servers are operated by DynDNS.org. And DynDNS doesn't have such a good reputation regarding privacy, see this blog about that issue.
This basically means we can now link Twitter to DynDNS, FBI to DynDNS, Duqu ( kasperskychk.dyndns.org ) to DynDNS

woensdag 23 november 2011

Shockerend filmpje + heldendaad

2 bizarre filmpjes waarbij al mijn radartjes gaan tikken. Helaas om meerdere redenen. Allereerst het meest schokkende filmpje, geplaats op dumpert 28 July 2007:
http://www.dumpert.nl/mediabase/21936/d811ae5e/frenkie_wil_zichzelf_dood_hebben.html

Waarop volgend dit filmpje: (Kijken vanaf 0:53)

Je oren klapperen hierbij werkelijk alle kanten op. Bij mij zelfs zo erg dat de Peter R in mij naar boven komt. Is dit verhaal wel op feiten gebaseerd? Een pistool met maar 1 kogel? Wat is het nut daarvan? Een jochie dat direct op de agenten af stapt en vraagt of ze een kogel in hem willen plempen? Te bizar voor woorden en dus reden genoeg om een feiten check te doen betreffende dit smeuige verhaal. Na wat wikken en wegen bij de crew van dumpert en vooral het kastje naar de muur effect bleek er een wijze opa te zijn die zich nog iets van dit filmpje kon herinneren en het verhaal kon bevestigen.

Hoxha: aah, 2007! Lijkt zo vers door die lay. Volgens mij is daar wel verzoek ip en origineel van geweest door de 5-0.


In bovenstaand filmpje is Patricia van Dalen te zien. Zij is Forensisch Internet Specialist bij Politie Haaglanden. Mevrouw heeft werkelijk een helden daad verricht door uit eigen initiatief achter het betreffende filmpje aan te gaan. De situatie zoals zij deze omschrijft is extreem shockerend en mevrouw verdient werkelijk waar een aantal extreem dikke zoenen!

edit:
Om het verhaal af te sluiten. "Er is nu genoeg aandacht voor hem op een positieve manier" aldus Patricia.

donderdag 10 november 2011

Twitter data Rop Gonggrijp (Inclusief DM's) overhandigt aan FBI

Schokkend nieuws: De Iraanse overheid luisterd zijn burgers af. De wereld in rep en roer.

Echter wanneer de Amerikaanse overheid gegevens van zijn burgers wil opvragen wordt je als Amerikaans bedrijf daar simpel weg toe verplicht.
Zo bepaalde vandaag een Amerikaans rechter dat alle twitter data van de personen Rop Gonggrijp (NL), Jacob Appelbaum (NL) en Birgitta Jonsdottir moeten worden overhandigd aan het ministerie van Justitie. Hieronder vallen ook alle prive berichten die via dit medium zijn verstuurd. Gelukkig niet de inhoud, maar wel naar wie en de datum wanneer deze verzonden zijn.
Concrete verdenkingen richting deze personen zijn er niet. Deze data wordt slechts opgevraagd ten behoeve van het onderzoek naar de zogenaamde "Collateral Murder".
Van Wikipedia:
Te zien is dat elf Iraakse burgers gedood worden, onder hen twee medewerkers van persbureau Reuters: fotojournalist Namir Noor-Eldeen (22 jaar) en zijn chauffeur Saeed Chmagh (40 jaar). Na een tweede aanval kwam het totaal aantal dodelijke slachtoffers op achttien.
Soldaat Bradley Manning wordt verdacht van het lekken van deze video. De omstandigheden waarin Bradley wordt vast gehouden hebben inmiddels de internationale aandacht getrokken van onder andere Amnesty International. Welke vind dat Bradley "onmenselijk" behandelt wordt.

Duidelijk moet zijn dat de drie personen, ooit werkzaam voor WikiLeaks, geen enkele strafbare verdenkingen aan hun broek hebben. Zij hebben slechts geholpen bij het publiceren van de video. Het is dan ook bijzonder te noemen dat alle data van deze personen aan de Amerikaanse overheid moet worden overgedragen, en dit brengt zeker de vrijheid van meningsuiting in het geding.


Het enige dat Bradley heeft gedaan, is de wereld de waarheid vertellen.

woensdag 9 november 2011

Sysadmin aanbevelingen Patch tuesday November 2011 - Worm kansen

Microsoft heeft op patch Tuesday het lek MS11-083 – Critical gemeld: “Vulnerability in TCP/IP Could Allow Remote Code Execution”.

Momenteel zijn er geen meldingen van actief misbruik van dit lek. Maar omdat het Internet Storm Center deze vulnerabilty een exploit index van 2 heeft meegegeven is misbruik hiervan op korte termijn te verwachten. Daarbij heeft dit lek grote potentie een nieuwe ‘computerworm’ voort te brengen waarbij verspreiding van deze worm in snel tempo zal plaats vinden.

Hoewel Microsoft zelf verwacht niet binnen 30 dagen een goed functionerende exploit te zien is het aan te raden alle kritieke systemen op dit moment direct te updaten met KB2588516 en te herstarten.
Kritieke systemen zijn de systemen die mogelijk een toegangsbrug vormen met uw interne netwerk. Wanneer UDP verkeer op minimaal 1 gesloten poort is toegestaan is het systeem kwetsbaar. Het gaat hierbij om de nieuwere versies van Windows, te weten alle Vista en 2008 versies, zowel 32 als 64-bit systemen.

Het feit dat deze vulnerability, een groot aantal UDP pakketten nodig heeft en remote code executie toe laat, maakt het tot een gevaarlijk geheel. De remote code executie maakt het mogelijk een worm te creëren (Denk aan Conficker). En wanneer er een grote worm uitbraak zal plaats vinden zal deze extreem veel UDP pakketjes het internet op slingeren. Dit brengt -alle op internet aangesloten- systemen in gevaar door de kans op UDP flooding gevolgt door een Denial of Service. Tevens zou dit het internet als geheel in gevaar kunnen brengen door de mogelijk immense toename aan netwerk verkeer.

Ik raad iedereen aan bovenstaande patch zo snel mogelijk te installeren.
Hieronder de door Microsoft opgestelde Deployment Priority:

vrijdag 4 november 2011

KPN (Dutch CA) immediately stops issuing certificates after finding DDoS tools

Everybody knows the DigiNotar story.
Alot of the DigiNotar certificates were replaced by KPN by names of "Getronics PinkRoccade PKI Overheid". And now KPN finds DDoS tools on their webservers.

After the DigiNotar debacle and the move of DigiNotar's certificates to "Getronics PinkRoccade PKI Overheid" KPN decided to do some extra examination on their infrastructure. With the result of DDoS tools found on one of their webservers, dated back to 4 years ago.

At this moment KPN says they haven't found any traces -yet- on their production environment. (We all know what this means, do we?) But they cannot guarantee it's safety.

The finding of DDoS tools can be seen as a good thing. Since DDoS tools are often used by skiddo's, but it does mean someone had control over their webservers in a way nobody wants them to.


The question now is, how will Microsoft, Mozilla and Google respond to this.

vrijdag 21 oktober 2011

Why we cannot trust DynDNS.org

After we've got LulzSec's Recursion and Neuron arrested because HideMyAss easily cooperated with the FBI and handed them the exact log files that led to their arrest. We've now got DynDNS.

Below are some photo's from an FBI dossier. They show the close cooperation between the FBI and DynDNS. DynDNS logs every movement you make and will easily hand over any information requested by the FBI, without informing me, without informing it's customers, without any opposition.

Since Duqu uses a module that makes use of the services provided by DynDNS I decided to publish this information.
DynDNS is a beloved services within the RAT world.


Same goes for -as expected- Microsoft's hotmail services.

dinsdag 18 oktober 2011

Duqu, versie twee van CyberWar

Waar stuxnet de allereerste vorm van CyberWar bleek te zijn. Lijkt er nu een opvolger ten tonele te zijn verschenen. Genaamd: Duqu. Dit omdat bestandsnamen met de prefix "~DQ" gecreeërd worden.

Dit virus lijkt vooral op een RAT. Met als voornaamste doel intelligence verzamelen over grote Industrial Control Facilities. Je zou het dus kunnen beschouwen als een inlichtingen bron, om mogelijk in de toekomst dergelijke Industrial Control Facilities aan te kunnen vallen.

De code vertoont zeer grote gelijkenis met Stuxnet. Nu slingerd de decompilatie code van Stuxnet overal op internet rond. Echter zit er een verschil in de werkelijke source code en de decompilatie ervan. Deze personen lijken toegang te hebben tot de werkelijke source code. Een erg opmerkelijk feit. Stuxnet toonde aan van ongekend hoog niveau te zijn. Het is onmogelijk door een individu gecreëerd, alleen een staat lijkt hiertoe de capaciteit te bezitten. Zie mijn vorige blogs over Stuxnet.

Op dit moment is Duqu aangetroffen bij 2 bedrijven in Europa. Het lijkt hierbij te gaan om twee verschillende versies en slechts één hiervan is geanalyseerd. Opmerkelijk hieraan is dat het is aangetroffen bij Europese bedrijven. De twee verschillende versies hebben verschillende compilatie datums, en mogelijk is het virus dus in de loop der tijd aangepast.

Het virus gebruikt enkele drivers die gesigned zijn door een bedrijf in Taipei, Taiwan te weten C-media corporation. Inmiddels is dit certificaat ingetrokken. Het officieel signen van een dergelijke driver behoort zo goed als onmogelijk te zijn. En geeft daarom aan dat dit een 'serieus' virus is. Het certificaat is aangevraagd op 3 augustus 2009, en gebruikt SHA1. Wat aangeeft dat het niet mogelijk is dit cerificaat te vervalsen.
Waar RealTek uit Taiwan was gebruikt voor het signen van Stuxnet. Is C-media gebruikt voor Duqu, beide bedrijven liggen in Taiwan.

Duqu gebruikt een Command and Control server welke resolvde naar een ip adres 206.[DEL].97 in India. Tevens gebruikte het twee adressen om te controleren of het geinfecteerde systeem internet connectiviteit heeft. Als eerste resolvt het microsoft.com, maar ook gebruikte het kasperskychk.dyndns.org en verwachtte het dat dit adres resolvde naar het ip adres: 68.132.129.18 een server in Amerika. Echter was destijds dit adres niet geregistreerd bij dyndns. Dyndns.org is een gratis DNS dienst welke veel bij RAT's gebruikt wordt en door script kiddies, immers: gratis. Dyndns.org staat er ook om bekend dat ze zeer snel optreden bij vermoeden van misbruik, en accounts blokkeren. Dyndns.org staat er ook om bekend dat ze alle data loggen: login ip-adressen, email adressen en alle changes binnen de DNS configuratie. dyndns.org werkt nauw samen met de FBI en overhandigt zeer gemakkelijk gegevens aan deze organisatie. Het feit dat hetip-adres van de Command and Control server resolved naar een adres in India is frapant, evenals dat het gebruik van dyndns opzichzelf ook vreemd is. De gekozen naam bij dyndns is ook opvallen: kasperskychk.dyndns.org. Kasperskychk suggererende dat het een check is voor kaspersky. Een erg amateuristische misleiding in ieder geval.

Om te communiseren gebruikt Duqu een speciaal protocol. Wat het doet is informatie op zo'n manier verpakken dat het erop lijkt alsof er .jpg plaatjes over en weer worden verzonden. Dit wordt gedaan om firewalls en IDS systemen te misleiden. Of in ieder geval zo min mogelijk alarm bellen te laten afgaan.

Hieronder de reden waarom Stuxnet en Duqu mogelijk van dezelfde makers zijn.

zondag 25 september 2011

Anonymous beschikt over database gepensioneerde KLPDers

Hacker Goo door de bocht. De beste man heeft mij gecontact om te vertellen dat Anonymous beschikt over de database van de website vvg-klpd.nl (inmiddels offline).
Leuk een database van ex-klpd-ers zou je zeggen. Echter waren er wat opmerkelijke dingen aan de hand met deze database. Zo stonden hier de wachtwoorden in plaintext opgeslagen. En waren de bankrekening nummers keurig aan de personen gekoppeld.
Omdat ik Mister Goo niet meteen geloofde vroeg ik hem mij 1 regel bewijs te laten zien, en dit heeft hij dan ook gedaan. Waardoor ik kan bevestigen dat het klopt.

De hack is gedaan via een dood eenvoudige SQL injectie, en ik neem aan, gezien onderstaande tweet, al geruime tijd geleden.

Hieruit kunnen we verder opmaken dat de site direct daarna offline gehaalt is. De vraag is nu of de gebruikers ook ingelicht zijn over deze hack. Lijkt me wel zo fijn om te weten wanneer werkelijk al je gegevens mogelijk op straat liggen. Slingerd de discussie over de meldingsplicht weer lekker aan.

Fascinerend is het feit dat Anonymous heeft besloten deze gegevens niet via een pastebinntje publiekelijk te maken. Maar dat is misschien ook wel logisch na de 15 jaar cel die Cody Kretsinger aka Recursion staat te wachten nadat deze de gegevens van sony WEL publiekelijk maakte.

Goed, nu de Nederlandse tak van Anonymous in het bezit is van de gegevens van ex-klpders inclusief hun bankgegevens, kunnen ze waarschijnlijk allen snel samen koffie drinken.

vrijdag 23 september 2011

LulzSec Recursion gepakt via HideMyAss.com

Groot nieuws! Wederom is een LulzSec member opgepakt. In dit geval zou het gaan op Recursion, echte naam: Cody Kretsinger. Hij zou het brein zijn achter de Sony hack.

Verhaal is op dit moment dat Recursion een private VPN zou hebben geregistreerd bij HideMyAss.com onder de username "recursion" (HEUL SLIM!). Een site die "Protect your online privacy" als slogan heeft. Via deze VPN zou Sony gehacked zijn. De FBI heeft op zijn beurt bij HideMyAss.com aangeklopt en de gegevens opgevraagd welke HideMyAss.com keurig verstrekt heeft. Erg nasty en vervelend voor Recursion. Aangezien hij zich veilig waande via deze aangeboden "Protect your online *fail* privacy".

Nu is het natuurlijk behoorlijk nieuws dat een site die een dergelijke service aanbiedt zomaar ip-adressen/log gegevens/adres gegevens/ dan wel bankgegevens van zijn gebruikers aan de FBI verstrekt. Maar misschien is het nog wel belangrijker te weten dat er meer LulzSec members zijn die HideMyAss.com gebruikten als VPN. Zie hieronder een chatlog:
Jun 03 22:44:15 Neuron: Sabu: did we lose people?
Jun 03 23:28:15 storm: agreed
Jun 03 23:28:16 storm: did we?
Jun 03 23:31:10 Sabu: yeah
Jun 03 23:31:18 storm: who?
Jun 03 23:31:23 Sabu: recursion and devurandom quit respectfully
Jun 03 23:31:27 Sabu: saying they are not up for the heat
Jun 03 23:31:32 Sabu: you realize we smacked the fbi today
Jun 03 23:43:08 sabu: clean your box out, make sure any sensitive info you have encrypted on a usb stick
Jun 03 23:43:12 sabu: stay behind your vpn
Jun 03 23:43:16 sabu: from now on your vpn is your weapon
Jun 03 23:43:23 sabu: without your weapon you are nothing
Jun 03 23:43:30 sabu: without you it is notihng blah blah blah
Jun 03 23:43:34 neuron: haha
Jun 03 23:43:39 sabu: and dont do nothing we dont approve of
Jun 03 23:44:04 neuron: Alright right now.. My "hackbox" has 512 aes encryption on the entire harddrive
Jun 03 23:44:18 neuron: two passwords and truecrypt on info concerning anything hacking related
Jun 03 23:44:24 neuron: and my vpn is HideMyAss




Om nog even door te gaan over dit subject, verbaast het mij nog steeds dat het Nederlandse lid Joepie91 / 92 nog steeds niet is opgehaald voor een verhoortje. Nu is bekend dat deze jongen zich strikt binnen de regeltje van de arm der wet houdt. Maar hij blijft zo'n beetje als enige van de groep gespaard. Moge hij van geluk spreken!

zaterdag 17 september 2011

Kinderporno filter van LeaseWeb nuttig?

Geweldige promo stunt van LeaseWeb natuurlijk. Een kinderporno filter.
Ze schijnen als hoster nogal eens met kinderporno te maken hebben, en dat vinden ze niet leuk natuurlijk (logisch...). Enfin, perfect dat ze daar iets aan willen doen. Dus hoppa we regelen een filter in samenwerken met het KLPD. Ministertje erbij die de boel het start sein geeft. TOP!.... al die publiciteit.

Want zoals we van KPN inmiddels weten is Deep Packet Inspection helemaal niet toegestaan. Hoe lossen ze dat op bij LeaseWeb? De klant mag zelf bepalen of het filter aan staat of niet. Goed, nu zijn er vast vele pedo's die zeggen dat ze geen pedo zijn, maar een filter aan zetten om hun eigen bestanden te laten controleren. Nee, mijn instinct zegt dat een beetje pedo dat toch niet zo snel zal doen.

Websites waarbij het de bedoeling is kinderporno te plaatsen zullen dus sowieso niet slachtoffer van dit filter worden. Wie kunnen we hier dan wel mee opsporen?
Dat zullen mogelijk pubers zijn die kinderporno op websites pleuren om mensen te shockeren, zoals dat een gewoonte is op 4chan bijvoorbeeld. Daarbij houden 14 jarige pubers ook wel van plaatjes van de wat jongere meisjes, immers, meestal valt de mens op leeftijd genoten en niet altijd op GILFs. Papa van deze pubers kan dus nog wel eens de lul worden.
Verder is het natuurlijk wel handig voor bijvoorbeeld image upload sites die niet gedient zijn van dit soort plaatjes, maar dat is puur uit eigen belang. Niet omdat ze zo graag zien dat die pedo's gepakt worden.


De techniek erachter.
De exacte techniek is mij niet bekend. Maar wat ik begrijp is dat er een hash van een geupload plaatje wordt gemaakt, deze hash wordt richting een server van het KLPD gestuurd. Welke vervolgens antwoordt met JA, het is kinderporno. Of NEE, dit plaatje is mij niet bekend. Wanneer het antwoord JA is wordt ook nog even het ip-adres van de uploader door gestuurd naar Fox-IT, oftewel: meldpuntcybercrime.nl (zie mijn eerdere blogs).
Uit bovenstaande omschrijving kan ik alleen maar op maken dat het HTTP verkeer 'afgeluisterd' wordt. En daar zit dan al gelijk weer een zwakte. Immers, pedo's zijn heul handig met internet en die sturen hun plaatjes natuurlijk niet via HTTP. Daar hebben ze allerlei andere truckjes voor, zoals bijvoorbeeld HTTPS.
Uit het feit dat het ip-adres direct naar het meldpuntcybercrime.nl mee wordt gestuurd maak ik op dat het HTTP verkeer afgeluisterd wordt, immers uit zo'n pakketje kan je het ip-adres halen. Als dit zou gebeuren nadat bestanden verzonden via HTTPS en dus ontsleuteld heb je het gekoppelde ip-adres er niet meer bij. Kan wel uiteraard, maar dan moet je een ingewikkelde constructie opbouwen, een waarvan ik denk dat de klanten van LeaseWeb zeggen: "laat maar zitten dat filter".

Neemt niet weg dat dit natuurlijk een mooi initiatief is. Perfect idee, database die bij KLPD draait, HTTP request en je weet meteen of een plaatje bekend is bij politie of niet. Eigenlijk zouden ze sowieso een programma moeten opstarten om deze techniek bij meerdere bedrijven toe te passen. Hopen dat het ip-adres van de database server niet uitlekt, de server niet gehacked wordt, nog dat pedo's er op welke manier dan ook hun voordeel mee kunnen doen.
Jammer is het gewoon dat de Nederlandse wet het op dit moment niet toestaat dit soort projecten op grote schaal te implementeren.

zaterdag 3 september 2011

Karma voor de Nederlandse overheid #DigiNotar

Even een in mijn ogen heerlijk blogje over het gevoerde beleid van de overheid.

24 augustus heeft de Nederlandse overheid 5 hackers veroordeelt tot voorwaardelijke gevangenis straffen van 3 maanden voorwaardelijk. Hiermee zorgende dat deze 5 personen vrijwel zeker nooit meer terecht kunnen in de security/beveiliging wereld evenals werken voor de overheid. Immers zijn er strikte screenings procedures welke door gespecialiseerde bedrijven worden uitgevoerd en een eventueel strafblad komt hierbij altijd naar boven. Een punt achter de carrière in de security/beveiliging industrie of een emigratie naar een ander land is de enige optie die de overheid hen biedt.
Opmerkelijk is het dan ook wel te noemen dat juist 1 van deze hackers met het eerste Nederlandse berichtje over de vervalste certificaten van *.google.com komt.
Hackers zien blijkbaar wel direct in welk gevaar bepaalde dingen vormen. Daar kan de overheid zelf nog wat van leren...

Snijdt de overheid zichzelf nu niet in de vingers? Karma?

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.

zondag 31 juli 2011

HBGary, ManTech, Vitrociset en nu Fox-IT

Oorlog tussen de white hats en blackhats, zoals ze zichzelf graag noemen.
Het begon met HBGary, het bedrijfje dat diensten voor de FBI verleende. De CEO van het bedrijf beweerde te zijn geïnfiltreerd in het collectief Anonymous en beweerde de leiders te kennen. Kort daarop werd HBGary zelf plat gehacked en kwam er allerlei informatie over het bedrijf naar buiten.
Deze 'hack' wordt door de hackers zelf als een van hun trofeeën gezien, en heeft hen veel plezier bezorgt.

De afgelopen periode zijn er aardig wat leden van 'AntiSec' dan wel Anonymous opgepakt, op die arrestaties lijkt Anonymous te reageren met het 'terug' hacken van deze organisaties. Hierdoor zijn recentelijk ManTech gehackt en Vitrociset, de Italiaanse variant van HBGary.
Gek genoeg hebben we in Nederland een situatie die een exacte copy lijkt van het HBGary verhaal. Er verschijnt een nieuws bericht van het om, waarin uit de doeken wordt gedaan dat het men geinfiltreerd is in de chat kanalen, en er wordt in vermeld in samen werking met welk bedrijfje dit gedaan is, te weten: Fox-IT. Misschien goed voor de naams bekendheid van Fox-IT maar een erg slimme actie lijkt het me niet. Ik zou het bijna willen betitelen als uitlokking.
Enfin, dat Fox-IT op de lijst staat moge duidelijk zijn gezien deze releases van Anonymous.
Fox-IT neemt mijns inziens een ongekend risico, daar ze sowieso met een 1 - 0 achterstand starten en alles te hacken is. Welk bedrijf dan ook, er werken mensen, en mensen maken fouten.
Door een vorige post van mij over dit bedrijf, en de bijbehorende log gegevens kan ik concluderen dat Fox-IT'ers ook maar gewone mensen zijn. Ze klikken nog wel eens op links waarvan ze de bestemming/afkomst niet weten. Ik zal geen namen noemen verder. ;) Enfin, een simpele 0day exploit erbij en de informatie stroomt binnen (om maar even een mogelijkheid te noemen).

Dat de motoren op volle toeren draaien mogelijk duidelijk zijn gezien enkele sinds korte tijd geregistreerde domeinnamen, te weten:
http://korpslandelijkepolitiediensten.nl/

Op dit moment lijkt er nog niets gehacked te zijn en speelt Anonymous op het misselijk makende persoonlijke vak, door een soort van intimidatie. We zullen zien wat de toekomst ons brengt, ik vrees voor het ergste.

woensdag 27 juli 2011

De vergeten harde schijven van AntiSecNL

Harde schijven
Enkele opmerkelijk feiten. De gearresteerd hacker Time, welke tegenover tweakers.net beweerde AntiSec te willen oprollen heeft nog enkele spullen bij hem thuis gevonden:

Beeldschermen, toetsenborden, kasten én hardeschijven. Die harde schijven zijn interessant, aangezien deze data kunnen bevatten. Belastende data. Het zou een extreem grote fail zijn als politie deze zou laten liggen. Maar is dit wel het geval in deze situatie?

BlackBerry
Een ander opmerkelijk feit is dat verdachte Time tijdens zijn arrestatie, gedurende de gehele periode dat hij in detentie heeft verkeerd, de beschikking had over zijn BlackBerry mobiele telefoon. Dit is normaal gesproken absoluut verboden.

Personalia
Daarbij komt dat Time de jongste van het stel is. Direct naar de media is gestapt. Direct weer overal 'on the webs' is verschenen is. Getuige zijn verschijningen op Skype en de AnonOps chat kanalen. Echter praat hij overal iedereen naar de mond, en komt er geen duidelijk kloppend verhaal naar voren.
Politie zal ongetwijfeld snel een analyse van de persoon Time gemaakt hebben. En mogelijk om die reden juíst Time deze 'privileges' gegeven hebben. De vraag is wat het belang hiervan is? het onderzoek?

Mogelijke verklaringen
De harde schijven zouden mogelijk een rootkit kunnen bevatten.
De harde schijven zijn wellicht al gebackupped -en dus secured-.
De BlackBerry bevat mogelijk een backdoor.
Een ander opmerkelijk iets is dat Time de dag na zijn arrestatie een afspraak had staan met enkele andere AnonOps leden. Deze afspraak is gemaakt via IRC, en dus zou het Team High Tech Crime hiervan op de hoogte moeten zijn, aangezien zij in dit kanaal waren geinfiltreerd. Wouden ze hen ook arresteren? Hoe zit het met het collusie gevaar?

Ik kan uit deze opmerkelijke gebeurtenissen maar één conclusie trekken. Dit cirkeltje is nog niet rond.
See you in court!

ps: Time, mooie Nikon D70.

vrijdag 22 juli 2011

meldpuntcybercrime.nl uitbesteed aan commerciële partij

Even wat fascinerende feiten op een rijtje in deze blog post.
Met het Meldpunt Cybercrime wordt veel geshowt de laatste tijd, en zelfs geadverteerd op google.
Prachtige disclaimer hebben ze om vertrouwen te wekken:
We hebben hier keurig te maken met de overheid, immers politie logotje links boven. Maar ondertussen wordt de server gewoon gehost in dezelfde range als de Fox-IT webserver.
83.96.129.55 - www.meldpuntcybercrime.nl
83.96.129.78 - www.fox-it.nl
Nu zegt dit in principe nog niets. Ware het niet dat de whois gegevens, dan wel deze pagina genoeg zeggen: https://control.meldpuntcybercrime.nl/

Even verder gaan over deze 'control' server (note: andere server dan www.meldpuntcybercrime.nl).
83.96.129.60 - control.meldpuntcybercrime.nl
83.96.129.55 - www.meldpuntcybercrime.nl
Een backend omgeving die aan het internet hangt (?!) om nog maar niet over de zwakheden betreffende het certificaat te beginnen.
En daar zouden dan al onze via de formulieren ingevoerde gegevens verwerkt dan wel bewaard worden. Immers, zo rolt een backend server.

Erg fijn dat de overheid hier nog duidelijk de regie heeft, wordt je vervolgens vakkundig door gesluisd naar Fox-IT. Vanwaar de overheid de regie kwijt raakt. Dat moet nog eens vetrouwen wekken!

De disclaimer praat keurig over Artikel 43 Wbp, zal allemaal wel, maar vertrouwen wekt het (bij mij) niet. Als crimineel zijnde is het natuurlijk een koud kunstje een 'concurrent' op te zetten, inclusief certificaatje, politie logotje, en meer dan genoeg formulieren om de concurrentie uit te schakelen.

Ik was altijd in de veronderstelling dat de overheid zo zijn eigen team specialisten had op dit gebied. Dat deze mannen mooie website kunnen bouwen is bekend. Maar wat kunnen ze nog meer?
Dit blog is verder puur bedoelt als constatering. Deze manier van werken wordt veel gebruikt door de overheid. Ik zet er dus alleen vraag tekens bij.

edit:
Fox-IT blijkt ook al flink betrokken bij het (oude) htcis.nl (High Tech Crime Initiatif Schiphol) check hier de gegevens:
Merk verder op dat het 80.126.72.50 een XS4ALL adresje is. Anyway, organisatie is al lang opgedoekt.
Enfin, Fox-IT doet het gewoon goed. En dit is blijkbaar de werkwijze van OM, so be it.

dinsdag 24 mei 2011

Whatsapp security weaknesses

The facts of whatsapp and all the drama.

In case of an iPhone if you open the Whatsapp application the following occurs:
- The application resolves sro.whatsapp.net.
- Gets the addresses 173.192.219.141, 173.192.219.149, 173.192.219.140 back from: ns1.softlayer.com
- An encrypted(!) connection is set up on port 443 with (in this case) 173.192.219.141.
Unfortunately I haven’t been able to perform a MITM attack to decrypt the data send between these two senders. So I don’t know what data is transported between them
- Through this encrypted(!) connection the ip-adres of the Whatsapp-chat servers is send, in this case: 50.22.227.220. Whatsapp uses the Extensible Messaging and Presence Protocol, but than it’s own version of it.
- From this moment on Whatsapp communicates via port 5222 met de Whatsapp XMPP-server 50.22.227.220. And simultaneously keeps the encrypted connection open. Remarkable about this is that al the messages send via the Whatsapp application are send without encryption over port 5222. In plaintext, as stated. The data transported contains sensitive data as names and corresponding telephone numbers are transported in plaintext as well.

For sending pictures Whatsapp uses mms.whatsapp.net and this time it does send the data encrypted.

The Android, Nokia and Blackberry way.
Above is the way the Whatsapp iPhone application works. The Android, Nokia and Blackberry applications work different. In their case Whatsapp does exactly the same, only difference is that instead of port 5222 it connects to port 443. People say this way Whatsapp suggests it uses an encrypted connection, since port 443 is mainly associated with encrypted HTTP traffic. If this is the case can be questioned, since they didn’t implement this way of connecting in the iPhone application it suggests that using port 443 on these devices has a good motivated reason.

We should not forget that encrypting your messages will make the application slower, the transport of the messages slower, and will eat your battery.
Despite that it is not necessary to transfer username and telephone numbers. Instead user-id’s and phone-id’s can be used.

Concerning these security weaknesses in Whatsapp, the application had another big flaw that allows account hijacking. For details on this subject see my previous blog: http://rickey-g.blogspot.com/2011/05/hijack-someone-elses-whatsapp-with-your.html
Since it possible to spoof sms messages, Whatsapp can fix this problem only by disabling all other verification methods other than sending a verification sms themselves.

zaterdag 21 mei 2011

Hijack Whatsapp with your iPhone

Hijack (someone else’s) Whatsapp with your iPhone
If you want to hijack someone else’s Whatsapp and receive messages addressed to that person with your iPhone, read on. (You don't have an iPhone? see bottom)

When you install Whatsapp on your iPhone, the Whatsapp application makes contact with the Whatsapp servers, and the Whatsapp servers will send you a verification sms with a code in it. Straight from that point a counter will start counting in the Whatsapp application. Within this time Whatsapp expects you to receive your verification SMS. If this period expires Whatsapp offers you several other authentication methods. (see below)
Here you choose for the option “SMS”. And you will have to fill in your email adress:
Your Phone will now start sending an SMS to the whatsapp servers for verification. You can cancel this, as it is not necessary.
What you’re going to do next is called SMS-spoofing. You can do this via many sites on the web. Choose one, and make up your fake SMS as shown in the picture below:
To: +447900347295
From: +(Country code)(mobile number)
Message: (your email adress)
That’s all! Within minutes you will receive the activation code in your email to activate whatsapp on your iPhone with someone else’s Telephone number, and from that moment on you will receive message’s addressed to that person on your iPhone.

The only way for Whatsapp to solve this issue is sending the verification SMS from their own servers and no other way.

If you have anything other than an iPhone your also able to Hijack someone else's Whatsapp. It's even easier for you.
All other systems will start sending an SMS verification immediately from your own mobile phone! So you disconnect your mobile phone, try to send the verification sms, which is impossible since you disconnected it. Check your outbox. There you will see the verification sms. Copy that whole sms to a website where you can spoof SMS. State the FROM field as the person's Whatsapp you want to hijack, and fill in your own mobile number in the TO field.
Thats it.

Whatsapp kapen met je iPhone

De filmpjes hoe je Whatsapp kan kapen met een Nokie N97 staan op internet. Hier is een beschrijving dit te doen met de iPhone.

Via de iPhone werkt het iets anders. Whatsapp heeft op de iPhone namelijk geen mogelijkheid smsjes te versturen vanaf jouw telefoon. Om die reden maakt Whatsapp connectie met de whatsapp-servers, en deze server versturen dan een sms naar jou toe.
Als je dus via de iPhone iemands Whatsapp wil overnemen krijgt de persoon die je overneemt sowieso een verificatie sms van Whatsapp. En wellicht wordt deze daardoor al wakker geschut. Een dader is echter verder niet te achterhalen. En het slachtoffer kan de nieuwe verificatie ook niet stopzetten. Succes verzekerd dus.

Op het moment dat je Whatsapp opnieuw installeerd vraagt Whatsapp om jouw telefoon nummer. Hier vul je het telefoon nummer in van het slachtoffer. Whatsapp verstuurd nu een sms vanaf de Whatsapp servers, deze komt dus aan bij het slachtoffer. Tegelijk gaat er een teller in jouw applicatie lopen waarbinnen je de sms met verificatie code zou moeten ontvangen en invoeren. Wacht tot deze tijd verstrijkt.
Als deze tijd is verstreken verschijnt onderstaand scherm:

Kies hier voor "sms". Nu moet je jouw email adres 2x invoeren.

Je iPhone gaat nu vanaf jouw toestel een smsje versturen. Het is verder niet nodig dat hij deze verstuurd, dit kan je dus gewoon cancellen.
Wat je nu gaat doen is je sms spoofen. Dit kan via vele sites. Kies er 1 naar wens en ga je gang. De sms die je moet opstellen moet er als volgt uitzien:


Ontvanger: +447900347295
Verzender: Telefoonnummer van je slachtoffer. LET OP: Altijd +316(nummer) gebruiken. Niet 06, dit herkend hij namelijk niet.
Bericht: (jouw e-mail adres)

Meer moet er niet instaan. Heb je dit gedaan zal je binnen enkele seconden in jouw emailbox de verificatie code ontvangen:

Vervolgens nog even je code in de whatsapp applicatie op je iPhone invoeren. En veel plezier!

Enige manier voor Whatsapp om dit te fixen is het verificatie smsje vanaf hun servers te verzenden, en niets anders.

dinsdag 17 mei 2011

Privacy en Whatsapp tegenover KPN en DPI

Laatste dagen is Whatsapp nogal in het nieuws gekomen door KPN die gebruik zou maken van DPI (Deep Packet Inspection) om het gebruik van Whatsapp inzichtbaar te maken. Dit omdat Whatsapp het gebruik van sms terugbrengt en dus ook de inkomsten voor KPN. Want, kort samen gevat: voor ieder smsje betaal je, en whatsapp valt binnen je internet bundel. Het is dus een dienst die door een andere dienst als 'extratje' wordt aangeboden, geheel gratis en misschien zelfs nog beter ook. Ik zou hierbij graag een ieder dit filmpje willen laten zien over: House party's die men ook ooit eens wou verbieden.

Wat alle rumoer heeft veroorzaakt is dat KPN DPI gebruikt heeft om dit verkeer in kaart te brengen. De privacy van de internet gebruikers zou zo geschonden worden en dit is onacceptabel. Over deze discussie ga ik het nu niet hebben, maar ik ga het wel even over de privacy hebben die Whatsapp ons zelf verder biedt.

Naar aanleiding van dit alles ben ik even de Whatsapp packetjes gaan inspecteren die het internet opgepompt worden door deze applicatie. Wellis waar een kort/om-te-schamen onderzoek, maar des al niet te min met een bijzondere uitkomst.
Een aantal dingen komen toch wel vrij snel aan het licht. En dat is dat alle Whatsapp berichtjes als plaintext worden verstuurd (lekker snel, dat wél), én dat bij deze berichtjes de telefoonnummers van de ontvangende partij, evenals de naam van deze contacten wordt verzonden. Ik heb zelfs vernomen dat Whatsapp je gehele adresboek copiert naar de Whatsapp servers, dit heb ik zelf nog niet kunnen waarnemen (Ik heb dit niet getest), maar dit kan zeker als voor 'waar' worden aangenomen.
Kanttekening hierbij is dat Whatsapp een Amerikaans bedrijf is. De servers van Whatsapp in Amerika staan. Ze worden gehost door The Planet Internet Services wat nu bekend staat als SoftLayer Technologies. En zoals te zien bij het plaatje visitors heeft Amerika hiermee weer een prachtig bedrijf in handen (+de gegevens van de gebruikers).
Maar genoeg d00m-denkerij hierover, ik lijk wel een echte g33k. Over naar de facts.

Even op een rijtje de facts van het verkeer:
- De applicatie resolved eerst sro.whatsapp.net.
- Krijgt de adressen 173.192.219.141, 173.192.219.149, 173.192.219.140 terug van ns1.softlayer.com
- Er wordt direct een SSL verbinding over port 443 opgezet met (in dit geval) 173.192.219.141.
Ik heb helaas geen MIM-attack gedaan dus ik weet niet welke info er over de SSL verbinding is verstuurd.
- Via deze niet af te luisteren verbinding komt blijkbaar het ip-adres door van de Whatsapp-chat server in dit geval 50.22.227.220. Whatsapp werkt via het zogenaamde Extensible Messaging and Presence Protocol, en daar dan een eigen afgeleide van.
- Vanaf dit moment gaat Whatsapp communiceren via port 5222 met de Whatsapp XMPP-server 50.22.227.220. Het opmerkelijke hieraan is dat Whatsapp dit doet ZONDER dat de verbinding versleutelt is. Dit houdt dus in feite in dat ieder station waar jouw berichtje langs komt kan lezen wat jij verstuurd, aan welk 06 nummer, en de naam van die persoon. Dit is in het bijzonder van belang bij draadloze netwerken, waar in feite iedereen zich op kan aanmelden. Ga je dus met je mobiel op een gratis wifi hotspot lekker zitten Whatsappen, kunnen we allemaal leuk meelezen, om vervolgens de persoon in kwestie nog even een belletje te geven. *nerd-fear*

Enfin, hier dan nog even de plaatjes als bewijs. Onderstaand screenshot geeft een weergave van een contact persoon waar naar toe ik een berichtje stuur. Bij ieder berichtje dat ik verstuur, verstuur ik dus het 06-nummer mee. Zoals je in het screenshot duidelijk kan zien stuur ik enkel de tekst "Test" naar deze persoon.

En in onderstaand screenshot is te zien dat Whatsapp mijn eigen contact gegevens, wederom onversleuteld, het internet opslingerd, dit inclusief mijn naam en mijn 06-nummer.

Een aantal andere conclusies kunnen we hier ook uit trekken. Als KPN de mensen wil gaan factureren per whatsapp berichtje zal KPN (zeer diepe) DPI moeten gebruiken. De applicatie Whatsapp staat in een constante verbinding met zijn servers en aan de hand van Source + Destination (makkelijkste manier) is niet te bepalen hoeveel berichtjes er via Whatsapp verstuurd zijn.
De enige manier van KPN om inzichtelijk te krijgen hoeveel Whatsapp berichtjes er verstuurd zijn dan wel ontvangen is via deze 'diepe' vorm van DPI waarbij de berichtjes daadwerkelijk ook gelezen worden. Het is mogelijk dat KPN dit invoert. Maaaarrrrrrrrrr, te verwachten is dat Whatsapp in de toekomst zijn diensten gaat aanbieden met een SSL functie (het is al verrassend dat zij dat nu nog niet doen), zoals gebruikelijk binnen het Jabber (XMPP) protocol.
Dan is het voor KPN zo goed als onmogelijk te bepalen hoeveel berichtjes een persoon verstuurd dan wel ontvangt. Men kan de applicatie een hele dag open hebben staan, zeer veel data gebruiken, maar geen enkel berichtje ontvangen of verzenden.

Feit blijft dat Whatsapp SMS gaat vervangen, vroeg of laat. Daar gaat KPN niets aan veranderen.
Zolang KPN mobiel internet aanbiedt zullen er eindeloos veel manier zijn om een tarifering te omzeilen. Deze zullen er ook zeker komen omdat het animo voor het gebruik van Whatsapp gewoon veel te groot is.
Als KPN nog schulden moet aflossen in verband met het aangelegd 3g netwerk zullen ze dat moeten verhalen op de klanten via verhoging van het tarief van de internet bundel (terecht!). Dat gaat niet lukken via het tariferen van specifieke applicaties als Whatsapp.
Als KPN meer inkomsten wil hebben om het personeel te kunnen blijven betalen zullen de kosten van alle bundels omhoog moeten gaan.

zaterdag 19 maart 2011

Helden, Fukushima's 50. of Fukushima's 180

180 zijn het er inmiddels. Echte helden. Van semi helden die hun zendtijd krijgen bij SBS shownieuws, weten we hun naam. Van deze echte helden.. weten we niets. Alleen dat ze er zijn, en dat ze bereidt zijn hun leven op te offeren.
750 werknemers telde de kerncentrale ten tijde van het begin van de catastrofe. 50 van hen is in eerste instantie gevraagd te blijven, 120 werden er aan toe gevoegd. Het zijn waarschijnlijk de oudste werknemers, degenen die zich niet meer zullen voortplanten, degenen die sowieso nog maar het kortste te leven hebben. Degene waarbij de straling zo min mogelijk blijvende schade kan aanrichten. Degene die het minst zullen lijden onder de straling. Degene waar we eigenlijk toch al afscheid van hebben genomen. Degene die... de geschiedenis in zullen gaan als échte helden.

Eén van de mannen stuurt een e-mail naar zijn vrouw: "Ik zal voorlopig niet terug keren." (Zie onderste youtube film)
Als er 62 Nederlanders dood gaan tijdens een vliegtuig ongeluk zenden we geen lachwekkende filmpjes meer uit. Over deze mannen horen we slechts sporadisch iets. Veel te weinig, ik voel me verplicht hen aandacht te geven. Daarom doe ik dat hier:

15 maart 2011, Fukushima, Japan.







En dan nog een klein plaatsje voor de liquidators van Tsjernobyl. De mannen die exact dezelfde taak als de Fukushima-50 hadden. Even grote helden, hopelijk minder grote verliezen.