Stuxnet's Legacy: Get Back to Basics or Get Owned

Gunkerty Jeb writes "Attacks such as Stuxnet, Operation Aurora or GhostNet are not what most enterprises and organizations need to be worried about. The plain fact is that most organizations are falling far short in protecting against the same threats that they've faced for the last 10 years. SQL injection, phishing, malicious attachments, social engineering. Old, every one of them. And yet, still incredibly effective at compromising networks in some of the best-known and theoretically best-protected companies."

Re:Perspective

[COMON$]

Now this is a mixed message because coming up through the IT field it was the old timers causing the security problems. "What? I have to clean my inputs? This is the way I have always done it and this is how I am going to keep doing it" as well as "bah, our company is not a target".

Now it is 10 years after I entered the field full time, things are FAR FAR FAR FAR FAR better. Yes there are still old sites out there, there are still companies that don't update their security because they are struggling to keep the lights on. But seriously as opposed to 10 years ago, Infosec is widespread, companies have security training seminars for employees, Pentests are a regular phenomenon. This increased security is largely because those of us who grew up with tech, intentionally went into the field, and really enjoy the work are now getting to the 10-15 year range on experience and fixing all the damn problems our predecessors set before us. All the while doing our best to defend against the up and comers who are trying to push out projects as fast as possible to pad their resume.

PHP is a big part of the problem

[Animats]

PHP is a big part of the problem. PHP's interface to SQL encourages putting in parameters without proper escaping. Python has a slightly different interface, one where there's one SQL statement with fields represented by %s, and a tuple with the values to be filled in. The values are escaped automatically. If PHP had only such an interface, most SQL injection attacks would fail.

It would help if there was simply a restriction that only one SQL statement can be submitted per call. Since all the major SQL implementations now have transactions, there's no reason to put two statements in one call any more.

Another problem with PHP is a tendency to install a large number of standard PHP scripts which shouldn't be installed at all. Look at your server logs and you'll see constant attempts by hostile sites to call common bad scripts.

Hosting "control panels" implemented in PHP are part of the problem. If you have one of those, you can't just turn off PHP, even if you're not using it. Worse, "control panels" tend to run with very high privileges, and present a large attack face.

Re:Security is hard

[dudeman2]

Actually, those centrifuges were never on the public Internet. Stuxnet was cleverly designed to infect the workstations running Step 7 PLC programming software, hijack the communications with the PLC to install its payload on the PLC. I don't know if the Step 7 workstations were on the Internet either; they may have been infected by sneakernet - USB keys, CDROMs, and the like.