Home Tags Posts tagged with "Man in the Middle Attack"
Tag:

Man in the Middle Attack

Hacking remote desktop protocol using rdpy - blackMORE Ops
HackingHow toSecurity

Hacking remote desktop protocol using rdpy

by blackMOREOps
written by blackMOREOps

RDPY is a Microsoft RDP Security Tool developed in pure Python with RDP Man in the Middle proxy support. This allows a user to record sessions and develop honeypot functionality. It supports both Microsoft RDP (Remote Desktop Protocol) protocol client and server side. RDPY supports standard RDP security layer, RDP over SSL and NLA authentication (through ntlmv2 authentication protocol). This article will briefly go over on hacking remote desktop protocol using rdpy and different usage of it.

Hacking remote desktop protocol using rdpy - blackMORE Ops

RDPY Features

RDPY provides the following RDP and VNC binaries :

  • RDP Man In The Middle proxy which record session
  • RDP Honeypot
  • RDP screenshoter
  • RDP client
  • VNC client
  • VNC screenshoter
  • RSS Player

Included binaries and usage

Dependencies are only needed for pyqt4 binaries :

  • rdpy-rdpclient
  • rdpy-rdpscreenshot
  • rdpy-vncclient
  • rdpy-vncscreenshot
  • rdpy-rssplayer

dpy-rdpclient

rdpy-rdpclient is a simple RDP Qt4 client.

$ rdpy-rdpclient.py [-u username] [-p password] [-d domain] [-r rss_ouput_file] [...] XXX.XXX.XXX.XXX[:3389]

You can use rdpy-rdpclient in a Recorder Session Scenario, used in rdpy-rdphoneypot.

rdpy-vncclient

rdpy-vncclient is a simple VNC Qt4 client .

$ rdpy-vncclient.py [-p password] XXX.XXX.XXX.XXX[:5900]

rdpy-rdpscreenshot

rdpy-rdpscreenshot saves login screen in file.

$ rdpy-rdpscreenshot.py [-w width] [-l height] [-o output_file_path] XXX.XXX.XXX.XXX[:3389]

rdpy-vncscreenshot

rdpy-vncscreenshot saves the first screen update in file.

$ rdpy-vncscreenshot.py [-p password] [-o output_file_path] XXX.XXX.XXX.XXX[:5900]

rdpy-rdpmitm

rdpy-rdpmitm is a RDP proxy allows you to do a Man In The Middle attack on RDP protocol. Record Session Scenario into rss file which can be replayed by rdpy-rssplayer.

$ rdpy-rdpmitm.py -o output_dir [-l listen_port] [-k private_key_file_path] [-c certificate_file_path] [-r (for XP or server 2003 client)] target_host[:target_port]

Output directory is used to save the rss file with following format (YYYYMMDDHHMMSS_ip_index.rss) The private key file and the certificate file are classic cryptographic files for SSL connections. The RDP protocol can negotiate its own security layer If one of both parameters are omitted, the server use standard RDP as security layer.

rdpy-rdphoneypot

rdpy-rdphoneypot is an RDP honey Pot. Use Recorded Session Scenario to replay scenario through RDP Protocol.

$ rdpy-rdphoneypot.py [-l listen_port] [-k private_key_file_path] [-c certificate_file_path] rss_file_path_1 ... rss_file_path_N

The private key file and the certificate file are classic cryptographic files for SSL connections. The RDP protocol can negotiate its own security layer. If one of both parameters are omitted, the server use standard RDP as security layer. You can specify more than one files to match more common screen size.

rdpy-rssplayer

rdpy-rssplayer is use to replay Record Session Scenario (rss) files generates by either rdpy-rdpmitm or rdpy-rdpclient binaries.

$ rdpy-rssplayer.py rss_file_path

References

1 comment
0 FacebookTwitterPinterestThreadsBlueskyEmail
Create MITM Test Environment using Snifflab
HackingHow toKali LinuxLinuxSecurity

Create MITM Test Environment using Snifflab

