I recently worked a fair bit with some of the new features in HTML5. If you haven’t played with them yet please don’t get your hopes up. Although a standards sounds nice, the implementation by all the browsers is appalling. </html5-rant>

Anyway, during development I stumbled upon the ‘postMessage’ function. In short, ‘postMessage’ allows you to send messages between frames even if they are hosted on different domains. The function itself is incredibly easy and very useful. Every browser supports sending a ‘string’ to the other frame. A message is send using <target-frame>.postMessage(, ). The target frame defines (or hooks) the ‘onmessage’ event. ‘postMessage’ will only send the message to the defined frame if the domain name is equal to the one defined in ‘targetOrigin’ unless a wildcard is used. Its possible some developers will use this function incorrectly and transfer sensitive data between frames. I also think that some developers will set the targetOrigin to a wildcard. This is usually not a problem unless – in a worst case scenario – the post messaging system is used to comunicate back and forth between two frames. I think it should be possible to exploit this in some cases by taking control over the messages that are being exchanged between two frames. Unfortunately I don’t have a real life example – and i’m to lazy to build one – so if you find one, please do share.

Apart form the possible vulnerabilities that could occur while using postMessage, post messages are a pain in the ass to debug. So I create a small Chrome plugin that will notify you – via an icon in your address bar (see fig. 1) – if HTML5 post messages are received on the current page. All received messages will be printed to the console (using console.log) when this happens.

html5detect

Fig 1. Chrome address bar when a post message has been detected

The plugin is very basic – I created it in about an hour – but very useful when developing web applications or simply looking for juicy bits on a website.

Github: https://github.com/damnsecure/html5detect

Cheers, Ruben.

For the last few weeks I’ve been working on a security plugin for WordPress called iDapt. The plugin is still under heavy development but I wanted to do a quick write up on what I’m currently working on.

Small into: the upcoming plugin is a plugin that everybody should be able to install and use. One of the core requirements from the start has been that even if you don’t own your own server or have deep computer/security knowledge you’re still able to use the plugin and understand the defense mechanisms. Since, most detection can be done in more advanced way’s I wanted to create a piece of software that is easy to use and install yet powerful enough to detect attackers even within (possibly) their information-gathering stage.

I’m implementing a few methods to detect (possible) attackers. There are three that I would like to write about.

Blocking (in)valid logins the cool way

The first simple feature that I’m working on is a way of dealing with the insane amount of login attempts that is allowed in WordPress. WordPress does not offer a lockout functionality after a certain amount of failed login attempts. WordPress does not offer any type of notification on brute force attacks on accounts. In a nutshell, WordPress does not offer any type of protection against the brute force login attacks that take place every single day. Since I’ve seen around 3000 unique IP’s trying to find their way into my admin account in the last week I figured its time for a decent solutions.

wordpress-attacks Fig 1. Geo location of last weeks attacks (~14 may 2013 until 21 may 2013)

Since we see so many unique IP’s it is nearly impossible to base invalid logins on IP’s. Although iDapt will still process these activities preventing them is kinda difficult. Therefore the simple solution is as follows: after a X amount of failed login attempts the user account will be blocked not allowing any logins from any IP. An email will be send to the owner of the account allowing the owner to unblock the account so they can log in. This might sound like a hassle but lets be honest here, how many people do not have email within reach these days?

An other method that will be used to block these high volume login attacks is by using central violation logging.

Central violation logging

Ok, this is not really new. But I just want to write about it because its one of the cooler features I think. A lot of attackers these days’ use a high amount of proxies. This makes blocking them quite difficult if you are an individual trying to block based on a violation count per IP. Example: you get 100 logins on your personal account via 100 proxies. In a normal brute-force detection plugin this will be logged as 100 separate login attempts, thus not blocking anyone. But the attacker just had 100 login attempts. This single event is not worth much. But it is very likely the attacker will move on to another blog. If this data is logged at a central location we can detected that now one IP has tried to login 2 times on 2 different blogs. Get where I’m going? So the more people who are going to use iDapt the faster attacks will be blocked by detecting these attack patterns. I hope the name iDapt makes a bit more sense now ;)

Honeyfiles, a theory on protecting against vulnerability scanners

