ITS Blog

IT Security blog – about up to date topics on IT security

Browsing Posts published by nidsche

Thanks to Security Nirvana the program and abstracts of password 11 are available.

Today I got the confirmation for attending password 11, a conference on password security. It is done by Selmer Centre a part of the university of Bergen, Norway.  I am looking forward to some interesting talks. In the mean time check out what happened on password 10, which happened in December 2010. For those of you unable to participate take a look at, there will be a recording/live stream of at least some of the talks.

Additionally I plan to write about the talks afterwards.

See you at password 11


No comments

Some words about comments on this site. You might be wondering that there are nearly no comments at all on the site. The reason for this is very simple. I approve comments only from people I know. I do not want my readers to be spammed. In the case you think your comment should appear on this site, even while I do not know you, send me an email, so we can discuss on the topic. There is a good chance to convince me about approving your comment.

Currently I am focusing on the topic of password security and guessing of passwords. For this work I started to analyse the famous rockyou password list. This list was leaked in December 2009 [wikipedia]. The list can be found on various sources for example at SkullSecurity, where are a lot more lists as well.

Taking a closer look on the passwords brings the following results:

12.2% are passwords with 6 letters lower case

8.4% are passwords with 7 letters lower case

7.5% are passwords with 8 letters lower case

7% are passwords with 6 digits

As a little performance test I took a list of raw-MD5 Hashes a asked John The Ripper to brute force all lower case words with 8 letters meaning from a to zzzzzzzz. It took around 5 hours then John had finished his work with roughly 2.4 Million words hashed per second.The work was performed on a Compaq nx9420 running a gentoo linux. Testing the digits from 0 to 99999999 took additionally 42 seconds.

This numbers bring us to the point:

  • use long passwords (10+ signs)
  • use small and capital letters
  • use numbers
  • use special signs !

All of these measures increase the security of your password and also help to protect your data.

Working in a company, being responsible for security, you have to deal with passwords. Passwords are used to login to the company network, to login to the desktop PC, to login to webshops. Passwords are used nearly every where.

Due to this, the default user has a lot of passwords to remember. For this reason most users use a very limited number of password. For some the number is just one. To make it even worser, the passwords are not exchanged over the time.

Users tend to forget their accounts. Most likely you encountered is by yourself already. Only accounts which are used on a regular basis stay in the focus of the users. Putting both things together the following happens:

  1. a user created an account on website “”, for example to write a comment
  2. he uses his default password, the same he used on his personal computer, his Email account and his company PC
  3. time passes ….. the user forgets his account
  4. some bad guys hack and do or don’t publish the user data via torrent

The user forgot the account and by this is not aware about the risk his accounts are in.

Step 4 happen last year to:

The databases from and gawker are still available via torrent.

What you should learn from this:

  • Use different passwords for different sites
  • Change your passwords at least ones a year

An alle, die heute festgestellt haben, das meine Seite nicht erreichbar war: Es war nicht geplant und wird nicht so schnell wieder vorkommen. In den letzten Wochen gab es einige Probleme meine Seite zu erreichen. Der Grund lag in der “nicht so guten Performance” meines früheren Providers, Die Seite war ab und an nicht erreichbar. Nachdem ich einige Tickets an das Helpdesk mit der Bitte um Klärung geschickt hatte, kam jedes mal die Antwort: “Wir können keinen Fehler feststellen”. Hierbei ist das Problem jedesmal ca 2-3 Minuten nach dem Öffnen des Tickets verschwunden.

Am Ende habe ich mich dazu entschlossen zu Strato zu wechseln. Strato ist ein wenig teurer, aber dafür stimmt die Leistung und Performance.

Der Grund für die Auszeit (immerhin 18 Stunden) war, das ich den Vertrag mit 1blu beendet hatte. Vorher hatte ich mit der Hotline gesprochen und unser Verständnis war, das ich die Authcodes für die Domains bekomme und danach 28 Tage Zeit habe die Domains um zu ziehen. Was die Hotline mir nicht sagte, war, das man um Mitternacht, nachdem ich den AUthcode bekommen habe, die Domain von ihrem Webspace trennt.

Dies hab ich leider erst 8 Stunden später mitbekommen. Da es einige Webseiten betroffen hat, hat es etwas länger gedauert.

Am Ende: Auf (nimmer) wiedersehen 1blu, Hallo Strato

Lesson learned: Man bekommt wofür man zahlt, Nie wieder 1blu

To all who encountered the downtime today: It was not planned, but it won’t happen again. In the last weeks there were a lot of problems to reach this site. The reason was the not so good performance of the servers of my last provider, The website was unreachable from time to time. After opening tickets to the help desk I always got the answer: “everything is fine, we can not find an issue”. Also the problem disappeared always 2-3 minutes after the ticket was opened.

At the end I decided to switch to They are a little more expensive, but hey they have a good performance on the servers.

The reason for this downtime (about 18 hours) was due to the fact, that I canceled my contract with 1blu. I talked to the hotline before and our understanding was, that I get the authcodes and have 28 days to transfer the domains. What they did not tell me was, that they at midnight after sending the auth codes disconnected the domain from the webspace.

I learned about it 8 hours after the disconnect. Since there were a lot of domains affected, it took some hours to move it.

At the end: goodbye 1blue, Welcome

lesson learned: you get what you pay for. Never ever again

