About two months ago the Bluetooth SIG renamed their latest standard, which was previously known as “Bluetooth v4.0”. When version numbers get higher and higher marketing likes to interfere and try something new. In this case: Bluetooth Smart.
Sounds smart, but is it?
Without getting into too much detail, let me quickly quote Wikipedia to get started:
“Cost-reduced single-mode chips, which enable highly integrated and compact devices, feature a lightweight Link Layer providing ultra-low power idle mode operation, simple device discovery, and reliable point-to-multipoint data transfer with advanced power-save and secure encrypted connections at the lowest possible cost.”
So we’re talking about the usual stuff: Lower energy consumption combined with more functionality. Great!
Ubertooth One - Photo from: ubertooth.sourceforge.net
Sounds smart, but is it safe?
With “Bluetooth Smart Ready” products just coming in it’s too early to tell. But one thing is for sure: 2012 will be the year where every major consumer product (smartphones, heart-rate straps or even simple clocks) will be equipped with it. Oh, and guess what… a new wireless standard doesn’t just come along with a new shiny gadget. Obviously you need an app for that. How about tracking your heart beat? Personally I’m looking forward for the first Bluetooth Smart Ready cardiac pacemaker…
And back to security: Either you trust the Bluetooth committee which states “Bluetooth technology is an industry leader when it comes to wireless data security.”, OR you ask somebody who would tell you the plain truth (given there is one): Michael Ossmann.
We did the latter and invited Michael to talk at TROOPERS12. He is a wireless security experts who also makes hardware tools to progress with his research. In early 2011 he successfully crowd-funded his latest gadget: Ubertooth One. A very capable Bluetooth monitoring device.
We’re looking forward to mid March where we all meet to discuss things in more depth at TROOPERS12. Until then keep yourself up-to-date and have a look into Michael’s latest blog entry: Bluetooth for Bad Guys
Have a wonderful Christmas time,
Florian
PS: Drop us a comment, when you find some “Bluetooth Smart Ready” labels under your Christmas tree 😉
During one of our pentests in some corporate environment we were to analyze an application-server called Liferay. Liferay comes with a lot of functionalities, runs on top of Apache Tomcat and includes a nice API that makes it very easy to add components or further functionality that are not part of the core. These (potentially selfmade) “addons” are called “portlets” and they can be inserted in any place in the frontend.
We quickly found an active default-account (test@liferay.com : test) which immediately led to the question: how to get access on the system-layer through the account on the application. Because we were not aware of any portlet which provided the desired functionality, we decided to write it on our own and created a straight-forward portlet for system level command execution.
As mentioned above, Liferay offers an API for adding portlets to the core. This can be done by creating a standard war-file which contains java-classes, including the desired functionality and some – in this case – Liferay-specific xml-based configuration files. War files are often used to expand the functionality of java-servers (e.g. Tomcat can also be extended via war-files) – it just needs to contain the application-specific xml-files.
Our java-class includes a html-form consisting of an input-field and a button, which sends commands (via GET) to the server. On the server the input gets executed in a shell – a new java HTTP-Shell is born. After some adjustments regarding to the operating system and the java compiler (1) we had a GET-Parameter-based HTTP-Shell.
The following steps are necessary to deploy the shell portlet:
3.) Execute create.bat / create.sh [Note: javac and jar must be installed in the PATH.]
4.) Have fun with the ShellPortlet.war
How to deploy the war-file?
1.) Login to your Liferay-System with a privileged user-account and open http://yourdomain.com/group/control_panel/manage
2.) You should find a category called “Server” on the left side in the navigation. Click “Install Plugin” and on the next site click “Install more plugins” followed by “Fileupload”
3.) Upload the war-file and use “tail -f $CATALINA_HOME/logs/catalina.out” or (on Windows) the Tomcat-console to observe the logs for any error/exception. When everything worked you’ll find an entry like “1 Portlet for ShellPortlet is available for use”
4.) Now go back to your mainpage via the link in the upper area “Back to Liferay”. Then click “Add” -> “More” and you will see all categories in which the portlets are sorted.
5.) If everything went right you will find a category named “Ownage” in this list. Click on it and drag&drop the shellportlet anywhere on your website.
6.) Have fun playing! 🙂
This shows – once again – that it’s not that hard to gain system-access over a (web-) application. Everyone who uses web-applications should secure the higher-privileged accounts by strong passwords or better deactivate them in case they are not needed. It also shows that – once again – comprehensive and reasonable hardening would have prevented the compromise of yet another system.
(1): The java-class must be compiled by the same compiler-version which the tomcat-server is using. (E.g.: If the tomcat uses jre1.6, the java-class in the war-file must be compiled by a javac which is out of the jdk1.6)
today I’ll give a short preview of my newest tool, pytacle. It is simply a little helper program to control gnuradio/airprobe/kraken/some_other_tools, convert their input/output and to find a use able clear/cipher text combination to break A5/1. In the end it should record, crack and decode/play a gsm phone call with ~5 mouse clicks.
Take a look at this video:
The code is not available yet, as its not finished 😉 the recording and cracking part are working, but the decoding doesn’t. I need to put some more time into the code, but there isn’t much spare in that time of the year 😀
On last year’s TROOPERS11, Matthias (mluft) and I gave a talk on Multifunction Devices. Hardly surprising: It was related to the state of secure operation of MFDs. It was heavily motivated by experiences we collected out in the wild. We faced a frightening low level of awareness concerning the role of MFDs for the overall security picture – in particular regarding the processing of sensitive data…
However, instead of only showing and proving well-known weaknesses and vulnerabilities, we decided to adapt ERNW’s Seven Sistersmodel in order to match the needs of secure MFD operation and to develop some kind of guideline. As Matthias already lost some words on this, I’m not gonna waste your valuable time by repeating, what has already been said. However I described our approach and our thoughts on that topic in a recently published ERNW Newsletter. If for what ever reason you didn’t see our talk or even didn’t attend TROOPERS11 at all, have a look on Newsletter 37 and give us feedback on what you think about the whole topic…
Btw: Enno just wrote some lines about what’s so special about the TROOPERS conference. In case you might want to discuss mentioned and related topics at first hand, think about joining TROOPERS12. For our part, we cannot wait to come together at Heidelberg next March.
This is a _very_ interesting paper just published by some researchers (mainly) from RUB (Ruhr-University Bochum). Here’s the abstract:
“Cloud Computing resources are handled through control interfaces. It is through these interfaces that the new machine images can be added, existing ones can be modied, and instances can be started or ceased. Effectively, a successful attack on a Cloud control interface grants the attacker a complete power over the victim’s account, with all the stored data included.
In this paper, we provide a security analysis pertaining to the control interfaces of a large Public Cloud (Amazon) and a widely used Private Cloud software (Eucalyptus).
Our research results are alarming: in regards to the Amazon EC2 and S3 services, the control interfaces could be compromised via the novel signature wrapping and advanced XSS techniques. Similarly, the Eucalyptus control interfaces were vulnerable to classical signature wrapping attacks, and had nearly no protection against XSS. As a follow up to those discoveries, we additionally describe the countermeasures against these attacks, as well as introduce a novel ‘black box’ analysis methodology for public Cloud interfaces.”
===
While the actual described vulnerabilities have been fixed in the interim this stresses once more the point we made in this post: the overall security posture of the management (or “cloud control” as the authors of the above paper call it) interfaces is crucial for potentially all the data that’s processed by/on your cloud based machines or applications.
Great research from those guys! This will help to drive the discussion and security efforts for a reasonable use of cloud based resources in the right direction…
After having introduced the basic elements of our concept of trust, control and confidence in this post, today I’ll try to strengthen your (and maybe even my own as well ;-)) understanding of these ideas by applying them to another candidate, that is Dropbox. Hence this post is mainly about performing a certain analysis method to some object; conclusions as for the question if Dropbox is suited to be used in enterprise environments processing sensitive data are out of scope and are left entirely to you, the valued reader.
Two more preliminary remarks might be helpful to further understand the direction and intent of this post:
a) I don’t have any practical experience with Dropbox. I don’t use it personally and at ERNW using it for company-related data would require a risk acceptance, which – probably not too surprisingly – no company member has ever filed (and which would have a quite high likelihood of being turned down by the CEO anyway ;-)). In other words: I can’t imagine any occasion we’d use cloud based storage services for any of our data. It’s just that – given our idea of “highly skilled, thoughtful and responsible humans working here” – we don’t use terms like “xy is strictly forbidden” very often…
So feel free to jump in by PM or comment to this post if this stated lack of practical experience has lead to wrong conclusions or factual errors.
b) This post is not about blocking Dropbox in corporate networks by technical means (which – afaik – is relatively easy compared to, say, blocking Skype, as DB seems to operate mainly from a well-defined /24 network range). Doing so (technically blocking DB on corp firewalls) would not solve the underlying problem of potentially misplaced trust (or ignorance) and might just lead to yet-another-risk-acceptance popping up on the ISOs’ desks (I know, I know: some of you would be happy if at least a risk acceptance existed for DB within your organization…). And, of course, the corp_fw way would not address the aggregate problem of running Dropbox on mobile devices (at least assumed that no cloud based proxy services are in use for those, which is currently the case in most networks I know).
However this post is about asking a certain set of questions and clarifying some company’s or service’s attributes to induce a reasonable discussion about the exact company’s/service’s suitability for processing sensitive assets. To us, such an approach is aligned with our understanding of an ISO as a trusted business advisor (as opposed to the “paranoid pitbull” or “unfortunately unheard master of governing guidelines” mission understanding of ancient times).
Now let’s have a look at the object of today’s trust exercise, that is Dropbox. Founded in 2007 and fueled by US$ 7.2 million venture capital (as of this Forbes article) the California-based company provides cloud-based file storage services with a simple GUI and some nice collaboration capabilities for groups of users sharing files. The description in the CrunchBase profile goes: “Always have your stuff, wherever you are”. A technical overview can be found in this paper recently presented at USENIX Security.
As you might recall from the first post of this series, there I laid out some trust contributing factors, which I took from the ISECOM “Mastering Trust” methodology that is taught in their Trust Analyst course (pls note that my interpretation of these may be wrong as I never attended that course. sorry, Pete ;-)).
These are:
Size – “Who exactly are you going to trust?”
Symmetry – “Do they trust us?”
Transparency – “How much do we know about $TRUSTEE?”
Consistency – “What happened in the past?”
Integrity – “[How] Do we notice if $TRUSTEE changes?”
Value of Reward – “What do we gain by trusting?” (that’s the one that Ponzi schemes are based on)
Components – “Which resources does $TRUSTEE rely on?”
Porosity – “How separated is $TRUSTEE from its environment?”
Applying all these to Dropbox might yield the following answers:
a) Size
While this might seem a simple one given Dropbox is a not-too-big company presumably held by their founders and some investors/venture capital providers (plus maybe employees holding stocks or options or sth) it should be noted that, more or less obviously, there’s more entities in the overall picture => see below at section “Components”.
b) Symmetry
Usually this one is hard to apply to B2C scenarios, so I’ll skip it here.
c) Transparency
Honestly, as I’m not a user of their service I don’t have a ultimate attitude here. However from a trust analyst point of view I just note there’s a number of people out there who think that DB failed severely in this regard. And there’s a (still pending?) complaint for injuctive relief filed to the FTC stating that Dropbox “continues to make deceptive statements to consumers regarding the extent to which it protects and encrypts their data.”
So overall this one (transparency) seems at least debatable; see also discussion on factor “Integrity” below.
d) Consistency: well, probably most of you know that three months ago DB suffered a breach which exposed all online storage lockers to anyone entering any password for ~ 4 hours.
Strictly taking the “consistency road” this does not contribute to their trustworthiness, from my humble evaluation.
e) Integrity
This post from the Hunton & Williams privacy blog provides an overview how Dropbox’ security statements (on its website) changed over time. I tend to assume the majority of users is/was not aware of those changes. In general it seems that one of their main communication channels is their blog. Which – given that most of you probably read a blogpost right now 😉 – might certainly be a valid channel… for B2C scenarios in modern times at least. Not sure if this is the right channel for the security properties of corporate information assets though.
f) Components
This is a particularly interesting one. As obvious as this may be, most users are probably not aware that DB does not operate the servers providing the service themselves. To the best of my knowledge the (Dropbox) service heavily relies on Amazon S3 and EC2 instances, in a certain setup that Mulazzani et.al., in their paper, comment on as follows: “However, the fact that encryption and storage is done at the same place seems questionable to us, as Amazon is most likely able to access decryption keys”.
g) Porosity
We can’t provide an evaluation here as we do not dispose of any information as for clear demarcation lines on the financial (e.g. who might potentially influence DB’s decisions due to simple ownership of shares ;-)) or organization/infrastructure (which 3rd parties actually provide which type of supporting service, e.g. do they share their office space with other parties in a business/office incubator etc.) sides of things.
So, once again, taking a structured approach when evaluating some party’s trustworthiness (to counter the fact that trust – by it’s very (Diego Gambetta’s) definition that we used in the initial post – is sth subjective) leads to – hopefully – interesting insight and results. Still, in this particular case, there’s another potential use of this way of looking at things: when dealing with (business’ desire to use) Dropbox in your organization, you might convert this points into a simple (one slide ;-)) checklist containing questions like
Do you know who owns the company Dropbox?
Do you know where their servers are located?
Do you know if they own the servers providing the service themselves or who else does this on their behalf? And where the servers of that “other party” are located? Which legislation applies there?
Do you know that they just suffered a breach temporarily allowing anyone in the world to access any one of its 25 million customers’ online storage lockers, simply by typing in any password?
Do you know who owns the keys necessary to decrypt data stored under your account?
[in case you like to promote your concerns the FUD way – which we do not like or recommend – you might add: “If you were a well-funded attacker, maybe from an emerging market, would Dropbox be an interesting target for you?”…]
If some people within your organization are still going to use DB for corporate data then, well, that’s an “educated decision by business” [no, no, the quotes are not put here to hint there might be a contradictio in adjecto ;-)].
Stay tuned for more stuff to come in this series & have a good week,
Enno
btw: we’ll probably have a talk about Dropbox at next year’s Troopers which takes place on 03/21 and 03/22 2012 in Heidelberg.
A few weeks ago, I released version 0.9 of a web application testing tool called tsakwaf (The Swiss Army Knife for Web Application Firewalls) together with an ERNW Newsletter about web application firewalls. tsakwaf is based on perl and supports fingerprinting of some supported WAFs and code generation methods to circumvent filter rules. Today, version 0.9.1 will be released, which adds SSL support for the WAF fingerprinting function (Big thanks to Simon Rich!) and a bug fix regarding the detection of WAF reactions which may lead to false positives. Additionally, I’m happy to announce that at least one talk at next year’s Troopers will cover attacks against WAFs (like this one from the 2009 edition) . So mark your calendar – Troopers12 will happen on 21st and 22nd March 2012, with the usual workshops before the conference and the round table sessions the day after – and enjoy playing with tsakwaf!
During our ongoing research on the security of cloud service providers and cloud based applications, we performed a regular audit of our AWS account password. Thinking of popular incidents and evergreens in attack vectors, we were wondering which consequences an online bruteforce attack on our AWS password would have. So we decided to perform a bruteforce attack against our own account. Analyzing the login process of AWS, the following requirements for the bruteforce tool to be used could be derived:
Cookie Handling
HTTPS support
HTTP 3xx support.
It turned out that it was pretty hard to find a password testing tool which fulfilled these requirements and would be able to actually handle the complex AWS login process — eventually there was none. Since we use and like Burp Suite pretty much, the Intruder suggested itself as an alternative which is straight forward to configure even though it might lack the speed and efficiency of special bruteforcing tools. Using burp’s history, we were able to identify the request which triggered the login process:
After the request is sent to the Intruder, the password field is marked
and the payloads to be used are configured.
Using exemplary payloads, it is possible to identify a successful login attempt, since it results in a redirect to the authenticated area/SSO server/whatever whereas a wrong passwords results in HTTP 200 presenting the AWS login page again:
Having this basic bruteforcing process established, the wordlist to be used must be generated. To decide which complexity should be covered, the Amazon password policy must be analyzed — if the restrictions in place deserve to be called a policy. The only restriction is that the password is between 6 and 20 characters (though the upper limit was determined regarding the maxlength field parameter when changing the password using the webfrontend, since there is no documentation about this available. Thinking of business needs, this behavior might be understandable since Amazon loses “endusers” and therefore money if their password policy is too strict). So we decided to use a wordlist which contains all passwords of 6 characters consisting of numbers (which can be generated pretty easy reactivating some old perl scripting skills: perl -le ‘printf “%06d”, $_ foreach(1..999999)’ 😉 ). Such passwords even might be pretty common when thinking of “birthday passwords”.
After performing about 400k requests, we paused the attack and searched for requests which resulted in a HTTP 302 response, just as the baseline request did.
And indeed, it was possible to bruteforce the password — which is not such a big surprise though. The bigger — and worse — surprise is, that it was still possible to login to our amazon account after performing about 2 million requests (including some dry runs) within two days originating from one single IP adress without having the account locked, being throttled down or notified in any way. And we were performing about 80k requests per hour.
Coming back to the title of the blogpost: At the moment of our investigation, there were no protection mechanisms against bruteforce attacks for the key to your datacenter — which your AWS credentials actually can be, if you are hosting a large amount of your services in EC2. Following a repsonsible disclosure policy, we contacted the AWS Security Team and got a very comprehensive answer. As we supposed, they pointed us to their MFA solution, which is basically, even though there was a major incident recently, a viable security control when authenticating users for data center access. But in addition, we had a long and beneficial dialog about potential mechanisms such as connection throttling and account locking. The outcome of our discussion is a CAPTCHA mechanism which kicks in after a brute force attempt is detected — and was also re-tested several times by our bruteforcing attempt. It was quite impressive to see that it was possible for Amazon to implement additional security measures in such a short time frame, regarding the huge size and complexity of the AWS environment. So we were really glad to get in touch with the committed AWS Security Team and were really happy to see that those guys are really into security and trying to communicate with their customers.
Today I’m proudly releasing the first version of apnbf, a small python script designed for enumerating valid APNs (Access Point Name) on a GTP-C speaking device. It tries to establish a new PDP session with the endpoint via sending a createPDPContextRequest. This request needs to include a valid APN, so one can easily distinguish from a valid APN (which will be answered with a createPDPContextResponse) and an invalid APN (which will be answered with an error indication message). In addition the tool also parses the error indication and displays the reason (which should be “Missing or unknown APN” in case of an invalid APN).
Don’t waste time, get the source here (5a122f198ea35b1501bc3859fd7e87aa57ef853a)
So, after having a completely new release yesterday, we will stay with already known but updated software today. You might have heard of gtp_scan before, which is a small python script for scanning mainly 3G and 4G devices and detecting GTP (GPRS Tunneling Protocol) enabled ports. As GTP is transported via UDP and we all know, UDP scanning is a pain, the tool uses the GTP build-in echo mechanism to detect GTP speaking ports. Since the last version I’ve implemented some new features:
Support of complete GTP spectrum (GTP-C, GTP-U, GTP’)
Support for scanning on SCTP
Improved result output, including validity check of response packages
Find the sources here (bbdcc8888ebb4739025395f8c1c253fa5fd2bb15).
About two months ago the Bluetooth SIG renamed their latest standard, which was previously known as “Bluetooth v4.0”. When version numbers get higher and higher marketing likes to interfere and try something new. In this case: Bluetooth Smart.
