Hacker-Tool – Unix Sec Lab

Hacker-Tool Hump-Day – ps

I had less time to work with the new Bash Bunny than I anticipated. I chewed on what to cover for today, but a team mate (my team lead) at work stumbled upon a new flag for “ps” that we either hadn’t seen before, or had forgotten completely existed, and it’s a pretty cool flag.

The “-T” flag takes a process ID (PID) and presents a “tree” view of it and all of its child processes similarly to how “htop” works.

Being able to see the children of a PID at a glance is nice when you’re trying to track down problems with complicated scripts that fork off lots of children.

To get the entire process view in tree format, just pass in PID 1.

ps -T 1

You can always pass the -o flag to narrow the view. The example we came across used -o to show the PID, owner, and command.

ps -T 1 -o pid,user,command

This is also useful in an incident response situation to see if there are processes that are spinning off children that don’t make sense. A long lasting “vi” session running a shell child would be very suspicious, for example.

I know this was short, but it’s a really nice tip to share, which was quick to write up with all the interruptions I’ve had today.

I really appreciate all of my readers.

I hope you’ve enjoyed!

Hacker-Tool Hump-Day – LAN Turtle Modules – ddnsc

The Hak5 LAN Turtle has a module for configuring a dynamic DNS client. This module is the “ddnsc” module, and configuration requires four fields to be filled in.

The first is the “Service” field, which is the Dynamic DNS provider service you will use. This might be “no-ip.com” or “dyn.com” or something similar.

The second field is the “Domain” field, which is the domain name you have reserved through the service. Once upon a time, I had DynDNS as a service, and they had a “homeunix.org” domain available. Mine was configured for “abtg.homeunix.org” at the time. I no longer use this service, but that’s an example of what you would need to put into this field.

The third is the “Username” field, which is whatever user name you signed up with your dynamic DNS provider for authentication with their services.

The final field is the “Password” field, which is simply the password you use to authenticate your user against that domain.

Internally, the module uses “uci” commands, which are part of the OpenWRT router project to provide a centralized configuration tool for the router functionality. It also does an “opkg install ddns-scripts” to pull down the standard scripts for this from the OpenWRT repositories.

The module is simple enough, but it provides a great way to get a persistent means of looking up the current external IP to whatever LAN the Turtle has been dropped on, if that network has a dynamic IP address on its WAN side. This way, you can get to your turtle on whatever known open port you have set up for use.

This has been short and sweet, but it has gotten late on me, so that’s the best kind of post I can give for today. Thanks for reading, and leave comments!

Hacker-Tool Hump-Day – Kali Nethunter on Nexus 10 tablet

Last week, my Nexus 10 tablet arrived in the mail. I ordered this tablet with a few purposes in mind, but foremost was my intention to run Kali Nethunter on it. I chose this particular tablet, because the forums seemed to indicate few issues with this device, the screen size is quite nice (for a tablet,) and it doesn’t have cell phone capabilities. I specifically wanted a tablet that only worked with local wifi, and not cellular networks. I chose the 32 gig version, because there is no documented way to increase the local storage.

The package arrived, and my wife texted me that it looked a bit beat up. When she showed me a picture of the package, my first thought was the opening scene from Ace Ventura. The device itself was okay, thankfully, so I placed an order for a tablet case/cover with keyboard, and began prepping the tablet for its new function in life.

The first evening, I allowed the tablet to update as far as it could, then went into the System Updates and selected updates manually until it went from Android 4.2.2 to 5.1.1. After each major update, I powered the tablet off and turned it back on. This took most of the evening, so I installed Netflix on it, and my wife and I curled up to watch the last episode of Blacklist available on the streaming service before going to sleep.

The next day, I downloaded the tools to my linux laptop for dealing with unlocking and rooting the device. The table of supported devices at the Kali Nethunter page said that Android 5.1.1 would be sufficient, but that the device would need to be unlocked and rooted, so that was the goal.

I downloaded android-studio-ide-145.3360264-linux.zip from https://developer.android.com/studio/index.html and extracted the zip file. Then I changed directories to android-studio/bin and ran “./studio.sh” to set up the initial installation. Unfortunately, this wasn’t what I needed or wanted, but I didn’t know that at the time. Once I figured out why things weren’t looking the way I expected, I went back to the developer site and found out that you need to scroll way down the page to get the actual file needed. I went up a directory and removed the files from this initial bad download.

