In the last blog post, knowing your enemy part 1, we looked
at the scale of cybercrime in general and highlighted the types of threat
actors that are prevalent and pose a serious risk to organisations.
This week we are going to focus on the “Hacktivist” and what
type of vulnerabilities this type of actor is looking to exploit and how.
The Hacktivist
The hacktivist chooses
to target his enemies with data theft, reputational damage, and the defacement
of websites and denial-of-service attacks. Hacktivism is a real challenge to
international affairs and is a powerful instrument. The very fact that
hacktivism is a form of protest it a double-edged knife.
Today’s hacktivists
are found all over the world, supporting all sorts of causes. And even though
hacktivism attacks are not directly related to money loss, there is often
something bigger going on behind website defacement or denial-of-service
attacks. Eventually, however, it all leads to money leakage.
So, what steps are we talking to protect ourselves from the
“Hacktivist”, does a Quarterly vulnerability scan of our remote, external
facing infrastructure and web applications provide the level of assurance
needed?
Well, it can help, depending on the process adopted and
whether the scanning vendor adopts a thorough vulnerability confirmation
process and also performs a level of manual testing.
The problem with automated vulnerability scanners is that
they rely on typical system signatures and behaviours and cannot see any
business logic or processes like an experienced security expert.
I will provide an example of the tree attack methods to show
this in more detail.
- Data Theft and Reputational Damage
Ok so data theft means data storage, which from a web app
perspective means some form of injection type of attack against a data store,
could be SQL or could be in an XML document (XPATH injection). Do VA scanners
pick up these types of threats, yes they do and they are by and large very good
at it these days. However, will they pick up an injection vulnerability in an
area of the application that is only accessible through completing some form of
business logic transaction, will the VA be able to step though these processes.
Unlikely, unless you are using a tool that can utilise technologies such as
Ghost scripts, but even then, these are going to be static not identify all
possible scenarios. A tester would be able to manually walk through the
application business logic and identify these issues.
As for reputational damage, will a VA know if the data in
the backend data store is encrypted or not, no but a manual tester will be able
to verify this.
- Website defacement.
There are many ways to deface a website, including cross
site scripting, injections (Code, Command, SQL etc). So most of the leading
edge vulnerability scanners will pick up the majority of any input validation
issues on the input forms.
But what if for example a contact form has a CAPTCHA in
order to be processed, the VA scanner will not know how to complete the capture
and would therefore fail to complete and process the form in order to test the
thousands of potential malicious strings.
A manual test will be able to process this and perform the
manual testing needed in order to confirm if this is an issue or not. Implementing
a simple CAPTCHA is a very basic way to prevent automated attacks, but they
also prevent the automated attacking tools from working, but that does not
remove the threat or mitigate the vulnerability.
- Denial of Service
Ok so most of us still think of a denial of service attack
at the packet level (SYN Flood, Smurf, PING of Death and more recently, TOR
Hammer). These types of attacks are still prevalent but are being protected at
the WAF or Firewall effectively, although simply utilising a BOTNET, and
attacker can instruct thousands of end systems to send legitimate requests to a
website or system in order to overload it, from disparate locations.
This is where the standard network firewall will fail and
most likely so will a WAF (application layer), unless it is specifically
configured to look for this type of attack – as the traffic will be by and
large legitimate.
This type of testing requires the expert to perform
automation testing techniques, to see if the system allows the automation of forms
without throttling the traffic, which could if such an attack were to be executed,
could overload the system.
Automation testing is unfortunately not included in the
OWASP web application testing version 4 Guidelines, which is a manual assessment
process that is adopted as standard in the Industry, although it is an area of
research being undertaken and adopted by the OWASP.
What about automated VA scanner’s? Well they rely on
automation in order to be able to function, so if automation protection was in
place, they may not function correctly and could report inaccurate results.
There is also the locking of user accounts, how many
Pen-test reports where a brute force attack has succeeded through automation
and the recommendation is to add an account lockout after say 15 attempts, well
couldn’t an attacker utilise that function and lock out all enumerated users
accounts (Usually an easily guessable email address) en-mass.
So adopting an effective brute force prevention that does
not cause a DoS to end users is vital, but rarely implemented at the time of
writing.
Links
Conclusion
These are the types of issues that a “Hacktivist” will look
to exploit. Unfortunately, the default recommendations from automated VA tools
and poorly executed manual testing reports provide, which do not help.
So what’s the answer. Well, for web applications, the method
of applying a thorough web application assessment (covering the OWASP testing
guide 4 plus more in depth area’s as discussed) at least annually alongside
regular VA scan’s throughout the year, as with the PCI DSS, is crucial.
Relying on just either a single annual web application
assessment of regular VA scan’s will not provide the level of assurance required,
as the annual full assessment will cover the depth needed for the issues
discussed and the regular scans will cover of any updated input validation
strings and techniques, you need to include both in your risk management
strategy to remain protected from the “Hacktivist”
