โŒ

Normal view

There are new articles available, click to refresh the page.
Yesterday โ€” 1 October 2023KitPloit - PenTest & Hacking Tools

Mellon - OSDP Attack Tool

By: Zion3R
1 October 2023 at 11:30


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.


Electron_Shell - Developing A More Covert Remote Access Trojan (RAT) Tool By Leveraging Electron's Features For Command Injection And Combining It With Remote Control Methods

By: Zion3R
30 September 2023 at 11:30

Electron_shell

Developing a more covert Remote Access Trojan (RAT) tool by leveraging Electron's features for command injection and combining it with remote control methods.

Read More: [AOH 024]ๆŽข็ดขๅฐ†Shellๅฏ„็”ŸไบŽElectron็จ‹ๅบ็š„่‡ชๅŠจๅŒ–ๅฎž็Žฐ

Features

  • Supports almost all operating systems

    • mac
    • linux
    • windows
  • Supports almost all desktop applications developed based on Electron

  • ๏Žจ All malicious operations are executed by the injected program, those commonly used trusted programs

  • Bypass of Network Access Control Policy for Applications by Zero Trust Sandbox

  • Verified that it will not be discovered by the antivirus software below

    (Please note that a simple command call has been implemented here, and some behavior based heuristic checks will still prompt , bypass AV is not a key issue to be addressed in this project)

    • Windows Defender
    • avast
    • ็ซ็ป’
    • 360
    • ่…พ่ฎฏ็ฎกๅฎถ
    • virustotal

๏Ž‰Intro

An increasing number of desktop applications are opting for the Electron framework.

Electron provides a method that can be debugged, usually by utilizing Chrome's inspect function or calling inspect through Node.js. In this project, the implementation of inspect was analyzed, and a method for automatically parasitizing common Electron programs was developed.

By establishing a connection with the Command and Control (C2) server, a simple remote control is achieved.

Due to the widespread trust of most antivirus software in these well-known applications (with digital signatures), executing malicious commands in the program context provides excellent concealment and stability.

For these injected applications, it is necessary to carefully consider the potential legal risks brought by such actions. When users analyze program behavior, they may be surprised to find that the parent process executing malicious behavior comes from the application they trust.

๏”จ Usage

C2 Server Setup

  1. Deploy a server and obtain a public IP address
  2. and then exec command: nc -lvnp 8899

Generating Implants

  1. clone this project

  2. modify build.config

    injected_app:  The electron program you want to inject
    c2: set c2_Public IP and c2_netcat Port
  3. exec node build.js, and then pkg to an execute program

  4. Send to victim, and get electron_shellย 



โŒ
โŒ