I downloaded android-sdk_r24.4.1-linux.tgz this time, and extracted the tarball. I changed directories to Changed directories to android-sdk-linux and ran tools/android. I went through the GUI but it was having issues with updating, so I went to “Selected Tools => Options” and checked the “Force https//… sources to use http://…” check box to deal with the “peer not authenticated” errors. I assumed these were caused by our corporate gateway that cracks open SSL for inspection, and turning this on did indeed work.

From there, I went to the “Packages” list and selected the “Android 5.1.1(API 22)” packages. I selected all of these, and told it to install the packages, accepted the license, and then hit “install.” I exited the SDK GUI, but had to come back to this and do this step again after connecting to the tablet later down. This step only installed two items, and there were well more than two needed before I was through.

On the tablet, I swiped down twice to click the settings gear, went ot “About tablet” and tapped the “Build number LMY49J” seven times to put the tablet into developer’s mode. It indicated as much with “You are now a developer.” I went back one screen and selected “Developer Options” which was now available, and turned on “USB debugging.” At this point, I plugged the tablet into the computer using the USB cable supplied with the tablet.

I ran a “dmesg” on the laptop to confirm it was seen as a new device, then ran “platform-tools/adb devices” to verify it was seen by the developer tools suite.

At this point, I re-ran the GUI tool “tools/android” and selected the rest of the files that were missing for my tablet. Once they were all installed, I was able to do the “platform-tools/adb devices” command again.

To put the device into fastboot mode, I ran “platform-tools/adb reboot bootloader” and while the tablet was at the fastboot menu, I ran the following command from the laptop to unlock the device:

platform-tools/fastboot devices
sudo platform-tools/fastboot oem unlock

If the first command (fastboot devices) doesn’t show your device, even if adb devices does, something is wrong and more troubleshooting is needed. Otherwise, go ahead and do the fastboot oem unlock at this point.

My table rebooted and seemed to be stuck in a boot loop. The graphic with the four swirley colorful dots never seemed to stop, so I did some online research and found that this device is known for getting in a boot loop after the unlock. The solution is to go back to fastboot mode by holding down both volume up and volume down as well as the power button (all three) until it reboots. Once it is back in fastboot mode, use the volume buttons until the menu says “RECOVERY MODE.” Push the power button again, and let it “recover.”

Because it took me some time to figure out how to get it out of the boot loop, I spent the rest of that evening letting it recover from the online backup it had made, then headed to bed with my wife.

On day three, I set up all of the developer tools again, put the tablet back into “Developer mode,” and hooked it up to the computer. I downloaded nethunter-manta-lollipop-3.0.zip via https://www.offensive-security.com/kali-linux-nethunter-download/ to my laptop. I also downloaded TWRP (Team Win Recovery Project) from https://twrp.me/site/update/2016/04/05/twrp-3.0.2-0-released.html per the recommendations on the Nethunter Wiki. The file was twrp-3.0.2-0-manta.img in case you’re following along.

In order to install twrp, I changed directories to the android-sdk-linux/platform-tools directory from the day before, and ran:

adb reboot bootloader
sudo fastboot recover twrp-3.0.2-0-manta.img

I installed via the menu options, then pushed the nethunter image across with:
adb push nethunter-manta-lollipop-3.0.zip /data/local/tmp/nethunter-manta-lollipop-3.0.zip

Back on the tablet, I navigated up, then back down to the appropriate location data => local => tmp.

I selected the ZIP file and told it to install, answered the questions presented, and rebooted.

Unfortunately, something went wrong with the installation using this method. Some more research, and I found that I could repair this by uninstalling the individual nethunter applications and then installing the latest “APK” file, instead. This meant I needed to get the latest.apk. I also needed to install SuperSU, which was an option that was unchecked by default in the ZIP install menu.

I went to Google Play to install SuperSU, then continued with the APK installation as below.

I opened chrome and selected the following URL to get the APK needed:
https://images.offensive-security.com/latest.apk

I then installed that by selecting it through the downloads folder, and it installed better. I’m not sure it installed perfectly, yet, but it at least has the nethunter app, now.

I then had to set Nethunter to be allowed with super user privileges by SuperSU.

Unfortunately, it says there’s no busybox, and I’m not sure if that got missed by the APK, or if something else is going on. TWRP wants to install a BusyBox app, but it’s not the one built into the Nethunter suite. I may go ahead and install that one, but I’d rather have the one provided by Nethunter.

Due to the extreme hecticness of this holiday season, I haven’t had an opportunity to really play with this, yet, but I will go through and work with it some more so that I can do a decent write up of some of its features, before I’m through. In the mean time, I’ll return to covering the Hak5 LAN Turtle modules next week.

Thanks for reading!

Hacker-Tool Hump-Day – Hak5 LAN Turtle module – ptunnel

