History of an audit

On Habré there are many articles on the history of various hacks, recommendations for generating passwords and other basics of information security. I decided to make my own contribution by writing a small report on the study of one of the rather large sites close to IT, in which, against the background of good security from the basic methods of hacking, I discovered completely banal errors in the design of the system itself.

Learn more about what you need to pay attention to when designing your sites under the cut.

Investigate

The site in question is written in ASP.NET; There are no special technological innovations like AJAX, HTML5 or other bells and whistles. Normal menu, static text. The audience - schoolchildren and students of primary courses.
The functionality that forms the basis of the project is implemented separately through a virtual java machine, where we will not go.

To get started, look at the registration. In general, using a separate username and nickname is not very convenient, but in this case, users enter real personal data, so adding a username is a good idea, while enhancing security. Naturally, this only has weight if you cannot get a list of logins. In this case, we will have to go through not only passwords, but also logins. Accordingly, the number of login attempts to a non-existent login will be large enough, which may be a sign of a hacking attempt.
')
Climbing a little more on the site, I have not found open logins anywhere. They are used only for registration and authorization. An obvious, but no less funny thought comes to mind: we send some busy login via the registration form - we get an error that such a user is already registered.
Accordingly, especially if you take a sufficient base of popular names, you can filter out logins by parsing error messages. For example, here
Of course, it does not work out very well, if for every non-existent login there is a registration. Already such a significant simultaneous increase in the number of users will be too noticeable.

I tried to work around this by changing the content of the POST request sent to the registration script. It revealed a useful vulnerability: the system first checked to see if there was a login in the database, and only after that checked passwords. (it is surprising that the password and confirmation are additionally checked for coincidence also on the server).
Thus, the search is completely organized around the actual registration. As for the captcha - it is simple enough not to be a hindrance.

However, a simple brute force login would not deserve a separate article. Already after finding a sufficient number of vulnerabilities, I found another one in the chat application: the user login was in the message sending window! It is difficult to say who and why put it there. Apparently, when writing the system, the full name has not yet been entered, and then forgot about this debug output. As the proverb says: “There is nothing more permanent than temporary.”

Results analysis

We need a login database. Get it easy, you just need to parse the page.
site / icq /? id = N for each user

for ($k=0;$k<$max_thread;$k++){ thread_search(); } $cv->recv; sub thread_search{ my $url = "http://site/icq/?user=".$i; http_get $url, sub { my ($body, $hdr) = @_; if ($hdr->{Status} =~ /^2/) { if ($body =~ /<TITLE>(.*) "/){ print OUTPUT $1.",$i\n"; } } else { print OUTPUT $url." error, ".$hdr->{Status}." ".$hdr->{Reason}."\n"; } $i++; if ($i>$MAX){ $cv->send; } else{ thread_search(); } }; } 

Written fulfilled quickly enough. As a result, I received a base, which I then sorted and divided into groups, and also built a beautiful diagram.


But examples of logins.

Directly action

Since no password policy is provided for in the system, and you can enter at least one character, an ordinary brute force should be a success.
In this case, we will distribute passwords by threads. Each thread will go through one password for all logins. This is optimal because Passwords on such resources are usually quite simple.

 #!/usr/bin/perl use LWP::UserAgent; require HTTP::Request; my $pass = $ARGV[0]; open(OUTPUT,'+>out'.$pass.'.txt'); open(INPUT,'<lof.txt'); while (<INPUT>) { my $l = $_; chop $l; my $ua = new LWP::UserAgent; $ua->agent("Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1"); $form = "lgn=$l&password=$pass"; my $request = HTTP::Request->new(POST => 'http://site/'); $request->content($form); $request->content_type('application/x-www-form-urlencoded'); my $response = $ua->request($request); my $co = $response->header("Set-Cookie"); print $co."\n"; } 

Well, some results of brute force. I did not go through all the users because there was no particular interest. However, even on a small focus group there were a lot of users with digital passwords, qweqwe, qwerty passwords and other similar passwords.
By the way, the qwerty password has only 0.1%, while various variations of digital passwords from 1 to 4 characters total more than 20%.

findings

The list of the most critical resource failures, in my opinion, includes:

* Inattention (logins were available on the site in open form)
* Invalid data validation sequence
* Weak captcha
* Uncontrolled number of authorization attempts from any IP
* Weak password policy (users should be prohibited from entering numeric passwords)

Related Links

UserAgent
AnyEvent
HTTP Request
threads

Thanks for editing the klok article