Application Level Denial of Service – An In-Depth Guide

Denial of Service attacks that bring down popular websites often involve thousands of hacked consumer devices and servers. While these attacks mainly aim to overwhelm the target system with traffic, in order to deny service to legitimate users, bugs at the Application Layer (Layer 7 in the OSI model) can have the same effect. Application Level Denial of Service (L7 DoS) errors are often tough to identify and sometimes even tougher to prevent. This guide aims to highlight the different techniques that will help you find out what to look for and where DoS conditions may occur. Table of Content Random Access Memory (RAM) Recursion Recursive File Inclusion Zip Bombs Billion Laughs Attack Tricking an Application Into Allocating a Huge Amount of Memory Deserialization Vulnerabilities Manipulating File Headers to Allocate Large Memory Chunks Other Reading Infinite Data Streams Central Processing Unit (CPU) Recursion reDoS SQL Injection Wildcard Attack Fork Bombs Abusing Resource-Intensive Operations Abusing Password Hashing Functions Headless Browser SSRF Disk Space Uploading Large Files Generating a Huge Amount of Databases or Log Files Arbitrary File Deletion Exhaust Allocated Resources for a Single User Email Bomb Free Website Restrictions Cash Overflow Logic-Based Denial of Service X-Forwarded-For Web Application Firewalls Wasting the...
Read more

Second-Order Remote File Inclusion (RFI) Vulnerability Introduction & Example

The main difference between a Remote File Inclusion (RFI) vulnerability and a second-order one is that in a second-order RFI, attackers do not receive an instant response from the web server, so it is more difficult to detect. This is because the payload that the attacker uses to exploit the vulnerability is stored and executed at a later stage. Exploiting a Second-Order Remote File Inclusion Vulnerability Imagine a website that allows users to submit links through a web form. These submissions are later reviewed by a moderator, on a control panel that directly adds the remote content into the page. If an attacker manages to use the form to submit a remote website containing a dangerous payload, this payload will be executed once the moderator opens the page. This means that the attacker's included will still be executed on the web server. However the attacker can not use a guided web shell with a user interface to issue commands, as the admin is the only one who would see the output. So they have to resort to alternative techniques, such as spawning a bind or reverse shell. A bind shell listens on a specific web server port and binds a shell (such...
Read more

The Equifax Breach – The Signs Were There

Whenever a big data breach happens – like the Equifax one – there is almost always a predictable order of subsequent events: The breach happens The affected company announces it The news outlets pick up the story and make it known to the general public Security researchers wonder how the breach might have happened and investigate further Then there is the aha moment: security researchers stumble a catastrophic lack of security practices, countless numbers of vulnerabilities and breaches of well-established protocols. Does It Have to Be Like This? In the end, the public often knows more about the dangerous vulnerabilities in the company's website than the actual attacker. Given enough eyeballs, all bugs become more shallow – particularly once an organisation is under public scrutiny. Going back to the series of events, you might conclude that we could completely eliminate events one to three, if there were more security researchers examining the security of their own products. So what would have happened if someone had warned Equifax about vulnerabilities on their websites before the breach happened? Would they have listened to concerned researchers? In 2016 Equifax Was Notified That Their Website Was Vulnerable To a Cross-site Scripting Vulnerability Basic XSS on Equifax, still working after being reported...
Read more