In my earlier post, “Security is Not the Point,” I explained why to most people security is an annoying layer of cost and inconvenience. I said that no one wants security, they want the benefits of security. But if security is not the point, what is?
The last time you had to do some tedious paperwork, you were no doubt muttering under your breath that you’d rather be doing the actual project and not filling out forms and writing a report. We are all like that. Documenting tasks and processes is not fun.
Compliance is like that, too. It is considered the necessary evil, the tedious paperwork required by “the powers-that-be” to meet some basic level of due care. Compliance requirements define the “minimums” for demonstrating that the business is being run responsibly.
However, compliance has a more attractive cousin. Read more HERE.
I am also the editor of the Neohapsis Labs blog. The following is reprinted with permission from
by J. Schumacher
Security professionals have been following the collective of Internet users calling themselves Anonymous for a few years now as they cause cyber mayhem to understand their tactics. There were two well written publications in recent weeks that caught my eye, The New York Times “In Attack on Vatican Web Site, a Glimpse of Hackers’ Tactics” and Imperva’s “Hacker Intelligence Summary Report, the Anatomy of an Anonymous Attack”. These articles shed light on how Anonymous takes a call to arms, recruits members, and searches for action. After reading these articles I kept thinking about current state of the Internet and wondering about the future of Anonymous’ with the cyber pandemonium it creates.
Taking the Imperva report as factual, the collective group of Anonymous has an approximate 10:1 ratio of laypeople to skilled hackers, which I believe limits the sophistication of attacks. I say “collective”, as targets for attacks are not often given from above, but must be approved or agreed upon by the masses before being launched. One very interesting note in Imperva’s report was that the attacks Imperva monitored in 2011 were not utilizing bots, malware or phishing techniques for exploit, but end users actively running tools or visiting special web sites to aid in the attack. There was a high level of public recruitment through social media of Twitter and Facebook, which can also act to inform the victim before the attack hits properly.
The New York Times article mentions that the attack on the Vatican took 18 days to gain enough recruitment and automated scanning tools were used for reconnaissance on the Vatican virtual front during this time. In this attack Anonymous was seeking to interrupt the International Youth Day by a certain date, but when that failed Anonymous changed tactics to widespread distribution of software for Distributed Denial of Service (DDoS) so they could to hit the Vatican with a thousand person attack. There were mixed statements from Anonymous and Imperva (who was a contractor for Internet security monitoring) regarding whether any sites across the globe were truly taken offline for any amount of time.
I think that Rob Rachwald, Imperva’s director of security, was quoted best by The New York Times article as saying “who is Anonymous? Anyone can use the Anonymous umbrella to hack anyone at anytime”. However, I believe Anonymous has currently reached their collective peak and will never be the same as in its early 4chan or even the 2008 days. However, by no means has the world heard the last of Anonymous, as people will be claiming affiliation to the collective “group” for a very long to come, and I believe it will also continue to evolve over time. How this change takes place is going to be exciting to see as Anonymous claims an “ideas without leaders” mentality and relies on general public for consensus of missions.
Recently, an interesting report from Symantec also came out about how Anonymous affiliates were tricked into installing the Zeus Trojan by a Pastebin tutorial covering how to install and use one of the attack tools, the Low Orbit Ion Cannon (LOIC), to support in DDoS attacks. Established Twitter handles for Anonymous contributors (YourAnonNews, AnonymousIRC, AnonOps) have tweeted that this was not done by Anonymous. But, with no leadership accountable (due to the collective nature of Anonymous), there is nothing to say whether this is a true, whether another entity is sabotaging Anonymous public fanfare, or if it was simply someone taking advantage of free publicity to trick users into installing malware. Since what many call the start of Anonymous in 2008 (Scientology attacks), there have not been any other large scale compromises of the those supporting attacks through infected tools, but this new activity could hurt the future of Anonymous recruitment and public support.
Depending on whether this recent instance of infected tools was a fluke, I see the future of Anonymous involving with skilled hackers increasing through a Wild West collaborative of honing their talents, while keeping the true base of Anonymous as largely unskilled hackers. The skilled will, at times, directly and indirectly work for entities (such as large scale crime syndicates as well as private entities) to whom they are lured by big pay for work that will never be reported in any news paper. The skilled hackers will still participate in Anonymous causes, and they will also enable other Anonymous members (through writing attack tools, scripts or apps), while also keeping knowledge of their well paid exploits limited to a smaller private offshoot group. These offshoots will put dedication into advanced exploits that require some financial backing to set up (such as servers for social engineering, injection data repository, proxies and bots) but these exploits will most likely never be communicated to the larger Anonymous collective or used for social causes of the masses but rather private gains.
At the same time though, the unskilled hackers, making up the majority of the group, are essential to Anonymous at large for bringing attention and support to causes, identifying weaknesses in networks, performing DDoS attacks and being a overall distraction and crowd to hide in. It seems bots will be unnecessary and replaced by humans where it is simpler. A large army that is not connected (outside of the odd one-off message to a public forums or social media) provides for a large pool that the authorities must sift through in finding the dedicated Anon. The collective group of Anonymous has showed support for many social causes, like the occupy movement and free speech outcries from proposed Internet legislation. At the same time Anonymous seems to have very publicly promoted every hack and breach that has been reported since 2010 whether the data exposed was government, private industry or public citizens.
I like to think of myself as a practical, but at times wishful, person. As I see it, the core ideology of the Anonymous’ movement is not going away, as their cause is not so much new as is the platform for their disobedience. There are some basic controls that organizations can implement to protect themselves from a virtual protest, whether the risk is from DDoS attacks or exploits of un-patched public devices. In the near term, I do not see a high probability of Anonymous becoming a super group of hackers that perform sophisticated attacks in the likes of Stuxnet. Nor do I see the possibility of a large scale take down of critical infrastructure. There will always be a risk and sometimes possible threats to critical infrastructure through technology but this risk can be largely mitigated through proper assessment and mitigating controls.
Side note –
If the recent instance of infected tools will continue on other causes then I believe we have seen the end of wide support for Anonymous. Distrust has always been a concern to involved members with very recent arrests across the globe for LulzSec. Anonymous will need to do internal damage control to prevent the collapse of the collective group and a public distrust in support for causes brought up by the Anons. Even if hacking group Anonymous goes in a different direct the damage has been done and Internet society can never reverse the damage physiologically from the last 5 years.
As writing this post there was news coming out that a prominent member of Anonymous, Sabu, along with 5 others have been arrested by the FBI. We will have more details once the dust settles a bit and all news sources can be processed, stay tuned.
I am also the editor of the Neohapsis Labs blog. The following is reprinted with permission from
By Michael Pearce, a Security Consultant and Researcher at Neohapsis
Throughout the US on Groundhog Day, an inordinate amount of media attention will be given to small furry creatures and whether or not they emerge into bright sunlight or cloudy skies. In a tradition that may seem rather topsy-turvy to those not familiar with it, the story says that if the groundhog sees his shadow (indicating the sun is shining), he returns to his hole to sleep for six more weeks and avoid the winter weather that is to come.
Similarly, when a company comes into the world of security and begins to endure the glare of security testing, the shadow of what they find can be enough to send them back into hiding. However, with the right preparation and mindset, businesses can not only withstand the sight of insecurity, they can begin to make meaningful and incremental improvements to ensure that the next time they face the sun the shadow is far less intimidating.
Hundreds or thousands of issues – Why?
It is not uncommon for a Neohapsis consultant to find hundreds of potential issues to sort through when assessing a legacy application or website for the first time. This can be due to a number of reasons, but the most prominent are:
- Security tools that are paranoid/badly tuned/misunderstood
- Lack of developer security awareness
- Threats and technologies have evolved since the application was designed/deployed/developed
Security Tools that are Paranoid/Badly Tuned/Misunderstood
Security testing and auditing tools, by their nature, have to be flexible and able to work in most environments and at various levels of paranoia. Because of this, if they are not configured and interpreted with the specifics of your application in mind they will often find a large number of issues, of which the majority are noise that should be ignored until the more important issues are fixed. If you have a serious, unauthenticated, SQL injection that exposes plain-text credit card and payment details, you probably shouldn’t a moment’s thought stressing about whether your website allows 4 or 5 failed logins before locking an account.
Lack of Developer Security Awareness
Developers are human (at least in my experience!), and have all the usual foibles of humanity. They are affected by business pressures to release first and fix bugs later, with the result that security bugs may be de-prioritized down as “no-one will find that” and so “later” never comes. Developers also are often taught about security as an addition rather than a core concept. For instance, when I was learning programming, I was first taught to construct SQL strings and verbatim webpage output and only much later to use parameterized queries and HTML encoding. As a result, even though I know better, I sometimes find myself falling into bad practices that could introduce SQL injection or cross-site scripting, as the practices that introduce these threats come more naturally to me than the secure equivalents.
Threats and Technologies have Evolved Since the Application was Designed/Deployed/Developed
To make it even harder to manage security, many legacy applications are developed in old technologies which are either unaware of security issues, have no way of dealing with them, or both. For instance, while SQL injection has been known about for around 15 years, and cross-site scripting a little less than that, some are far more recent, such as clickjacking and CSS history stealing.
When an application was developed without awareness of a threat, it is often more vulnerable to it, and when it was built on a technology that was less mature in approaching the threat remediating the issues can be far more difficult. For instance, try remediating SQL injection in a legacy ASP application by changing queries from string concatenation to parameterized queries (ADODB objects aren’t exactly elegant to use!).
Dealing with issues
Once you have found issues, then comes the daunting task of prioritizing, managing, and preventing their reoccurrence. This is the part that can bring the shock, and the part that can require the most care, as this is a task in managing complexity.
The response to issues requires not only looking at what you have found previously, but also what you have to do, and where you want to go. Breaking this down:
- Understand the Past – Deal with existing issues
- Manage the Present – Remedy old issues, prevent introduction of new issues where possible
- Prepare for the Future – Expect new threats to arise
Understand the Past – Deal with Existing Issues
When dealing with security reports, it is important to always be psychologically and organizationally prepared for what you find. As already discussed, this is often unpleasant and the first reactions can lead to dangerous behaviors such as overreaction (“fire the person responsible”) or disillusionment (“we couldn’t possibly fix all that!”). The initial results may be frightening, but flight is not an option, so you need to fight.
To understand what you have in front of you, and to react appropriately, it is imperative that the person interpreting the results understands the tools used to develop the application; the threats surrounding the application; and the security tool and its results. If your organization is not confident in this ability, consider getting outside help or consultants (such as Neohapsis) in to explain the background and context of your findings.
Manage the present – Remedy old issues, prevent introduction of new issues where possible
Much like any software bug or defect, once you have an idea of what your overall results mean you should start making sense of them. This can be greatly aided through the use of a system (such as Neohapsis Security Manager) which can take vulnerability data from a large number of sources and track issues across time in a similar way to a bug tracker.
Issues found should then be dealt with in order of the threat they present to your application and organization. We have often observed a tendency to go for the vulnerabilities labeled as “critical” by a tool, irrespective of their meaning in the context of your business and application. A SQL injection bug in your administration interface that is only accessible by trusted users is probably a lot less serious than a logic flaw that allows users to order items and modify the price communicated and charged to zero.
Also, if required, your organization should rapidly institute training and awareness programs so that no more avoidable issues are introduced. This can be aided by integrating security testing into your QA and pre-production testing.
Prepare for the future – Expect new threats to arise
Nevertheless, even if you do everything right, and even if your developers do not introduce any avoidable vulnerabilities, new issues will probably be found as the threats evolve. To detect these, you need to regularly have security tests performed (both human and automated), keep up with the security state of the technologies in use, and have plans in place to deal with any new issues that are found.
It is not unusual to find a frightening degree of insecurity when you first bring your applications into the world of security testing, but diving back to hide is not prudent. Utilizing the right experience and tools can turn being afraid of your own shadow into being prepared for the changes to come. After all, if the cloud isn’t on the horizon for your company then you are probably already immersed in it.