Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So they messed with the synchroniser and the synch check relays, on a reciprocating deisel. I design such systems and it sort of reads ok, but a few key details not right or not explained - those size of generators grid connected will have reverse power, pole slip, instantaneous over current electrical protection as well, AVR excitation limiting, plus overspeed relays which would not have let this happen. (gas turbines traditionally have a hydraulic control oil relief overspeed "bolt" that comes out with centrifugal force and no software could mess with, these days electronic replacements are coming in vogue, but...)

As for synch check, rule of thumb is two independant systems, one hard wired, three overall if you can swing it because often one of the multifunction protection relays will have that function available and you wire it and/or code it in line.

But I have seen big reciprocating diesels go into synch at 30-60 degrees out of phase and if they hold without tripping the generator protection then you might get a brief flicker of the lights, some stress on the crankshaft that who knows what it does long term, but some of them were old and had it done to them many times.

Yeah, so they did it, waste of a good machine for known outcome if ask me, very wasteful with no need.

And it is a very particular kind of attack, if you knew it was a problem it could be protected against for hundreds or thousands of generators literally in 24 hours or less - hardwired synch check which can be achieved with a voltage relay at it's simplest.

So I am not seeing anything in that excerpt other than highighting bad design practices.



> Yeah, so they did it, waste of a good machine for known outcome if ask me, very wasteful with no need.

And yet there are plenty of people who don't understand that software problems can cause permanent damage to hardware or people. Or they think of it in the abstract. I don't think it's wasteful to demonstrate.

It was definitely costly in this case. I think the author could have done with a smaller demonstration. But there is something to be said for grandeur.

> So I am not seeing anything in that excerpt other than highighting bad design practices.

Indeed. I think that was exactly the point of the demonstration.


There's 2 reasons why security researchers go beyond a theoretical demonstration into a destructive one:

1) Security researchers have an intense need to show their exploits actually work in case they're accused of not providing proof.

If you go to Defcon, most of the presenters spend half their talk on showing use of the exploit, no matter how tedious it is to the audience.

(When I supervise IT security audits, I have to tell pentesters just to document what they find instead of making changes, which introduces more problems and wastes time and effort. I've had auditors find a configuration file with passwords on a production server that uses them, then try to present a report on how they logged into each one. Duh, of course they work.)

2) This is related to #1, but business people, especially across silos in an organization, may not fully comprehend an exploit unless there is obvious proof. I've seen laughable levels of denial by otherwise intelligent people once they get into management. As in, "Yeah you showed it to me on the screen, but I'll need to confirm it with other sources" who then look at the same screen.

Pro tip 1: by default AWS AMI's are not encrypted. (The reason is that the main list of AMIs doesn't use your KMS keys.) So if you have a compliance program that requires encryption at rest, get cracking!

Pro tip 2: All theoretical exploits have shown to be practical ones later. Stop deceiving yourself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: