Attacking ICS Devices - Threat Emulation with Conpot
HTML-код
- Опубликовано: 7 июн 2024
- This is a talk and presentation I was originally going to deliver at the Ockomothon conference in Denver, Colorado -- but due to the state of the world currently, that changed...
If you would like to support me, please like, comment & subscribe, and check me out on Patreon: / johnhammond010
E-mail: johnhammond010@gmail.com
PayPal: paypal.me/johnhammond010
GitHub: github.com/JohnHammond
Site: www.johnhammond.org
Twitter: / _johnhammond
Your videos always seem to address something I'm learning or that interests me. Thank you for being the person that sparked my journey into cybersecurity. I can't thank you enough.
name a better youtuber. go ahead, ill wait
John Hammond
John Hammond
pewdiepie
"better youtuber"
hahahhaahahah funny dad joke hahahhahahahahah
Thats really awesome, thanks for putting this out
amazing one john been waiting for this you rock man .....
This was really great John. Would love if you did more on ICS home labs given the issues with Conpot. Maybe there are others
You are amazing open sourcing knowledge.
Incredible video!
Good job, congrats.
The difficult bit you’re missing here is the mapping of MODBUS coils/registers to process variables.
A MODBUS master/slave just looks like an Excel sheet full of numbers.
Will the slides or presentation be available to view offline after?
I'm working in industrial automation. I specialized in ICS systems. If you have any questions feel free to contact me.
hey man... can u give me some tips? where should i start? im 16, and trying to get into cybersecurity... what university degree should i go with. ive heard that most cybersecurity stuff at colleges are outdated.. should i go with computer science and certifications later? sry for my poor english, im not native..
My question is: where do you find documentation for implementing those PLC communication messages? Just quickly looking for the S7-200 documentation gave me a headache...
Siemens are the masters of writing 200 pages when 10 will do.
Hi John
Could you share the source code of the project?
Haha i hope this kind of thing takes off. The level of security in most of these systems are a real joke. Im not talking even the controllers or software or protocol, just the basic infrastructure.
If there is a working group on this, i would love to contribute. I know some fun things that could be done.
Will have a look at conpot and see if i can contribute there too.
OPC solves a lot of security issues, MODBUS and a similar industrial protocols were designed decades ago when security wasn’t an issue snd controllers weren’t powerful enough to deal with the overhead of security.
bro i really need an updated video on this. docu is so bad
Why do i think of the Beirut explosion after seeing this
Same
Probably because you wasn’t the sharpest pencil in the pencil case if you know what I mean…
Alright - So a tank doesn't exist in isolation. A PLC Dev would never (I hope) implement a 'drop tank level' command.
(Good) PLC devs operate with a philosophy of 'how do I make sure the tank maintains an optimal level', and 'how do I ensure the system behaves in a failsafe way, especially if the physical hardware fails in any number of specific ways'. Lets say we're trying to fill the tank.
The tank itself should have some sort of level feedback - be it a digital high level sensor, or an analog feedback (the tank is 69% full). Analog feedback is more flexible because the operator can set soft limits, typically a High and High-High level. (say at 80% and 95%).
The tank will have some pipework feeding into it, perhaps with some combination of pumps and/or valves. Those valves will have a hard interlock with the tank High level feedback, i.e., the software completely disallows the pumps to run and forces the valves to close if it believes the tank is going to overfill.
Control of the tank will typically look like - if the tank lowers to a low level setpoint, run the pumps until the tank reaches a high level setpoint. Once you reach that setpoint, stop the pump. This will all happen automatically without any sort of operator interaction. Remember, the point of a control system is to take a human out of the loop.
That said, a control system will generally allow an operator to override the auto mode functionality by manually turning the pump on and off. However, the pump will still obey a certain set of safety interlocks, including the tank high level.
Which brings me to my last point - a (good) PLC dev will also operate with the mentality of 'how do I make this system operator proof'. Operators are _Excellent_ at causing things to fail in strange and unexpected ways. Maybe they wanted the tank to be filled higher, so they might try and set the High and High-High level setpoints to >100% (which will never trigger because the tank will overflow at 100%). The dev needs to ensure that those limits are always valid, and so will limit the maximum setpoint to 100%.
For these reasons, I really wouldn't put much effort into attacking an ICS from SCADA.
If you wanted to actually overfill the tank, you need to attack the inputs to the system. It might be that you can find a way to force the system believe the tank is in a different state to what it actually is. If the tank relies solely on an analog level feedback, try and force the controller to believe the tank is always at say 50%, regardless of the actual tank level. Or, it might be there's a significant distance between the tank and the pumps, and they're controlled by different controllers. Intercept the communication stream between them, identify how the tank PLC is communicating the interlock to the Pump PLC and manipulate it there. Maybe there's a complex series of valves between the pump and the tank, find a way to manipulate the valve feedback such that the pump thinks it's pumping somewhere else.
A succesful cyber attack will need to seek to sever the control system from reality.
this is a valid point, and I like the summary "..sever the controller from reality."
Windows 10 use ethical hac*king tutorial. 👍👍👍👍👍👍👍
Lol
flag{sub2john}