On Thursday I attended a workshop on Red Team Testing. Red Team testing comes from military jargon. It means to try to break into a facility. Not only on electronic or network way but also, if needed, physically. At the very first beginning there was a video presented, showing a show called Tiger Team breaking in to a jewelry store. This action was done on behalf of the owner. If you would like to get an impression of such things take a look at They produced a show where the team broke into a car dealer facility.

Talking about read team testing, the testing team need always to have the permission of the owner or their representatives. Without this written permission all actions are illegal and should not be done. After having the permission the next step is to gather information on the target. This step will most likely take about 60% of the overall time for the test.

The target

Together with the customer first the business is evaluated with respect to the three aspects of security: Confidentiality, Integrity, Availability. For this task, first a list with all parts of the business is created. An example in case of a hospital could be:

  • billing,
  • health care,
  • credit card handling,
  • client data
  • etc.

The next step is to evaluate, the criticality of each aspect on each part of the business.

Looking at a hospital, it is important that patient data is kept confidential, integer and always available, simple because people can die if it is not. Dying people in a hospital will destroy this business, especially if it is in the responsibility of the hospital. On the other hand looking at credit data, confidentiality has to be high, but if the credit card information is not available for an hour it is not critical for the business. The money can be taken later from the account. After finishing the matrix the targets for the attack are the highest rated parts of the business.


After defining the target, the scope has to be clarified. Scope means, what is allowed and what is forbidden. If the goal is to break in to a facility, it has to be clarified, if you are allowed to use brute force, like driving a truck through the front door, or softer approaches have to be chosen. In general a good team should always be able to work without harming the systems with force. If during the test the team encounters opportunities, which are beyond scope or which had not been discussed, a call to the customer can clarify if the scope can or should be changed.

Information gathering

As in the beginning mentioned, 60% of the time needed is used for information gathering. During information gathering, it is important to stay out of the scope of the security team of the customer. Therefore you can not use portscanners or something similar, since the security team of the customer would get on red alert and therefore raise the alert level of the target. Your victim will immediately know that it is being attacked and take countermeasures. A better way is to use google or other sources to get information about your victim. Also their webside is a good information source. Looking at the job opportunities you can learn which kind of software they use just by looking at the required skillset. For Information gathering have a look at

Maltego or Foca

Foca allows you to search for files published by the victim and extract metadata from it. Maltego gathers information from various sources and puts everything together. Also mindmapping tools will help to organize the collected data.

The plan

Having all information gathered it is time to make a plan. In the planning phase the team should not only concentrate on one plan, but also think about a plan B, C, D … and so on. It is always good to have a lot of options in the back, in case something unexpected happens. This can range from some security guards, which catches the team, to the team cannot open a lock.

The second last step is then the attack by itself. This step is built a lot on experience. During the attack the team should document each target which is successfully taken. This can be a picture of the team holding some documents or something similar. Whichever documentation is choosen the customer should at the end be convinced that the goal was reached.


After the attack it is time to debrief the customer. The customer should get a full report, covering the parts of his business together with the security aspects which have been broken. Every step performed during the attack needs to be added to a report, together with the found weaknesses and suggestions how to improve the overall security. In this step the customer can be reminded that security is not only about performing tests but also that the security is a process. A process to which the customer needs to commit himself to. It is then up to the client, to make the needed changes to his habit, to his facility and to his processes to improve security.

Inside this article I could only cover a very small amount of the content of the workshop. I would like to thank Chris Nickerson and Ryan Jones for holding this workshop.

Cross Site Scripting – DOM based

In my previous articles about Cross Site Scripting (XSS) you got a definition on XSS. Today we are talking about a new kind of attacks, the DOM-based XSS.

Lets recall: In regular XSS  Javascript code is send to a webapplication. The webapplication does not propperly check the values it gets as parameters and puts it in the website, which is delivered to the webclient. In DOM-based XSS the Code is not included by the Web server itself, but by the page. A page evaluates the URL and includes certain parameter from it.

To make an easy example, create a small website and include the following JavascriptCode inside:


save the code to your disk and open it with a browser. Now change the URL to :

[your filename]l#<script>alert(123);</script>

A alert window should pop up saying 123.

Now lets see what happened. When we created the webpage, we included some code, which evaluated the URL location. To get rid of the strange signes, we unescaped the URL. The unescaped URL was then written to the page by the javascript. Inside the location there was your <script>alert(123);</script> which now was included in the page. During the parsing this triggered the alert window.

The interesting thing about this vulnerability is that it can not always be detected by the webserver and even static pages are vulnerable. The  reason why it is not always detected is, that the part after the #-sign is interpreted as a target within the webpage. Therefore it is not transfered to the webserver.

The vulnerability is not limited to the part after the #-sign. It might also be in parameters, or referrers of a page.

Just take a look by yourself, to see which pages are vulnerable on your site. Search for

  • document.URL
  • document.location
  • document.refrerrer
  • unescape

This list is by far not complete, but it is a good starting point for the moment.

Be aware that this kind of vulnerabilities can be found by code review, which can be done remote. An attacker has always access to the code of the webpage. He can perform automatic searches for keywords and then exploit the vulnerability manually.

At 11:00 in the morning the CTF @ was closed. There was already some nice feedback from the participating teams. During the lightning talk the winner are announced. The top places from all participants:

  1. Bobsleigh
  2. Nibbles
  3. Leet more

Only local team could win prices. My congratulations to the winners of the CTF and to the winners of the prices.