Does the SCADA community get interested in security? I think they not because they always say "don't touch those things, you could hurt people" to avoid moving their asses to secure their networks so with this bug and the previous about Wonderware DoS they will probably start to really secure their products and do better things during the development process.
Some people asked me how I found the vulnerability and the answer is simple:
1) Download and install the soft, duh!!!!
2) Select a process with a port listening for incoming connections (I just selected the first one I saw)
3) Start your favorite debugger
4) Set a breakpoint on recv() function (the one that receives info from TCP connections)
5) Use your favorite programming language (mine is python) and create a script to send a bunch of A's.
6) When the breakpoint hits, start debugging. You'll usually see that a byte of two are read from the socket and that is processed as the length of the rest of the packet so you could adjust your script to send a packet with those bytes at the beginning representing the length.
7) If you step out a function or two, you'll see the function that processes the packet content according to the length specified.
8) In those parser functions, you'll usually see that a byte or two are read from the packet and interpreted the field type (That is usually a huge switch-case).
8) According to the operation selected by the byte read, a byte or two are read as the size of the field to process (like Tag-Length-Value).
9) The field is copied into a fixed-size buffer on the stack by the length specified in the packet... OUCH!!! Eip = 0x41414141 ??? That's not good (for them... ahhaha)
peace!!!!!!!!!!!!!
Wednesday, June 11, 2008
Subscribe to:
Post Comments (Atom)
Subscribe in a reader
5 comments:
I confess, SCADA systems tend to follow commercial software by about five to ten years behind. The reason? It takes us that long to figure out what the flaws are like and to build a truly stable system around it.
Please don't start with the "Are we serious about this" nonsense. Nobody likes having flaws.
The reason we haven't been looking aggressively for flaws is because it was only recently that SCADA systems came to be entangled with other office IT network applications. We're still trying to figure out how one is supposed to build custom real-time applications that can somehow co-exist with office IT policies that have only recently discovered that there is a thing called availability.
You see, in the scheme of things for SCADA, Availability is at the top of the list. Not security. Not confidentiality. Availability.
You need to keep in mind that our application doesn't stop if SCADA dies. Things will continue to happen. This is very different than most office IT applications, where the computer application is the center of attention. With most industrial control systems the computer is peripheral to the primary activity.
That's how things got to where they are today. So please put aside your snide attitude and start thinking about how one can achieve availability measured in months.
Meanwhile, I'll try and figure out how to patch a real-time continuous process SCADA system.
Fair enough?
Jake, I know what you mean but I think that there are other things to consider:
1) Developers MUST know that a static buffer must be carefully handled, this is thumb rule.
2) Don't you audit yours soft to find logical bugs (not security ones)???
3) Security is really important in such systems even if they aren't connected to common IT networks cause someone with access to a device in a SCADA network could compromise the entire system (whether it's in an IT net or not) and that is UNACCEPTABLE.
I know that some of these things are new to SCADA guys but all I say is that making excuses never helped any OS vendor like microsoft, apple or anyone else so that should be taken as an example of how NOT to proceed :)
Jake, i understand your post and the mean attitude of Topo doesn't help. But keep in mind that the next bug on Scada systems may not be found by a security researcher, but real scary people that will use against your systems or instead of reporting it to the vendor. You should be glad, IMHO.
Topo you should consider the positives here:
- They found a flaw
- It was ethernet based
- They fixed the flaw.
Fact of the matter is the SCADA is one of those horrible aunties you have to deal with but don't like. I found it hard enough for them to include IT into their environment as they felt it was "insecure".
Fact of the matter, if someone is determined enough to hack Citect, figure out how it work and change the parameters - they know more than 50% of the industry, and will probably get a job out of it. Windows recently killed CitectSCADA system i was working on recently - all by failing while installing XP SP3. Just like that the whole system crashes. Likewise I have killed a whole redundant ring office network (HP) via a storm created by a RTU using ethernet to serial (9600bps).
In most situations with SCADA security is top of the list, which is why I ask you to please change your tone - the market is paranoid enough without naysaying. (google IEC61850 if you dont believe me). The only way forward is by IT helping the poor sods in SCADA and SCADA talking nicely to IT.
> - They found a flaw
I did, not them.
> - It was ethernet based
Hell yeah :)
> - They fixed the flaw.
After getting lots of other people involved, otherwise they didn't.
I politely reject your offer change my tone :)
SCADA systems are a piece of sh**t full of security bugs which make them perfect target for a terrorist attack/movie because they are such a piece of cr**p that only in movies you that kind of hack.
Now seriously, IT should be concerned and a bit of pressure will make them move their big fat as***s from their chairs.
peace!
Post a Comment