PacketSpy - Powerful Network Packet Sniffing Tool Designed To Capture And Analyze Network Traffic

PacketSpy is a powerful network packet sniffing tool designed to capture and analyze network traffic. It provides a comprehensive set of features for inspecting HTTP requests and responses, viewing raw payload data, and gathering information about network devices. With PacketSpy, you can gain valuable insights into your network's communication patterns and troubleshoot network issues effectively.

Features

• Packet Capture: Capture and analyze network packets in real-time.
• HTTP Inspection: Inspect HTTP requests and responses for detailed analysis.
• Raw Payload Viewing: View raw payload data for deeper investigation.
• Device Information: Gather information about network devices, including IP addresses and MAC addresses.

Installation

git clone https://github.com/HalilDeniz/PacketSpy.git

Requirements

PacketSpy requires the following dependencies to be installed:

pip install -r requirements.txt

Getting Started

To get started with PacketSpy, use the following command-line options:

root@denizhalil:/PacketSpy# python3 packetspy.py --help                          
usage: packetspy.py [-h] [-t TARGET_IP] [-g GATEWAY_IP] [-i INTERFACE] [-tf TARGET_FIND] [--ip-forward] [-m METHOD]

options:
  -h, --help            show this help message and exit
  -t TARGET_IP, --target TARGET_IP
                        Target IP address
  -g GATEWAY_IP, --gateway GATEWAY_IP
Gateway IP address
  -i INTERFACE, --interface INTERFACE
                        Interface name
  -tf TARGET_FIND, --targetfind TARGET_FIND
                        Target IP range to find
  --ip-forward, -if     Enable packet forwarding
  -m METHOD, --method METHOD
                        Limit sniffing to a specific HTTP method

Examples

1. Device Detection

root@denizhalil:/PacketSpy# python3 packetspy.py -tf 10.0.2.0/24 -i eth0

        Device discovery
**************************************
   Ip Address       Mac Address
**************************************
    10.0.2.1      52:54:00:12:35:00
    10.0.2.2      52:54:00:12:35:00
    10.0.2.3      08:00:27:78:66:95
    10.0.2.11     08:00:27:65:96:cd
    10.0.2.12     08:00:27:2f:64:fe

2. Man-in-the-Middle Sniffing

root@denizhalil:/PacketSpy# python3 packetspy.py -t 10.0.2.11 -g 10.0.2.1 -i eth0
******************* started sniff *******************

HTTP Request:
    Method: b'POST'
    Host: b'testphp.vulnweb.com'
    Path: b'/userinfo.php'
    Source IP: 10.0.2.20
    Source MAC: 08:00:27:04:e8:82
    Protocol: HTTP
    User-Agent: b'Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0'

Raw Payload:
b'uname=admin&pass=mysecretpassword'

HTTP Response:
    Status Code: b'302'
    Content Type: b'text/html; charset=UTF-8'
--------------------------------------------------

FootNote

Https work still in progress

Contributing

Contributions are welcome! To contribute to PacketSpy, follow these steps:

1. Fork the repository.
2. Create a new branch for your feature or bug fix.
3. Make your changes and commit them.
4. Push your changes to your forked repository.
5. Open a pull request in the main repository.

Contact

If you have any questions, comments, or suggestions about PacketSpy, please feel free to contact me:

• LinkedIn: LinkedIn
• TryHackMe: TryHackMe
• Instagram: Instagram
• YouTube: YouTube
• Email: halildeniz313@gmail.com

License

PacketSpy is released under the MIT License. See LICENSE for more information.

How to Analyze Malware’s Network Traffic in A Sandbox

Mellon - OSDP Attack Tool

OSDP attack tool (and the Elvish word for friend)

Attack #1: Encryption is Optional

OSDP supports, but doesn't strictly require, encryption. So your connection might not even be encrypted at all. Attack #1 is just to passively listen and see if you can read the card numbers on the wire.

