->Part of the F5/Owasp Top Ten Series
At the top of the Owasp list is Injections. Their definition is
“Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. “
Long story short, it’s is allowing unsanitized input into a program field that has the potential for execution. (which is darn near everywhere these days)
Everyone knows the story of little bobby:
In all honesty, I thought that Bobby’s Mom had a very valid point.
Let’s Inject:
Basic injection attacks are fairly simple to perform. We find an input parameter and try to send it something nefarious. In my labs, I’ve got a nice little auction site up and running. Everyone loves an auction.
To bid on items, of course, you need to be authenticated. Well, being the evilHacker, I want to get in without using my credentials. This is where the injection comes in. Using either passive intelligence gathering or just guessing due to the common usages, I decide to try a simple SQL-Injection attack:
The input we are injecting into is the USERNAME field:
Username: ‘ or 1=1 #
Pre-Injection:  | Post Injection:  |
Huh… a logged in user of ‘ or 1=1 #? Rut Row Shaggy! So what is going on here? Lets look at the code at play:
<php yadda yadda yadda
$query = "select id from users where nick='$username' and password='".md5($MD5_PREFIX.$password)."' and suspended=0";
It says:
Find me the user who’s username and password matches the input (username, plus some MD5 fun on the password) AND whose account is not suspended. How nice.
So what evilHacker did was make that simple query say:
$query = "select id from users where nick=`‘ or 1=1 # and password='".md5($MD5_PREFIX.$password)."' and suspended=0";
Now it says:
Find me the user <no one> or 1=1 (1=1 is a truth statement). In essence you get a select all records that exist in the table users.
Not a very strong front door eh?
Let’s fix
Wouldn’t it be nice if they could just fix it at the code level and be done with it? Well, this one they can (fairly simple escaping of characters). But we all know is reality, most code changes require scrums, waterfalls, validations, testing, and a flood of tears.
In our case, we already have the Virtual server for this website on the LTM/ASM (Virtual Edition 11.1). It’s a few steps to get the ASM in place to defend:
|
1. Create the HTTP Class for the Virtual Server: A. Local Traffic –> Virtual Servers –> Profiles –>Protocol –> HTTP Class –>Create B. Give it a name and select Enabled for the “Application Security” |  |
|
2. Go to Application Security –>Security Policies. Select “Configure Security Policy” |  |
| 3. For our case, we are going to “Create a Policy Manually” 4. Set the Policy Language. Here we are using UTF-8. |  |
| 5. Select the Signature Lists you want to use. For our site, we are going to run with the defaults and for the sake of the demonstration, I turned off staging. This way, we get immediate blocks (yay satisfaction!) |  |
| 6. Now we configure the Wildcard Tightening. It will put a wildcard in place so that we can have a chance to learn parameters as they are used. Hit next and finished. |  |
| 7. Now, we apply that HTTP Class to the virtual server. This hooks it into the asm. A. Local Traffic –> Virtual Servers –> Your VS – >Resources –>HTTPClass Profiles B. Add your profile and update |  |
| 8. Now we are passing traffic through the ASM, I hit the page and log in. In the ASM Learning section, I now see the parameters for username and password. A. Application Security –>Policy Building –>Manual –> Traffic Learning. Click on Parameters and we see them. B. For now, I hit accept all. |  |
| 9. Now the parameters are in the policy, the policy is listening transparently. I want to take the out of staging, so I get immediate blocks. I go to Policy –> Parameters –> Parameter List and select each parameter I want to remove from staging. Here, I do password and username. |  |
| 10. Now, I want to put the policy in blocking mode, to see this bad boy in action. A. Click Policy B Set Enforcement Mode to Blocking C. Profit? Or hit Save, then apply policy in the top right |  |
Now:
Pre-Injection:  | Post Injection:  |
Why the Block?
Now the coolest part, we, as the admins, can see why the block happened.
 |
We go to Application Security –> Reporting –>Requests. Put the Support ID into the filter. It returns the full request, why it was blocked, and the options to learn it as a false positive. |
Pretty cool huh? This is only the tip of the iceberg for what fun we can have with the ASM.
Part of the F5/Owasp Top Ten Series
