Exploit Dev # 10 : Remote Exploitation of HTTP Configuration in PLC – Vulnerability @ Hack-the-Box

Remote Exploitation of HTTP Configuration
HTTP server is enable in micrologix 1400 plc

In Exploit Development # 10 : Remote Exploitation of HTTP Configuration , we’re tackling a significant vulnerability in the Allen Bradley Micrologix 1400 Series B. This time, our focus is on the ability to remotely enable or disable the HTTP server feature. Building on the groundwork laid in our previous exploit where we tackled SNMP configurations, we’re now turning our attention to the HTTP protocol.

Our exploit involves sending specially crafted packets to manipulate HTTP settings, which allows us to turn HTTP on or off remotely. This feature is crucial because enabling HTTP can expose sensitive information about the PLC and its network, while disabling it can enhance security. The catch? Any changes made won’t take effect until the system is restarted.

What makes this even more concerning is that attackers can send these packets without authentication. This means they could turn on features like HTTP, Modbus, or DNP, and mess with network settings such as IP addresses and domain names. Depending on the keyswitch state—REMOTE, PROG, or sometimes RUN—they can do quite a bit of damage.

Role of HTTP server in PLC

The HTTP server on the PLC can be either enabled or disabled through its configuration settings. When enabled, it allows access to the PLC’s web interface, which can be useful for monitoring and diagnostics via a web browser. However, to enhance security and prevent unauthorized access, it’s often recommended to disable HTTP.

Disabling HTTP stops web-based access and hides extended diagnostics from view. It’s important to note that any changes to this setting won’t take effect until the PLC is restarted. You can modify this function either online, directly through the channel configuration, or offline, followed by a download to the processor. Once the PLC is restarted, the new settings will be applied.

Objective

In this blog post, “Remote Exploitation of HTTP Configuration” we’ve got four key objectives:

  • Identify the function and command codes, file numbers, and data types for HTTP configuration.
  • Develop a function to get the channel configuration.
  • Create a function to modify the channel configuration.
  • Implement a function to fix CRC checksum issues.

In this post, we will go though remotely enable or disable HTTP server feature.

  • Vulnerability Analysis: Overview of PLC systems and the specific vulnerability related to Unauthorized Access.
  • Exploit Development: Developing a Python script to exploit this vulnerability
  • Real-World Application: Showcasing the exploit on actual PLC hardware and exploring the real-world consequences.
  • Hack-the-Box PoC: Wrapping up with a Hack-the-Box style proof of concept (PoC).

In our PLC setup, we’re dealing with a MicroLogix 1400 PLC. For context, SNMP server thoroughly explored in Exploit Development # 9.

MicroLogix 1400 PLC: Device under test (DUT)

The MicroLogix 1400 PLC by Rockwell Automation’s Allen-Bradley is vital in many industries. Disruptions to its operation or configuration can lead to severe consequences, including halting critical processes and causing significant equipment damage.

Identified Vulnerability: Remote HTTP and Network channel Config Bypass

Protocol control feature of http seerver
HTTP server enabled in PLC

This vulnerability is all about access control, specifically in how the PLC handles permissions for data, program, and function files. Basically, an attacker can send a specially crafted packet that triggers either a read or write operation.

This can lead to a bunch of issues like leaking sensitive information, changing settings, or even modifying the ladder logic itself. The best part? They don’t even need to be authenticated to exploit this flaw.

key functions used for managing channel configurations in the Allen-Bradley MicroLogix 1400 PLC. The get_channel_config function retrieves current settings, while modify_channel_config updates these settings by altering protocol control bytes and recalculating CRC checksums. Finally, the script sends the modified configuration to the PLC for application. These operations underscore the importance of securing PLC configurations to prevent unauthorized access and modifications.

Protocol Control Byte Bitfield

To change the state of a service on the MicroLogix 1400, an update to the “Channel Configuration File” is necessary. Within this file, the “Protocol Control Byte” controls the state of various services through its bitfield structure. Each bit in this byte represents the state of a specific service. Table details the mapping of bits to services in the MicroLogix 1400 PLC.

76543210
ENIPUnknown ModbusTCP DNP3 Unknown SMTP SNMP HTTP

All they need to do is send the right packet. And just to show you how it works,

CMD: 0x0F – PCCC command code

FNC: 0xA2 – to read channel config

BYTE_SIZE: it decide how many byte data to be read

FILE TYPE & File Number:

This will decide that which register is going to be selected. please refer: phase 4 : DPI

File typeFile numberFile name
0x490x01Channel Configuration File

ELEMENT_NO & SUB_ELEMENT_NO::

  • 0x00 we are selecting base register based on file number & file type.

for more info – refer to user manual

Confused? 🤔 Check Out These Phases for a Step-by-Step Guide!

Feeling a bit lost in the technical jungle? Don’t worry! If you find yourself tangled in the weeds of this phase, just take a detour and revisit our previous adventures:

  • Phase 1: Basic Network Discovery – – – – – – – – – –> [Explore Phase 1 ]
  • Phase 2: MITM Attack and Protocol Packet captuing – – – –> [Explore Phase 2 ]
  • Phase 3: Packet Communication Protocol Analysis – – – – – – – – –> [Explore Phase 3 ]
  • Phase 4: Deep Packet Inspection (DPI) – – – – – – – – – – – – –> [Explore Phase 4 ]
  • Phase 5: Exploit Development – – – – – – – – – – – – – – – – – – – – – – – –> [Explore Phase 5 ]

They’re like your trusty map and compass, guiding you through the dense forest of PLC hacking. Trust me, even Indiana Jones needed a roadmap! So, grab your digital backpack and check out those earlier phases to clear up any confusion and get back on track. Happy exploring! 🚀

