Digital Bond

For Secure & Robust ICS

  • Home
  • Consulting
  • S4x19
  • Dale Peterson
  • Hire Dale To Speak
  • Contact Us

Koyo/Automation Direct Vulnerabilities

February 8, 2012 by Reid W 2 Comments

From Project Basecamp, we learned that the Koyo series of PLCs has some pretty fun security issues.

The first issue is with our test device’s built-in webserver. In addition to having denial-of-service vulnerabilities, the web server itself requires no authentication and allows changes to the PLC configuration, such as its IP address. To top things off, the server does not properly validate user input, and is vulnerable to cross-site scripting attacks (XSS).

There aren’t very many ECOM100 modules available on the internet, although a clever searcher could find a few dozen. Our researcher tells us that the standard ECOM module is far more popular than the ECOM100. The ECOM module lacks a built-in webserver, but should still be vulnerable to the ECOM100’s other issue: a limited password space and no lockout/timeout for authentication attempts.

Part of our Valentine’s Day tool release is going to be a module to brute-force the Koyo’s password. This should save some end users money: from Automation Direct’s FAQ, a lost password means that the end user must send the device in for a reset.

The biggest challenge in implementing the Koyo password brute-forcer was determining the DirectNet protocol’s CRC algorithm. The HAP protocol documentation (more on how we got this below) just says, “The CRC is computed using an algorithm which implements a moving exclusive-or and a translation table.” Not terribly informative.  The 16-bit CRC is placed inside of the UDP packet’s payload (I call this ‘encrapsulation’, because UDP has its own CRC-16 in its header, making this CRC somewhat redundant).

I started disassembling the .DLLs and .EXEs included with Host Engineering’s DirectNet SDK, searching them for the string ‘CRC’. I found that the NetEdit3.exe utility included some printf()’y looking messages about CRC failures. So, I figured there must be a function in that program that was computing the CRC for the HAP protocol.  Sadly, I couldn’t trace the data xrefs to these error messages back to the CRC function very quickly.

Being a lazy reverse engineer, I came upon a silly idea: instead of grasping through code xrefs to find the CRC function, why not just search the disassembly for instructions where the mnemonic is ‘xor’ and the src and target registers differ?  xor is often used in x86 assembly for clearing a register, i.e. xor eax,eax to clear the eax register, so a little IDAPython was required.

The first two search results were inside the correct function, located at 0x4246E0 in the disassembly

 

The DirectNet CRC Algorithm

So we see that it does a few xors, a right shift, and uses a lookup table to compute the CRC. I spent a while implementing the algorithm in Ruby, when a silly idea hit me: why not just google for the bytes of the lookup table? A lot of CRC algorithms have a ‘fast’ implementation using a small dictionary to speed them up, and a clever Ruby programmer may have implemented this one before, if I know what it’s called. The table starts 0x00, 0x00, 0x21, 0x10…

It turns out this is just CRC16-CCITT. There is already a one-liner Ruby implementation, making the upcoming Metasploit module far cleaner.

I’d like to give Digital Bond alumni Daniel Peck a huge amount of gratitude — he managed to find the protocol specification nugget that gave us the ability to make the module possible. I only wish that I could give our anonymous researcher some public acknowledgement (because this person is really smart and did a lot of hard work as a volunteer).

Image by erikcharlton

Filed Under: Basecamp, ICS Vendors, PLC Security, Research, SCADA Hacking, Uncategorized, Vulnerabilities, Vulnerability Disclosure

Comments

  1. rjaromin says

    August 7, 2012 at 12:22

    Reid, you mention “The HAP protocol documentation,” and a “protocol specification nugget” that helped you understand the HAP UDP packets, can you elaborate on these points? I’m trying to dissect the protocol myself and I’m finding the automation direct and Hosteng resources lacking.

    Thanks,
    Robert

  2. Chris says

    August 3, 2017 at 11:26

    My interest is the same as Robert’s: dissecting the protocol.

    What HAP protocol documentation were you using?
    Is it available publicly?

Leave a Reply Cancel reply

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

Subscribe to the S4 Events YouTube Channel

S4x19 Is Open For Registration

Jan 14 – 17 in Miami Beach

Follow S4 Events on Facebook

Tools & Talks

DNS Squatting and You

DNS Squatting and You

February 24, 2016 By Reid W 3 Comments

Basecamp for Serial Converters

Basecamp for Serial Converters

October 30, 2015 By Reid W 3 Comments

escar Asia

escar Asia

September 9, 2015 By Dale Peterson 1 Comment

Unsolicited Response Podcast: Cyber Insurance

Unsolicited Response Podcast: Cyber Insurance

August 27, 2015 By Dale Peterson 3 Comments

S4 Events Newsletter

Subscribe to our newsletter on leading / bleeding edge ICS cyber security information and S4 Events.

* indicates required
Email Format

Dale's Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.

Recent Comments

  • Chris on Attacking CANBus – Part 1
  • Chris on Koyo/Automation Direct Vulnerabilities
  • Brandon Workentin on The ICS Security Stories We Tell And Love
  • Joe Weiss on Insanely Crowded ICS Anomaly Detection Market
  • Stuart Bailey on Unsolicited Response Podcast Is Back … With John Matherly of Shodan

Search….

Follow @digitalbond

Copyright © 2019 Digital Bond. - All Rights Reserved ·