Onity HT lock provides its own key when questioning it

The vulnerability found by Cody Brocious and presented at BlackHat Las Vegas 2012 deserves an entry in this blog. The Onity HT lock is installed on a huge amount of hotel doors around the globe and you might have already seen it, when you stayed in couple of hotels. 

 

This picture was extracted from Cody Brocious' talk at the BlackHat 2012 in Las Vegas.

Even more disturbing is the vulnerability that Cody discovered. Every lock has a small barrel-type DC power socket on the bottom. This is used to charge up the battery, when it is empty, but also to program the lock. Every hotel has its own random sitecode installed, which is used to encrypt/decrypt cards, program locks or open locks. This 32-bit key, however, is stored in the lock's memory and by connecting to the power socket, an attacker can extract the key. Moreover, the key is always stored on the same location and no authentication at all is needed to the extract the key.


More information can be found on Cody's website: http://daeken.com/blackhat-paper

Free cigarettes, anyone?

I know that is a very simple and very obvious one, but do not leave your cash / ATM card unattended in public space!

We got that one sent in at the end of last year before Christmas shopping, but the honest finder did return it the person to whom the card did belong to. Interestingly though, how much information somebody could get out of a card, apart from the money, of course. There is still some information stored on the magnetic stripe of the card and magnetic stripe card readers are easy to obtain.

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. :-)