Test recon tools

[glaslos]

There are various tools available to identify IC systems. We should run them against conpot and create a recon tool profile for better handling in the future. This could also be integrated as a test to verify if we are responding according to the modbus specification. Infracritical NMAP scripts: http://www.infracritical.com/?p=4909

[glaslos]

Metasploit has a couple of modules we can test against Copot: http://dev.metasploit.com/redmine/projects/framework/repository/entry/modules/auxiliary/scanner/snmp/

[glaslos]

@creolis Would be awesome if you have something like a document about your results:

• Name of tool
  • Protocols scanned
  • Conpot support
  • Required to fully support

Maybe add some example profiles that show how to provide the information requested by the scanners. The document could be added somewhere in the documentation: https://glastopf.github.io/conpot/

[glaslos]

Running plcscan against Conpots modbus resulted in an error in plcscan and an exception in conpot.

[katkad]

hi,

1. plcscan asks for slave no. 255. so i changed default.xml to contain slave 255
2. in modbus_server.py handle() i take only response from self._databank.handle_request() and i log what i get:

response = self._databank.handle_request(query, request)
elapse_ms = int(time.time() - start_time) * 1000

logger.debug('Modbus traffic from {0}: {1}'.format(address[0], session_id))

logger.info("XX"+format(response)+"XX")

in log:

**2013-09-02 16:01:51,716 XX('\x00\x00\x00\x00\x00\x03\xff\xab\x01', {'function_code': 43, 'slave_id': 255, 'request': '2b0e0100', 'response': 'ab01'})XX**

debug in modbus.py from plcscan:

def DeviceInfo(self):
        print 'AAAAA'
        res = self.Request(0x2b, '\x0e\x01\00')
        print 'BBBB'

python ./plcscan.py 192.168.1.1
Scan start...
AAAAA8.1.1:502...   
AAAAA
192.168.1.1:502 unknown protocol
Scan complete

[glaslos]

• Any idea why plcscan asks for slave 255? Is that some standard?
• plcscan's Request never returns. Did you had a look what it expects as return value?

[creolis]

I will ask Dmitry for the reason - according to the example he posted on google code, he seems to expect an error message:

 127.0.0.1:502 Modbus/TCP
   Unit ID: 0
     Response error: ILLEGAL FUNCTION
     Device info error: ILLEGAL FUNCTION
   Unit ID: 255
     Response error: GATEWAY TARGET DEVICE FAILED TO RESPOND
     Device: Lantronix I WiPo V3.2.25

so probably using "0" and "255" is not intended and he just abuses this fact so that the device reveals its identity ("Device:") inside the error response stanza.

But let's see if Dmitry responds :)

[glaslos]

0 in modbus is the broadcast slave id, so the message goes to all slaves and shouldn't return something to the client. Broadcast only allows write (makes in some way sense). 255 is actually not a slave id and should cause an error response. See #97

[creolis]

f*\ I forgot ... I'm sending the request to Dmitry right now .. sry :(

[glaslos]

Do that but I think I figured out most of it :)

[creolis]

I also expected that it tries to trigger an error response, so I think you're right - but I'm curious if this matches his intensions :)

[creolis]

From: Dmitry --> I'm allowed to quote him here:

Hi Daniel,

First of all, I’m not so familiar with Modbus PLC so maybe I’m wrong…

The purpose of plcscan – to get Modbus response from remote device (no matter OK or error) and try to get device identification.

I suggest, that most of slave device would response for request with Unit Identifier 0 or 255:

“On TCP/IP, the MODBUS server is addressed using its IP address; therefore, the
MODBUS Unit Identifier is useless. The value 0xFF has to be used.
…
Remark : The value 0 is also accepted to communicate directly to a
MODBUS/TCP device.” (http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf)

And, yes, I suggest that gateway devices would also response for request with id 255. And as I know some of them response for “Read device identification” request.

Also you could use --brute-uid option to brute slave devices behind gateway, or --modbus-uid to try special uids.

If now devices that don’t response for uids 0 and 255, or if you know better candidates for default uids, please let me know.

Best regards,
Dmitry Efanov

[glaslos]

So it looks like that if we are serial, we should treat uid like this

The MODBUS slave device addresses on serial line are assigned from 1 to 247 (decimal). 
Address 0 is used as broadcast address.

In TCP mode Dmitry is right, the default uid seems to be 0 and 255/0xFF.

[glaslos]

More tools to try: https://github.com/atimorin/PoC2013

[glaslos]

DNP3 fuzzing: https://github.com/OpenRCE/sulley

[adepasquale]

How about testing these IDS rules too? http://www.digitalbond.com/tools/quickdraw/dnp3-rules/ http://www.digitalbond.com/tools/quickdraw/modbus-tcp-rules/

[glaslos]

Here a couple of other tools: https://github.com/atimorin/scada-tools

[z-abdellahi]

how to send read request in dnp3?? by which tool it is possible to send read request??

[xandfury]

@z-abdellahi Sorry. We currently don't support dnp3. You may still try proxying a DNP3 connection with Conpot if you have a real device.

In case you don't, you may try proxying a device running open-plc. This is a personal opinion, not an endorsement. Good luck!

[z-abdellahi]

can i use Burp to proxy dnp3 traffic and change th code functions??

[xandfury]

@z-abdellahi I don't think Burp is the right tool here since it can be used to intercept and decode HTTP, HTTPS traffic only. DNP3 is a different protocol altogother. With wireshark, you may be able to edit/view packet contents but it wouldn't "intercept" packets. Just save the edited packets to logs etc..
A quick google search tells me Netsed can do the job for you.