New Rapidly-Growing IoT Botnet Treatens to Take Down the Internet

Just a year after Mirai—biggest IoT-based malware that caused vast Internet outages by launching massive DDoS attacks—completed its first anniversary, security researchers are now warning of a brand new rapidly growing IoT botnet.

Dubbed 'IoT_reaper,' first spotted in September by researchers at firm Qihoo 360, the new malware no longer depends on cracking weak passwords; instead, it exploits vulnerabilities in various IoT devices and enslaves them into a botnet network.

IoT_reaper malware currently includes exploits for nine previously disclosed vulnerabilities in IoT devices from following manufactures:

• Dlink (routers)
• Netgear (routers)
• Linksys (routers)
• Goahead (cameras)
• JAWS (cameras)
• AVTECH (cameras)
• Vacron (NVR)

Researchers believe IoT_reaper malware has already infected nearly two million devices and growing continuously at an extraordinary rate of 10,000 new devices per day.

This is extremely worrying because it took only 100,000 infected devices for Mirai to took down DNS provider Dyn last year using a massive DDoS attack.

Besides this, researchers noted that the malware also includes more than 100 DNS open resolvers, enabling it to launch DNS amplification attacks.

"Currently, this botnet is still in its early stages of expansion. But the author is actively modifying the code, which deserves our vigilance." Qihoo 360 researchers say.

Meanwhile, researchers at CheckPoint are also warning of probably same IoT botnet, named "IoTroop," that has already infected hundreds of thousands of organisations.

"It is too early to guess the intentions of the threat actors behind it, but with previous Botnet DDoS attacks essentially taking down the Internet, it is vital that organisations make proper preparations and defence mechanisms are put in place before attack strikes." researchers said.

According to CheckPoint, IoTroop malware also exploits vulnerabilities in Wireless IP Camera devices from GoAhead, D-Link, TP-Link, AVTECH, Linksys, Synology and others.

At this time it is not known who created this and why, but the DDoS threat landscape is skyrocketing and could reach tens of terabits-per-second in size.

"Our research suggests we are now experiencing the calm before an even more powerful storm. The next cyber hurricane is about to come." CheckPoint researchers warned.

You need to be more vigilant about the security of your smart devices. In our previous article, we have provided some essential, somewhat practical, solutions to protect your IoT devices.

Google to add "DNS over TLS" security feature to Android OS

No doubt your Internet Service Provides (ISPs), or network-level hackers cannot spy on https communications.

But do you know — ISPs can still see all of your DNS requests, allowing them to know what websites you visit.

Google is working on a new security feature for Android that could prevent your Internet traffic from network spoofing attacks.

Almost every Internet activity starts with a DNS query, making it a fundamental building block of the Internet. DNS works as an Internet's phone book that resolves human-readable web addresses, like thehackernews.com, against their IP addresses.

DNS queries and responses are sent in clear text (using UDP or TCP) without encryption, which makes it vulnerable to eavesdropping and compromises privacy.

ISPs by default resolve DNS queries from their servers. So when you type a website name in your browser, the query first goes to their DNS servers to find the website's IP address, which eventually exposes this information (metadata) to your ISPs.

Moreover, DNS Security Extensions — widely known as DNSSEC — only offers data integrity, not privacy.

To address this problem, Internet Engineering Task Force (IETF) last year proposed an experimental feature called — DNS over TLS (RFC 7858), which works approximately the same way https does.

Just like Transport Layer Security (TLS) encrypted protocol secures HTTPS connections cryptographically, DNS-over-TLS dramatically enhances privacy and security with end-to-end authenticated DNS lookups.

Google is reportedly adding "DNS over TLS" support to the Android Open Source Project (AOSP), currently at an experimental stage, to allow smartphone users to turn on or off "DNS over TLS" feature under Developer Options settings.

"Presumably, if such an option is being added to Developer Options, then that means it is in testing and may arrive in a future version of Android such as version 8.1." Xda-developers said in a blog post.

However, just enabling "DNS over TLS" feature would not prevent your ISP to know what websites you visit.

