Stuxnet's Legacy: Get Back to Basics or Get Owned 162
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."
Security is hard (Score:5, Insightful)
No matter how much companies (and individuals) would like to pretend otherwise, security is really hard to do. It's not just a matter of having the right technology in place; people have to follow some inconvenient rules and exercise self control and common sense.
So we're always going to have some of these problems.
Re: (Score:2)
Re: (Score:2)
Sometimes the slow drag of being protected against oneself costs more than the risk being averted though.
For example, the cost of code generators to access bank accounts online in Europe surely prevents some fraud, but how much compared to the cost of every generator, and the inconvenience of not having access if you lose it.
Similar with active protection virus software not too long ago. It caused instability and slowed things down immensely.
Re: (Score:2)
Re:Security is hard (Score:4, Insightful)
Girls being used to social engineer men or using social engineering against men is as old as it gets. I'll leave it as an exercise for the reader to google up the reason why it works.
Re: (Score:3)
Re: (Score:2)
Same difference.
Social engineering via flattery or infatuation is about becoming what the other side desires the most, what is the difference between presenting a sex kitten to a man and the perfect gentlemen to a girl?
OP was right, they played on the targets desires. It's one of the simplest social engineering vecto
Re: (Score:2)
As Flyerman points out, the 16 year old was posing as a man, and she social engineered a female within the organization.
The person who got scammed was Jussi Jaakonaho, who is male.
Her gender might still have something to do with it, though. Women are generally thought to have more social intelligence than men, which might make it a little easier for them to pose as someone else in an email.
Re: (Score:2)
I'll leave it as an exercise for the reader to google up the reason why it works.
- I was trying to google up the reasons but now I am just exhausted from all the porn and I still don't know why it works :(
Re: (Score:3)
>>>trying to protect clients/users/family from themselves ...
(takes scissors to ethernet cable leading into generator, centrifuge, etc) SNIP. Okay it's secure. Never should have been on the internet in the first place.
Re:Security is hard (Score:4, Interesting)
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.
Re: (Score:3)
Rumor has it that USB keys were scattered in the parking lots.
Re: (Score:2)
I don't know if that's an actual rumour or if you're kidding, but that would probably work very well, as would leaving a simple CD with some interesting label around.
Autorun is one of the major culprits in such a scheme, although people would probably click on random innocently-named executeables, too. Guess I should try that sometime.
Re: (Score:3)
Yeah, I mean, I think they should make cars that blow up if you don't check the oil, belts, timing belts, brakes, transmission, coolant, tires, hoses, spark plugs, wires, distributor caps/rotors, and air filters precisely at the best mileage for each! That way, people who refuse to help themselves by daring to drive a car without knowing the full maintenance schedule (and implications of missing parts of it) will be taken out of the education. Those stupid, incompetent, lazy people.
Re: (Score:2)
Car drivers are more analogous to users on a controlled computer system...
Someone who (supposedly) understands the system better manages the technical details, and the users are only required to interact with a select few aspects of the system.
If you don't maintain your car, or drive it in a stupid fashion it will break sooner or later. If you don't know how to maintain it, you typically pay someone who does.
Some people do indeed buy cars and never service them at all, such cars gradually deteriorate until
Re: (Score:2)
Yeah, I mean, I think they should make cars that blow up if you don't check ... hoses, ... wires, ...
Those items can actually cause the car to explode or burst into flames...just a thought, it isn't as impossible as you are making it out to be. When you are driving around an item with 10-40 gallons of highly flammable liquids, it can explode. Good reason to respect the maintenance schedule.
Re: (Score:2)
A computer having its available data indiscriminately wiped is a comparable disaster to a catastrophic car failure in the amount of disruption it can cause. You are consummately guilty of not thinking about the implications of what you advocate, and in the classic manner are attempting to shout down anyone who might expose flaws in your reasoning.
Now, you've extended the analogy farther than it was originally grown, and in doing so invalidated it. Computers are not cars. Routine maintenance on a computer
Re: (Score:2)
Regular updates to fix known vulnerabilities would be considered routine maintenance similar to whats performed on cars...
Preventative measures, analogous to rust proofing for instance, include hardening the system, changing settings to more secure defaults and removing unnecessary exploit vectors.
Regular maintenance to a car, like regular updates to a computer will not stop a user from doing something stupid... If someone drives a car into a brick wall, or fills it with the wrong kind of fuel etc then chan
Re: (Score:2)
if somebody needs to be protected from themselves i say fuck it, let them get 0wned.
[...]
. if they do it enters this beautiful category called not your problem.
Unless you need to be protected from their actions as well say because they're introducing malware onto your network that you need for your job. Then it enters an ugly category called "your problem".
Re: (Score:2)
... or onto the network on which your bank account information is stored, or your email is stored, or that runs the system that provides water and electricity to your home...
Re: (Score:2)
You seem to misunderstand what anti-virus software does and does not do. Anti-virus software only works for known viruses and virus patterns. It does not work for unknown patterns.
If you use an insecure operating system you are more vulnerable than if you use an operating system designed from the ground up with security in mind. Anti-virus software on an insecure OS is not as effective as a secure OS.
Give a damn (Score:4, Insightful)
Re:Give a damn (Score:5, Insightful)
Thank you, Anonymous Coward. You've helped me to figure out exactly why Linux is more secure than Windows. It isn't the operating system. It isn't the user. It isn't any application, set of applications, or combination of utilities. It's right there in your post. "average users wont start giving a damn" For the most part, Linux users are those who give a damn. The attitude - nothing more, nothing less. You've got to give a damn, or the best system is just a non-secure mess of code!
I would add that there are reasons why systems like Linux appeal so much to this kind of user.
The biggest single one is that it doesn't assume you're an idiot. The system is built for users who intend to gradually become more and more familiar with how their systems work and how to maintain them. Users who traverse the learning curve at their own pace are rewarded with more and more ability to assume control and enjoy a system that does what they want the way they want to do it. You can also peek under the hood and see for yourself how things really work, with your skill level being the only limit. Generally things are made as simple as possible but no simpler, unlike Windows.
I would not classify Windows as easy to use, myself. I would call it easy to learn. Linux is quite easy to use if you have learned it. Learning how to use it is a one-time investment that continues to pay off. You can learn all about Windows but that won't make it much more convenient to automate, won't stop it from getting in your way whenever you try to do something advanced, and it won't stop it from trying to make you do things the way Microsoft intended.
The culture around Windows tends to encourage treating it like a black box and memorizing a set of steps to take in order to accomplish a specific task. The culture around Linux and Unix tends to encourage actually understanding how and why the tools work.
Linux also tends to be logical and predictable, the way you'd expect a machine to function. If something breaks, it broke for a good reason. It will stay broken until you fix it. When you fix it, it will stay fixed. You can actually get a meaningful error message that really does help you identify and isolate the problem. Windows has come a long, long way on these two points but it has yet to match the elegance of Linux and Unix. It's also helpful that all of the important configuration ultimately resides in plain text files. There is no opaque single point of failure like the Windows registry, which is a binary database that tends to become a mess over time.
I'd also say that the package management systems that come with Linux distros are vastly superior to the way software is acquired and installed on Windows. Instead of each third-party program having to chase down its own updates, often popping up nag screens requiring the user to complete the final step, you can update every last piece of software on your system with a single command. It's neater, less error-prone, and frankly less annoying. That counts for a lot considering how important it is to keep your system updated, considering how many Windows machines are compromised by exploiting already-patched vulnerabilities. Unfortunately I do not believe central software repositories would be possible on Windows, as the proprietary licenses of most Windows software would not allow third parties to redistribute them.
The users contributing the most to the rampant security problems are what I call permanent newbies. They hate learning new things. Somehow, they can use a tool for ten years without ever knowing much more about it than when they started. They don't even pick up knowledge here and there over time, let alone would they actively study anything. It is like they are too proud to do that. Asking them to do a bit of light reading for their own good is like asking an aristocrat to "fraternize with the help". It is a mentality to which I cannot easily relate. I cannot name anything non-trivial I do on a daily basis that I never learn new things about as I acquire more experience.
Re: (Score:2)
I know it's a stage all geeks go through, but man is it irritating. The only thing that kept my rage in check was the knowledge that I was an even bigger douchebag at their age.
The thing to keep in mind is that for most of the planet computers are a means to an end. They are (and should be) practically invisible to the user when t
Re: (Score:2)
Well said...
Tools aimed at end users should be greatly simplified, they don't need a full blown computer with a complex OS, they need a simple system that satisfies whatever their individual needs may be (see ipad, games consoles etc). Leave complex general purpose computing to those who know how to deal with it.
Re: (Score:3)
Managing an IT shop at a school, my biggest problem with the student workers was beating the "anyone who doesn't give a shit about computers is a stupid idiot" out of them.
I know it's a stage all geeks go through, but man is it irritating. The only thing that kept my rage in check was the knowledge that I was an even bigger douchebag at their age.
The thing to keep in mind is that for most of the planet computers are a means to an end. They are (and should be) practically invisible to the user when they work. The fact that we have to constantly harass users into sane behavior (e. g. "don't open that, it's a goddamn virus") isn't a reflection of their intelligence, it's a reflection of POOR DESIGN.
That's one "side" of it if you like. Certainly I have never advocated that we make things needlessly complex.
I am wondering how best to explain this because it's a mentality, a willingness to invest, a recognition of a certain mental laziness. I'll concentrate on some basic everyday things, for computers have become everyday tools.
I know more about driving today than back when I first obtained my driver's license. I have learned by doing, through experience. Specifically this has to do with defensive dr
Re: (Score:3)
No kidding. The only perfect security just happens to lock out all legitimate users as well. So long as some one can access the info, then some one else can find a way in as well, the more people that need to be able to access it, the more ways in there will be. It doesn't help that traditionally, security tends to be the lowest item on the list. Need to save money, most companies will skimp on security before they will skimp on janitorial. Guess they want to be sure the place looks nice for any one that br
Re: (Score:1)
My issue with Vista was simple, I don't need to be asked 3 or 4 times if I'm sure i want to open Windows Explorer in a manner that will allow me to view/modify my system as I see fit. Like it or not, once it's installed it is my computer and my Operating System(License), while security is important, if that security is circumvented I should be able to modify ANY file or directory structure on my computer as needed to remove said security breach. If I don't have access to do that due to something you've put
Re: (Score:2)
Quite so. The fact that they made it so that the security is really only aimed at watching the owner rather then protecting them is where they ended up going way wrong. I'm a fan of letting people break what they own. Protect me from others, but never protect me from my self. Sadly, real security is not popular, so companies fake it by getting in the way of the user, and most users assume it's getting in the way of the hackers even more. Real security requires that people think, and making people think does
Re: (Score:3)
But SQL injection vulnerabilities are pretty easy to avoid. I'd say in the general case SQL injection problems point are a good indication to avoid a company.
If you inadvertently allow malicious access to your DB via SQL injection - fine. Just don't fib by saying your company should be taken at all seriously when considering their security credentials.
Re: (Score:2)
Security is only hard to do if you don't know what you're securing.
Code is fractal and dense. It's an implosion of vulnerability.
Think of it instead as a building with a hundred doors. You know you can secure all those doors. But open one and behind it are a hundred more. Okay, so you can secure the first hundred, you can secure these. But behind these may be more doors, and you don't know which doors where are unlocked and can allow the outside world in.
The only way to handle this situation is to ensu
Re: (Score:2)
No. It's not that tough. You make it out to be layering against different kinds of vulnerabilities. It's much different than that.
You have an OS with its faults, access RPC with its faults, code with its faults, and libraries with their faults. You can control only parts of this in your code. The rest is choosing solid OS and RPC support, and libraries with known code and behaviors.
Then you build parsers with as much concrete as you can, update platforms, rinse, repeat.
Re: (Score:2)
Then someone comes along and finds bug #32,767 in the browser you trusted, lathers you up, and repeats all over you.
Doors inside of doors, because "solid OS and RPC support" is a hall of doors you just tacked on because someone selling it said "uh, yeah, sure. it's secure..."
Re: (Score:2)
Then the solution is something like your own cut of BSD, linted of all extraneous code, hardened kernel, with your own control of your own written RPC APIs.
Re: (Score:2)
Efficiency in coding is therefore the enemy of security in coding. Until we get back to the nuts and ensure that we can know where all the doors are and that we can check them to be sure they are all locked.
By which point hiring an army large enough to impose martial law in the whole city so you can do your business in peace comes out as the cheaper option.
Modern applications require thousands of man-hours to complete in spite of the practice you call "[importing] a whole new building behind a few new doors". If developers were forced to build them from the ground-up the cost would be almost unmeasurable, and that's even without considering the problems of auditing the damn thing, since even the best programme
Re: (Score:2)
Some things really aren't hard, though: There are plenty of well-known programming practices that make SQL injections and XSS attacks a thing of the distant past.
What is absolutely true in your post is that any company that says "buy this security product and you'll be perfectly safe" is talking nonsense. And yes, I'm including McAfee and Symantec in that kind of company.
Re: (Score:2)
There are plenty of well-known programming practices that make SQL injections and XSS attacks a thing of the distant past.
And that is part of the problem. A lot of security is still only based on "good programming practice" and while it really should be just giving the user a compile errors.
Re: (Score:2)
Re: (Score:2)
I think implementing biometrics is the way to go, swiping a finger is much easier than typing. Also don't have to remember it or write it on the post-it note stuck to the monitor.
Common sense? Well, social engineering is one of the biggest security hol
Re: (Score:3, Insightful)
Biometrics are terrible. You leave fingerprint everywhere, most fingerprint readers seem to be incredibly easy to bamboozle, it gives incentives to detach fingers, it is hard to get new fingerprints if you find out the ones you have are compromised, and on and on.
Now, for certain types of authentication they probably make a lot of sense, but not for medium value authentication across miscellaneous un-managed hardware.
Re: (Score:2)
I forget who to attribute it to, but the quote "There is no patch for human stupidity" remains as appropriate as it ever did.
derivation (Score:2)
Re: (Score:2)
Considering how long humans have been around at, roughly, the same level of intelligence, what is really stupid is to design a system that is based on a level of human performance that a significant number of humans lack.
Re: (Score:3, Insightful)
There are a few things you can do, though:
1) Don't let your developers go berserk with their framework of choice. Standardize on something company-wide, thoroughly audit/evaluate it as a platform, assign staff to maintain and patch it, and train everyone else on how to securely develop for it. I know corporations hate to train or otherwise improve their staff, but at some point they're going to have to bite the bullet.
2) Build an internal team and use them for your development needs. Mentor them, build i
Re: (Score:2)
Three words: Defense in depth.
A company can't depend on one single thing for their security. These days, it does take network security, host security, having policies in place that people follow, and periodic (scheduled and unscheduled) audits/pen tests. Without all these, it is only a matter of time before a blackhat easily gets their way in.
This doesn't mean paranoia, but it also means that one can't hide their head behind a fence and expect a blackhat not to target the derriere that is exposed.
Not so much "hard" as "lazy won't make it". (Score:2)
Basic security is easy. Very easy. It's just not convenient.
The problem is that people are lazy. Even if it is easy, they want it convenient for them.
And when it becomes convenient for them, it becomes convenient for the crackers.
The more convenient for your users, the more convenient for the crackers. It's linear. If your users can access your systems from anywhere in the world, so can the crackers.
As seen with the HBGary crack.
Re: (Score:2)
Re: (Score:2)
yes, security is hard to do, so we need to find alternative ways to protect the everso fragile code we run.
One suggestion I've seen is walling it off in 'fortresses'. Ie you do not directly run sql from code running in the web server, instead you pass fixed requests through to a back-end server process through a well-defined and small interface and have that run the sql (that you do not pass in as a parameter).
Even this is not going to be perfect, but it'll reduce the attack surface significantly. Too bad m
Re: (Score:2)
Good points. To add to this, if you let folks type free text and pass that back to sql then you are at risk. As you say if the number of ways to do this is small, the areas you have to secure are small, but it's not about passing sql back and forth, it's about accepting characters from users that eventually appear in a sql statement, something a lot of apps need to do. Parameterizing your queries is smart but it's not foolproof (of course you are not suggesting it is foolproof, I'm just trying to add some d
Re: (Score:2)
"common sense" is anything but common...
This is more of an open problem (Score:3, Insightful)
Well, the problem with most of these is even if you know about them it only takes one lazy employee to introduce them. So, its hard to be 100% vigilant against the threats and because it only takes one crack to break the damn, this makes it impossible for most security companies to improve.
Of course it still works (Score:2)
Just because you can put a label on something doesn't mean it's simple or easy to defend against. SQL injection, yes. But phishing, malicious attachments, and social engineering aren't easy or simple to defend against. Well, you can get rid of malicious attachments by getting rid of all attachments, but even if that's practical, it leaves the rest.
Meh (Score:2)
Re: (Score:2)
Here's [youtube.com] your sign [amazon.com]
Perspective (Score:5, Insightful)
And every one of them gets learned the hard way by the new batch of up-and-comers. It isn't like the average knowledge of us IT folk has gotten any bigger. Old, season folks leave, and new, green folks join. Also, management.
Re: (Score:3)
Re: (Score:2)
Uh, yeah, good luck with that.
Seriously, it is hard to codify decades of experience in to a simple class that can be easily transmitted to the next generation. Furthermore, the concept of apprenticeships has been neglected in favor of the bureaucratic and idiotic practice of Human Resources (formerly known as Personnel Management). Now we have well certified people who have absolutely no experience applying anything they have learned. They are nearly worthless in real life; but wow, they look good on paper!
Re: (Score:2)
Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible? Then all you have to do is convince the green new up and comers to use the existing tools. Only downside is that the newbies don't learn the lesson, but this particular lesson is pretty costly to learn the hard way.
Re: (Score:3)
The best solution is, as always, in between. You don't want people in 50 years time having no clue how to write a secure database library.
Re:Perspective (Score:5, Insightful)
Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible? Then all you have to do is convince the green new up and comers to use the existing tools. Only downside is that the newbies don't learn the lesson, but this particular lesson is pretty costly to learn the hard way.
In IT, there is this general belief that the seasoned professionals, also known as "old timers", are filled with antiquated and useless knowledge, while the green newbies, also known as "cutting edge fresh talent", know all the whiz-bang new way of doing things.
Sometimes, this is true, but sometimes it is not. As long as we continue to view this industry as being one that changes so rapidly that everything learned last week is obsolete, we will continue to make the same mistakes and reinvent the same flawed wheels.
Re: (Score:2)
"As long as we continue to view this industry as being one that changes so rapidly that everything learned last week is obsolete, we will continue to make the same mistakes and reinvent the same flawed wheels."
Ask any "seasoned tech professional" what does he think about seasoned tech professionals being old timers and newbies being cutting edge fresh talent. The day they stop saying "bullshit" is the day you will be right.
No, the problem is not "we viewing industry this or that". There will be problems a
Re: (Score:2)
As long as we continue to view this industry as being one that changes so rapidly that everything learned last week is obsolete, we will continue to make the same mistakes and reinvent the same flawed wheels.
I've now been in the field for 11 years. Some things have changed; now I write in PHP/javascript, most of my programming now is event driven, nearly all with prototype, etc.
But lots hasn't changed one iota. Arrays are still arrays, strings are still strings, and security holes are still security holes. Values are still passed by reference or by value, input needs to be validated, algorithms are largely the same regardless of the language, namespaces are still namespaces, etc.
I think that one of the biggest
Re:Perspective (Score:5, Interesting)
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.
Social Engineering (Score:3)
I thought phishing was a type of social engineering?
And social engineering isn't a technical problem likely to be "fixed" - it's a continuous education of users that can never be considered done or even successful.
Re: (Score:1)
I don't know if we can educate people in social engineering unless getting scam becomes a basic part of our education system and upbringing. I mean its the natural abuse of common human behavior. A 2 hour seminar isn't going to cut it for most people.
phishing, malicious attachments, social engineerin (Score:3)
The problem is people (Score:2)
Another take (Score:2)
Re: (Score:3)
I see a lot of comments about "dummies." Management needs to take a look at themselves as well. They hold the purse strings and the power of decision. In cases I have been exposed to, it's not the admins that are dropping the ball, it is the people making the decisions about things they do not appreciate or understand. Don't get me started on the overwhelming and pervasive attitude of users, "you mean I have to remember my password!?!"
As a user, don't get me started on admins & devs dropping the ball, making decisions about things they do not understand.
I spent 2 hours this week changing passwords for my work systems. I had 15 sets of credentials to update. Not all those systems are on the same 90-day expiration schedule as my main network ID, but I like to change them all at the same time. Otherwise, I'd never be able to keep my passwords straight.
And by 15 sets of credentials, I mean the user name is not the same for all of them
Re: (Score:3)
"As a user, don't get me started on admins & devs dropping the ball, making decisions about things they do not understand."
" had 15 sets of credentials to update [...] There is no excuse for these systems to not work with a single directory that lets me access them all with a single pair of user name and password."
Do you *really* think you have 15 different credentials because devs and admins? Really?
"Management needs to stop accepting solutions which do not work with the company directory"
Stop acceptin
A slightly different take. (Score:2)
Most of the cases I've seen, of that type, have been ego issues.
They are management and YOU do NOT tell THEM what to do.
It is YOUR job to protect the network given the constraints of their requirements. If you cannot do that, well, there's another guy looking for your job who says he can.
Re: (Score:2)
They're not paid enough to care. They are subject to being tossed out on the curb the moment the CEO needs to make his numbers on Wall street. Where's their motivation top care if the company gets hacked? To them, a password is nothing more than an obstacle to them making their numbers so their manager will give the other guy the axe instead.
Re: (Score:2)
That's what your competitors hope.
10 years (Score:1)
protecting against the same threats that they've faced for the last 10 years. SQL injection, phishing, malicious attachments, social engineering.
10 years? Those attacks have existed for as long as those technologies have existed.
See
(Google won't go further than the '90s, but you get my drift.)
Can be solved, but usually won't be (Score:1)
I think the social engineering, phishing, and attachments could be solved, in organizations that made it a high enough priority, i.e., ahead of being nice to employees or not spending a lot of time and money on it. It breaks down into two steps. First, train everyone very well in how to recognize and avoid the threats. Second, have a dedicated tiger team continuously try to break security by sending phishing emails, emails with pseudo-malicious attachments, and trying to social engineer the employees. First
Re: (Score:2)
How about this quote of the day from the bottom of the page?
"Dow's Law: In a hierarchical organization, the higher the level, the greater the confusion."
Security is only as strong as the weakest point (Score:1)
PHP is a big part of the problem (Score:5, Interesting)
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: (Score:3)
I hate PHP too, but the problem there is PHP programmers, not PHP itself.
What you're talking about, as someone pointed out already, is prepared statements. Virtually all mainstream programming languages have the ability to use those, including PHP for almost as long as its been mainstreamed. The only issue is that the most commonly used MySQL interface didn't use them, and the community didn't push them.
They were available AND they were easier to use than the "bad" way of doing thing. You are NOT supposed t
Re: (Score:2)
Very much agreed. I can't say PHP is a problem so much as...it encourages the problem.
My experience with PHP went something like this, back when I was a professional newb.
Boss: "I need you to write this app, here are the specs, it should be done in PHP, that way we can hand it off to another group and we don't have to maintain it".
It SOUNDED great. The problem is, php is easy. its easy to start, its easy to mock something up real quick. its easy to think you are doing well and producing something good that
Re: (Score:2)
Yup. It doesnt help that most samples you'll find online normally show the "easy quick way" of doing things, and often its the wrong way.
I'm an ASP.NET developer myself. ASP.NET has two "main" ways of working: WebForm (old), and MVC (new).
The MVC way has very good samples that generally show best practices. WebForm is technically superior in a lot of ways, but 99.999% of examples online show HORRILE HORRIBLE ways of using it.
Thus, virtually all WebForm code I've touched over a decade has sucked balls. Think
Re: (Score:2)
Thats why no amount of string escaping is 100% safe.
People like you think there is something mythical or mystical in programming. There isn't. Sanitizing user input is 100 % safe. It may not be the best way to do things most of the time, but there are times when it's the only way, like when the SQL statements are constructed from another SQL statement, which happens e.g. when pivoting a many-to-many relation.
Re: (Score:2)
You can still dynamically generate prepared statements. Thats how ORMs do it. Most RDBMs will even let you dynamically generate a prepared statement and call it within a stored procedure.
There's nothing mythical about it: escaping still sends a string to the database, and relies on the conversion algorithms of it to deal the values. Every so often, as more research is done in vulnerabilities of string encodings and whatsnots, people find ways to confuse the engines with some really screwed up strings. Its n
Re: (Score:2)
You can still dynamically generate prepared statements.
You can't use a prepared statement to dynamically turn rows into columns. Or if you know how, by all means tell me.
since you're letting your application layer guess the behavior of the database, so any change to either side, and boom! Or do you think SQL injection is just about sneaking a second command to the first one by adding --, ;, or whatever terminator the database uses, like what most script kiddy attacks do?
Sounds like folklore to me. I suppose you could run into problems if you use, say, mysql_real_escape_string() to escape a string going to, I don't know, Pervasive SQL. But what can I say... just don't fucking do it! Or did you think sanitizing input means string.replaceAll("'","''") ? In that case you'd be the naive one, not me. Also, the database engine won't just change all by itself. Someth
Re: (Score:2)
The very reason there IS a mysql_real_escape_string is one of the more well known occurance of what Im talking about. There was another case with Oracle about 2 years ago. Escape functions are unreliable.
And you can just dynamically create the SQL with concatenation, as long as the source of the data is trusted, and you use parameters, thus how you can do a prepared statements to do it: again, all good ORMs do it like this to deal with databases without a decent pivot function/facility.
Re: (Score:2)
Yes you can write bad code in PHP, that would allow an SQL attack. You can do the same in almost any language.
The issue isn't that you can blow your leg off in any language. The issue is that PHP does the equivalent of putting a big flashing red button in and daring developers not to press it. To be clear, the problem with PHP is that it was traditionally far harder to Do It Right than to Do It Wrong (a recipe for disaster in the hands of non-experts, and even sometimes experts) and that when you got it wrong, it still would work with the sort of input data that most people test with. It's just one giant collection
What else is there? (Score:2)
Re: (Score:2)
Besides "SQL injection, phishing, malicious attachments, social engineering", what other types of realistic attacks are there?
When an army of machete-wielding pirates with stacks of floppies and USB drives break down the doors to your server room, you will know... yes... you will know!
how is stuxnet an example of old vulnerabilities? (Score:3)
But seriously, stuxnet isn't as good an example of a glaring security incompetence as the recent HBGary intrusion. That started with a simple SQL injection, and ended up with executive emails revealing nefarious corporate dealings by a company pretending to be a security consultant.
Here is an EXCELLENT technical dissection [arstechnica.com] of the HBGary attack. Nothing spectacular involved. Just nuts-and-bolts hacking with impressive results.
Seth
Re: (Score:2)
Well, I read the part that said "Stuxnet's Legacy", and then I foolishly expected some kind of legacy related to Stuxnet.
Most /.ers think technology is not to blame... (Score:2)
...but I think otherwise. Technology is largely (but not 100%) to blame for the security problems. Here are the reasons:
1) the usual programming language used for most desktop/system software (C or C++) has a lot of faults: unchecked array access, pointer arithmetic, arrays interchangeable with pointers, lack of non-nullable pointers, etc. This type of programming does not scale well in complexity and time.
2) the hardware, and more specifically, CPUs, do not provide a way to isolate software components with
Hey, you are funny! (Score:2)
1 - So, that is why buffer overflow is in evindence on "SQL injection, phishing, malicious attachments, social engineering"... Oh, wait, the author didn't even remember it exists. Also, post that at the "PHP code is flawless" section. People need unchecked memory access and pointer arithimetics, just because you never a saw use for it doesn't mean that there isn't one.
2 - There are plenty of ways to isolate code sections within the same process. Some of them are used all the time, others, rarely. Anyway, th
Re: (Score:2)
Oh, wait, the author didn't even remember it exists
So? unchecked memory access and pointer arithmetic has been established as a set of flaws that lead to security problems.
People need unchecked memory access and pointer arithimetics, just because you never a saw use for it doesn't mean that there isn't one.
I need it too, but it doesn't need to be the default.
There are plenty of ways to isolate code sections within the same process.
There are none. No CPU supports component isolation from within the same process.
Anyway, that has no relevance in a discussion about security.
I already explained in my post above why it is relevant to security.
You want to sandbox the software from the file system, right?
Not only the filesystem, but any resource a program should not touch.
that means you weren't thinking about servers
What I said is valid for servers as well.
Well, most people just don't want their browsers sandboxed.
No, most people simply don't care about that, as long as they get their job don
Re: (Score:1)
As a customer I want cost minimized too though. If regulation increases overall cost the cure is worse than the disease.
Cost of a breach can be shared by more than the prevention though, which would be a case for regulation to step in, as total cost could go down, even if corporate cost goes up.
Re: (Score:3)
I'll just whip those Chinese children a little harder to increase production a few more percent so that you're happy.
Re: (Score:1)
Cost of being whipped is an expense to the children. The regulation could reduce over-all cost of the system, which in the end is what I want as a consumer.
Re: (Score:2)
Re: (Score:2)
"If this were true, then you would expect corporations to ignore labor laws, tax laws and pretty much every other rule and regulation from how many toilets per employee to what goes in the First Aid kits."
Which is exactly what corporations do as much as they can. Why do you think outsourcing and fiscal paradises are so fashionable?
Re: (Score:2)
Fact of the matter is:
- Maintaining security is a cost
- Security breaches are not a cost
Corporate policy dictates "costs are bad", ergo there's zero incentive to fix this until it's regulated.
Have a nice day.
Recovering from breaches are a cost. A huge cost. A cost that keeps on drawing, thanks to negative publicity, pissed off clients, lawsuits, turnover. Sadly, the only way to prove that for some folks is to get hacked. The nice thing is that, as more and more hype mach......media coverage gets out regarding large intrusions, the more likely the people in charge are to sit up and take notice.
Re: (Score:2)
Then think of it this way:
Maintaining security of something you don't understand is NP-hard, at best.
Securing a breach is finite.
The first is an unjustifiable cost. The second justifies itself.
Yes, this is as much a failing of corporate thinking as it is of software security design.