This is a theory I have – well, probably somebody else came up with it before me – is to create a ‘honey file’. This is a file that sits on your web server and triggers an alert when visited. Its important that this file is not approached by users that are using your blog/website like they should. Instead, I actually only want dodgy crawlers to find this file. I know that legit crawlers will obey my robots.txt – if they don’t, I don’t think they can be called legit. So if I print the link on my page:

potato

The link is now “invisible” to the user. The only one who will find this link is a non-legit (is that even a word?) crawlers or people poking around. In any case, I would like to know. Just to make sure it won’t be visited by legit bots I add the following to my robots.txt file:

User-agent: * Disallow: {file}.php

Now, this is just a theory and I have no proof if this works yet. But I see no real reason why not.

Anyway, that is what I’m working on. In case you are interested in becoming one of the first testers please give me a buzz so we can talk.

Cheers, Ruben.

Today no security post but a post on how to configure your apache server so you can easily add and remove subdomains. The reason I’m doing this post is because it took me a while to find the correct configuration and I don’t want you all to go through the same effort if I can just as easily share what I found (yay! free information!)

Ok here we go. What I wanted is the follwowing: I have a domain – lets say potatojuice.com – and I want my apache server to process requests for this domain. But! I also want to be able to setup subdomains easily without going into my VirtualHost config all the time. So, what I want is my web directory /var/www/potatojuice.com/ to contain all the possible subdomains. By default it alway’s contains the directory www. If I need a subdomain I easily create a new directory called ‘i-like’ and the subdomain i-like-potatojuice.com is redirected to load the content from /var/www/potatojuice.com/i-like

My virtual host looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<VirtualHost *:80>
    ServerAdmin admin@potatojuice.com
    ServerName potatojuice.com
    ServerAlias *.potatojuice.com
    DocumentRoot /var/www/potatojuice.com

    RewriteEngine on 
    Redirect permanent / http://www.potatojuice.com # Set the default subdomain 
    RewriteCond %{HTTP_HOST} ^([^\.]+)\.potatojuice\.com # URL needs to have a subdomain
    RewriteCond /var/www/potatojuice.com/%1 -d # Select content directory
    RewriteRule ^(.*) /%1/$1 [L] # Rewrite

    <Directory /var/www/potatojuice>
        AllowOverride all
        Order deny,allow
        Allow from all
        Options -MultiViews -Indexes FollowSymLinks
    </Directory>
    ErrorLog /var/log/apache2/error.log

    # Possible values include: debug, info, notice, warn, error, crit, alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
</VirtualHost>

This allows you to just create a new directory in /var/www/potatojuice/. This subdir is from now on a subdomain on your website. Easy as that. Hope this is something you needed or where looking for.

Hugs, Ruben.

PS: I’m no sys admin so in case you see ‘misconfiguration’ or incorrect comments next to the rewrite rules please leave a message so I can update the post.

Tweerex had a small update today. It was mainly just a major code cleanup where I removed useless output and the very bloated way of defining and reading/printing regexes. See the CHANGELOG and code for more info on what happend.

Current release is available via github: https://github.com/damnsecure/Tweerex

Cheers, Ruben.

We have all seen blog posts about the most frequent passwords, the most popular, and the worst. But, I figured, I haven’t read a post that actually describes the passwords we are choosing. What do we use? Are they complex? How are they constructed? I realized that over the last few years I collected about ~3 million passwords – I know there are people out there with way more, so if you like to contribute feel free to shoot me an email so I have more data to work with for analysis.

