Russische spionen die via YouTube communiceerden ontmaskerd.

Voor het eerst sinds het einde van de koude oorlog heeft Duitsland publiekelijk twee Russische spionnen ontmaskerd. De twee spionnen, een echtpaar codenamed Pit and Tina, echte namen Andreas and Heidrun Anschlag, ontvingen jaarlijks 100.000 Euro van hun geheime werkgever de SVR, het vroegere KGB. Ondanks onderhandelingen met de Russische regering zal de rechtszaak tegen hen doorgaan, dit omdat Rusland verstek heeft laten gaan tijdens onderhandelingen. Beide zijn in Oktober 2011 gearresteerd. Het rekruteren van Raymond Valentino Poeteray, een medewerker van het Nederlandse Ministerie van Buitenlandse Zaken, wordt beschouwd als hun grootste succes, hij verkocht hen top-secret NAVO documenten.

De woning van de verdachten in Marburg Michelbach.

Raymond Valentino Poeteray

Gehieme boodschappen via YouTube
Het echtpaar gebruikte onderandere YouTube accounts om te communiceren. Beide account zijn nog toegankelijk. De accounts lijken een voorliefde te hebben voor de voetballer Christiano Ronaldo en reageren alleen onder video's die veel bekeken worden en waar heel veel onder gereageerd wordt. Uit de reacties is op het eerste gezicht niet veel interessants op te maken, maar ongetwijfeld zullen de boodschappen ontcijfert moeten worden. Het account cristianofootballer plaatst telkens een lang bericht, het account Alpenkuh1 plaatst echter telkens maar 1 zin. Ondanks dat het echtpaar zich uitgaf als vluchtelingen met een Oostenrijks paspoort, gevlucht uit Zuid Amerika, heeft het account cristianofootballer als land "Rusland" en Alpenkuh1 als land "Duitsland". Dit is opvallend omdat het echtpaar tegen hun omgeving op geen enkele manier hun connectie met Rusland kenbaar maakte.
Wie is er in staat de geheime boodschappen te ontdekken?

Stembreker.nl de sleutel tot een coup!

Pats boem daar is G500, de nieuwe partij met leider Sywert van Lienden en zijn trouwe volgelingen die hevig worden geënthousiasmeerd door Sywerts jeugdige fanatisme. En hoewel er al jaren wordt gediscussieerd over digitale stemcomputers pleurt Sywert even een app online die gaat bepalen wat jij gaat stemmen!
En ja, dat allemaal via jouw browser thuis, via zijn app, in zijn database en via zijn algoritme dat even gaat bepalen wat jij moet gaan stemmen! Tja, vertrouwen, dat hebben we wel in Sywert.

Laat ik even dit als eerste zeggen, mensen als Sywert hebben we nodig. Daardoor maken we namelijk sprongen vooruit. Waar men al jaren discussieert over digitaal stemmen voert Sywert het gewoon even eigenhandig in. Gewoon, omdat hij het tijd daarvoor vind, en hij er zijn stemmen mee wint. Want waar vallen stemmen te winnen? Juist, achter dit beeldscherm waar deze lettertjes op verschijnen.

Enfin, you win some, you lose some. Hieronder de haken en ogen aan deze applicatie.

De applicatie gebruikt HTTPS verkeer, which is good! Echter verschuilt de applicatie zich achter CloudFlare (En is daardoor natuurlijk niet terug te vinden *kuch* *kuch* 31.*.103.144). Mooi spul dat CloudFlare, alleen voor een SSL oplossing biedt het slechts één mogelijkheid. En dat is een klassieke Man in the Middle oplossing. (Hieronder afgebeeld).

Het verkeer tussen CloudFlare en de Client wordt versleuteld, echter ontsleuteld CloudFlare het om de inhoud te kunnen bekijken. En dat is waar een probleem zich voordoet. CloudFlare heeft dus de beschikking tot álle data die via de applicatie verstuurd wordt, het kan deze inzien én manipuleren. Als CloudFlare het kan, dan kan de Amerikaanse overheid het helemaal, willen we zoiets?

