Many a times we talk about vulnerabilities, exploitations and other specific issues that cause an would be attacker to be successful in breaking into systems. But looking at the different varieties of attacks and other specific payloads used for the break in at the end of the day, it has always been a brute force or a social engineering attack that benefits the maximum, at least from the attackers point of view.
All the recent XSS attacks like the one against Apache, JIRA are all because of the fundamental weakness - Humans - As long as we have people handling certain activities and ways of doing things, these kind of breaks would continue and go on for a long time. Many say two factor solves the issue, but have in my experience found so many two factor fobs having their primary username password scribbled or hanging on the fob. How useful that is.
The purpose of the two factor can be easily defeated and again it is the indefatigable (wow where does that word come from - may be it exists) user. Many a times, it is desirable for the builds to be automated with a set of scripts to ensure there is consistency and human errors do not creep in. The other important aspect to be taught to the administrators is use a different set of passwords and usernames for your application (web app or any other app) and the operating system. We have also seen many a times, that a
easily crackable user name and password combination exists in the web application and has a corresponding account in the operating system with sometime sudo permissions. The simple idea is to separate the OS from the overlying application layer. Segregation of users may not be possible but at least an option to segregate the different components with its own set of passwords may mitigate the issue to a certain extent. A simple paradigm would be to ensure that we have consistent roll outs with minimal human interventions, though this may not be possible when it comes to a small set up where the cost of automation is not warranted. Even in such instances, it is always recommended to go in for a standard build. Build a maker checker functionality, the human fallibility when it comes to checking your own work is phenomenal. It is as good as absurd and always would be gaping holes when it comes to checking what you have done. Self audit is fine, but humans have a tendency to go about and ignoring something, because of the fact, that they are confident about what they did and the fact that it was completed by them, gives them that false sense of security. Always have another person to run through the builds, use a tool to scan and provide you with basic inputs. A tool is only as good as how well it is configured. Ensure that you use the tool properly. And presto many a problem may vanish.
All the recent XSS attacks like the one against Apache, JIRA are all because of the fundamental weakness - Humans - As long as we have people handling certain activities and ways of doing things, these kind of breaks would continue and go on for a long time. Many say two factor solves the issue, but have in my experience found so many two factor fobs having their primary username password scribbled or hanging on the fob. How useful that is.
The purpose of the two factor can be easily defeated and again it is the indefatigable (wow where does that word come from - may be it exists) user. Many a times, it is desirable for the builds to be automated with a set of scripts to ensure there is consistency and human errors do not creep in. The other important aspect to be taught to the administrators is use a different set of passwords and usernames for your application (web app or any other app) and the operating system. We have also seen many a times, that a
easily crackable user name and password combination exists in the web application and has a corresponding account in the operating system with sometime sudo permissions. The simple idea is to separate the OS from the overlying application layer. Segregation of users may not be possible but at least an option to segregate the different components with its own set of passwords may mitigate the issue to a certain extent. A simple paradigm would be to ensure that we have consistent roll outs with minimal human interventions, though this may not be possible when it comes to a small set up where the cost of automation is not warranted. Even in such instances, it is always recommended to go in for a standard build. Build a maker checker functionality, the human fallibility when it comes to checking your own work is phenomenal. It is as good as absurd and always would be gaping holes when it comes to checking what you have done. Self audit is fine, but humans have a tendency to go about and ignoring something, because of the fact, that they are confident about what they did and the fact that it was completed by them, gives them that false sense of security. Always have another person to run through the builds, use a tool to scan and provide you with basic inputs. A tool is only as good as how well it is configured. Ensure that you use the tool properly. And presto many a problem may vanish.
Comments