I decided to run ‘pipal’ (great tool: https://github.com/digininja/pipal) over this list of unique passwords (took quite a while). Pipal is a great tool to get most of the interesting statistics I wanted. Below you’ll find the results. Most of them are pretty straight forward, although some a quite interesting.

Total amount of passwords analyzed:

Total entries = 3.276.063
Total unique entries = 3.276.023

Password length (count ordered)

8 = 843068 (25.73%)
9 = 606576 (18.52%)
10 = 549104 (16.76%)
11 = 278862 (8.51%)
7 = 270189 (8.25%)
6 = 263599 (8.05%)
12 = 176808 (5.4%)
13 = 101304 (3.09%)
14 = 63425 (1.94%)
5 = 48913 (1.49%)
15 = 32060 (0.98%)
16 = 23135 (0.71%)
17 = 5704 (0.17%)
18 = 3564 (0.11%)
19 = 2191 (0.07%)
4 = 1957 (0.06%)
3 = 1623 (0.05%)
2 = 1526 (0.05%)
20 = 959 (0.03%)
21 = 514 (0.02%)
22 = 292 (0.01%)
23 = 197 (0.01%)
24 = 128 (0.0%)
1 = 97 (0.0%)
25 = 85 (0.0%)
26 = 45 (0.0%)
27 = 25 (0.0%)
32 = 19 (0.0%)
28 = 16 (0.0%)
40 = 16 (0.0%)
31 = 15 (0.0%)
29 = 13 (0.0%)
30 = 12 (0.0%)
39 = 6 (0.0%)
34 = 4 (0.0%)
33 = 3 (0.0%)
36 = 3 (0.0%)
35 = 2 (0.0%)
64 = 1 (0.0%)
45 = 1 (0.0%)
54 = 1 (0.0%)
43 = 1 (0.0%)

        |                                                               
        |                                                               
        |                                                               
        |                                                               
        ||                                                              
        |||                                                             
        |||                                                             
        |||                                                             
        |||                                                             
        |||                                                             
      ||||||                                                            
      ||||||                                                            
      |||||||                                                           
      |||||||                                                           
      |||||||||                                                         
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||      
000000000011111111112222222222333333333344444444445555555555666666
012345678901234567890123456789012345678901234567890123456789012345

One to six characters = 317715 (9.7%)
One to eight characters = 1430972 (43.68%)
More than eight characters = 1845091 (56.32%)

This surprised me a little bit because I always thought that ~6 is the average amount for passwords.

Alpha, numeric, alpha- and upper-case:

Only lowercase alpha = 443775 (13.55%)
Only uppercase alpha = 317443 (9.69%)
Only alpha = 761218 (23.24%)
Only numeric = 24096 (0.74%)




First capital last symbol = 67278 (2.05%)
First capital last number = 683295 (20.86%)

Months:

january = 64 (0.0%)
february = 38 (0.0%)
march = 630 (0.02%)
april = 720 (0.02%)
may = 6304 (0.19%)
june = 1196 (0.04%)
july = 857 (0.03%)
august = 318 (0.01%)
september = 54 (0.0%)
october = 143 (0.0%)
november = 134 (0.0%)
december = 104 (0.0%)

Compaired to the amount of passwords that we analyzed these values are not very interesting. At first I was a bit confused by the high amount of ‘May’ usage. But this confusion quickly dissipated when checking the ‘pipal’ source code. The code detects the word ‘may’ in the text. ‘May’ is a string that occurs probably a little bit more in common every day words (or names) than the other months. This is why ‘may’ has such a high count.

Days:

monday = 64 (0.0%)
tuesday = 33 (0.0%)
wednesday = 16 (0.0%)
thursday = 17 (0.0%)
friday = 102 (0.0%)
saturday = 22 (0.0%)
sunday = 82 (0.0%)

Years (Top 10)

2011 = 6764 (0.21%)
2010 = 5754 (0.18%)
2008 = 5579 (0.17%)
2007 = 4244 (0.13%)
2009 = 4155 (0.13%)
2006 = 3480 (0.11%)
2000 = 3092 (0.09%)
2005 = 2883 (0.09%)
2012 = 2447 (0.07%)
1980 = 2371 (0.07%)

Colours:

black = 2069 (0.06%)
blue = 4121 (0.13%)
brown = 1047 (0.03%)
gray = 583 (0.02%)
green = 1979 (0.06%)
orange = 489 (0.01%)
pink = 1964 (0.06%)
purple = 477 (0.01%)
red = 11573 (0.35%)
white = 949 (0.03%)
yellow = 451 (0.01%)
violet = 159 (0.0%)
indigo = 90 (0.0%)

Tailing digits:

Single digit on the end = 424798 (12.97%)
Two digits on the end = 505042 (15.42%)
Three digits on the end = 162703 (4.97%)





Last digit
1 = 312509 (9.54%)
3 = 165354 (5.05%)
2 = 164638 (5.03%)
7 = 126409 (3.86%)
9 = 123559 (3.77%)
0 = 122785 (3.75%)
5 = 120416 (3.68%)
4 = 119135 (3.64%)
8 = 115571 (3.53%)
6 = 107765 (3.29%)




Last 2 digits (Top 10)
23 = 42163 (1.29%)
01 = 36592 (1.12%)
11 = 35860 (1.09%)
12 = 32446 (0.99%)
10 = 25681 (0.78%)
00 = 22101 (0.67%)
08 = 21245 (0.65%)
07 = 20770 (0.63%)
13 = 19100 (0.58%)
09 = 18492 (0.56%)




Last 3 digits (Top 10)
123 = 26606 (0.81%)
007 = 7118 (0.22%)
011 = 5834 (0.18%)
234 = 5644 (0.17%)
010 = 5197 (0.16%)
008 = 4983 (0.15%)
000 = 4978 (0.15%)
001 = 4817 (0.15%)
009 = 3846 (0.12%)
006 = 3293 (0.1%)

Last 4 digits (Top 10)

2011 = 4877 (0.15%)
1234 = 4559 (0.14%)
2008 = 4104 (0.13%)
2010 = 4044 (0.12%)
2007 = 3131 (0.1%)
2009 = 2959 (0.09%)
2006 = 2551 (0.08%)
2000 = 2242 (0.07%)
2005 = 2083 (0.06%)
2345 = 1896 (0.06%)

Last 5 digits (Top 10)

12345 = 1692 (0.05%)
23456 = 910 (0.03%)
54321 = 350 (0.01%)
56789 = 277 (0.01%)
55555 = 154 (0.0%)
00000 = 153 (0.0%)
11111 = 150 (0.0%)
67890 = 116 (0.0%)
34567 = 109 (0.0%)
77777 = 101 (0.0%)

Character set ordering

stringdigit: 1052534 (32.13%)
allstring: 840318 (25.65%)
othermask: 585169 (17.86%)
stringdigitstring: 414663 (12.66%)
digitstring: 116446 (3.55%)
stringspecialdigit: 111342 (3.4%)
digitstringdigit: 54196 (1.65%)
stringspecialstring: 51826 (1.58%)
alldigit: 24096 (0.74%)
stringspecial: 19754 (0.6%)
specialstring: 3246 (0.1%)
specialstringspecial: 2039 (0.06%)
allspecial: 434 (0.01%)

Unfortunately the gross of all the passwords are still string based.

I realized after looking at these statistics that the only thing I can say about my data set is the following:

  1. The most common length for a password is 8 characters (25.73%)

  2. 32.13% of the passwords are ‘stringdiget’ based. This is probably caused by a password policy. I don’t think this is a decision by the user.

  3. Only ~5% uses a password that is “acceptable” for most security policies. This means that 95% is likely to choose a password that can be considered “insecure”!

That’s it for now. Again, do you have a .pot file, and you feel like sharing it with me please do .pot files always make me happy ;)

Cheers, Ruben.

Most of us probably have already seen or heard about the released 0day exploits by ‘kingcope’. For MySQL version 5.1 up unitl 5.5 five exploits where released and a FreeBSD exploit. In this post I’ll focus on the MySQL 0-day exploits. All the exploits can be found here: http://seclists.org/fulldisclosure/2012/Dec/

Both the remote exploits and the privilege escalation exploit are usable. The buffer an heap overrun give you control over the code execution flow but do not provide a usable payload. It is most likely these exploits are not in this state anymore. This means that at the moment there are 3 working remote exploits and 2 almost done exploits that are causing a risk to fully patched MySQL installations.

This sounds very scary but before we go into total “Team America hands up in the air” panic mode (http://www.youtube.com/watch?v=92d1xtjXf8E) lets have a quick look at all the exploits to see what they do:

Privilege escalation exploit (Unix):

* Connect to the MySQL Server
* Create a table named rootme for the trigger
! Create the trigger file in /var/lib/mysql//rootme.TRG
! Crash the MySQL Server to force it to respawn and recognize the trigger file (by triggering the stack overrun)
* INSERT a value into the table so the trigger event gets executed
* The trigger now sets all privileges of the current connecting user in the mysql.user table to enabled.
! Crash the MySQL Server again to force it reload the user configuration
! Create a new mysql user with all privileges set to enabled
! Crash again to reload configuration
* Connect by using the newly created user
* The new connection has ADMIN access now to all databases in mysql
* The user and password hashes in the mysql.user table are dumped for a convinient way to show the exploit succeeded
* As said the user has FULL ACCESS to the database now

The lines starting with the ! character are very clear indicators that something strange is going on on your server. These are indicators you can look for (crashing services and new users). Standard monitor software (like Zabbix) alerts when services are restarted.

Buffer and heap overrun (Unix)

Both these exploits will work post-authentication. Overrun in the buffer_overrun exploit:

grant file on $a.* to 'user'\@'%' identified by 'secret';

Overrun in the heap_overrun exploit:

@commands = ('USE d', 'SHOW TABLES FROM d', "DESCRIBE t", "SHOW FIELDS FROM t", "SHOW COLUMNS FROM t", "SHOW INDEX FROM t",
             "CREATE TABLE table_name (c CHAR(1))", "DROP TABLE t", "ALTER TABLE t DROP c",
             "DELETE FROM t WHERE 1=1", "UPDATE t SET a=a","SET PASSWORD=PASSWORD('p')");

foreach my $command (@commands) {
    for ($k=0;$kquery($c);
    }
}

As you can see here, both the exploits run one or multiple SQL commands to trigger the vulnerable state.

Remote exploits (Windows):

Both the remote exploits for MySQL only work on the Windows platform. mysqljackpot needs a valid login Both exploit rely on “INTO DUMPFILE”

Summary: As you can see the exploits have a significant impact. As you probably also noticed the lower the exploit is in this blog post the harder they get to detect. Unfortunately this is all the knowledge I have about defending against 0day exploits. But I do think the exploits show behavior that can be monitored in a reasonable fashion until patches have been released. The advantage you have at the moment is that you can checkout what the exploits look like, how they work and what they need to work. Monitor these characteristics and monitor account creation on your server (not just the MySQL service but also Unix/Windows system accounts). Using an IDS – example: snort – should give you a hand with detecting these attacks withing a reasonable amount of time – no updated rules set has been released yet when I wrote this blog post.

Questions? Please do ask. Defending is a difficult job. Maybe on my own I’m not able to give you the information you need but I’m sure we can find an answer. Also, are you someone who has more info or additional information on how to defend against these attacks? Please do contact me so I can add your information to this post.

Cheers, Ruben.

A while ago Ron from skullsecurity.net blogged about the .git directory. It was interesting to read this because I recently noticed the same about the .svn directory.

Ron wrote that the .git directory is full of useful stuff. This is the same for the .svn (working copy) directory. I’m pretty sure others have noticed this about the .svn directory to. But I haven’t really found a post or a tool that does the same. And if there is, than I just needed a bad excuse to write a new tool :P (we all know that feeling where you just feel like coding something cool).

The .svn working copy directory is a directory that is used by SVN to manage the local working copy of a repository. You’ll find the .svn directory on the machine of developers or other people who commit or checkout code to the SVN server. Because the ‘dot’ directories are not shown by default on a UNIX system via the ‘ls’ command, these directories can be overlooked quite easily. A possible method to deploy new code is to do a checkout and this gets deployed to the server. When the .svn directory is not dealt with an attacker can use this to gather information or – depending on the type of files – download valuable content.

Note: during this post I’m only talking about what happens when the .svn directory gets deployed on a webserver.

Because the .svn directory is deployed with the rest of the application the .svn directory will be accessible via the web. At first the directory doesn’t look that interesting at all, until I looked at ‘wcprops-all’. This file contains file names of files that are in the SVN respository. On there own, file- and directory-names are just useful for info-gathering. But, the under laying directories contain the content of the files listed in wcprops-all. This creates a valuable resource for us when performing a pentest, both during information gathering and a possible attack scenario as well. The reason being is, its is likely database dumps or other critical files are kept in SVN.

Do remember that this method relies on files that are already in the SVN. The files listed in the ‘wcprops-all’ file should all be on the webserver but some files are not linked to via URL’s on the webpages. So this method is great for finding “hidden” files. With “hidden” I mean that some developers will check-in database backups or other valuable files into SVN to keep track of changes. With a little luck you can find these files ;)

The .svn directories are very simple to find using the following googl-dork:

".svn" intitle:"Index of" site:

I wrote a script that allows you to download the content of the .svn directory. You can download the script at: ‘https://github.com/damnsecure/FlowerMonkey

git pull https://github.com/damnsecure/FlowerMonkey.git

The script is very easy to use. Just provide it with a URL and let the script do its work. See the git page (README.md) for more info.

  • Remember, this tool only downloads the provided url (direct path inc folder) and the discovered files in the .svn directory. This script does NOT crawl any underlying directories of the website.

So what can you do about it? The solution is very easy. There are multiple methods but I think the following two are the most useful:

  1. Remove the .svn directory when deploying your application. Easy right ;)

  2. Deny access to the .svn directories.

You can do this by adding the following to your httpd.conf or .htaccess files:

    Deny From All

[edit] Also redirecting it to a 404 page is a possibility:

RedirectMatch 404 /\\.svn(/|$)

[/edit]

As described in Ron’s post the .git directory allows you to do a new checkout. I haven’t tested this with the .svn directory but I see no reason why this shouldn’t work. This could actually be even a better way of obtaining files (including source code) of a web application. But again, I have not tested this. If somebody did please do let me know. Either way, I’ll get back on you on this topic I think. Even if this works, it is still possible the SVN server is hosted on an internal server making a straight checkout impossible. This is where this tool is useful.

But for now, cheers and stay warm, Ruben.

[edit] I also just found a metasploit module that does about the same as my script. The module is called: “svn_scanner” and can be found at: http://dev.metasploit.com//redmine/projects/framework/repository/revisions/master/raw/modules/auxiliary/scanner/http/svn_scanner.rb [/edit]

A few day’s (or maybe weeks) I saw the following project coming by in my twitter feed:

https://github.com/alsmola/nopassword

In short, my understanding is that this is a login system that removed the need for a password. It completely relies on your email. So, you want to login, you provide your email address, you receive an email, click the link, done! Just like resetting your password but every time.

I liked the idea. And till today I can’t think of a serious issue that this project would cause. I would like to port it to PHP one day, but I’m pretty swamped at the moment (just like everybody). But I can’t not share this because I really like the concept.

Cheers, Ruben.

When searching for vulnerabilities (bugs) in applications fuzzing has been proven to be a very effective method to identify input validation bugs. In this post we will have a look at a very simple fuzzer. At the end we will have a fuzzer that will fuzz the IMAP protocol. Lets get started.

During this exercise we will fuzz “Eudora Qualcomm WorldMail 3.0” The installation file for this mail server can be downloaded from: http://www.exploit-db.com/wp-content/themes/exploit/applications/7b4ab5fe7aed0d10fd23bfa3f5555045-WorldMail3_installer.exe

After installation you will see the mail server is running multiple services on different ports either via the WorldMail management console or/and via a nmap scan. We will focus on port 143 which is running IMAP.

So what is fuzzing? Fuzzing in short is a technique where you send all sorts of data to the application to see if it crashes. You’ll use the application logic to reach different parts of the code. The best way to understand fuzzing is by building a very simple fuzzer yourself.

The first thing that is important is that we create a simple program that connects to the server and is able to send and receive data.

import argv from sys

print "[*] Building connection"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((argv[0], 143))
data=s.recv(1024)
print "[*] Successfully connected. Recieved banner: " + data.strip()
print "[*] Sending data..."
s.send(data + "rn")
print "[*] Data send, closing connection"
s.close()
print "[*] Done"

Easy, now we can connect, receive the IMAP worldmail banner and send data.

Lets write the fuzzing part: We will keep this fuzzer extremely simple. We will create a string with a specific character, then we will in create the size with every loop. We’ll repeat this process for every IMAP command till the string we are sending is equal or larger then a length of 5000

Lets see what this looks like:

#!/usr/bin/python
import time
import socket
from sys import argv