by blackMOREOps
written by blackMOREOps

Snifflab is a technical test environment for capturing and decrypting WiFi data transmissions. Snifflab creates a WiFi hotspot that is continually collecting all the packets sent over it. All connected clients’ HTTPS communications are subjected to a “Man-in-the-middle” attack, whereby they can later be decrypted for analysis. This article presents a brief overview on Snifflab and how to create MITM Test Environment using Snifflab.

Create MITM Test Environment using Snifflab

Motivation

Researchers and end-users alike often seek to understand what data their mobile device is sending to third parties. Unfortunately, monitoring one’s phone to see what, and to whom, data is sent is not exactly simple. Using packet capture software on Android is impossible without first rooting the device, and even then, difficult to use and export saved data. There are no applications to capture packets on iOS.

How it works

A researcher simply connects to the Snifflab WiFi network, is prompted to install a custom certificate authority on the device, and then can use their device as needed for the test.

All traffic on the network is logged by a Raspberry Pi dedicated to that task (“PCAP Collecting Machine”, in the Figure). The traffic is cloned by a Great Scott Gadgets Throwing Star LAN Tap, which routes it both to its destination, and to our Raspberry Pi. The Pi continually collects packet data, creating new packet capture (pcap) files at a regular interval, or once the active file reaches a configurable size. Saved files are regularly transferred to another machine (“Backup Machine”) for persistent storage. Users with SSH access to the Pi can also manually restart the pcap service, to get instant access to the captured packets, instead of waiting for the interval.

The custom certificate that each client must install enables the proxy server (“MITM Proxy Machine”) through which Snifflab routes its traffic to intercept HTTPS requests to the outside world, and re-encrypt them using certificates generated on-the-fly. This allows for the researcher to later decrypt most captured network traffic sent over HTTPS.

On the backup machine, the researcher has access to all previously-collected PCAPs, organized into folders by date, with each file named by the unix time at which the capture began.

The researcher may then open up the collected PCAP(s) in Wireshark or their utility of choice to analyze and decrypt the traffic.

Using SNIFFLab MITM Enivronment

SNIFFlab.py -h
    -i (specify the network interface)
    -s (specify the file size limit)
    -t (specify the time interval, in seconds, between new PCAP files)
    -f (specify a filename suffix to append to each PCAP.
    -u (specify a ssh username for a remote backup)
    -h (specify a ssh host for remote backup)
    -p (specify the path on the remote host for backup)

Reference:

0 comments
0 FacebookTwitterPinterestThreadsBlueskyEmail
MITM - Man in the Middle Attack using Kali Linux - blackMORE Ops - 1
HackingKali Linux

Man in the Middle Attack using Kali Linux – MITM attack

by blackMOREOps
written by blackMOREOps

The man-in-the-middle attack (often abbreviated MITM, MitM, MIM, MiM, MITMA) in cryptography and computer security is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, an attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle).

A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other—it is an attack on mutual authentication (or lack thereof). Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL can authenticate one or both parties using a mutually trusted certification authority.

Scenario:

This is the simple scenario, and I try to draw it in a picture.

MITM - Man in the Middle Attack using Kali Linux - blackMORE Ops - 1

Kali Linux Man in the Middle Attack

  1. Victim IP address : 192.168.8.90
  2. Attacker network interface : eth0; with IP address : 192.168.8.93
  3. Router IP address : 192.168.8.8

Requirements:

  1. Arpspoof
  2. Driftnet
  3. Urlsnarf

Following steps show how to perform Man in the Middle Attack using Kali Linux and a target machine.

Open your terminal (CTRL + ALT + T kali shortcut) and configure our Kali Linux machine to allow packet forwarding, because act as man in the middle attacker, Kali Linux must act as router between “real router” and the victim.

You can change your terminal interface to make the view much more friendly and easy to monitor by splitting kali terminal window.

The next step is setting up arpspoof between victim and router.

arpspoof -i eth0 -t 192.168.8.90 192.168.8.8

