Test recon tools about conpot HOT 20 OPEN

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

from conpot.

@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/

from conpot.

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

from conpot.

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

from conpot.

• 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?

from conpot.

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 :)

from conpot.

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

from conpot.

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

from conpot.

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

from conpot.

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 :)

from conpot.

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

from conpot.

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.

from conpot.

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

from conpot.

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

from conpot.

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

from conpot.

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

from conpot.

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

from conpot.

@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!

from conpot.

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

from conpot.

@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.

from conpot.