The next module for the Hak5 LAN Turtle we’ll look at is the ptunnel module. This is for the “ping tunnel” program, which allows tunneling TCP traffic over ICMP. It’s not exactly fast, but it can potentially get you out where other tools won’t.

To use ptunnel, you want a “client” configuration, and a “proxy” configuration. The PROXY must be running somewhere outside of the firewall you’re having issues with, and you must be able to ping the host it is running on. To start the proxy just call “./ptunnel” without any flags. If you test this and it doesn’t work, you can try one or more of the following flags:

If you need packet capturing, use the “-c ” flag with this.
You might want to try it in unprivileged mode first, with the “-u” flag.
You can set an arbitrary password with the “-x ” flag, as well.
Finally, if you want some logging at the proxy side, you can use the “-f ” and “-v ” flags.

Once the proxy is running and waiting for connections, you can use the module on the LAN Turtle to connect to that.
A standard client connection would look like this:
ptunnel -p -lp -da -dp

For example, if we wanted to be able to ssh over ICMP to our proxy box (proxy_server) and our listening port for this is locally set to 443,
and the target to ssh to is the host “server_x” on port “22” because it’s the standard ssh port, we would run this for a client set up:
./ptunnel -p proxy_server -lp 443 -da server_x -dp 22

We would then run ssh like so:
ssh -p 443 localhost

Well, the module has four configuration settings you need to fill in through the module configuration menu.
Those four settings all correspond to the four items we just discussed:
-p Proxy Server – called “PTunnel Host” in the menu
-lp Local Port
-da Destination Address – called “Dst Server” in the menu
-dp Destination Port

Note that there is no configuration for a password here. If you want to use a password on your proxy set up, you’ll need to manually configure that, or modify the turtle script to include it.

There is also no configuration through the Turtle menu to run the Turtle as the proxy host. Only a proxy client. You of course can always run the host yourself from the command line, though.

Again, this isn’t the fastest way to get your packets where they’re going, but it does work well when it works at all.

Also, if you do decide to run this, be responsible. Don’t break out of your corporate firewall if it’s against corporate policy… and it almost assuredly is.

Thanks for reading, and if you liked this or even didn’t like it, leave a comment below!

Hacker-Tool Hump-Day – Hak5 LAN Turtle module – sshfs

There is a very nice program that allows you to use an ssh connection to “mount” a remote directory as if it is local. This program is called “sshfs,” and it sometimes makes things easier from the perspective of needing to copy a lot of files between systems, but not wanting to deal with the scp or sftp commands to do it. The Hak5 LAN Turtle has a module for this, and the primary purpose of this (most likely) is to assist in off loading large files to a remote location. You could use sshfs to remote mount a file system on another machine you control, then configure your ex-filtration tools to dump their payloads to that directory. In essence, the payload would never truly be written to the turtle in the end.

To use this, you need to go to the modules and choose “configure” as you would any module we’ve covered, thus far.

The configuration takes a “Host” a “Port” a “User” and a “Path” as options to be filled in. Since a “Password” is not among the options, you will need to do some preliminary work as well. The ssh keys would need to be generated and configured for the target user at that host.

The “Path” option can be left empty if you just want to use the target user’s home directory for the path.

Once everything is configured, use “Start” to make sure it works, and “Enable” if you want it to persist, as normal.

This module is quite nice consider the very limited space on the LAN Turtle, so play with it. I think you’ll enjoy the benefits.

Thanks for reading!

Hacker-Tool Hump-Day – OpenSSL

We’re skipping the LAN Turtle module that would have been show cased this week in favor of a short post. On the bright side, I got 1804 words written for my first day of NaNoWriMo 2016. On the less than shiny side, I’m oncall this week at work, and I’m short on time for the Wednesday post. So let’s get to it.

Today’s topic is a tool that some people may not realize can be used in the same vein as telnet, netcat, and socat for connecting to ports and testing them with manual manipulation of whatever the plain text protocol might be (such as HTTP or IRC, for example.) It can also be used to stand up a temporary SSL enabled service for testing how clients behave, similarly to how a netcat listener might be used.

To test connectivity, use the “s_client” module with the “-connect” flag. The target of the -connect flag should be an IP or hostname with a port, and separated by a colon. For example:
openssl s_client -connect google.com:443

Once you connect, you should see some information about the certificate along with a status code to indicate what the problem is if the certificate doesn’t meet expectations. It will then sit and wait for you to send whatever commands you might like just like a telnet or netcat connection would do. It handles the actual SSL handshake for you.

