joana&pedro

joana&pedro

Metasploit is an advanced hacking tool that comes itself with a complete lack of advanced penetration testing tools. Penetration testers and hackers are taking so much advantage of this tool. It's a complete hack pack for a hacker that he can play almost any attack with it. Here I am going to discuss the basics of Metasploit. I am not covering attacks in this article, as I am just making sure to share the basics of Metasploit and basic commands of Metasploit. So, we can get back to cover attacks of Metasploit in the next articles.

BASICS OF METASPLOIT

The Metasploit framework has three types of working environments.

msfconsole
msfcli interface
msfweb interface

However, the most preferred and used is the 'msfconsole'. It's a very efficient command-line interface that has its own set of commands and system's working environment.

First of all, it's most important to know and understand all the useful commands of Metasploit that are going to be used.

BASIC COMMANDS OF METASPLOIT

Metasploit have a huge number of command that we can use in different type of attacks, but I am just going to share the most used and useful commands here that a beginner can easily understand and follow 'em.

help (It will give the basic commands you need to launch an exploit.
search (Finds out the keywords in the selected attack method).
show exploits (Shows list of an available exploit in the selected option).
show payloads (It lists all the payloads available).
show options (It helps you to know all the options if you might have forgotten one).
info (This is used to get information about any exploit or payload).
use (It tells Metasploit to use the exploit with the specified name).
set RHOST (Sets the address of specified remote host).
set RPORT (Sets up a port that connects to on the remote host).
set PAYLOAD (It sets the payload that gives you a shell when a service is exploited).
set LPORT (Sets the port number that the payload will open on the server when an exploit is exploited).
exploit (It actually exploits the service).
rexploit (Reloads your exploit code and then executes the exploit without restarting the console).

These are the most used Metasploit commands which come in handy in most of the situations during any sort of attack. You must give all the commands a try and understand 'em how it works and then move to the next part of designing an attack.

Related posts

joana&pedro

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.

This week at the USENIX Security conference, Dennis Felsch will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE. [alternative link to the paper]

In his blog post, Dennis showed how to attack the public key encryption based authentication methods of IKEv1 (PKE & RPKE) and how to use this attack against IKEv2 signature based authentication method. In this blog post, I will focus on another interesting finding regarding IKEv1 and the Pre-Shared Key authentication.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Pre-Shared Key authentication

As shown above, Pre-Shared Key authentication is one of three authentication methods in IKEv1. The authentication is based on the knowledge of a shared secret string. In reality, this is probably some sort of password.

The IKEv1 handshake for PSK authentication looks like the following (simplified version):

In the first two messages, the session identifier (inside HDR) and the cryptographic algorithms (proposals) are selected by initiator and responder.

In messages 3 and 4, they exchange ephemeral Diffie-Hellman shares and nonces. After that, they compute a key k by using their shared secret (PSK) in a PRF function (e.g. HMAC-SHA1) and the previously exchanged nonces. This key is used to derive additional keys (k_a, k_d, k_e). The key k_d is used to compute MAC_I over the session identifier and the shared diffie-hellman secret g^xy. Finally, the key k_e is used to encrypt ID_I (e.g. IPv4 address of the peer) and MAC_I.

Weaknesses of PSK authentication

It is well known that the aggressive mode of authentication in combination with PSK is insecure and vulnerable against off-line dictionary attacks, by simply eavesedropping the packets. For example, in strongSwan it is necessary to set the following configuration flag in order to use it:

charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes

For the main mode, we found a similar attack when doing some minor additional work. For that, the attacker needs to waits until a peer A (initiator) tries to connect to another peer B (responder). Then, the attacker acts as a man-in-the middle and behaves like the peer B would, but does not forward the packets to B.

From the picture above it should be clear that an attacker who acts as B can compute (g^xy) and receives the necessary public values session ID, n_I, n_R. However, the attacker does not know the PSK. In order to mount a dictionary attack against this value, he uses the nonces, and computes a candidate for k for every entry in the dictionary. It is necessary to make a key derivation for every k with the values of the session identifiers and shared Diffie-Hellmann secret the possible keys k_a, k_d and k_e. Then, the attacker uses k_e in order to decrypt the encrypted part of message 5. Due to ID_I often being an IP address plus some additional data of the initiator, the attacker can easily determine if the correct PSK has been found.

Who is affected?

This weakness exists in the IKEv1 standard (RFC 2409). Every software or hardware that is compliant to this standard is affected. Therefore, we encourage all vendors, companies, and developers to at least ensure that high-entropy Pre-Shared Keys are used in IKEv1 configurations.

In order to verify the attack, we tested the attack against strongSWAN 5.5.1.

Proof-of-Concept

We have implemented a PoC that runs a dictionary attack against a network capture (pcapng) of a IKEv1 main mode session. As input, it also requires the Diffie-Hellmann secret as described above. You can find the source code at github. We only tested the attack against strongSWAN 5.5.1. If you want to use the PoC against another implementation or session, you have to adjust the idHex value in main.py.

Responsible Disclosure

We reported our ﬁndings to the international CERT at July 6th, 2018. We were informed that they contacted over 250 parties about the weakness. The CVE ID for it is CVE-2018-5389 [cert entry].

Credits

On August 10th, 2018, we learned that this attack against IKEv1 main mode with PSKs was previously described by David McGrew in his blog post Great Cipher, But Where Did You Get That Key?. We would like to point out that neither we nor the USENIX reviewers nor the CERT were obviously aware of this.
On August 14th 2018, Graham Bartlett (Cisco) email us that he presented the weakness of PSK in IKEv2 in several public presentations and in his book.
On August 15th 2018, we were informed by Tamir Zegman that John Pliam described the attack on his web page in 1999.

FAQs

Do you have a name, logo, any merchandising for the attack?
No.
Have I been attacked?
We mentioned above that such an attack would require an active man-in-the-middle attack. In the logs this could look like a failed connection attempt or a session timed out. But this is a rather weak indication and no evidence for an attack.
What should I do?
If you do not have the option to switch to authentication with digital signatures, choose a Pre-Shared Key that resists dictionary attacks. If you want to achieve e.g. 128 bits of security, configure a PSK with at least 19 random ASCII characters. And do not use something that can be found in public databases.
Am I safe if I use PSKs with IKEv2?
No, interestingly the standard also mentions that IKEv2 does not prevent against off-line dictionary attacks.
Where can I learn more?
You can read the paper. [alternative link to the paper]
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods of IKEv1 and it gives message flow diagrams of the protocol. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2.

Let's get started

Luckily, you don't need any soldering skills for the first steps. Just connect the USB mini port to the bottom left connector on the badge, connect the other part of the USB cable to your computer, and within some seconds you will be able to see that the lights on your badge are blinking. So far so good.

Now, depending on which OS you use, you should choose your destiny here.

Linux

The best source of information about a new device being connected is

# dmesg

The tail of the output should look like

[267300.206966] usb 2-2.2: new full-speed USB device number 14 using uhci_hcd [267300.326484] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001 [267300.326486] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [267300.326487] usb 2-2.2: Product: FT232R USB UART [267300.326488] usb 2-2.2: Manufacturer: FTDI [267300.326489] usb 2-2.2: SerialNumber: AC01U4XN [267300.558684] usbcore: registered new interface driver usbserial_generic [267300.558692] usbserial: USB Serial support registered for generic [267300.639673] usbcore: registered new interface driver ftdi_sio [267300.639684] usbserial: USB Serial support registered for FTDI USB Serial Device [267300.639713] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected [267300.639741] usb 2-2.2: Detected FT232RL [267300.643235] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0

Dmesg is pretty kind to us, as it even notifies us that the device is now attached to ttyUSB0.

From now on, connecting to the device is exactly the same as it is in the macOS section, so please find the "Linux users, read it from here" section below.

macOS

There are multiple commands you can type into Terminal to get an idea about what you are looking at. One command is:

# ioreg -p IOUSB -w0 -l

With this command, you should get output similar to this:

+-o FT232R USB UART@14100000  <class AppleUSBDevice, id 0x100005465, registered, matched, active, busy 0 (712 ms), retain 20>     |   {     |     "sessionID" = 71217335583342     |     "iManufacturer" = 1     |     "bNumConfigurations" = 1     |     "idProduct" = 24577     |     "bcdDevice" = 1536     |     "Bus Power Available" = 250     |     "USB Address" = 2     |     "bMaxPacketSize0" = 8     |     "iProduct" = 2     |     "iSerialNumber" = 3     |     "bDeviceClass" = 0     |     "Built-In" = No     |     "locationID" = 336592896     |     "bDeviceSubClass" = 0     |     "bcdUSB" = 512     |     "USB Product Name" = "FT232R USB UART"     |     "PortNum" = 1     |     "non-removable" = "no"     |     "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}     |     "bDeviceProtocol" = 0     |     "IOUserClientClass" = "IOUSBDeviceUserClientV2"     |     "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}     |     "kUSBCurrentConfiguration" = 1     |     "Device Speed" = 1     |     "USB Vendor Name" = "FTDI"     |     "idVendor" = 1027     |     "IOGeneralInterest" = "IOCommand is not serializable"     |     "USB Serial Number" = "AC01U4XN"     |     "IOClassNameOverride" = "IOUSBDevice"     |   }

