Sometimes attackers just have to listen

This story happened yesterday in a bank just near my place. A woman, approximately 55 years old, entered the bank and went up to the friendly guy behind the desk to get some cash. Her voice was louder than the everage and therefore good to understand.

Woman (W): "I lost my company's money somewhere. I can't find it anymore - don't know where I put it."

Man (M): "You should probably just have another look at home, it will be somewhere around."

W: "Yes, sure it will be - I always hide it behind one of the big containers at home - under the doormat. I will have a look at there later on."

The man looked confused and so did a couple of other people, who were standing in the same room. The bank assistant grinned for short, but tried to explain her to speak in a low voice and that she should have a look at different places where she puts the money usually. But the woman was not going to stop.

W: "I think, it has to be under the container. I also put my wallet there, this time."

At this point a man, standing behind the woman already the whole time interrupted: "Sorry lady, but you should stop talking about your secret places in your own interest."

But once again the womand didn't want to listen:
"Ah...nobody knows where I am living. And I am going home afterwards to look for it. Just doing groceries before that."

Eventually, the woman left the bank and my friend, who was standing on the other side of the room, called me to tell me what he had just experienced. The story is true and is an awkward reminder of security awareness. But there is also a good side of this story. It also points out that security is already in everybody's mindset when it comes to topics like this - except for the woman, of course. And security measures, like not talking about sensitive information, can get a very natural part of their lives. A man even took action to shut her up, how often do we see an employee reminding colleagues about keeping company secrets?

Security functions suggested to be turned off by default - guess why

Slideshare.net provides a service that enables you to upload your presentations and share it with the public. Just like at YouTube or vimeo you cannot only watch the shared content directly at the slideshare.net website, but you can also use an "embed"-feature and incorporate presentation contents into your own web presence.

For each presentation slideshare offers a convenient HTML-code snippet that is ready to copy&paste it into your site. Here a shortened example:

<object id="__sse763783" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=grant-presentation-1227010891051378-9&stripped_title=welcome-to-ip-surveillance-101-presentation&userName=grantsupplies"><param name="allowFullScreen" value="true"><param name="allowScriptAccess" value="always"></object>
As you can see, the embedded code loads a flash player that in turn shows the desired presentation contents. By default, the privileges of a flash file are restricted if it is loaded from a different domain than the surrounding web site. That means that the flash file cannot access the DOM of the site, nor make JavaScript calls or similar things.

However, the code snippet above loads with the "allowScriptAccess=always" parameter. That means that these security functions are actively turned off: the embedded content has full access to and control over the the embedding site. Altering the DOM or stealing cookies are just two possible scenarios.

Here what slideshare does with its - through the suggested embed code quasi self-given - privileges: it actively integrates "web analytics functions" (other people would call this "user tracking") into the embedding web site. Just take the HTML snippet shown above and integrate it into an otherwise completely empty web page. Here is what you will end up with:


The HTML view shows that you unknowingly just integrated "analytics functions" from Google Analytics and Scorecardresearch. Central tracking of which IP adress accessed which contents at what time made easy. Given that you have absolutely no control over what these scripts do with your site, nor what information they collect about your users, you may have a problem if your site is located in a German-speaking area. Whether the use of Google Analytics is legal here is still a source of controversal discussions.

If you decide to use the default flash security mechanisms ("allowScriptAccess=samedomain") the shown scripts disappear, as the slideshare content is not allowed to alter the page - just give it a try yourself.

Security functions leading to the attackers goal

Sometimes a security function just does not work like intended by its designers or developers. Suppose you run a website that offers a file download mechanism implemented in PHP. Nowadays, many programmers are aware of the security problems that might arise from flawed implementations in that area. They might easily lead to the disclosure of arbitrary files of the web server.

Always keeping the user experience in mind, people often tend to sanitize user input (e.g. removing unwanted content and then continue) rather than failing gracefully and confront the user with an error message. Just as in the following code:

$dlfile = $_GET["file"];
...
// Prevent directory traversal attack
$dlfile = preg_replace("/\.\.\//", "", $dlfile);
...

What the developer tries to do is removing "../" sequences in order to prevent attackers from reading other files than those available in a specific directory. In the following example, the first request should lead to a normal file download, while the second one should be prevented:

/download.php?file=funnycat.jpg
/download.php?file=../../../../etc/passwd

What has not been kept in mind is that the parameter can be chosen in order that it uses the regular expression to construct the desired outcome. Just consider the following input (without the parenthesis):

/download.php?file=.(../)./.(../)./.(../)./.(../)./etc/passwd

Those parts highlighted with parenthesis are removed by the "security function". The rest stays. This leads to:

../../../../etc/passwd

In order to prevent that pitfall there are many possible solutions. The easiest would be to simply abort processing when an error is encountered, instead of applying sanitization. Others include performing the sanitization repeatedly, whitelist allowed file names or character ranges, or (in this case) link to the files directly instead of using a PHP indirection. Of course, contents could also be stored in a database instead, but SQL injections are a different topic ;-)

And what are you doing during your working time?

Flo did another trip around Europe and brought sent some pictures to SecurityPitfalls.org, thanks for that. This time, we clearly see that he was passing by one of the IBM offices. To be more specific, this shot was taken in one of the branches of IBM in London.

The more interesting part of this story is that he got a very good view into the offices and could directly see the computer screens of the employees. Besides the fact, that it might be interesting for someone to see if the employees are productive - and they really are according to those pictures - this shows a tremendous security risk.

From this very public place you can easily spy on the company's data, you could have a look at interesting project files lying on desks or you might get the chance to observe someone typing in a password or important information. 

Some companies might not think about the risk of someone external walking through the company's premises looking for important data on tables or the computer screen. However, not caring about the fact you can easily get an insight into a company from a public place where you can sit down and take photographs all the time, is a different level of risk. IBM should probably rethink their office design.

By-passing Security Gates

In Hagenberg, Upper Austria, there is a security gate that should prevent external people from entering the student village's premises. This picture is taken from Google Maps and shows how easily this security measure can be circumvented.

Actually, there are parking lots near the gate and right near the entrance of the first building there is enough space for a car to bypass the security gate.

I guess, even one little, heavy plant placed on the by-pass road would prevent the people from using this route. Most of the time, people could close security loopholes by spending none or little money. They just need a little help to find their vulnerabilities.

Need any help in finding the key?

This pictures was posted on Hirngulasch's Soup and was discovered and reported by N0rb. It shows a message left by one of the children which says "Mum, the key is on the balcony!!!!".

Unfortunately, we could not find the owner of the picture and therefore we cannot be sue if this is a true story. Nevertheless, it points out an important topic - awareness. It's not just that children are often not aware of risks, we have to face the same problems in companies with unaware employess. Unless they are not trained to focus on specific types of risk, they would never think that actions they carry out could be a security risk for the company.  The solution is simple, talk to the people and talk to your children and explain it to them, they will understand as long as they care about their place of living and working.

Open day at a youth hostel

Flo submitted the following security pitfalls from a youth hostel in Linz, Upper Austria. In the following picture you can see how the building looks from the street.

Taking a look around, he discovered the first issue. There was a back entry which was opened and would make a perfect entry point for an attacker. The entry to the stairs leading to the door, was secured by 1.5m high railings. Without a doubt, an easy to surmount obstacle.

On the back side of the building, or what somewhat could be called a backyard, Flo discovered the next entry point. There was a service entry for a building attached to the youth hostel. 

The entry opened up access to a variety of rooms, not part of the normal housing. Flo did not enter the corridor, as this would have not been allowed in terms of the Austrian legislation. Another point that caught Flo's attention were all the containers and garbage around. Assuming that, like in other hostels already described on this blog, access codes to rooms were set using a specific algorithm, old code numbers could give access to rooms in the hostel and a free night.  

Thanks to Flo, for his contribution to the project.