Attack #2: Downgrade Attack

Just because the controller and reader support encryption doesn't mean they're configured to require it be used. An attacker can modify the reader's capability reply message (osdp_PDCAP) to advertise that it doesn't support encryption. When this happens, some controllers will barrel ahead without encryption.

Attack #3: Install-mode Attack

OSDP has a quasi-official “install mode” that applies to both readers and controllers. As the name suggests, it’s supposed to be used when first setting up a reader. What it does is essentially allow readers to ask the controller for what the base encryption key (the SCBK) is. If the controller is configured to be persistently in install-mode, then an attacker can show up on the wire and request the SCBK.

Attack #4: Weak Keys

OSDP sample code often comes with hardcoded encryption keys. Clearly these are meant to be samples, where the user is supposed to generate keys in a secure way on their own. But this is not explained or made simple for the user, however. And anyone who’s been in security long enough knows that whatever’s the default is likely to be there in production.

So as an attack vector, when the link between reader and controller is encrypted, it’s worth a shot to enumerate some common weak keys. Now these are 128-bit AES keys, so we’re not going to be able to enumerate them all. Or even a meaningful portion of them. But what we can do is hit some common patterns that you see when someone hardcodes a key:

• All single-byte values. [0x04, 0x04, 0x04, 0x04 …]
• All monotonically increasing byte values. [0x01, 0x02, 0x03, 0x04, …]
• All monotonically decreasing byte values. [0x0A, 0x09, 0x08, 0x07, …]

Attack #5: Keyset Capture

OSDP has no in-band mechansim for key exchange. What this means is that an attacker can:

• Insert a covert listening device onto the wire.
• Break / factory reset / disable the reader.
• Wait for someone from IT to come and replace the reader.
• Capture the keyset message (osdp_KEYSET) when the reader is first setup.
• Decrypt all future messages.

Getting A Testbed Setup (Linux/MacOS)

You'll find proof-of-concept code for each of these attacks in attack_osdp.py. Checkout the --help command for more details on usage. This is a Python script, meant to be run from a laptop with USB<-->RS485 adapters like one of these. So you'll probably want to pick some of those up. Doesn't have to be that model, though.

If you have a controller you want to test, then great. Use that. If you don't, then we have an intentionally-vulnerable OSDP controller that you can use here: vulnserver.py.

Some of the attacks in attack_osdp.py will expect to be as a full MitM between a functioning reader and controller. To test these, you might need three USB<-->RS485 adapters, hooked together with a breadboard.

Additional Medium / Low Risk Issues

These issues are not, in isolation, exploitable but nonetheless represent a weakening of the protocol, implementation, or overall system.

• MACs are truncated to 32 bits "to reduce overhead". This is very nearly (but not quite in our calculation) within practical exploitable range.
• IVs (which are derived from MACs) are similarly reduced to 32 bits of entropy. This will cause IV reuse, which is a big red flag for a protocol.
• Session keys are only generated using 48 bits of entropy from the controller RNG nonce. This appears to not be possible for an observing attacker to enumerate offline, however. (Unless we're missing something, in which case this would become a critical issue.)
• Sequence numbers consist of only 2 bits, not providing sufficient liveness.
• CBC-mode encryption is used. GCM would be a more modern block cipher mode appropriate for network protocols.
• SCS modes 15 & 16 are essentially "null ciphers", and should not exist. They don't encrypt data.
• The OSDP command byte is always unencrypted, even in the middle of a Secure Channel session. This is a huge benefit to attackers, making attack tools much easier to write. It means that an attacker can always see what "type" of packet is being sent, even if it's otherwise encrypted. Attackers can tell when people badge in, when the LED lights up, etc... This is not information that should be in plaintext.
• SCBK-D (a hardcoded "default" encryption key) provides no security and should be removed. It serves only to obfuscate and provide a false sense of security.

Serious Security: Browser-in-the-browser attacks – watch out for windows that aren’t!