Luggage Security

If you travel a lot, especially for business, you are at one point probably concerned about the contents of your luggage. Usually, you find a possibility to lock it either with a padlock or with a number lock, TSA approved, or not. However, the following video shows that even secured luggage might not be as secure as it looks like.




Thanks to Norb, who sent us the link to the kipkay.com site, from where this video is originally from. So take what you send and how you secure your luggage, the next time.

Know the platforms you use

The open source content management platform Drupal is widely used for both commercial and personal web pages. While using a ready-made content management system makes life easier by hiding some complexity, it also bears the risk that your web page has some functionality available you are not aware of and do not want to expose.

Many web pages based on Drupal are used as personal blogs or just offer some company information. In these cases, Drupal is more or less just used to "hide the HTML stuff underneath". Drupal (and add-ons), however, can offer far more functionality such as discussion boards or community management.

One common functionality is the user registration, by default available at the URL path "/user/register". A lot of these interfaces can be found by a simple Google search (click here). In the cases shown, this is most likely desired functionality, where users should be able to register their own accounts and (depending on their rights) create or alter web page contents.

Sometimes, however, user registration interfaces just have been forgotten and they were never disabled after the initial installation. Although they are not linked from the normal web page contents, the relevant pages are still present. In these cases, an attacker might simply register his own account and, for example, modify web page data. This simple example shows that it is always important to have knowledge about the platform you use - be it a content management system like Drupal or be it infrastructure components such as application servers (JBoss, Tomcat, etc.)

In order to automate the task of finding and reporting Drupal user registration interfaces during security assessments, I created a simple script that uses the nmap scripting engine. More information about the nmap scripting engine and all the ready-made scripts that already ship with your nmap installation can be found here.

Unfortunately, I cannot add attachments to this blog post, so I paste the script here at the end, which makes the whole message a bit lengthy...

description = [[
Reports possible user registration pages of the Drupal CMS, 
available at the URL path "/user/register". Some Drupal 
installations have this functionalty unintentionally left open.
]]

---
-- @usage
-- nmap -p 80 --script drupal-registration-page.nse example.com
--
-- @output
-- PORT   STATE SERVICE
-- 80/tcp open  http
-- | drupal-registration-page.nse: Possible CMS user registration 
-- |_interface at: http://example.com:80/user/register

author = "mk"
license = "BSD license (3 clause)"
categories = {"safe", "discovery"}

require 'shortport'
require 'http'
require 'stdnse'

local url = "/user/register"

-- Strings that must be present in a working registration page
local positiveCriteria = {
 "<form action=\"/user/register\"",
 "<input type=\"text\" maxlength=\"64\" name=\"mail\""
}

-- Strings that must not be present in a working registration page
local negativeCriteria = {
 "Access Denied",
 "You are not authorized"
}

function portrule(host, port)
 return shortport.http(host, port)
end

function action(host, port)
 local httpResp
 local msg = {}

 -- Abort if the HTTP response is empty or not 200 OK
 httpResp = http.get(host, port, url)
 if httpResp.status ~= 200 or httpResp.body == "" then
  return nil
 end

 -- Abort if known "access denied" strings are found
 for k,v in pairs(negativeCriteria) do
  if string.find(httpResp.body,v) then
   return nil
  end
 end

 -- Abort if known registration page strings cannot be found
 for k,v in pairs(positiveCriteria) do
  if not string.find(httpResp.body,v) then
   return nil
  end
 end

 -- Output message
 msg[#msg+1] = "Possible CMS user registration interface at:"
 msg[#msg+1] = port.service .. "://" .. host.targetname .. ":" .. 
   port.number .. url
 return stdnse.strjoin("\n", msg)

end

In case anybody is still wondering...

Given the media attention to recent hacks (Anonymous, AntiSec, NoNameCrew, etc) it is easy to observe how the public reacts to these incidents and read some comments on what people think about it. The most common reaction seems to be astonishment and a bit of surprise how apparent technical barriers can be circumvented.

Google dorks are by no means new, but do a good job in demonstrating how easy it could be sometimes. In the case of the German Customs Authority hack a misconfigured XAMPP installation seemed to be the gateway into the internal network. XAMPP is a preconfigured web development environment not intended for production use, as some security options are purposely turned off. Want some more XAMPP installations connected to the internet? Click here.

Looking for access to phpMyAdmin, a tool to administer web sever databases (and potentially to get full r/w access to several web sites at once)? Click here. Looking for user names and passwords of FTP logins, potentially used for web site administration? Click here. (By the way, a free online tool to decrypt these obfuscated passwords can be found here.)

Looking for access to the JMXConsole, an administrative interface of the JBoss application server that potentially allows you to upload your own applications and execute arbitrary operating system commands? Click here.

All in all, from my point of view, chances that a person with little knowledge can easily carry out an attack that gets media attention are quite high, if the attack process is turned around: Don't pick a juicy target and search for vulnerabilities - instead take a vulnerability or misconfiguration and search for a well-known target.

What login screens reveal

This picture was sent to us by Flo just a couple of days ago. Thanks buddy, keep being that active! What it shows is a company's desktop background. We don't have much more information on that but we can tell from experience that you find such screens a lot more often than you would think.
Administrators in big companies tend to use the desktop background to include detailled information on (most likely server) systems they use. This if of course helpful if you do a lot of remote work and don't wanna accidentally reconfigure a wrong server. However, as practical as it might be for admins, as practical is it for remote (or even local) attackers.

There is some information anonymised on this picture, but I'm sure you get that there are a lot of questions that can be answered just by looking at this picture. You can probably derive the server's role in the network from its hostname. IP address info gives you more knowledge about the network - how a local user could connect or in which address space the servers reside in. You get information about which domain the server belongs to and even get alrady a valid administrator username! You don't have to do any OS recon anymore, do you? Just start preparing your exploints right away. And if you are not sure if a DoS attack would be viable - just have a short look at its cpu, memory, volumes and free space.

Decide yourself if you wanna give all this information to strangers in your network, but probably you do better with increasing the awareness of your admins.

Information disclosure classic

A few days ago, I spent a couple of hours on a train which by chance lead me to the following information disclosure classic. The person in front of me did some work on his notebook and obviously was not aware that someone might be watching. He was editing a cooperation aggreement that of course showed the involved parties on its first page and allowed me to read some details.

I googled the companies (mostly in the field of smoke detectors and facility management) and from what I saw, they are not really "big players". But I am pretty sure a lot of large companies also fail in protecting their internal information in these situations. A simple screen privacy filter would have done the job. :-)

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