The most important information you get is the USB serial number - AC01U4XN in my case.
Another way to get this information is

# system_profiler SPUSBDataType

which will give back something similar to:

FT232R USB UART:            Product ID: 0x6001           Vendor ID: 0x0403  (Future Technology Devices International Limited)           Version: 6.00           Serial Number: AC01U4XN           Speed: Up to 12 Mb/sec           Manufacturer: FTDI           Location ID: 0x14100000 / 2           Current Available (mA): 500           Current Required (mA): 90           Extra Operating Current (mA): 0

The serial number you got is the same.

What you are trying to achieve here is to connect to the device, but in order to connect to it, you have to know where the device in the /dev folder is mapped to. A quick and dirty solution is to list all devices under /dev when the device is disconnected, once when it is connected, and diff the outputs. For example, the following should do the job:

ls -lha /dev/tty* > plugged.txt ls -lha /dev/tty* > np.txt vimdiff plugged.txt np.txt

The result should be obvious, /dev/tty.usbserial-AC01U4XN is the new device in case macOS. In the case of Linux, it was /dev/ttyUSB0.

Linux users, read it from here. macOS users, please continue reading

Now you can use either the built-in screen command or minicom to get data out from the badge. Usually, you need three information in order to communicate with a badge. Path on /dev (you already got that), speed in baud, and the async config parameters. Either you can guess the speed or you can Google that for the specific device. Standard baud rates include 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 bits per second. I usually found 1200, 9600 and 115200 a common choice, but that is just me.
Regarding the async config parameters, the default is that 8 bits are used, there is no parity bit, and 1 stop bit is used. The short abbreviation for this is 8n1. In the next example, you will use the screen command. By default, it uses 8n1, but it is called cs8 to confuse the beginners.