Kali Linux Man in the Middle Attack

  1. And then setting up arpspoof from to capture all packet from router to victim.
arpspoof -i eth0 -t 192.168.8.8 192.168.8.90

Kali Linux Man in the Middle Attack

After step three and four, now all the packet sent or received by victim should be going through attacker machine.

Use DriftNet to Monitor packets and images

Inspired by EtherPEG (though, not owning an Apple Macintosh, I’ve never actually seen it in operation), DriftNet is a program which listens to network traffic and picks out images from TCP streams it observes. Fun to run on a host which sees lots of web traffic.

In an experimental enhancement, DriftNet now picks out MPEG audio streams from network traffic and tries to play them.

Now we can try to use DriftNet to monitor all victim image traffic. According to its website……

Use the following command to run DriftNet

driftnet -i eth0

When victim browse a website with image, DriftNet will capture all image traffic as shown in the screen-shot below.

Use URLSnarf to Monitor packets

URLSnarf is a tool that can sniff HTTP requests in Common Log Format. URLSnarf outputs all requested URLs sniffed from HTTP traffic in CLF (Common Log Format, used by almost all web servers), suitable for offline post-processing with your favorite web log analysis tool (analog, wwwstat, etc.).

urlsnarf -i eth0

and URLSnarf will start capturing all website address visited by victim machine.

When victim browse a website, attacker will know the address victim visited.

Defenses against the attack

Various defenses against MITM attacks use authentication techniques that include:

  • DNSSEC Secure DNS extensions
  • Strong encryption (as opposed to relying on small symmetric or asymmetric key sizes, broken ciphers or unproven ciphers)
  • Public key infrastructures
    • PKI mutual authentication The main defence in a PKI scenario is mutual authentication. In this case as well as the application validating the user (not much use if the application is rogue)—the users devices validates the application—hence distinguishing rogue applications from genuine applications
  • A recorded media attestment (assuming that the user’s identity can be recognized from the recording), which can either be:
    • A verbal communication of a shared value for each session (as in ZRTP)
    • An audio/visual communication of the public key hash (which can be easily distributed via PKI)
  • Stronger mutual authentication, such as:
    • Secret keys (which are usually high information entropy secrets, and thus more secure), or
    • Passwords (which are usually low information entropy secrets, and thus less secure)
  • Latency examination, such as with long cryptographic hash function calculations that lead into tens of seconds; if both parties take 20 seconds normally, and the calculation takes 60 seconds to reach each party, this can indicate a third party
  • Second (secure) channel verification
  • Carry-forward verification
  • Testing is being carried out on deleting compromised certificates from issuing authorities on the actual computers and compromised certificates are being exported to sandbox area before removal for analysis

The integrity of public keys must generally be assured in some manner, but need not be secret. Passwords and shared secret keys have the additional secrecy requirement. Public keys can be verified by a certificate authority, whose public key is distributed through a secure channel (for example, with a web browser or OS installation). Public keys can also be verified by a web of trust that distributes public keys through a secure channel (for example by face-to-face meetings).

Forensic analysis of MITM attacks

Captured network traffic from what is suspected to be a MITM attack can be analyzed in order to determine if it really was a MITM attack or not. Important evidence to analyze when doing network forensics of a suspected SSL MITM attack include:

  • IP address of the server
  • DNS name of the server
  • X.509 certificate of the server
    • Is the certificate self signed?
    • Is the certificate signed by a trusted CA?
    • Has the certificate been revoked?
    • Has the certificate been changed recently?
    • Do other clients, elsewhere on the Internet, also get the same certificate?

Conclusion

  1. To change or spoof the attacker MAC address, you can view the tutorial about how to change Kali Linux MAC address.
  2. Driftnet or Urlsnarf was hard to detect, but you can try to find the device in your network with promiscuous mode which have possibility to sniff the network traffic.

Hope you found it useful.

9 comments
0 FacebookTwitterPinterestThreadsBlueskyEmail
@2021 - All Right Reserved. Designed and Developed by PenciDesign