Gelukkig loopt het verkeer vanaf CloudFlare richting de server in Nederland wel weer via SSL, de "Full SLL" optie die CloudFlare biedt, zoals hieronder te zien is:

Daarnaast is men 1 ding vergeten, en dat is dat de website ook gewoon bereikbaar is via poort 80, zonder SSL dus. Dit biedt uiteraard enkele handigheidjes om in te breken op de server, onder andere:

De webmail:

De phpMyAdmin:

En nog een webmail:

En nóg een webmail:

Daarnaast wordt het stemadvies met een smsje verstuurd. En een smsje kunnen we natuurlijk gewoon spoofen!

Dat er enigszins is nagedacht over de beveiliging moeten we natuurlijk niet vergeten, zo wordt er gebruik gemaakt van een telefoonnummer en een wachtwoord. Daarnaast verschijnt er een captcha, wat computer gestuurde registratie onmogelijk maakt (en laten we voor het gemaak de captcha oplossende chinezen even vergeten) als laatste moet een op het mobieltje verschenen code ter verificatie worden ingevoerd. Veiligheidsmaatregelen die een doel lijken te dienen.

Maar wat de ontwikkelaars dan precies met al deze pagina's aan het doen zijn? https://stembreker.nl/test.php
https://stembreker.nl/login_form/
https://stembreker.nl/export/
https://stembreker.nl/temp/
https://stembreker.nl/phpMyAdmin/changelog.php
https://stembreker.nl/heartbeat/
https://stembreker.nl/config/
https://stembreker.nl/advies/
En laten we deze maar helemaal vergeten:

Enfin, verstopt achter CloudFlare, dus hierbij de portscan van de server 31.*.103.144 wat natuurlijk 'gewoon' een random ip is... ;)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
53/tcp open domain
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
465/tcp closed smtps
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s

Nu is dit natuurlijk flink wat gebash tegen deze app. Maar dat maakt het hele idee niet minder interessant! Mensen als Sywert zijn een verrijking voor de samenleving, en zonder dit soort types blijven we compleet stil staan. Sywert, thumbs up!

Ps.
Ook props natuurlijk voor Paul, Richard en Daniel voor de mooie app!

Source code of Management System used for Dorifel/Citadel