Exploit Development: Remote Exploitation of HTTP Config

Here’s a closer look at the Python script that powers our exploit. We’ll walk through its key components, so you know exactly what’s happening under the hood.

1. hexadecimal padding – pad_hex()

Purpose: Ensures that your hexadecimal string is the right size by padding it with leading zeros. Think of it as giving your hexadecimal string a well-fitted jacket!

Details: This function takes a hexadecimal string (hex_str) and ensures it matches the desired size (size) by padding it with zeros.

1.1 byte padding : pad_byte()

1.2 hex splitting: split_hex()

The split_hex function takes a single hexadecimal string and divides it into a list of two-character substrings. This is often useful for handling raw binary data or converting a long hexadecimal string into more manageable chunks.

2. Get CRC checksum : get_crc()

function computes the CRC16 checksum of a given raw instruction. It first cleans up the instruction by removing and replacing specific byte sequences. Then, it uses the crcmod library to calculate the CRC16 value. The computed CRC is formatted into a hexadecimal string and returned in a specific byte order.

3. Generation of Transaction Number : get_tns()

Purpose: Generates a unique transaction number for each command. It’s like giving your commands a unique name tag at a party—no confusion, just pure, unadulterated identity!

4. Response processing : parse_response ()

The parse_response function processes a binary response, checking its length and converting it to a hexadecimal string. It extracts the session handle and response data from the hex string. The response data is then converted to a list of ASCII characters, with non-printable characters replaced by underscores. The function returns a dictionary with the session handle, response data in hex format, and ASCII representation

4. Create a Register session packet : Register_Session()

Purpose: Registers a session with the PLC, much like signing up for a new club. This function sends a registration command and retrieves a session handle.

Details: Constructs and sends a registration request to the PLC, then processes the response to get the session handle. This handle is essential for subsequent communication.

Reference: Dive into [Explore Phase 4 🔍] for a detailed walkthrough of session registration and its importance in setting up your attack vector.

5. Build an ENIP packet : Build_Ethernet_instruction()

Purpose: Crafts the Ethernet instruction payload for the PLC. Think of this as assembling the perfect care package for your PLC—everything it needs in one neat little box.

Details: Builds a complete payload for sending instructions to the PLC, including encapsulation headers and PCCC command data. This function ensures the message is formatted correctly and includes all necessary information.

Reference: For a full breakdown of how to assemble these payloads, check out [Explore Phase 4 🔍]. It’s where we dissect and understand the intricacies of packet construction.

6. Create a Function to send Packets: send_instruction()

Purpose: Sends an instruction to the PLC and waits for a response. This is your direct line to the PLC, like making a call and eagerly waiting for the answer.

7. retrive channel config : get_channel_config ()

The get_channel_config function retrieves and parses the channel configuration from a PLC. It sends two read (fnc = 0xa2) commands to the PLC using the provided session handle, collects and combines their responses.

The function then extracts various configuration details from the combined response, such as IP address, netmask, gateway, domain name, and DNS servers.

It also retrieves the protocol control byte. The function returns a dictionary containing these configuration details.

8. Modify Channel cofig : modify_channel_config()

The modify_channel_config function updates the channel configuration of a PLC. It performs the following steps:

  1. Update Protocol Control Byte: Sets the 8th bit of the protocol control byte to “1” and updates the configuration.
  2. Calculate and Update CRC: Computes the CRC value for the modified configuration and updates the CRC fields.
  3. Prepare Payloads: Splits the channel configuration into two payloads for modification.
  4. Create Modified Commands: Constructs two commands with the updated configuration data, including necessary headers and payloads.

The function returns a list of modified commands to be sent to the PLC.

8. Function to send Program routine packet : program_register()

Purpose: Programs the PLC by sending a series of instructions to change CPU modes, execute commands, and more. It’s like performing a detailed operation—one step at a time—to ensure everything is set up correctly.

9. Setting Up the Connection

  • PLC: This variable holds the IP address of the PLC '192.168.0.102'
  • PORT: Port 44818 is commonly used for EtherNet/IP ML1400 PLC communication, but it might vary based on your PLC configuration.
  • socket.socket: Creates a new socket object using IPv4 addressing (AF_INET) and TCP (SOCK_STREAM) to establish a connection with the PLC.
  • sock.connect: Connects to the PLC using the IP address and port specified. This action establishes a communication channel between your script and the PLC.

9. main function routine : functions specific to HTTP

Retrieve & modify Channel Configuration

Initialize mod_element: Sets mod_element to an empty string (not used in this snippet).

Retrieve Channel Configuration: Calls get_channel_config(session_handle) to get the current channel configuration.

Define Channel Configuration Header: Specifies the header values needed for modifying the channel configuration.

Modify Channel Configuration: Uses modify_channel_config(mod_element, channel_config, channel_config_header) to update the channel configuration.

Program the PLC: Sends the modified configuration to the PLC using program_register(channel_config, session_handle).

Python POC for Malicious Payloads: Remote Exploitation of HTTP Config

POC Demo: Hacking PLCs with Python

Ever wondered what happens when you combine Python with a PLC ? It’s not a new programming language but a gateway to some serious digital shenanigans!

As shown in the video, we’re able to Remotely Enable HTTP feature of PLC.

Conclusion

In this , we examined the Remote Exploitation of HTTP vulnerability in the Allen-Bradley MicroLogix 1400 PLC. We covered how to manipulate HTTP settings and modify channel configurations.

Thank you for reading. Stay tuned for more insights and practical applications in PLC security.

<—Prev

Exploit # 9: Remote Exploitation of SNMP Config

Next —->

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top