The listening option is the “s_server” module with the “-accept” flag. The target of the -accept flag is just a port number. Of course, the listening service should probably also be given a certificate to use for the listening connection, so use the “-cert” flag to pass a certificate to this command for use on the listening socket. You can set up a listening socket without a cert by using the “-nocert” flag, but this is kind of pointless.

Again, the primary focus of this for most people will be the s_client module, so that SSL enabled ports can be probed for banners and such. Alternatively, shell scripts can be written that call this in order to automate certain kinds of connections with intentionally malformed requests to test how the server behaves, or to pass known vulnerable requests to the server, and so on.

Of course, it can also be used to look at the server’s certificate and settings in case there is a vulnerability there, such as a weak cipher list, for example. Perhaps the certificate is due to expire, soon. A man in the middle situation might be easier to set up during that window between certificate expiration and certificate renewal if the site owner allows the cert to fully expire before renewing. Possibilities are almost endless.

That’s all for now. Thanks for reading!

Hacker-Tool Hump-Day – LAN Turtle Modules – netcat-revshell

Since we’ve covered netcat in the past (briefly,) this is a good module to jump in on for today.

This module creates an outbound netcat connection to an already listening netcat remote listener, and presents a shell to that connection. It almost sounds backwards, but here’s the set up.

Before you configure this module, you need a shell account on a target box that also has netcat installed. For my example, the box is OpenBSD based, so the “netcat” is “nc” and has all of the flags I care about by default. We’ll call this “Server_B” since you’re connecting to this as a target. The first step is to get the IP address of the server. An “ifconfig -a” shows all of the interfaces, or an nslookup of the domain name should get this for you. If it has multiple interfaces configured, you can check the routing tables with “netstat -nr” and look for the default gateway to figure out which IP belongs on that subnet. Whatever the case, the LAN Turtle needs to be able to talk to that same network from its ethernet jack.

For our purposes, we’ll assume the IP was 192.168.0.7.

We also need an available port. “netstat -an | grep LISTEN” will show the ports already taken. For this example, 8080 is free, so we’ll use it.

To set this up, run the following netcat command:
nc -k -l -v 192.168.0.7 8080

Now switch to your LAN Turtle interface, and go to the Modules menu. Select the netcat-revshell module and go to “Configure” to toss the IP and PORT into the fields. After you back out, you can hit “Start” and you should see activity on the netcat listener you started on Server_B. In our example, we got this line:
Connection from 192.168.0.174 58624 received!

Remember that the listening netcat process was just presented a shell back into the LAN Turtle. You won’t see a prompt, because it’s not a proper login, so your environment isn’t set up. However, you should be able to type commands and get responses back. For example, “uname -a” returns this:
Linux turtle 3.10.49 #7 Thu Jul 16 05:05:51 PDT 2015 mips GNU/Linux

You can stop the reverse shell at any time from the Turtle, using the menu option. If you “Enable” this, it will make an attempt at creating that reverse shell on start up next time it is plugged in or rebooted. In other words, if you want this to persist, you’ll need to keep the netcat listener running on that target box all the time.

The benefits to having this are the speed and efficiency in setting it up for getting a shell back into the Turtle from the LAN side of the interface. For example, if you plugged the Turtle into a USB power adapter, but wanted to be able to get into it for further configuration and work, you would want this module or one like it to present that shell for you. It’s not fancy, but it gets the job done.

The Hak5 LAN Turtle is a versatile tool for any hacker (or system’s administrator) to have on hand.

Hacker-Tool Hump-Day – LAN Turtle module(s) – cron and uptime

I’m covering two modules, just because of the sheer shortness of the content.

The “cron” module’s “configure” menu is a raw interface to essentially “crontab -e.” In other words, you have to put in the cront entry by hand, using the crontab format you would use on the majority of standardized cron systems across the land of Unix in general. After you add all of the entries you want, you can “start” and/or “enable” as per any other normal module for the LAN Turtle. This will get your cron jobs loaded and ready to kick off whatever scheduled tasks you intended it to run.

minutes hours day-of-the-month month day-of-the-week command-to-run

The “uptime” module doesn’t need the “start” or “enable” menu options. The “configure” menu option simply displays the system uptime to the user.

I feel bad for cheesing out on two of the really short module topics, but I have a wicked cough still. I’ll try to pick a more exciting module to cover next week, I promise.

Thanks for reading.

Hacker-Tool Hump-Day – Lan Turtle Module – autossh