Server Name Indication (SNI) — an extension of the TLS protocol — also indicates ISPs that which hostname is being contacted by the browser at the beginning of the 'handshake' process.

So to enjoy full anonymity, users are still required to use a trusted secure VPN service in combination with DNS-over-TLS protocol.

Using Metasploit Workspaces to Organise Your Data

One of my favourite features of Metasploit is the ability to organise all the data collected throughout a penetration test into an easily searchable format. This greatly assists in mapping a network and finding vulnerable high value targets to go after.

Metasploit uses ‘workspaces’ to separate data sets. Before starting a new penetration test it is a good idea to create a new workspace where all the data collected during the test can be stored without contamination from previous tests. To create a new workspace, from msfconsole, issue the command ‘workspace –a [name of workspace]’. Then change to the newly created workspace using ‘workspace [name of workspace]’.

Typically, one of the first activities that would be performed in a penetration test is host and service discovery. This almost always involves port scanning and the most popular tool to do this is nmap. Metasploit can import nmap outputs in the XML format. To do this, from msfconsole, issue the command ‘db_import [path to file]’.

Metasploit has now added all of the results from the nmap file ‘top1000TCP.xml’ into the ‘example’ workspace. Alternatively, nmap scans can be launched from within Metasploit with the db_nmap command. This will automatically add the results to the current workspace.

Now that the workspace is populated with nmap results the ‘hosts’ and ‘services’ commands can be used to search for interesting targets to exploit.

Using the command ‘hosts’ without any parameters will list all hosts in the current workspace and some additional data about them.

Similarly the ‘services’ command without any parameters will list all of the services that are stored in the current workspace.

Both the ‘services’ and ‘hosts’ commands have a number of options to limit their output to specific results. By typing ‘help [command]’ Metasploit will list the options and what they do.

Metasploit provides functionality to use the results of a ‘services’ or ‘hosts’ command to set the RHOSTS field of a module. In this way, Metasploit modules can be run against specific hosts in the workspace that share common properties.

To filter out all the hosts that have port 445 open and use this as the RHOSTS field for a module the following command is issued ‘services –p 445 –u –R’. The ‘-p’ option means only return hosts with port 445, the ‘-u’ option means only return hosts where the service is up, and the ‘-R’ option means set the output as the RHOSTS field.

Now when the module is set and run, it will be run against all the hosts in the ‘example’ workspace with port 445 open.

This demonstrates a simple use case of the usefulness of workspaces and is something that I find myself using frequently on infrastructure tests. There are many other commands that can be used within workspaces to view credentials found and write or view notes on particular hosts.

Gaining Access the Easy Way

Alibaba had a problem. Over the span of two week in late 2015, over 20 million accounts were compromised from an on-going brute force attack. While a portion of the compromised accounts were due to password reuse, there were likely many accounts which simply used weak passwords. In attacks like this, many times hackers only need to use small variations on a few common passwords in order to gain access to a large number of accounts. While many services demand pseudo-complex passwords (e.g. minimum eight characters including at least one capital letter, one number and one special character), users often make predictable substitutions to their default password to meet these requirements.

As security professionals, it is critical that we identify systems that can easily be compromised due to weak credentials. While there are several stand-alone tools that are commonly used to brute force access for various protocols, I want to focus on Nmap's brute library. The advantage here is that any password mutation updates we make to this library will automatically take effect in all of the NSE scripts within the brute category (currently 125 scripts). Brute force tools are as effective as the username / password lists that you provide them. Simply put, the difference between having the string password, but not common iterations of the same string, such as p@ssword, p@ssw0rd and Password1, can be the difference between success and failure when brute forcing credentials.

Paulino Calderon created an incredibly useful patch for Nmap's brute.lua library that adds basic password mangling to all Nmap brute scripts. I added more sophisticated password mangling cases (based on mutator) to the patch as well as modified the patch to work with the latest version of Nmap. The updated version is available here.

To avoid bloat, Nmap only comes with a handful of default usernames and around 5000 passwords. For maximum effectiveness, it is important that we choose an appropriate word list. For example, the default MS SQL user sa is not included in Nmap's username list. On the password front, therockyou.txt password dump is often effective when brute forcing accounts belonging to native English speakers. However, you might need to use a language / region specific word list in other cases. The userdb and passdb script arguments can be used to specify alternative word lists. An example of Nmap using password mutation via our updated patch is shown below:

To summarize, although our default password list only contained the string password, we demonstrated that we were able to detect a common variation of this password using our updated brute library. In order to successfully brute force credentials, we may need to mangle our word list to modify case or substitute, prepend or append characters. Passwords (or slightly modified versions of passwords) are often reused across multiple services. By collecting a diverse set of password dumps and running a robust set of password mangling rules on them, we can alert clients who use weak passwords before an attack occurs.

Optimizing Default File Enumeration with Nmap

Default files are often left behind on production servers. While these are normally low risk findings, depending on the file they can often be leveraged to gain insight into the underling software versions, give access to source code or even provide direct access to configuration files or backups. While there are many stand alone tools that are often used to automate this process, I want to focus on the nmap http-enum.nse script. The reason being is that most default file automation tools are not kept up to date, http-enum makes it easy to add your own default files to its library. Furthermore, using a single engine to automate your web app testing tasks allows you to easily manipulate the output in one place. To begin, we simply run nmap using the -p flag to set the port, the --script flag to run the http-enum script and then specify the target.

# ./nmap -p80 --script http-enum localhost

Starting Nmap 7.50SVN ( https://nmap.org ) at 2017-07-12 12:31 
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000044s latency).

PORT   STATE SERVICE
80/tcp open  http
| http-enum: 
|   /wordpress/: Blog
|   /test/: Test page (401 Unauthorized)
|   /test/logon.html: Jetty (401 Unauthorized)
|   /wordpress/wp-login.php: Wordpress login page.
|_  /server-status/: Potentially interesting folder

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

Right off the bat we identified several interesting files and directories that require further investigation. The list of files and directories used are stored under /nselib/data/http-fingerprints.lua , The fingerprints are simple Lua tables and look like this:

table.insert(fingerprints, {
    category = 'general',
    probes = {
      {
        path = '/archiva/index.action',
        method = 'GET'
      }
    },
    matches = {
      {
        match = '.*">Apache Archiva (.-)',
        output = 'Apache Archiva version \\1'
      }
    }
  });

As shown above, the table includes:

• a category, which allows you to limit the default scan to a specified category
• a path, which specifies the URL to request
• a method, which specifies which HTTP method to use
• a match which specifies the string to search for in the response
• the output text shown on a match

Lua tables support patterns, thus in the example above we can parse the version number from the match and include it in the output text.

In addition to default files we can leverage the http-fingerprints file to test for certain attack types, for example the following fingerprint tests for CVE-2009-3733, a Path Traversal vulnerability in VMWare:

table.insert(fingerprints, {
    category = 'attacks',
    probes = {
      {
        path = '/sdk/../../../../../../../etc/vmware/hostd/vmInventory.xml',
        method = 'GET',
        nopipeline = true
      },
      {
        path = '/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/etc/vmware
/hostd/vmInventory.xml',
        method = 'GET',
        nopipeline = true
      }
    },
    matches = {
      {
        match = '',
        output = 'Path traversal in VMWare (CVE-2009-3733)'
      },
      {
        match = '',
        output = 'Possible path traversal in VMWare (CVE-2009-3733)'
      }
    }
  });

There are several other options that are quite useful in http-enum.nse. When the http-fingerprints.nikto-db-path variable is set, nmap will include nikto's default tests within its scan. The http-enum.basepath variable can be used to prepend a directory to all requests (e.g. /web/). By default nmap uses its own User-Agent header. If your target blocks that, you can set the http.useragent parameter with your own value to bypass the check. Finally, http-enum only displays pages that return a 200 or 401 response. Under some circumstances this may result in a false negative. You can set the http-enum.displayall variable when running nmap to display all results (except for 404 responses).

HTTP Strict Transport Security, the practical explanation

Most people would know that the HSTS HTTP Header tells the browser to not even try the HTTP port, but instead to go straight to HTTPS. But not a lot of people would know the other security feature to this header: that it will prevent the browser from giving the user the option to accept an invalid certificate. By the end of this post, I'd hope you have a clear vision of how important both these features are.

