Insecure Key Switch and Full Mailbox

Being very active we got another hint from Flo, who shot the following two pictures during a physical assessment. He posted those pictures on his own blog dosbartjones.org, so we will just keep his text and pictures in original and wanna refer to his own blog entry at this point. Thanks for your contribution to the project, Flo. 

Easy access to your mailbox

This image has been taken while performing a physical security assessment and shows the vulnerability of a stuffed mailbox. This mailbox has not been emptied in a while and can easily be accessed by outsiders. It was not even necessary to pick locks.

 

Insecure key switch

The following image displays an insecure key switch. This switch in particular controls the access to a company building. Although an attacker might try to break the lock, a screwdriver is everything one would need to gain entry.

Police in Paris probably doesn't have ISO 27001 in place

It is already three years ago that Flo was wandering through the streets of Paris. Thanks to him that he didn't forget to send us his observations from this tour through the city of love. The pictures he sent us have nothing to do with love, though.

What he discovered was this police station in the heart of the city. It looks quite fine at first, but an expert eye probably instantly sees what is wrong in this picture.

 

Chapter 9.2.3 "Cabling Security" of ISO 27002 states: "Power and telecommunications cabling carrying data or supporting information services should be protected from interception or damage."

I agree that the cable coming from inside the building, hanging just besides the video camera near the entrance is in a height that a 1,60 m tall woman or man cannot instantly catch it and get some data or video feeds. But, letting this cable reside on a nevertheless easy to reach position outside of the building is definitely a breach according to the above stated paragraph in ISO 27002.

So we might come to the conclusion that the police in Paris has not implemented ISO 27001 in their information security system. Probably they have, but then they should probably re-think their security strategy.

Making logout a bit more complicated

An established and most often applied design principle in the field of web application security is to provide users with a logout button on every page of an application. Ideally, this button is always in the same place so that users can leave the application with one click on a defined spot. Making logout as simple as possible and having users actually using the logout function leads to the prevention of a number of possible attacks. Cross-site request forgery, session hijacking or just someone using the same computer and thereby getting access to the session are a few examples.

However, some popular platforms seem to prefer making logout a bit more complicated. Google Mail and Facebook are just two examples:




As you can see, logout needs at least two clicks, which might leads to a decrease of the total number of users actually using the logout button. While this leads to a decrease in security, it also leads to an increase of privacy problems.

Popular platforms want your session to be established as long as possible, in order to be able to track which web sites you use and gather as much information about a person as possible. Social media plugins like the Facebook like button just come in handy in this process, as third party cookies and of course your current IP address are visible to the respective platforms when you access external sites with these plugins integrated. So long, happy tracking!

Android lock screen

If you have an Android mobile phone, you probably already use the lock screen functionality that makes you enter an unlock code or draw an unlock pattern each time you want to use the phone. If you don't, you should. Otherwise, contact details or personal messages can be stolen within seconds, if you leave your mobile unattended. Other people may also make long distance calls or send unwanted messages to your contacts.

Android offers the functionality to unlock your mobile by drawing a pattern on the touch screen. This is generally faster than typing an unlock code again and again. Connect the dots shown on the screen in the correct order to draw your pre-defined pattern and you are done.


On the other side, using a touch screen always leaves some traces of your fingers. If you do not use your mobile extensively after the unlock (and thereby blurring your traces), attackers may be able to reconstruct your unlock pattern.

Even though taking photos of the finger traces did not lead to satisfying results, you generally get the idea: tilt the mobile against your next best source of light and see what you can reconstruct. Click on the photos to enlarge them.


But keep in mind: using the Android lock screen with a draw pattern instead of an unlock code is still way better than using no lock functionality at all.

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 ;-)