Posts Tagged ‘fail’


Yesterday something went wrong – Below is screenshot pointing out the problem. Read the rest of article to find out more details.

The screenshots had very common mistake – redirection. It’s very good tool for phishing attacks. If attacker has any possibilities to send e-mail to registered user, he is able to attack against the user. For example how many would have noticed the redirection bug if he got the e-mail message:

From: root@trusted-mail.net

Subject: E-mail validation

Please, validate that your e-mail address is still valid by logging in to the Trusted Mail. We are not requesting any passwords by e-mail and as you can see from link below, it is pointing to Trusted-mail.net. Make always sure that address bar has correct address.

So please, log in with this validation link:

https://trusted-mail.net/horde/imp/login.php?url=%68%74%74%70%73%3A%2F%2F%65%76%69%6C%68%61%78%6F%72%2E%63%6F%6D%2F%68%61%78%2F%74%72%75%73%74%65%64%2D%6D%61%69%6C%2F

Sincerely,

Mail admin of Trusted-Mail.com

That mail looks valid – doesn’t it? When redirection goes wrong, the attack against the service users is simple. It just takes few minutes to copy the original login page, change the form processing so that submitted data is stored to local file or database, and then redirect back to original site. It’s very difficult to notice, that the target site is actually new site and not the original one. At least I’m mistyping my passwords every now and then, and when the system says that password is wrong, I try to write it a bit more careful but without checking where my browser actually is.

So the failures are actually at many level. Bad web application is not validating its input correctly. I have written about that before at post “Phun with redirects“. But second is more fundamental failure. It’s at e-mail protocol. The From field is not validated. Attacker can give any From address and receiver wouldn’t notice that.

The original SMTP protocol was defined at RFC 821 year 1982. Back then there wasn’t need for security. And now it would be just too expensive to add new security layer, because everything has been implemented to use old and insecure protocol. Maybe at next bug report I should state:”The root cause for bug is Internet and its protocols.”


Test automation tools are much like the hunting gun. You have real uses for it, but you can use it to do nasty things. This blog is about Skype but same kind of issues can be at any other application.

Let’s imagine that I’m evil h4x0r and I’d want to find new ways to extend my bot network. Everyone has become more and more careful with e-mail attachments so spamming is not the option anymore. Let’s take a quick look at Skype. Could we use it to automate our malware distribution? If I tried to register 1 million new user from web page, I’d have to give correct Captcha for each one of them. But if I do registration thru the Skype, the registration screen is shown below. No Captcha. When I registered, I also noticed there isn’t any e-mail confirmation.

If I already have small bot network, I can use those weaknesses to register plenty of Skype users. Easiest way to do that is to use automation. My proof of concept was done with AutoIT which is free test automation library. If the desktop application doesn’t have same bot-prevention systems as web application, small automation script can create new users. If you are able to create users, you are also able to do any other task. So my bot could start to call to people, start to add contacts, send files and so on. Chat could start with:”Hello. I am Jack Nicholson from Skype security contact.  We have noticed that you have major security risk which can be fixed by installing the patch which I’m going to send you.”

Skype has two major security related failures at registration thru the application:

  1. No Captcha which would have prevented automated guessing.
  2. No e-mail confirmation. Confirmation would have required exploiting the weaknesses of some free e-mail service.

Those two steps would increase the cost a lot and simple few hours bot coding wouldn’t be enough. I reported these as security issue to Skype at mid-July.

And how short the script is which creates the new user? Well… Here is my full proof of concept. It works only at my laptop and machines with same resolution and other visual settings. The attacker can make the script more generic with some work.

Run("C:\Program Files\Skype\Phone\skype.exe")
Sleep(5000)

MouseClick("left", 628, 437)
WinWaitActive("Skype™ - Luo tili")
Send("Evil Robot")
MouseClick("left", 500,501);
Sleep(500)
Send("q1w2e3")
MouseClick("left",794,496)
Sleep(500)
Send("q1w2e3");
MouseClick("left",485,549)
Sleep(500)
Send("something@kiva-mesta.net")
MouseClick("left",778,549)
Sleep(500)
Send("something@kiva-mesta.net")
Sleep(500)
MouseClick("left",1051,678)

I ended up to the bed with IEC 61066. It is standard for the safety related systems, so I thought it could be nice standard. Oh well – it is nice example of the standard which should definitely not exist. If we have safety related item which has security related quality requirement, it should not conflict with itself. Let’s quote (p109, 14.2.3.5):

In the case where data are not transmitted via a simple electrical data connection from one device to another, for example transmission via a network, it shall not be  possible to modify, delete or add something to these data. In addition, the receiving part of the dosimetry system, for example the computer, shall make sure that the received data are authentic. That means it shall be recognised if the data come from another device than the reader assigned to the dosimetry system.

NOTE One possible technical solution is: All transmitted data are combined in well-defined data sets including date and time of the generation of the data set, a running number, an identification of the transmitting part, for example serial number of the reader, and the relevant data. The whole data set is protected by an electronic signature (CRC, at least CRC-16 with a secret start value). The receiving part, for example computer, checks the contained data by making sure that no running number is missing (or double) and that the identification of the transmitting part is the correct one.

One possible technical solution is in conflict with the requirement. CRC is insecure algorithm for signing the data. It is usable for error detection. First the problem is size. To get the correct CRC-16 value with brute force requires only 2^16 steps, which is 65536. It doesn’t take much time to walk thru all of those. Actually the easier solution is to calculate the secret start value which also takes in worst case those 65536 steps. If that is too many steps, then there is 50% change to find the real start value with only about 256 steps.

The example solution does not honor the spirit of the requirement. With the example solution there isn’t any guarantees that the origin of the data is from the original device. Much better signature algorithms are presented at [1].

I really wonder why that kind of mistake has been made. The error detection algorithm is mixed with the signature. My guess is, that the creators of the standard are professional at embedded systems and communication. They are not security experts. The standard contained cross-domain issues, which would have required also the knowledge of security. The standard creation is too often too closed so the input from different domains is not received when they were needed.

[1] Ferguson N., Schneier B.: Practical cryptography, Wiley Publishing, 2003