If you are still wondering if your web server needs to be on HTTPS, I'd recommend you look at the answer yourself at https://doesmysiteneedhttps.com 

To be clear, the issue I have with HTTPS, without the HSTS Header, is that, unless you're security savvy and always checking for the green browser signal next to the HTTPS (truth be told, recent browser versions help a lot with that), you might miss on the fact that a man in the middle (MitM) attack is in progress by downgrading your usual HTTPS website to HTTP, or simply assume that the company/institution just decided to not implement HTTPS.

THE ATTACK

So, how easy is it to do a Man in the Middle (MitM) attack even with HTTPS and without HSTS set on the server? Very!

The following illustrates the lab setup. It’s a quite common setting in coffee shops, airports, or anywhere you decide to access the wireless “FREE-WIFI” network. 



Having this setup, the attacker has to do some ARP poisoning, by telling the network gateway that the attacker is the victim, and telling the victim that the same attacker is the gateway.



This implies that, in this case, a linux box (kali) is routing packets through itself. This is done by executing echo "1" > /proc/sys/net/ipv4/ip_forward. The successful ARP poisoning can be easily verified by executing arp -a on the Windows victim host, in which you can tell that both IPs, .10 (hacker) and .138 (gateway) have the same MAC address.



At this point in time, you can just store all traffic by executing tcpdump -w dump.pcap and later extract any HTTP credentials (or other cleartext protocols) with tools like dsniff, wireshark, ettercap, and so on.

But what if it's HTTPS? Now we are ready for the packet manipulation that will allow us to strip away the HTTPS and deliver simply HTTP to the victim. To do this smoothly, all we want is to intercept that typical "www.example.com" input into the browser, or stored (bookmarks) https://example.com, that will translate into an HTTP request, which would be then redirected to the HTTPS port. This is the usual scenario on HTTPS websites without the HSTS set, and to intercept the HTTP request, create a new HTTPS request to the original server, strip the content from it, and deliver it back to the victim, over HTTP, we'll use sslstrip, by @moxie.

To do this we need to redirect all HTTP (tcp/80) traffic to sslstrip. This is done by executing iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080 and having sslstrip running while listening to that port.



To show you the behaviour of a well-known website that runs on HTTPS, without HSTS set, we'll look into Skype (they do have HSTS but with a ridiculously low max-age of 10 minutes). The following screenshot shows the behaviour of a normal (not MitM) request.



But after having sslstrip running on our lab, and having the victim type "www.skype.com" into the browser, the page comes back... in HTTP instead.





After the victim inserts the credentials, these are stored by ssltrip by default on sslstrip.log file.



These are the username validations. The first "ninja" attempt failed, since the site validates your username before allowing you to insert the password, so I had to put in a real email address that exists on skype. And then, on the attacker machine you also have the passwords.



This is where the HSTS HTTP Header comes in. It protects the victim by letting the browser know that the page should not be requested in HTTP, but always on HTTPS, so the first request to an HTTP port will never be sent by the browser. Instead, an HTTPS request will be sent, and when an attacker tries to MitM it, they have to do so using a self-generated/bogus certificate. This can be done with sslstrip python sslstrip.py ... -k ca.key -c ca.cert ssl 0.0.0.0 8443 after generating your certificates with openssl, or more easily with tools like Cain&Abel.

Now we have two scenarios. The first one is a website that does not use HSTS HTTP header, and in the second scenario it's used.

First scenario (without HSTS):


Second scenario (with HSTS):


Can you tell the crucial difference? On the second (safe) one - facebook.com - the browser does not allow for the victim to bypass the insecure connection warning. This is key! As a system administrator, if you know your website is only provided in HTTPS, bypassing the insecure connection warning should never be an option.

And those are the two reasons why you should have the HSTS header set on your web server. It forces the first browser’s request to get out using HTTPS, and it does not allow for the insecure connection warning bypass.

IMPORTANT DETAILS

Not a silver bullet against HTTPS MitM attacks

