It was a clear example of what the world powers who oppose Iran are capable of. They understood the ASM that was being delivered to the controllers of SPECIFIC IRANIAN airgapped devices. The agency responsible was able to exfiltrate enough information regarding those devices that they could create a highly sophisticated operational "glitch" that would severly damage Layer 1 devices. That's worlds beyond someone knowing you have X phone with X version of firmware...
Wrong. It WAS worlds beyond, but now we've delivered thousands of copies of it to terrorist wanna-bees around the globe.
The military developers of Stuxnet were certainly geniuses, but they were also short-sighted idiots who didn't consider the collateral damage of deploying a weapons-grade tool on the internet. All that brain-power you boast about is now in the hands of global sociopaths ranging from corrupt governments to 4channers who might redeploy it for teh lulz.
Assuming you know SCADA (and you can learn all you need to on line) you can modify Stuxnet's payloads to damage any Siemens industrial control based system you can get it to. You could make a variant that randomly operates valves or motors anywhere. Screw trying to target the Predator drone factory: just cause chaos anywhere, and they can even blame the Americans or Israelis for producing the worm.
I hope every factory in America is patching their systems and updating their security policies, but I'm guessing that some will fail at it, and we're going to see a public instance of collateral damage on shore as a result. It won't be a nuclear plant, but it might be a bakery or dairy that fails to sterilize their products, causes a chemical factory to vent pesticides, or maybe a waste treatment plant will route all raw sewage to the nearby river. Less spectacularly, it may just kill a few factory workers when their safety equipment goes offline.
All this might even have been worth it if Stuxnet had succeeded at destroying the Busheshr turbine, and their nuclear program was disabled for a few years. But it didn't. It interfered with a couple hundred centrifuges, and delayed the refining of some of their U-235. So now we still have a nuclear Iran, and we've given them their very own cyberweapon.
It was intended to be laughable, but insane works for me, too. But the point is valid. Trying to defend stuff with DRM from determined hackers is similar in many ways to trying to defend anything else that can be found in the hands of determined hackers -- useless.
The Stuxnet went after control systems in nuclear power plants. The only thing that happened was they couldn't run - BFD.
No, that's not the only thing that happened. Stuxnet physically damaged a number of centrifuges, it prevented them from successfully enriching uranium, and its second payload appears to have been designed to cause their nuclear reactor's steam turbine to destroy itself, which would have delayed their ability to create a nuclear bomb for years.
Nuclear weapons have human controls - nothing gets launched without a human being turning keys and pressing buttons.
Sure, we're told that American nuclear weapons have human controls. But do we really know that Pakistan's missile triggers aren't connected to a computer network? That the Pakistani president doesn't have an iNuke app on his phone, with a single big red button labeled "Mumbai" glowing in the middle of the screen? Or that North Korea's weapons are air-gapped, and not just hooked to a 300 baud modem in some back room?
If the world powers join to "pinch off" the threat, and the treaties and hotlines are in place to address that, then it has a chance of working.
So the US, China and Russia all agree to not hack electrical power plants? BFD. Who's going to convince Iran, Iraq, North Korea, Israel, Nigeria, Chechnya, Lichtenstein and Morocco to not make secret plans? Who's going to convince the various organized criminal entities? Who's going to stop J. Random Hacker, who can download and modify a copy of Stuxnet from the comfort of his mother's basement?
Think about it: the best (most experienced) people to ask for advice on how to be effective at stopping hackers would be the RIAA. And if that image doesn't convince you how useless attempting it is, you're deliberately not paying attention.
I think the ISP's will be much more effective in fixing any problems, possibly by blocking all traffic from the offending country, if it comes down to that.
This is "cyberwar" (their word, not mine) we're talking about. General Hayden, the former Director of the NSA, spoke at Blackhat on the topic this summer. He said that the Internet today resembles a vast indefensible plain, and that an enemy attack can come from anywhere. He thought (hoped?) a kind of "geography" would eventually evolve on the internet, allowing for tactical maneuvering, permitting the kind of strategies warriors like to fight and defend from. You're alluding to a similar type of thinking, where if the attack comes from China, you pull the cable on the back of your router marked "From China".
It's that kind of thinking that's unfortunately going to fail at cyberwar.
If I'm attacking your country's systems, I'm not coming from China. I'm hopping hacked servers and networks from China to Estonia to Russia to France to London to New York. If it's a DDoS attack, I'm not commanding a million Chinese PCs to send you SYN packets, I'm sending one instruction to a command and control network to tell an army of zombies across the country and globe to send you SYN packets. Or I'm activating the hostile commands buried in my counterfeit Cisco routers spread across your country by cheapo eBay resellers.
The best defense against info-warfare is to have a good alternate strategy. Twitter may not need backups, but Wall Street does. Industrial plants and the electrical grid need air gaps (and obviously a lot more protection than they have today.) The armed services need an isolated network. So does the intelligence community. The first, second, and third jobs of cybercommand should be creation of these defense plans.
Do you care as much about the recipients reading the email, or do you care more if they act upon it? I'd go for the tracking URL if it's the latter.
As a recipient of such fine emails as yours, a web bug will never tell you if I got them or not as I long ago blocked linked image downloading. But if I'm interested in the content, I'll usually click on the tracking link rather than going to my browser and manually loading the related web page. If the email is useful to me, I don't mind rewarding the email system with feedback saying they successfully delivering an interesting link to me.
Of course you'll still only have a unique sneakemail.com address, and if you cheese me off for any reason you'll end up on my blacklist, unknowingly never able to deliver a message to me again.
Let's use the extreme bad analogy: various actresses have appeared in movies in a state of undress; so would the same judge also decide it "does no harm" if Google sent staff to sneak onto their properties, photo them through their bathroom windows, and publish naked pictures of them on the Web then -- as they've shown they "don't value their privacy"?
The problem with trivializing the bomb squad's action is the next suspicious object may not be a innocent little toy.
No, the next innocent object will also be innocent. The next object found stuck to a bridge will not be a bomb. Nor will the next, nor the next after that, nor the next after that.
The only realistic way this could have been a bomb is if we already had a rash of bombs. But until there's a proven problem in this country with bombs stuck to bridges, train platforms, buses, sidewalks, signs, streetlights, wastebaskets, and slow-moving cats, no, it's not a bomb, and I can say that with fifteen digits of confidence. Out of all the hundreds of thousands of objects I will see on the way home tonight, exactly 0 of them will be bombs.
There is a huge gulf between possible (a boolean) and probable (a double precision float). Saying it could be a bomb fuels the stupid people who think a boolean possibility means a 50/50 probability -- the extremely stupid, gullible, and cowardly 'we-gotta-cover-our-asses' crowd who insisted the police blow up this toy, for example.
Don't feed the fear-mongering trolls another bite.
But really, can you see this speech getting you elected to office:
"Sure, a lot of good folks died on 9/11, but we have to be strong. 9/11 is bait, we have to be sure not to walk into the trap, because we have so much more to lose than they can ever hope of gaining. Some are calling for war. War will cost trillions of dollars and thousands more American lives. I've authorized a small team of operatives to act on capturing the perpetrators dead or alive, and I've activated a special diplomatic corps to curry favor with host countries for allowing our teams to work on their soil. First we're going to ask politely, then we'll bribe them, and if that doesn't work, we'll threaten embargo and international action, and finally, we'll use our superior skill and technology to just go ahead and get the job done as cleanly as possible without permission. Hopefully it doesn't come to that."
Holy crap, I'd vote for you like a Chicago voter -- at least twice per election! And that's not even considering your stance on the economy, health care, taxes, abortion, human rights, animal rights, the environment, global warming, or anything else we're told matters. If you're that rational about terrorism, you've already proven you're more rational and honest than every politician in office today.
Yes, a lot of spying had to happen in order to make this worm effective. The industrial plant reconnaissance was critical, but I left out the part where the worm incorporates code signed by not one but two different secret signing keys, one from Realtek and one from JMicron (both of which were revoked back in July when it was discovered.) Someone had to break into both of those companies, steal their signing keys, and leave undetected. If the companies were following good security protocols (no guarantees) the signing machines should have been offline and inaccessible to any but a physical attack. Yet another instance where highly qualified spies would have been used.
To answer your "alternatives to Siemens" question, I'm not an industrial logic guy (my factory experiences are limited to pre-SCADA serial communications with G-code based CNC tools, and prior to that a mop bucket) so I'd recommend you ask one. I do know Siemens is one of the biggest and most respected players in the field, and that another big player is GE Industrial. But I know nothing about their control software, what platforms they run on, or other such useful data.
I think the immediate Siemens problems with Stuxnet can be dealt with via security patching. For example, removing the hard-coded password the worm exploits would be a good start (sorry, another omitted detail.) But they really need to redesign their product line in terms of security, and that's going to take a long, long time, given what I've learned following the story of this worm.
One more thing to consider is a point raised by another commenter. After investing the millions of dollars needed to create this precisely crafted and targeted weapon, would its creators leave to chance that a USB stick would somehow just find its way from an infected engineer's PC to a control station? It's possible that the USB air gap "hack" was added to divert attention from an inside agent who intentionally slotted the Stuxnet-laden stick into the control system; the same agent who possibly gave them the details of the system in the first place. It would eliminate chance. My point is that Windows may have been targeted simply because that's what the Iranians use. Had they been running on a different system, the attackers would likely have still found a different way to breach it, just not in public via a worm like Stuxnet.
I'd guess the likely answer is performance. In the serial world of drive access we live in now, extra bits of address take extra transit time to send. 2 TB can be addressed in 32 bit sector numbers. One petabyte would take something like 42 bits to send and would probably be rounded up by engineers to 48 bits, which is 50% longer for each and every block requested. So sending the full address block for each 512 byte sector requested would slow all storage transfers down by about half a percent.
If we're talking parallel interfaces, then petabyte addressing costs more at the connector and size level. You now need 48 wires instead of 32, and your connector size needs to be bigger, heavier, and costlier.
All this performance and/or expense would paid today for hardware that may not commercially exist for a decade. Is everyone willing to accept that penalty now?
BTW, abandoning Windows as the operating system is not as easy as a "week or so" dropping in of a UNIX environment. Both the control software and programming environments are built exclusively on Windows 2000. Siemens would have to port their entire package before any such changes could be made. Given the complexity of the systems they support, I would guess that the porting job will not be easy.
What's really odd is that these are obviously safety and life critical systems. Windows long ago came with warnings in their licenses saying stuff like "not for use in nuclear power plants or on submarines" (I remember Slashdot mocking them for it.) And while their operating system security resembles Swiss cheese, unlike the cheese they do not improve with age. How did Siemens justify continuing down the Windows path? Why didn't their engineers balk?
Interesting. So what you're essentially saying is the AUTORUN propagation exploit was built only to provide a plausible cover to their inside agent at the plant.
It seems that the targeting abilities of the wore were wildly exaggerated. The worm reports back to servers, hmm air gap, that makes no sense. It seems there was a lot of obfuscating built into the worm, specifically to hide how it gain entry past an air gap, and how any new program was accepted on appliance based machines.
I would bet the worm 'bought' it's way in and the external stuff was typical 'COINTELPRO' misinformation.
You're making a lot of assumptions that are simply incorrect.
You really should read the analysis of the worm's function as written up by Symantec's researchers. They published exactly how it bridges the air gap -- a bug in how Windows processes the AUTORUN.INF file permits infecting a machine as soon as removable media is inserted, and does not rely on AUTORUN itself to be turned on. The rest of the infected machines serve as the conduit for delivering updated virus payloads and instructions to the machines that write the USB sticks or CD-ROMs that cross the gap. Assuming the operators of the plant had to perform maintenance or updates (which happens often as existing devices are reconfigured or new ones are brought on line) the updated payloads will find their way across the gap soon enough.
And Symantec wasn't the only company to decompile the worm and figure it out.
Nobody had to 'buy' the worm in. Nobody had to falsify how it got installed. The worm itself provides the evidence of sophistication. If you doubt it, simply get a copy and infect your Windows machine, put in a fresh USB stick, then put the USB stick into an uninfected Windows machine. Now you have your own copy of proof in the form of two infected machines.
Where espionage would come in would have been in studying the nuclear plant, learning what the control system configuration was, how their engineers used removable media to bridge the air gap for ordinary maintenance, then designing a payload that would specifically target their process.
Just disconnect any sensitive nuclear facility from the freaking Internet. Are they so stupid?
No, they're not stupid. Of course the nuclear plant's control network is isolated from other networks. You just don't understand how this worm works.
Using one of four different previously unknown (0-day) Windows exploits, it finds its way onto new machines. Two of the exploits are network attacks (one print spooler, one RPC.) One of the exploits strikes using a bug in how Windows reads the AUTORUN.INF file, and will install the virus whenever infected removable media is inserted, such as USB sticks or CD-ROM discs. Stuxnet is written to all removable media on an infected machine. AUTORUN can be disabled, but the bug is such that it doesn't matter -- simply inserting the infected media spreads the infection.
It's stealthy, and hides itself using Windows rootkit methodology. It looks for specific 32-bit Windows operating systems and which antivirus software packages are installed, and will either fail to install if the antivirus can't be worked around, or it uses different exploits to elevate privileges depending on the security environment of the machine.
It contacts a set of command and control servers (that were taken offline) to download updates to the virus. The virus-infected machines periodically check in to those servers to see if there's new payload or software, update themselves, then spread it around to the other infected machines.
Once it finds its way onto a machine running "Step 7", a programming environment for programming Siemens industrial control systems, it modifies the code that is compiled for the control system. It uses another kind of hiding technology that acts like a rootkit here, telling the engineer that the deployed code is OK.
The engineers do their work on an infected machine connected to the regular networks. They then have to transfer their newly compiled control program data onto the isolated control network. They typically do so using USB sticks or CD-ROMs, which then infect the machine that is transmitting the code to the industrial control network.
The modifications to the data sent to the control network are subtle. Stuxnet has two payloads. The first tries to figure out that it's in an environment that matches the target by comparing frequency controller IDs with those of specific Iranian-made controllers, looks for an array of more than 32 of them, and then watches to see if they run at high speeds for a couple weeks. If so, it'll switch to a damage cycle where it over-revs the centrifuge motors, then suddenly slows them, then suddenly speeds them up again. It repeats this hour-long cycle once every 27 days or so. Even if the over-revving doesn't damage the centrifuges, the sudden slowdowns and speed-ups mixes the uranium up again, rendering the purity of the uranium inexplicably unrefined.
The other payload appears to be intended to cause more damage. It's believed to be designed to attack the control systems at the Buhesher nuclear reactor, opening and closing steam valves in order to over-stress the turbine, with the intent of destroying the 150 foot long shaft and its enclosure. It also pretends to be the reactor's environmental sensors, and reports false data back to the controller; all of this faked data makes the turbine look like everything's operating normally, but in reality a hellstorm is going on inside the turbine enclosure.
I was very surprised that he admitted it, at first. A rational leader would never confirm an attack like this that couldn't externally be proven.
But then I remembered this guy is from a different world, and isn't talking to us. He's a kleptocrat who stays in power by painting the image of a religious strongman, and talks to his ignorant power-base making it sound like his scientists gloriously smashed the meaningless virus as they would a Western fly.
So I don't know if this child-like line is a simplification made by the translator (who might have difficulty with technical language) or if this is how he normally talks to his people?
1. No, it's not the first. The 2010 Verizon Data Breach Report shows that 54% of successful attacks using malware used customized or custom-written malware, and that 97% of the data records stolen were done so with the use of custom malware.
2. Yes, we're going to see a lot of it. It's already begun, according the the engineer who dissected the industrial control code that stuxnet injected.
Re:Can we get a sultry female voice instead?
on
Linux Radio
·
· Score: 2, Funny
OMFG, I thought you were kidding! Then I thought it was a hack of some sort, but Blitzableiter didn't complain about the flash. It really does moan your IP!
Re:Holy cow !!!
on
Linux Radio
·
· Score: 2, Funny
Agreed. When you get into some of the blocks of repeated stuff, such as #includes, it builds up a bit of rhythm, then breaks arrhythmically into code, which sounds like it evolves its own rhythm. It's not unlike a techno or electro percussion line. Throw some lines of synth along the top of this, and you'd have an album.
And I just followed the advice on the page: "if you can't get enough, you can always open Linux Radio in two or more different browser tabs". Ooo! It makes me feel all cybery inside!:-)
How about combining the worst with the worst? Add "nofollow" to any links in negative reviews, and copy negative reviews to a shadow site that's filled with links to sites known for porn, pedophilia, viruses and malware.
I agree with most of what you said, but there is a certain kind of parasite (who lurks in flattish organisational hierarchies) who will always opt for prescribing more processes and tying the whole project up with red tape, so that they can guarantee that project failure can be blamed on someone not following due process.
This also has the handy side effect of making them seem extremely important and busy with project management, without having to build anything that solves the client's problem in time and budget.
There's a thin line there that you may not see from your vantage point (I can only assume you're an engineer.) I'll offer an example near to my heart, and see if I gain any sympathy from you.
I'm a lead engineer that is working on trying to improve the "quality" of a large, old, legacy product. One of the approaches I'm working on is adding automated unit tests. It's a big challenge, as unit tests can be very difficult to retrofit into certain types of existing code (code with many environmental dependencies, code that indirectly alters state, code that mixes dependent object construction with object logic, etc.) To do so, I'm trying to show the engineering teams the benefits of writing automated unit tests: they help prevent repeat bugs; they help catch new bugs; they make maintenance easier by providing usage examples; they reward the creation of more usable interfaces; they strongly reward appropriate module design by making the tests much easier to write; and they can lead to test driven development. My intent is that once the engineers recognize the benefits, and see some working examples, they will be less hesitant to write and fully use them.
My boss is asking questions like "how will we govern this? How will we ensure they are writing automated unit tests? I want you to add a tollgate, or a review board, to make sure they write them." It's making me crazy, because those are exactly the wrong approaches. If teams are required to write unit tests, they will write just enough to meet whatever minimum is set in the standard, and never actually use them to improve their code. And it's doubly tough in the waterfall methodology, because once they have written what they think is working code, they want to waste no more time in delivering it by having to go back and add tests after-the-fact.
So it's an example of the competing goals I mentioned earlier. Project teams don't want to write tests because they add time to the delivery dates. The boss oxymoronicly wants processes that prove "quality" happened. I have to increase the quality of the product and want to do so the most effective manner (which does not include red tape.)
And I am certainly trying hard not to be the parasite you mentioned but I'm stuck in that middle zone you described, busy with project management, I'm not adding code to directly solve the client's problems, increasing project budgets, and under pressure to apply artificial constraints that are orthogonal to success. If I don't keep doing it, the code base will get even worse. So if the worst thing that comes out of this is that the other engineers view me as a parasite, I guess I can live with that.
No, you really can't prove anything. Code testing code is not a proper proof especially when they are both written by the same user. If I contract you to program a pacemarker, why should I trust you when you say, "look all my tests pass, therefore all requirements are met"?
Two things. First, a contract for a safety critical device (such as a pacemaker) is going to include all kinds of formal testing requirements that a one-man-shop will never be able to meet alone, so it's not a valid example. Building the test fixture for pacemakers is substantially more complex than building the devices, according to a co-worker who actually worked on building test fixtures for pacemakers.
But if someone runs the tests your mythical lone cowboy wrote, and says "look this test failed, you'd kill someone with this code, go back and fix it," I'd believe that a lot. I'd feel better about someone with "white box knowledge" writing a strong testing package than adding someone with only "black box knowledge". The white box author will understand the edge cases better.
Of course it doesn't prove a negative, and the single author writing their own tests won't catch all the missing cases, which is your point. I get it. But enough test cases and proper management of them can ensure that mistakes made before aren't repeated. Test cases can be engineered to thoroughly cover expected situations. Writing those test cases can lead you down additional code paths, and lead you to recognize new unhandled cases. And different kinds of testing (such as fuzzing) can be automated to give you some confidence that your product will work even in the presence of unexpected inputs, errors, and even malicious attacks.
2. Slavish adherence to anything (incl. processes) MAY be ill advised at times. Typically, standards and/or processes are instituted for a good reason. This does not remove the need to consider whether they are appropriate in all cases. Process does not remove the need to think.
The problem is that slavish adherence to process is seen by many as a guarantee of ass-covering. If things go wrong BECAUSE of the process, the person who followed it blindly still believes that they did no wrong. I've seen important people go out of their way to defend a failing process, just because they play an important role in it, and would be uncomfortable (or perhaps fearful for their jobs or their teams' jobs) if it were to change in any way.
5. I agree that even where "best practice" processes are in place, there are still inordinately many failures. However in my experience (25 years), this is almost ALWAYS down to people/political issues. My own hypothesis is that there is no system, process, methodology or framework that can enforce appropriate behaviour and that cannot be "gamed". The best you can do is try and minimise the opportunities for gaming the system. Irrational agents (at any level) can (and will if given enough time) completely bugger up the best laid plans.
In any modestly sized organization (or larger), you will find a number of people are going to behave this way regardless of the process. Adding more processes (such as checklists, tollgates, audits, etc.) in an attempt to make the system game-proof takes the system in the wrong direction. The best approach I've found is to involve the dissenters in changing the process -- give them the opportunity to improve it. The hope is that they'll see that other people recognize they play a valuable part in the process (removing fear), they'll see the amount of compromise that goes into making some of the weird decisions (getting the bigger picture), and maybe recognize that they can never get 100% of what they want. But if they feel they are a part of it, and are able to address the most egregious violations of sanity they have to deal with, they usually accept the new situation.
Slashdot Mirror
It was a clear example of what the world powers who oppose Iran are capable of. They understood the ASM that was being delivered to the controllers of SPECIFIC IRANIAN airgapped devices. The agency responsible was able to exfiltrate enough information regarding those devices that they could create a highly sophisticated operational "glitch" that would severly damage Layer 1 devices. That's worlds beyond someone knowing you have X phone with X version of firmware ...
Wrong. It WAS worlds beyond, but now we've delivered thousands of copies of it to terrorist wanna-bees around the globe.
The military developers of Stuxnet were certainly geniuses, but they were also short-sighted idiots who didn't consider the collateral damage of deploying a weapons-grade tool on the internet. All that brain-power you boast about is now in the hands of global sociopaths ranging from corrupt governments to 4channers who might redeploy it for teh lulz.
Assuming you know SCADA (and you can learn all you need to on line) you can modify Stuxnet's payloads to damage any Siemens industrial control based system you can get it to. You could make a variant that randomly operates valves or motors anywhere. Screw trying to target the Predator drone factory: just cause chaos anywhere, and they can even blame the Americans or Israelis for producing the worm.
I hope every factory in America is patching their systems and updating their security policies, but I'm guessing that some will fail at it, and we're going to see a public instance of collateral damage on shore as a result. It won't be a nuclear plant, but it might be a bakery or dairy that fails to sterilize their products, causes a chemical factory to vent pesticides, or maybe a waste treatment plant will route all raw sewage to the nearby river. Less spectacularly, it may just kill a few factory workers when their safety equipment goes offline.
All this might even have been worth it if Stuxnet had succeeded at destroying the Busheshr turbine, and their nuclear program was disabled for a few years. But it didn't. It interfered with a couple hundred centrifuges, and delayed the refining of some of their U-235. So now we still have a nuclear Iran, and we've given them their very own cyberweapon.
It was intended to be laughable, but insane works for me, too. But the point is valid. Trying to defend stuff with DRM from determined hackers is similar in many ways to trying to defend anything else that can be found in the hands of determined hackers -- useless.
The Stuxnet went after control systems in nuclear power plants. The only thing that happened was they couldn't run - BFD.
No, that's not the only thing that happened. Stuxnet physically damaged a number of centrifuges, it prevented them from successfully enriching uranium, and its second payload appears to have been designed to cause their nuclear reactor's steam turbine to destroy itself, which would have delayed their ability to create a nuclear bomb for years.
Nuclear weapons have human controls - nothing gets launched without a human being turning keys and pressing buttons.
Sure, we're told that American nuclear weapons have human controls. But do we really know that Pakistan's missile triggers aren't connected to a computer network? That the Pakistani president doesn't have an iNuke app on his phone, with a single big red button labeled "Mumbai" glowing in the middle of the screen? Or that North Korea's weapons are air-gapped, and not just hooked to a 300 baud modem in some back room?
If the world powers join to "pinch off" the threat, and the treaties and hotlines are in place to address that, then it has a chance of working.
So the US, China and Russia all agree to not hack electrical power plants? BFD. Who's going to convince Iran, Iraq, North Korea, Israel, Nigeria, Chechnya, Lichtenstein and Morocco to not make secret plans? Who's going to convince the various organized criminal entities? Who's going to stop J. Random Hacker, who can download and modify a copy of Stuxnet from the comfort of his mother's basement?
Think about it: the best (most experienced) people to ask for advice on how to be effective at stopping hackers would be the RIAA. And if that image doesn't convince you how useless attempting it is, you're deliberately not paying attention.
I think the ISP's will be much more effective in fixing any problems, possibly by blocking all traffic from the offending country, if it comes down to that.
This is "cyberwar" (their word, not mine) we're talking about. General Hayden, the former Director of the NSA, spoke at Blackhat on the topic this summer. He said that the Internet today resembles a vast indefensible plain, and that an enemy attack can come from anywhere. He thought (hoped?) a kind of "geography" would eventually evolve on the internet, allowing for tactical maneuvering, permitting the kind of strategies warriors like to fight and defend from. You're alluding to a similar type of thinking, where if the attack comes from China, you pull the cable on the back of your router marked "From China".
It's that kind of thinking that's unfortunately going to fail at cyberwar.
If I'm attacking your country's systems, I'm not coming from China. I'm hopping hacked servers and networks from China to Estonia to Russia to France to London to New York. If it's a DDoS attack, I'm not commanding a million Chinese PCs to send you SYN packets, I'm sending one instruction to a command and control network to tell an army of zombies across the country and globe to send you SYN packets. Or I'm activating the hostile commands buried in my counterfeit Cisco routers spread across your country by cheapo eBay resellers.
The best defense against info-warfare is to have a good alternate strategy. Twitter may not need backups, but Wall Street does. Industrial plants and the electrical grid need air gaps (and obviously a lot more protection than they have today.) The armed services need an isolated network. So does the intelligence community. The first, second, and third jobs of cybercommand should be creation of these defense plans.
Do you care as much about the recipients reading the email, or do you care more if they act upon it? I'd go for the tracking URL if it's the latter.
As a recipient of such fine emails as yours, a web bug will never tell you if I got them or not as I long ago blocked linked image downloading. But if I'm interested in the content, I'll usually click on the tracking link rather than going to my browser and manually loading the related web page. If the email is useful to me, I don't mind rewarding the email system with feedback saying they successfully delivering an interesting link to me.
Of course you'll still only have a unique sneakemail.com address, and if you cheese me off for any reason you'll end up on my blacklist, unknowingly never able to deliver a message to me again.
Let's use the extreme bad analogy: various actresses have appeared in movies in a state of undress; so would the same judge also decide it "does no harm" if Google sent staff to sneak onto their properties, photo them through their bathroom windows, and publish naked pictures of them on the Web then -- as they've shown they "don't value their privacy"?
Links please!
Oh my god, am I a closet Paultard?
Excuse me, i have to go wash my brain out with bleach. Eeew.
The problem with trivializing the bomb squad's action is the next suspicious object may not be a innocent little toy.
No, the next innocent object will also be innocent. The next object found stuck to a bridge will not be a bomb. Nor will the next, nor the next after that, nor the next after that.
The only realistic way this could have been a bomb is if we already had a rash of bombs. But until there's a proven problem in this country with bombs stuck to bridges, train platforms, buses, sidewalks, signs, streetlights, wastebaskets, and slow-moving cats, no, it's not a bomb, and I can say that with fifteen digits of confidence. Out of all the hundreds of thousands of objects I will see on the way home tonight, exactly 0 of them will be bombs.
There is a huge gulf between possible (a boolean) and probable (a double precision float). Saying it could be a bomb fuels the stupid people who think a boolean possibility means a 50/50 probability -- the extremely stupid, gullible, and cowardly 'we-gotta-cover-our-asses' crowd who insisted the police blow up this toy, for example.
Don't feed the fear-mongering trolls another bite.
But really, can you see this speech getting you elected to office:
"Sure, a lot of good folks died on 9/11, but we have to be strong. 9/11 is bait, we have to be sure not to walk into the trap, because we have so much more to lose than they can ever hope of gaining. Some are calling for war. War will cost trillions of dollars and thousands more American lives. I've authorized a small team of operatives to act on capturing the perpetrators dead or alive, and I've activated a special diplomatic corps to curry favor with host countries for allowing our teams to work on their soil. First we're going to ask politely, then we'll bribe them, and if that doesn't work, we'll threaten embargo and international action, and finally, we'll use our superior skill and technology to just go ahead and get the job done as cleanly as possible without permission. Hopefully it doesn't come to that."
Holy crap, I'd vote for you like a Chicago voter -- at least twice per election! And that's not even considering your stance on the economy, health care, taxes, abortion, human rights, animal rights, the environment, global warming, or anything else we're told matters. If you're that rational about terrorism, you've already proven you're more rational and honest than every politician in office today.
Yes, a lot of spying had to happen in order to make this worm effective. The industrial plant reconnaissance was critical, but I left out the part where the worm incorporates code signed by not one but two different secret signing keys, one from Realtek and one from JMicron (both of which were revoked back in July when it was discovered.) Someone had to break into both of those companies, steal their signing keys, and leave undetected. If the companies were following good security protocols (no guarantees) the signing machines should have been offline and inaccessible to any but a physical attack. Yet another instance where highly qualified spies would have been used.
To answer your "alternatives to Siemens" question, I'm not an industrial logic guy (my factory experiences are limited to pre-SCADA serial communications with G-code based CNC tools, and prior to that a mop bucket) so I'd recommend you ask one. I do know Siemens is one of the biggest and most respected players in the field, and that another big player is GE Industrial. But I know nothing about their control software, what platforms they run on, or other such useful data.
I think the immediate Siemens problems with Stuxnet can be dealt with via security patching. For example, removing the hard-coded password the worm exploits would be a good start (sorry, another omitted detail.) But they really need to redesign their product line in terms of security, and that's going to take a long, long time, given what I've learned following the story of this worm.
One more thing to consider is a point raised by another commenter. After investing the millions of dollars needed to create this precisely crafted and targeted weapon, would its creators leave to chance that a USB stick would somehow just find its way from an infected engineer's PC to a control station? It's possible that the USB air gap "hack" was added to divert attention from an inside agent who intentionally slotted the Stuxnet-laden stick into the control system; the same agent who possibly gave them the details of the system in the first place. It would eliminate chance. My point is that Windows may have been targeted simply because that's what the Iranians use. Had they been running on a different system, the attackers would likely have still found a different way to breach it, just not in public via a worm like Stuxnet.
I'd guess the likely answer is performance. In the serial world of drive access we live in now, extra bits of address take extra transit time to send. 2 TB can be addressed in 32 bit sector numbers. One petabyte would take something like 42 bits to send and would probably be rounded up by engineers to 48 bits, which is 50% longer for each and every block requested. So sending the full address block for each 512 byte sector requested would slow all storage transfers down by about half a percent.
If we're talking parallel interfaces, then petabyte addressing costs more at the connector and size level. You now need 48 wires instead of 32, and your connector size needs to be bigger, heavier, and costlier.
All this performance and/or expense would paid today for hardware that may not commercially exist for a decade. Is everyone willing to accept that penalty now?
BTW, abandoning Windows as the operating system is not as easy as a "week or so" dropping in of a UNIX environment. Both the control software and programming environments are built exclusively on Windows 2000. Siemens would have to port their entire package before any such changes could be made. Given the complexity of the systems they support, I would guess that the porting job will not be easy.
What's really odd is that these are obviously safety and life critical systems. Windows long ago came with warnings in their licenses saying stuff like "not for use in nuclear power plants or on submarines" (I remember Slashdot mocking them for it.) And while their operating system security resembles Swiss cheese, unlike the cheese they do not improve with age. How did Siemens justify continuing down the Windows path? Why didn't their engineers balk?
Interesting. So what you're essentially saying is the AUTORUN propagation exploit was built only to provide a plausible cover to their inside agent at the plant.
It could have happened that way.
It seems that the targeting abilities of the wore were wildly exaggerated. The worm reports back to servers, hmm air gap, that makes no sense. It seems there was a lot of obfuscating built into the worm, specifically to hide how it gain entry past an air gap, and how any new program was accepted on appliance based machines.
I would bet the worm 'bought' it's way in and the external stuff was typical 'COINTELPRO' misinformation.
You're making a lot of assumptions that are simply incorrect.
You really should read the analysis of the worm's function as written up by Symantec's researchers. They published exactly how it bridges the air gap -- a bug in how Windows processes the AUTORUN.INF file permits infecting a machine as soon as removable media is inserted, and does not rely on AUTORUN itself to be turned on. The rest of the infected machines serve as the conduit for delivering updated virus payloads and instructions to the machines that write the USB sticks or CD-ROMs that cross the gap. Assuming the operators of the plant had to perform maintenance or updates (which happens often as existing devices are reconfigured or new ones are brought on line) the updated payloads will find their way across the gap soon enough.
And Symantec wasn't the only company to decompile the worm and figure it out.
Nobody had to 'buy' the worm in. Nobody had to falsify how it got installed. The worm itself provides the evidence of sophistication. If you doubt it, simply get a copy and infect your Windows machine, put in a fresh USB stick, then put the USB stick into an uninfected Windows machine. Now you have your own copy of proof in the form of two infected machines.
Where espionage would come in would have been in studying the nuclear plant, learning what the control system configuration was, how their engineers used removable media to bridge the air gap for ordinary maintenance, then designing a payload that would specifically target their process.
Just disconnect any sensitive nuclear facility from the freaking Internet. Are they so stupid?
No, they're not stupid. Of course the nuclear plant's control network is isolated from other networks. You just don't understand how this worm works.
Using one of four different previously unknown (0-day) Windows exploits, it finds its way onto new machines. Two of the exploits are network attacks (one print spooler, one RPC.) One of the exploits strikes using a bug in how Windows reads the AUTORUN.INF file, and will install the virus whenever infected removable media is inserted, such as USB sticks or CD-ROM discs. Stuxnet is written to all removable media on an infected machine. AUTORUN can be disabled, but the bug is such that it doesn't matter -- simply inserting the infected media spreads the infection.
It's stealthy, and hides itself using Windows rootkit methodology. It looks for specific 32-bit Windows operating systems and which antivirus software packages are installed, and will either fail to install if the antivirus can't be worked around, or it uses different exploits to elevate privileges depending on the security environment of the machine.
It contacts a set of command and control servers (that were taken offline) to download updates to the virus. The virus-infected machines periodically check in to those servers to see if there's new payload or software, update themselves, then spread it around to the other infected machines.
Once it finds its way onto a machine running "Step 7", a programming environment for programming Siemens industrial control systems, it modifies the code that is compiled for the control system. It uses another kind of hiding technology that acts like a rootkit here, telling the engineer that the deployed code is OK.
The engineers do their work on an infected machine connected to the regular networks. They then have to transfer their newly compiled control program data onto the isolated control network. They typically do so using USB sticks or CD-ROMs, which then infect the machine that is transmitting the code to the industrial control network.
The modifications to the data sent to the control network are subtle. Stuxnet has two payloads. The first tries to figure out that it's in an environment that matches the target by comparing frequency controller IDs with those of specific Iranian-made controllers, looks for an array of more than 32 of them, and then watches to see if they run at high speeds for a couple weeks. If so, it'll switch to a damage cycle where it over-revs the centrifuge motors, then suddenly slows them, then suddenly speeds them up again. It repeats this hour-long cycle once every 27 days or so. Even if the over-revving doesn't damage the centrifuges, the sudden slowdowns and speed-ups mixes the uranium up again, rendering the purity of the uranium inexplicably unrefined.
The other payload appears to be intended to cause more damage. It's believed to be designed to attack the control systems at the Buhesher nuclear reactor, opening and closing steam valves in order to over-stress the turbine, with the intent of destroying the 150 foot long shaft and its enclosure. It also pretends to be the reactor's environmental sensors, and reports false data back to the controller; all of this faked data makes the turbine look like everything's operating normally, but in reality a hellstorm is going on inside the turbine enclosure.
It's quite a sophisticated worm.
"Yeah, and last year you said diarrhea builds character."
He was just shitting you.
I was very surprised that he admitted it, at first. A rational leader would never confirm an attack like this that couldn't externally be proven.
But then I remembered this guy is from a different world, and isn't talking to us. He's a kleptocrat who stays in power by painting the image of a religious strongman, and talks to his ignorant power-base making it sound like his scientists gloriously smashed the meaningless virus as they would a Western fly.
So I don't know if this child-like line is a simplification made by the translator (who might have difficulty with technical language) or if this is how he normally talks to his people?
1. No, it's not the first. The 2010 Verizon Data Breach Report shows that 54% of successful attacks using malware used customized or custom-written malware, and that 97% of the data records stolen were done so with the use of custom malware.
2. Yes, we're going to see a lot of it. It's already begun, according the the engineer who dissected the industrial control code that stuxnet injected.
They need the voice from MoanMyIP.com.
http://www.moanmyip.com/
OMFG, I thought you were kidding! Then I thought it was a hack of some sort, but Blitzableiter didn't complain about the flash. It really does moan your IP!
Agreed. When you get into some of the blocks of repeated stuff, such as #includes, it builds up a bit of rhythm, then breaks arrhythmically into code, which sounds like it evolves its own rhythm. It's not unlike a techno or electro percussion line. Throw some lines of synth along the top of this, and you'd have an album.
And I just followed the advice on the page: "if you can't get enough, you can always open Linux Radio in two or more different browser tabs". Ooo! It makes me feel all cybery inside! :-)
How about combining the worst with the worst? Add "nofollow" to any links in negative reviews, and copy negative reviews to a shadow site that's filled with links to sites known for porn, pedophilia, viruses and malware.
I agree with most of what you said, but there is a certain kind of parasite (who lurks in flattish organisational hierarchies) who will always opt for prescribing more processes and tying the whole project up with red tape, so that they can guarantee that project failure can be blamed on someone not following due process.
This also has the handy side effect of making them seem extremely important and busy with project management, without having to build anything that solves the client's problem in time and budget.
There's a thin line there that you may not see from your vantage point (I can only assume you're an engineer.) I'll offer an example near to my heart, and see if I gain any sympathy from you.
I'm a lead engineer that is working on trying to improve the "quality" of a large, old, legacy product. One of the approaches I'm working on is adding automated unit tests. It's a big challenge, as unit tests can be very difficult to retrofit into certain types of existing code (code with many environmental dependencies, code that indirectly alters state, code that mixes dependent object construction with object logic, etc.) To do so, I'm trying to show the engineering teams the benefits of writing automated unit tests: they help prevent repeat bugs; they help catch new bugs; they make maintenance easier by providing usage examples; they reward the creation of more usable interfaces; they strongly reward appropriate module design by making the tests much easier to write; and they can lead to test driven development. My intent is that once the engineers recognize the benefits, and see some working examples, they will be less hesitant to write and fully use them.
My boss is asking questions like "how will we govern this? How will we ensure they are writing automated unit tests? I want you to add a tollgate, or a review board, to make sure they write them." It's making me crazy, because those are exactly the wrong approaches. If teams are required to write unit tests, they will write just enough to meet whatever minimum is set in the standard, and never actually use them to improve their code. And it's doubly tough in the waterfall methodology, because once they have written what they think is working code, they want to waste no more time in delivering it by having to go back and add tests after-the-fact.
So it's an example of the competing goals I mentioned earlier. Project teams don't want to write tests because they add time to the delivery dates. The boss oxymoronicly wants processes that prove "quality" happened. I have to increase the quality of the product and want to do so the most effective manner (which does not include red tape.)
And I am certainly trying hard not to be the parasite you mentioned but I'm stuck in that middle zone you described, busy with project management, I'm not adding code to directly solve the client's problems, increasing project budgets, and under pressure to apply artificial constraints that are orthogonal to success. If I don't keep doing it, the code base will get even worse. So if the worst thing that comes out of this is that the other engineers view me as a parasite, I guess I can live with that.
No, you really can't prove anything. Code testing code is not a proper proof especially when they are both written by the same user.
If I contract you to program a pacemarker, why should I trust you when you say, "look all my tests pass, therefore all requirements are met"?
Two things. First, a contract for a safety critical device (such as a pacemaker) is going to include all kinds of formal testing requirements that a one-man-shop will never be able to meet alone, so it's not a valid example. Building the test fixture for pacemakers is substantially more complex than building the devices, according to a co-worker who actually worked on building test fixtures for pacemakers.
But if someone runs the tests your mythical lone cowboy wrote, and says "look this test failed, you'd kill someone with this code, go back and fix it," I'd believe that a lot. I'd feel better about someone with "white box knowledge" writing a strong testing package than adding someone with only "black box knowledge". The white box author will understand the edge cases better.
Of course it doesn't prove a negative, and the single author writing their own tests won't catch all the missing cases, which is your point. I get it. But enough test cases and proper management of them can ensure that mistakes made before aren't repeated. Test cases can be engineered to thoroughly cover expected situations. Writing those test cases can lead you down additional code paths, and lead you to recognize new unhandled cases. And different kinds of testing (such as fuzzing) can be automated to give you some confidence that your product will work even in the presence of unexpected inputs, errors, and even malicious attacks.
2. Slavish adherence to anything (incl. processes) MAY be ill advised at times. Typically, standards and/or processes are instituted for a good reason. This does not remove the need to consider whether they are appropriate in all cases. Process does not remove the need to think.
The problem is that slavish adherence to process is seen by many as a guarantee of ass-covering. If things go wrong BECAUSE of the process, the person who followed it blindly still believes that they did no wrong. I've seen important people go out of their way to defend a failing process, just because they play an important role in it, and would be uncomfortable (or perhaps fearful for their jobs or their teams' jobs) if it were to change in any way.
5. I agree that even where "best practice" processes are in place, there are still inordinately many failures. However in my experience (25 years), this is almost ALWAYS down to people/political issues. My own hypothesis is that there is no system, process, methodology or framework that can enforce appropriate behaviour and that cannot be "gamed". The best you can do is try and minimise the opportunities for gaming the system. Irrational agents (at any level) can (and will if given enough time) completely bugger up the best laid plans.
In any modestly sized organization (or larger), you will find a number of people are going to behave this way regardless of the process. Adding more processes (such as checklists, tollgates, audits, etc.) in an attempt to make the system game-proof takes the system in the wrong direction. The best approach I've found is to involve the dissenters in changing the process -- give them the opportunity to improve it. The hope is that they'll see that other people recognize they play a valuable part in the process (removing fear), they'll see the amount of compromise that goes into making some of the weird decisions (getting the bigger picture), and maybe recognize that they can never get 100% of what they want. But if they feel they are a part of it, and are able to address the most egregious violations of sanity they have to deal with, they usually accept the new situation.