def imap_connect(junk):
        try:
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            s.connect((argv[1], 143))
            data=s.recv(1024)
            print "[*] Sending junk (\\x%s * %i)" % (junk[0].encode("hex"), len(junk))
            s.send(junk + "\r\n")
            s.close()
        except:
            print "[!] An error has occured, this is probably good news ;)"
            quit()

#Lot of IMAP commands are missing but you get the concept ;)
commands = ["LIST", "AUTHENTICATE", ""]

if argv[1]:
    #Getting our char
    for char in range(256):
        junk = chr(char) 
        counter = 1
        while len(junk) < 1000:
            junk += str(chr(char) * 50) #Adding 50 chars to our current junk str
            for command in commands:
                imap_connect("A01 " + command + str(junk)) 

Now this is nice but you can probably see that this fuzzer is dead simple. Also, there is no other implementation of the IMAP protocol except for the IMAP commands. We are not even logging in. I would be great if we had those opportunities to. Luckily, other people already wrote fuzzers that do this for you. A good example is Spike (comes with backtrack). Spike is great for this scenario because it already has a IMAP protocol implementation.

You should be able to get the same type of crash (the previous simple fuzzer script will cause a crash, more about application crashes in part 2) with Spike by running the following commands:

cd /pentest/fuzzers/spike/src/
./generic_send_tcp <server-ip> 143 audits/IMAP/imap1.spk 0 0

Well thats it for now. We have a crash. Next post we’ll have a look to see if we can exploit this crash.

Happy crashing, Ruben.

As some of you probably already noticed, it seems like half the internet thinks they got a free out of jail card when it comes to computer crimes. Today it was Yahoo’s turn to handover 456.581 email addresses including passwords. Just before you stop reading let me tell you the following: In this post you won’t find how you should store your customers passwords. And that you should alway’s nicely hash and salt them. And use an algorithm that takes a long time to bruteforce (cough http://www.f-secure.com/weblog/archives/00002379.html cough) ow no I didn’t, I tricked you a bit did I? You did read all that stuff just now! Ow well, lets continue. There are plenty of posts out that that do exactly that (give you advice on how to store passwords) – some do a very poor job by the way… so when looking for this stuff make sure you ask somebody who knows where to find the right doco’s. What I will do though is give some more info about the data leak.

Unfortunately the leek itself has been taken offline (although I’m sure mirrors exists). And no I wont put it online here. It has been taken offline for a reason ;)

So what did the dump exactly contain? First the dump started with the usual info about the hacker group, who is responsible and stuff like that. Followed by the information about the database that got popped (including HOSTNAME, oops… not so responsible disclosure). Somebody (sorry can’t remember or find his twitter account) made a quick analysis that this was probably the database from the Yahoo Voice service. This service is a user contribution service on the Yahoo! network[1]

This information was followed by the dump of 456.581 email addresses including plain passwords. Lets do a quick analysis:

456581 password found
342513 unique passwords found

Top 10:
1667 x 123456
780 x password
437 x welcome
333 x ninja
250 x abc123
222 x 123456789
208 x 12345678
205 x sunshine
202 x princess
172 x qwerty

Till today these passwords are still being used and are still allowed. Isn’t it time we start to blacklist these passwords just like Twitter is already doing? Except for ninja, you cannot ban a ninja from your system….

Just before we wrap it up please remember the following: It is most likely that your customers will use a password in your application that they use somewhere else too. It is not uncommon (maybe even mainstream – hipsters this is your chance to change the general understanding of a password policy) for a user to have 2 or 3 passwords in total. So its very likely that the customers password in your database is also used for other applications eg email. Being aware of this is YOUR job. Not the customers. Security awareness will slowly increase under the general public but this will not change over night. You as a developer are responsible and you will have to create the rules when it comes to application security. Getting hacked can happen to everyone, but make sure that when it happens the data you store is stored safely. So NO plain passwords! cough captain obvious cough

Personally, I don’t think this is a responsible way of disclosing a vulnerability. But more on this so called “hacktivism” in a post planned later this week. So keep visiting DamnSecure! And don’t forget to follow me on twitter and put my blog in your RSS feed.

Well thats it for today. Stay warm (I don’t like being frosty)

Cheers, Ruben.

[1] http://www.todayonline.com/Technology/EDC120712-0000173/450,000-passwords-stolen-from-Yahoo!-Voices