Brute Force: Anatomy of an Attack

Leave a reply

I am back to blogging, but my blog posts now appear on the Varonis blog. I will keep publishing links to those posts here for my loyal followers.

This time:

The media coverage of NotPetya has hidden what might have been a more significant attack: a brute force attack on the UK Parliament.  While for many it was simply fertile ground for Twitter Brexit jokes, an attack like this that targets a significant government body is a reminder that brute force remains a common threat to be addressed.

It also raises important questions as to how such an attack could have happened in the first place.  These issues do suggest that we need to look deeper into this important, but often misunderstood type of attack.

Read more…

Bobby Tables real life coutnterpart

Leave a reply

If you are a member of the application security community, you are bound to know this hilarious xkcd cartoon. It is so good that it found its way to non-expert circles. I once got it physically framed as a birthday present from friends.

tables

Like most of you, I though that this is a great way to explain SQL injection. For most of us, this is what it is. For a few, it is a real life problem

My dear friend Or Katz published an even more hilarious blog post outlining the challenges of someone who happens to have a first name which is an SQL keyword. His post is also a very good discussion of the use, or rather abuse, of signatures for web application security. A great and worthwhile read.

Anniversary to the ModSecurity Core Rule Set celebrated with a new major release

Leave a reply

I have a very warm place reserved for the ModSecurity Core Rule Set (CRS). I created it a decade ago. Actually the first release in the readme file, labeled 1.1, is dated to October 2006, so this is an anniversary. And what a great present I got for the Anniversary from Chaim Sanders, Walter Hop and my dear friend Christian Folini: a brand new major release!

If you don’t know what the CRS is, a short introduction is due. Continue reading →

The WAF Guidebook: What is a Web Application Firewall?

2 Replies

Simply put, Web Application Firewalls are security controls designed to provide the best automated operational protection for HTTP applications, whether web based on mobile. What is “the best” protection, or even “sufficient protection” is not a simple question.  As a result there is a spectrum of solutions for protecting web applications with varying quality and functionality. Which one can call itself a web application firewall is not an easy question to answer.

Probably the only way to define a web application firewall is to list the key features common to web application firewalls uniquely suited for protecting web and mobile applications and which would differentiate than other operational security controls such as intrusion prevention systems and network firewalls. The following sections touch on those key features of WAFs. A fuller discussion of the features will follow in later posts. Continue reading →

Sorting out web automation attacks

1 Reply

If anything makes  web applications security different, and more interesting, than traditional information security, those are threats to the application logic, i.e. attacks that abuse legitimate functionality. Such attacks often raise legal and ethical questions: if this is legitimate functionality, can it be an attack? Ethical questions a side, there is no question that click fraud, scraping and comment spam cause real pain and financial damage to web site owners.

The new OWASP automated threat handbook tries to sort out this field and define an ontology for web automation attacks and for countermeasures.

My own presentation on the topic takes a different approach: there is no real dividing line between valid and malicious automation. It is a continuum. I scored each such automation technique for “obviousness”, i.e. how clear it would be that this is automated and not and for maliciousness.  Based on the scores I split the techniques into obviously malicious, accepted and borderline. So for example, given a 1-5 scale (1 being not obvious/not malicious, 5 being obvious/malicious):

  • “Auction sniping” gets 2 for obviousness and 3 for maliciousness – which makes it borderline.
  • “Web spam” 3 for obviousness and 4 for maliciousness – the extra points puts it in the malicious category.
  • At the edges, Blind SQL injection gets 5 and 5 (so it is extra malicious) while comparative shopping gets 1 for maliciousness as it became a standard in the industry. Which does not imply the “attacked” web site is not negatively impacted.

Read the presentation to get the scored for all of them and learn what “Queue Jumping”, “auction sniping” and “web spam” are!

The WAF Guidebook: Secure Development Life Cycle

Leave a reply

(This is the first chapter of a Web Application Firewall Guidebook to be published in the next few posts)

Before getting into web application firewalls let’s review the problem they solve and alternative solutions. As web application security is essentially a software quality problem, resolving it require fixing the way we develop, deploy and operate software. This process is usually referred to as the software development life cycle, or SDLC for short. The security aspects of the SDLC process are called Secure Development Life Cycle, which confusingly has the same abbreviation: SDLC.

Ideally, fixing the security of web applications should be done at all SDLC stages as vulnerabilities are introduced in all stage. While it is better and potentially cheaper to fix issues early on, no quality assurance is perfect and bugs are carried on to following SDLC stages.

Since there is a cost for implementing security in any stage of the SDLC, when allocating resources we need to make a choice as to where to invest and how much. If any of the solutions outlined below was a silver bullet, the decisions would have been easier, however this is not the case. Is it better to invest a lot in educating developers and having a more secure code but neglect to test or protect the code in the operational environment? probably not, after all no code is vulnerability free no matter how good the developers were. On the other hand, should we only deploy a real time operational control such as a web application firewall? It would be unnerving to release buggy software no matter what automated solutions are there to protect it.

Let’s review the available application security solutions at every stage of the SDLC: Continue reading →