Scenario #1 - first time access to the URL:

Even if a web server has the header configured, the victim will still be vulnerable on the first ever access to it. This is why the preload directive exists. It allows for browsers to have a pre-defined list of hostname that should only be accessed through HTTPS. This way even if it's your first ever facebook login, for example, it will still send it through HTTPS even if you type "https://facebook.com".

Scenario #2 - governments or powerful entities doing MitM:

In this scenario, one typically assumes that such an entity is capable of generating certificates that will be considered valid by browsers. Such attackshave occurred and will continue to, on well known totalitarian regimes.

Just so we're clear, this was never something that HSTS was supposed to solve. That's an issue for HPKP (which Scott Helme argue convincingly that is dead) and Certificate Authority Authorization (CAA) DNS records.

Major security testing tools report the lack of  HSTS as a Low or Medium issue

That's because tools can't tell the importance of the data you have on your web server, so they would rather not cry wolf and have you ignore other High risk issues. But giving hackers the possibility to change any of your website's data, from altering images to reputation-damaging ones, to changing bank details from donation sites, or to change the company’s contact number and later perform social engineering attacks, there are no good reasons to keep providing access to your website using HTTP or poorly configured HTTPS (without HSTS).

That's also why you should not rely simply on tools. There are many good reasons for having an experienced penetration tester looking at your servers, and this is one of them... and also being able to detect more complex vulnerabilities and bypasses, and not stop checking for a SQL injection because ' or 1=1 # did not work.

Bypassing CSRF tokens with Python's CGIHTTPServer

There are ways to configure Burp using macros to bypass CSRF tokens on HTML forms, so we can use Burp Active Scans, Burp Intruder, Burp Repeater, and (cautiously) even Burp Proxy. There's also Grep-Extract and pitchfork attack type specifically for Intruder. And, you might even develop your Burp Extension to do it. Sqlmap has a --csrf-token and a --csrf-url for the same purpose, or you can just configure Burp as previously stated, and run sqlmap through Burp using --proxy.

Now, here's another way, using CGIHTTP Server from python.

The lab

The lab is a simple PHP/mysql environment, in which you login to access a restricted area. I uploaded the PHP code here in case you want to try it out, and change/adjust it for other scenarios. Just bear with me, because I'm not a PHP specialist, but I do prefer to develop the environment I'm testing (within reason). It always helps you understand better what you're testing and what to look for in real world scenarios.

The CSRF token is a SHA256 hash of a randomly generated number, and it's different for each HTTP request.

The problem

So, without any special configurations, Burp won't detect the issue.



And neither will sqlmap:



I used the --technique, --dbms, and -p flags to speed up the scan. And since this is a simple boolean-based SQLi, --level 1 (the default) is more than enough. But, with wrong credentials, the --risk must indeed be set to 3. This is because only on that higher risk number, OR boolean-based SQL injections are tested. OR boolean-based SQL injections are dangerous because they can make any condition become true. If you think about cases where you inject into a WHERE clause of an UPDATE or DELETE statements, you could accidently update, let's say, the passwords for all users on the database, or dump that user's credentials table... exactly the kind of thing you avoid at all costs when performing pentests to your clients.

OR boolean-based SQLi detected with sqlmap --csrf-token="mytoken":



But because this is a login validation form, it's obviously a SELECT statement, which means there's no harm in the highest risk 3.

Of course, if you have valid credentials (which you might not have in a real pentest), this is also vulnerable to AND boolean-based SQLi. But even if I do have valid credentials, I'd rather first test it with another (valid) username to find an OR SQLi, so I don't accidently lock the account (if it does lock at all).

AND boolean-based SQLi also detected with --csrf-token="mytoken":

CGIHTTPServer for the rescue

Creating the CGI script:



This should be created inside folder_whatever/cgi-bin/, which we'll call mask.py , and make sure the .py is executable. After the file is created, run "python -m CGIHTTPServer" from within "folder_whatever". It will, by default, listen on the 8000/tcp port.



You can test it, with the correct password:



And with the wrong one:



So now, it becomes pretty easy to detect, without any special configuration, to both Burp and sqlmap.