I stopped publicizing my findings on the Dorifel/Citadel servers because most of my goals have been achieved and because people started messing with my findings. (Logging in on people's bank accounts, spoiling their privacy etc)

But since other company's are still on the hunt I'd like to share some interesting information with them.

Here's the source code of the management system. It manages the donkey/money mules, exploits, sellers, infections and browser versions.. It gives you an insight of the database structure and file structure, which can be of great value in further investigation.

Source code can be downloaded here. 

Complete details of the Dorifel servers, including its 'master' server in Austria

Below are my findings of the two servers used in the (targetted) attack mainly taking place in the Netherlands.

We have 2 server setups that are close to identical, their ip-adresses are:
184.22.103.202 (Domain: reslove-dns.com)
184.82.162.163 (Domains: 10ba.com, windows-update-server.com, wsef32asd1.org, dns-local.org)
Both are hosted within AS21788

From now on I consider both IP-adresses as one server. Or both IP-adresses as a proxy.

Both have the following ports open:

PORT      STATE    SERVICE              VERSION
22/tcp    open     ssh                  OpenSSH 5.5p1 Debian 6 (protocol 2.0)
80/tcp    open     http                 nginx 0.7.67
111/tcp   open     rpcbind (rpcbind V2) 2 (rpc #100000)
545/tcp   open     http                 Apache httpd 2.2.16
2407/tcp  open     http                 Apache httpd 2.2.3 ((CentOS))
2408/tcp  open     http                 Apache httpd 2.2.3
41666/tcp open     status (status V1)   1 (rpc #100024)

The SSH-keys are:
 | ssh-hostkey: 1024 c6:2f:e9:64:2c:ac:27:77:ed:da:60:a2:da:46:1f:fb (DSA)
 |_ 2048 e9:97:b5:d7:7d:01:f2:03:7b:9f:22:4c:a0:eb:a9:a5 (RSA)
Googling both of them brings up this page, prompting us with another IP-adres and domain name to investigate: 184.22.62.88 with the domain passget.com (date: 2011-10-26 04:22). This time SSH on port 222 is used instead of 22.

Directory listing of 184.22.103.202 and 184.82.162.163 (nginx/0.7.67 PHP/5.3.3-7+squeeze13):
/index/
/icons/
 |_/small/
/www/
 |_/images/
 |_/secure/ (Fragus login)
       |_/files/ (virus binaries)
               |_23 (Virustotal)
               |_24 (Virustotal)
               |_25 (Virustotal)
               |_26 (Virustotal)
               |_27 (Virustotal)
               |_28 (Virustotal)
               |_29 (Virustotal)
               |_30 (Virustotal)
               |_31 (Virustotal)
               |_32 (Virustotal)
       |_/templates/
               |_/english/ (Fragus login)
/web/
 |_/mak/
/doc/
/cgi-bin/
/img/
/uk/
/jump/
/ssl/
 |_ /milk/ (phpMyAdmin)
 |_/billk/
/bl/
/gl/
/ppp/ (password login)
 |_/css/
      |_/css/
      |_/ajax/
 |_/img/
 |_/data/
 |_/install/
      |_/install/
 |_/temp/
      |_/stat/
      |_/options/
      |_/temp/
      |_/config/
 |_/script/
      |_/script/
 |_/ppp/
      |_/bd/
      |_/card/
      |_/bot/
      |_/priv/
      |_/del/
      |_/c2txt2c/
      |_/virustxt/
      |_/govtxt/
      |_/xls/
      |_/searchform/
      |_/convertxtodvd/
      |_/intellitxt/
      |_/1txt1/
      |_/search_txt/
      |_/pictlogotxt110x60/
      |_/1txt2/
      |_/1txt3/
      |_/login_txt/
      |_/customnews_txt/
      |_/password_txt/
      |_/robots-txt/
/ver/
/vox/
/mak/
/server-status/

3 interesting finds here. Apparently Fragus is used for administratering the bots. Screenshot of the login:

phpMyAdmin is used with only 3 languages installed (en-US, en-UK, ru-RU), screenshot below:

And the last one is a login with only a password field, screenshot below:

A complete backup of the files can be found here: http://www.sendspace.com/file/ak8q2f
But please remember everything is full of virusses, so be carefull.

I will keep updating this blog.

Update 0:18:
Pretty fast after posting this blog both IP-adresses stopped displaying any html messages. Eventhough the servers themselves are still up. Which is an indiction of them just being proxies.

Update 2:12
Discovered that these 3 domains once pointed to this same server, google has some good cache pages:
handicaptaskprint.info (Registrated 10/7/2012) 149.154.154.47
intermediatedefragger.info (Registrated 26/7/2012) Undefined
onesizefitsallnik.info (Registrated 10/7/2012) 149.154.154.47

Here we have just one ip-adres 149.154.154.47 which once hosted the domain: lertionk13.be
This domain was registrated by: Elsakov Oleg using email adress thefirstweek@yandex.ru.
The name Elsakov Oleg points to yet another domain, bank-auth.org. Which has an A record pointing to: 158.255.211.28.
These 2 domains are connected to the "Police Trojan". More details here: http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp_police_trojan.pdf

If you look closely at the files and types of malware used by this gang, you'll see everything matches. They make the same directory listing mistakes over and over, and use exactly the same files. So this can be considered their fingerprint.

The gang registrated a certificate for https://bank-auth.org on the 1-8-2012. So they are probably planning to do something valuable with the website, which is running the default installation at the time being.

Update:
Oh well, I think we pretty close to the source now.
Lets get further into investigating this bank-auth.org domain. It resolves to: 158.255.211.28.
Once we investigate this machine further this is the first thing to pop-up: Apache/2.2.16 (Debian) Server at 158.255.211.28 Port 80.
That same Apache version with Debian again. I don't know why they use this version all the time, but one thing is for sure, they don't know nothing about directory listing, so I'm mirroring their site again....
And because this time I have ALL the logs, I'll make sure the right people receive them aswell!
I will upload a mirror of the site later. The admin passwords included.

I've made an online backup of the admin panel here, with all the original data.
This could be the IP-adress of the russian owner: 188.187.144.152. Not sure though. But this 'person' is also known as Ozgur Morkan and according to it's IBAN number he's from Turkey. If we look at this page we'll see the Russian IP-adres 188.187.144.152 involved in another kind of scam, this time the owner is known as Olga: http://www.anti-scam-forum.net/showFullThread_1288628426.htm

Further investigation reveals that the https://bank-auth.org domain with its valid certificate is used for the injection of malicious code within the victims browser. Several warning messages shows the criminals are no native speaking Dutchies:

Om technische redenen, het internet bankieren dienst is tijdelijk niet beschikbaar, gelieve in te loggen in 24 uur

Since the files found on the server are all in Dutch, the Dorifel compaign can be considered a targetted campaign against The Netherlands. Its a good example of the capabilities of Citadel, which was used to spread Dorifel.

Directory listing of https://bank-auth.org:

/
/index/
/cgi-bin/
/7/
/icons/
/www/
/p/
 |_dns.php
 |_ing.php
 |_ing2.php
 |_jys.php
/ca/
 |_/admin/
/javascript/
/inc/
/abc/
 |_inc.php
 |_sig1nl
 |_sig2nl
 |_sig3
 |_waitnl
/phpmyadmin/
 |_/themes/
/ing/
 |_inc.php
 |_tan1.txt
 |_wait
 |_wait.txt
/sns/
 |_WARNING.txt
 |_inc.php
 |_sig1
 |_sig1.txt.crypt
 |_sig2
 |_sig2.txt.crypt
 |_sig3
 |_sig3.txt.crypt
 |_wait
/abn/
 |_inc.php
 |_sig1
 |_sig2
 |_sig3
 |_wait

/rabo/
 |_WARNING.txt
 |_inc.php
 |_sig1
 |_sig1.txt.crypt
 |_sig2
 |_sig2.txt.crypt
 |_sig3
 |_sig3.txt.crypt
 |_wait

index.php
7.php
www.php
inc.php
sns.php
abn.php


ps.
I've been convicted for hacking already, never tried to steel a penny though. These guys have never been convicted. For me now it's very very hard in the security industry (Banks for example, is out of the question). Yet I stay on the right side. But thats probably because I'm such a bad bad boy!

Why I think the Linkedin password file is fake

Well first of all, there is no connection to LinkedIn other then the suspected 'hacker' saying it is from LinkedIn.

There are 6.5 Million unique passwords in the file! LinkedIn has approx 160 Million registrated members, this means approx 25 people share the same password on average. This could indeed be true.
But then it means the 'hacker' has posted the password list of -all- LinkedIn members. And still many people confirm their password is -not- on the list.
For 6.5 million unique LinkedIn password just to many people are denying their password is on the list.

What people at this stage are doing is identifying themselves with a hashed sha1 password file. But identifying yourself with a password is of no means reliable. Verifying yourself with a password is. But this means you would first have to tell your name, and afterwards a password comparison is done.

So whenever a match with your password is found on the list, this doesn't mean it's YOUR password. It just means someone or some bot ever printed out that same password. Maybe you should try googling your password. Chances are pretty big it will bring you at least one hit.

At this stage I don't know in what way the file is compiled. The only confirmation we can make at this point is that the file contains words that match a 'strong' password policy.

And let's not forget, the chances your 'strong' password is in a 6.5 Million unique password file are pretty big. And yet so many people confirm they are -not- on the list...

Please remember, you are NOT your password.

ps.
Do we really think LinkedIn uses SHA1? Haven't their security specialists heared of the HBGary and Rootkit.com hack? SHA1 + salt is even considered weak.

The passwords "WelcomeToLinkedIn" and "LeakedIn" are not on the list. Was there really nobody able to make up one of those?


/edit
Ok, seems like I'm wrong. LinkedIn just confired that at least a part of the hashes corresponds. It isn't a full confirm, but suggests one will come soon.

Those tweets confessed me:
https://twitter.com/mrkoot/status/210352495602581505
https://twitter.com/spruceNL/status/210418946770337792
https://twitter.com/mrkoot/status/210416085483266048

GemNet vergeet certificaat te revoken

Op 8 December 2011 kwam in het nieuws dat een server van GemNet gehackt is. Vervelend nieuws, vooral omdat GemNet een certificaat leverancier is. In een persbericht laat KPN het volgende weten:

Daarbij wil KPN graag gebruik maken van de kennis en expertise die hiermee geboden wordt. KPN hecht er belang aan om de dialoog aan te gaan, zodat mogelijke gevoeligheden in systemen boven tafel komen. Vooral zo kan gezamenlijk een grotere veiligheidswaarborg voor internetgebruikers worden bereikt en de dienstverlening verbeterd.

Om die reden deze blog post. Zo is mij namelijk informatie toegespeeld die doet concluderen dan KPN enkele steekjes heeft laten vallen tijdens de damage control. De server voor www.gemnet.nl is direct offline gehaald en die hebben we dan ook niet meer terug gezien. Het certificaat (hieronder de private key) voor "www.gemnet.nl" is direct revoked.

Echter is men vergeten goed naar de server configuratie te kijken. Het certificaat voor "webchat.gemnet.nl" (hieronder de private key afgebeelt) was namelijk ook op deze server aanwezig en is door in ieder geval één aanvaller buitgemaakt. KPN heeft nagelaten dit certificaat in te trekken, waardoor deze geruime tijd in de handen van tenminste één hacker is geweest. Gezien het feit dat er meerdere sporen van meerdere hackers zijn aangetroffen, is deze mogelijk zelfs in handen van meerdere hackers geweest.

Het in bezit hebben van de private key van een certificaat is niet direct een gevaar. Om een succesvolle aanval met dit certificaat uit te voeren zijn meerdere niet direct praktische omstandigheden nodig. Maar het is zeker mogelijk, en zeker de certificaten van een certificaat leverancier zijn hierbij van zéér hoge waarde.
Hieronder is in het kort gedemonstreerd hoe een mogelijke aanval plaats zou hebben kunnen vinden. Waarbij de gebruiker denkt met GemNet te communiceren, terwijl dit niet het geval is.
Er is gebruik gemaakt van het certificaat voor webchat.gemnet.nl.

Bij een aanval moet te allen tijde de DNS gemanipuleerd worden. Dit kan door een host file op een systeem aan te passen (makkelijkst), de DNS servers van GemNet te hacken (moeilijkst + meest gevaarlijk), via DNS cache poisoning (meest waarschijnlijk) of op alle andere mogelijke manieren waarbij een MitM attack kan worden uitgevoerd. In dit voorbeeld is de host file aangepast.
Het certificaat is op server 192.168.81.132 geïnstalleerd.
Bij het slachtoffer systeem is in de hostfile de volgende configuratie toegevoegd:
webchat.gemnet.nl         192.168.81.132
De gebruiker opent de pagina webchat.gemnet.nl, en het onderstaande scherm zal verschijnen:

Hieronder een Youtube filmpje van deze aanval:

Ik heb dit probleem bij het NCSC aangemeld en KPN heeft direct dezelfde dag nog dit certificaat revoked. Later is besloten hierover te berichten op de eigen website, waarvoor hulde - hulde - hulde.

Fuck up your Samsung TV

Inspired by all the awesome apps for Samsung TV's and by Luigi Auriemma his PoC to crash one. I started looking a little bit more to my own Samsung. Well a little bit more wasn't necesary at all. I quickly found that there is no filtering of any input at all and close to every string sent to the television will crash it. Here's an easy PoC for everyone at home.

Fire up your browser, enter the ip-adres of the Samsung TV with the correct TCP port: 55000, hit <enter>. Thats -seriously- enough to crash a Samsung TV. Have fun, don't forget to check out the wireless lan's at the pubs, bring your smartphone, but please don't spoil the games. ;) Any browser works.