If you type:
# screen /dev/tty.usbserial-AC01U4XN 9600
or
# screen /dev/ttyUSB0 9600
and wait for minutes and nothing happens, it is because the badge already tried to communicate via the USB port, but no-one was listening there. Disconnect the badge from the computer, connect again, and type the screen command above to connect. If you are quick enough you can see that the amber LED will stop blinking and your screen command is greeted with some interesting information. By quick enough I mean ˜90 seconds, as it takes the device 1.5 minutes to boot the OS and the CTF app.

Windows

When you connect the device to Windows, you will be greeted with a pop-up.

Just click on the popup and you will see the COM port number the device is connected to:

In this case, it is connected to COM3. So let's fire up our favorite putty.exe, select Serial, choose COM3, add speed 9600, and you are ready to go!

You might check the end of the macOS section in case you can't see anything. Timing is everything.

The CTF

Welcome to the Hacktivity 2018 badge challenge!  This challenge consists of several tasks with one or more levels of difficulty. They are all connected in some way or another to HW RE and there's no competition, the whole purpose is to learn things.  Note: we recommend turning on local echo in your terminal! Also, feel free to ask for hints at the Hackcenter!  Choose your destiny below:    1. Visual HW debugging   2. Reverse engineering   3. RF hacking   4. Crypto protection  Enter the number of the challenge you're interested in and press [

Excellent, now you are ready to hack this! In case you are lost in controlling the screen command, go to https://linuxize.com/post/how-to-use-linux-screen/.

I will not spoil any fun in giving out the challenge solutions here. It is still your task to find solutions for these.

But here is a catch. You can get a root shell on the device. And it is pretty straightforward. Just carefully remove the Omega shield from the badge. Now you see two jumpers; by default, these are connected together as UART1. As seen below.

But what happens if you move these jumpers to UART0? Guess what, you can get a root shell! This is what I call privilege escalation on the HW level :) But first, let's connect the Omega shield back. Also, for added fun, this new interface speaks on 115200 baud, so you should change your screen parameters to 115200. Also, the new interface has a different ID under /dev, but I am sure you can figure this out from now on.

If you connect to the device during boot time, you can see a lot of exciting debug information about the device. And after it boots, you just get a root prompt. Woohoo!

But what can you do with this root access? Well, for starters, how about running

# strings hello | less

From now on, you are on your own to hack this badge. Happy hacking.

Big thanks to Attila Marosi-Bauer and Hackerspace Budapest for developing this badge and the contests.

PS: In case you want to use the radio functionality of the badge, see below how you should solder the parts to it. By default, you can process slow speed radio frequency signals on GPIO19. But for higher transfer speeds, you should wire the RF module DATA OUT pin with the RX1 free together.