Today, we’ll go over one of the simplest modules provide for the Hak5 LAN Turtle. The “autossh” module is used to create an ssh session from the Turtle out to a pre-designated target server, and use the SSH proxying features to present a port for logging back into the Turtle over this tunneled proxy connection. This can be used in an environment that allows outbound SSH connections to create a connection into the internal LAN via some outside listening system. While there might be legitimate uses for this, make sure you follow corporate policy on such things before taking advantage of this feature on your work network.

To set this up, go to the Turtle shell (menu) and select:
Modules => autossh => CONFIGURE.

There are three fields that need to be filled in. The first is the “User@Host” field, where you put the target user and the target hostname or IP address for logging into the remote system. In order to make that outbound connection, the Turtle needs to know who to login as, and where to login at. This is how you tell it that.

The second field is the “Remote Port” field, and defaults to 2222. This is the port that will get established for the “dial back in via the proxy” tunnel.

The last field is the “Local Port” field, which defaults to port 22 and is fine to leave as is.

After you configure the ports, you can try to use it right away by telling it to “start,” but I generated a key pair and pushed the public key out to the target system from the command line when I tested this. I don’t think it will work without setting up a key manually, first. The Turtle does include “ssh-copy-id” if you prefer to push your key that way, and “ssh-keygen” to generate that key, but the key type should be RSA and use the “id_rsa” default naming scheme. This appears to be hard coded within the module. If you prefer a different key type, you’ll need to modify the module script to call a different key. The script is at /etc/turtle/modules/autossh if you’re looking to customize this.

After you’ve pushed your key and set up the “config” options, you can go back to the Turtle shell (menu) and select the module again, then select “START” instead of “CONFIGURE” to test it. Log into your remote target machine and see if you have a listening port per your “Remote Port” setting (default 2222.) If you do, you can try logging into the Turtle from that machine by doing “ssh -p 2222 root@localhost” (replace 2222 with whatever port number you chose to use if you overrode this default value.) You should be able to connect. If it works as expected, you can go back to the Turtle shell (menu) and select the module one more time, this time to “ENABLE” it. This will make it autossh every time the Turtle is rebooted (or powered on.)

This is equivalent to using the -R flag discussed on Monday.

Disable it when you’re not intending to use it, though. If you’re not getting the expected connection back into the Turtle, make sure there’s not a conflicting service using that “Remote Port” option you chose. If there is, change it to a port that’s not in use. Also check that firewalls aren’t blocking that port per standard troubleshooting techniques (netstat, telnet, etc.)

That’s it for this week, folks. We’ll probably cover another module next week, but with the new kids, the schedule might change without warning.

Thanks for reading!

Hacker-Tool Hump-Day – john the ripper

Another quickie today. Before we get to the technical goods, I thought I’d share an update on the family situation. We have both “bonus” children home safe and sound, and everyone is settling in just fine. The hectic nature of the trip, and post-trip excitement has reduced the time I have to work on a good detailed post this week, so I apologize in advance for the lack of substance I may be about to present. I will review this post, and possibly do a more in-depth review of this tool to flesh out the details another day. On to the spotlight!

John the Ripper is a staple tool for cracking passwords. If you can get your hands on a set of hashed passwords, you can use this tool to make an attempt at cracking them. It does a fair job on any standard system, but some people build elaborate rigs to throw as much computing power at the tool (or a modified version of it for distributed cracking) to reduce the time it takes to crack some of the more complex passwords a user might set.

You can feed it a dictionary file, tell it to try different permutations of each word, and even brute force all characters in a set using various flags. Different people have different routines for running it, but my general work flow is to kick it off on one machine with a dictionary of common words, and on another machine with a brute force crack, and just let it hum. I don’t have an elaborate rig, and I’ve never tried to crack a password I wasn’t asked to crack for work purposes (outside of my own lab/gear, of course.) It can take a while to crack some passwords, but if you have the time and / or horse power, you can crack most password hash schemes. It can handle simple hashes such as what you might generate with OpenSSL, as well as Windows hashes such as NTLM.

Oddly enough, during my SANS Sec504 class, the one hash scheme I had trouble with was md5. I used another tool (Cain/Abel) on a Windows machine to crack that while john sat and choked on it. I think it was because of the version of john that was provided with the class materials.

Just a reminder that John is used for brute forcing / dictionary attacking an already retrieved set of password hashes. Other tools are often used to brute force passwords as actual login attempts to a machine. This is a better tool if you can get the hashes, because it doesn’t actually attempt to log into anything, and thus doesn’t lock out any accounts due to too many failures, or leave a bunch of failed login attempts in a log file somewhere.

And after all of that, I’m not showing any examples for this command for today’s post. I think I will definitely do a follow up article for that, instead.

Until next time, go hug a family member. Or a friend. Your imaginary one, if noone else will do.