Bicycle syndrome
In the last article I suggested that my reader knows how SQL works in detail, as well as the mechanism of the HTTP protocol . But usually it’s not the case. And I immediately remembered the story described in one of my favorite books «Suspicious minds: Why we believe conspiracy theories» by Rob Brotherton. It describes the following experiment – psychologist Rebecca Lawson asked the group of test subjects if they ride a bicycle in their lives at least once? The majority replied positively. Then she asked if they knew how the bicycle works. There were little less positive answers, but still the vast majority. And then she proposed the following image and asked to finish the picture so it would be possible to ride this bicycle.
And then the most amazing thing happened – more than half of people could not do it. This deceptively simple task shows that most people have no idea how the bicycle works. But the most interesting thing is that they do not understand that they do not know it, and begin to understand it only at the moment when they have to demonstrate this knowledge.
It’s pretty much the same thing with HTTP and SQL. More than 90% IT specialists wrote SQL requests at least once in the lab or university. People work with HTTP every day as regular users, and as IT professionals they occasionally configure web servers that actually works with HTTP. But when one has to answer a specific question … well, you’ve got the idea.
The information security analyst should know the technology in detail with all the nuances and subtleties. If we don’t know how a particular technology should work, then how can we figure out what’s wrong with it? =)
Injections (sort of)
I mentioned that the data validation should occur on the server, but not on the client. You can occasionally see input forms where individual elements are inactive. And it is assumed that they will become active after certain conditions have been met. Or, for example, the user name input field is 7 characters long, thus limiting the maximum length of the user name. All this is a very bad practice and this is why: elements on the page that are already received by the browser can be edited before being sent back to the server without any special technical means. In OWASP Mutillidae II take a look at «Other» > «Client-side» security «controls».
Here is the form in which you have to enter a random number, this time it is 2056694312. The «difficulty» here is that the fields have limitations. There is a «Read-Only» field, where the number 42 cannot be replaced, there is a too short field called «Short Text Box», where our number simply won’t fit, there is a disabled field «Disabled Text Box» which is inactive, and so on.
In fact, the task is solved very simply. In the browser (in my case it is Mozilla Firefox), you must go to the developer console (F12) and begin to inspect the elements of the form.
For example, a read-only field looks like this:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Remove readonly=“readonly” and voila, the form is writable, and we can enter our number. In the next field our value is simply won’t fit, look at this element:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Here we will notice maxlength= “3″. Replace 3 with 333 and now we can enter our number without any problem.
And it’s not only about input fields. Similarly, you can change any of the elements, such as checkboxes. Take a look at this:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
It is quite simple, replace the value with our number, and now it will be sent when the user clicks the button.
In general, if you know how html works you will not have any problem to fix this form and enter all the necessary data. Just read the section about bicycle syndrome again =)
Not only SSQL
Injections are not only about databases. By and large, injection can be made to any form that does not filter the incoming data. In the example «Application Log Injection» > «Dns Lookup» there is a convenient form for DNS requests:
And indeed, if you enter an address there, for example, google.com, you’ll get all the necessary information:
However, the vulnerability here is that beside the first valid command, we can introduce something else. For example, type:
google.com && dir
And now the output of the command is much more interesting:
We have executed a request for a dns server, but other than that, we’ve executed the «dir» command and got the directory structure on the server. It is not difficult at all, combining different commands, browse through the hard disk of the server and look for something really interesting.
Next time we’ll look at another examples and see how you can automate your work.
Simon Says «0» 