Category Archives: Pentesting

Username Enumeration Timing Attack

This is kinda cool. One way of enumerating usernames is to try a username against a login screen and have the error message tell you “That username doesn’t exist.” Or try to create a new account and have the system tell you “That username already exists.” But if a site is coded properly, it won’t give you that kind of info, making username enumeration (ie. figuring out valid and existing usernames) harder. So how about figuring them out with a timing attack?

When a username and password are submitted to a site for checking, they’re sent to a database and the dbms needs to find the username, and when it finds the row with the username, it checks the password hash against what exists in the database. However if the username doesn’t exist, the dbms doesn’t need to bother checking the password hash. It can just return the generic fail message. This small difference can be seen in the response time. In a recent test, I created a list of 50 usernames and 5 were known good. I interspersed the valid usernames in with all the invalid ones. I used the same password for every attempt, and ran them through Burp Intruder. The result was that the five good returned the slowest response times. There was one invalid password mixed in, but out of the six slowest responses, my five valid usernames were right there. Knowing this, I could do some open source searches for potential usernames and test them against a login screen. I did also test usernames of varying length and it didn’t change the results. Just in case of having a list with mostly valid usernames, I could also pad it with likely garbage usernames, things like “aaaaaaaaa” or “nekdhspfacshabdfks”. This one will be fun to try again in future assessments.

119 total views, no views today

Web App Test

In my first test, I worked with my manager. It was a web test and one that was pretty solid. However one fun thing was something I saw in a presentation at BSides Baltimore last week. A bad password policy may be a low finding. A lack of bad auth attempt lockout feature may be a low finding. A username enumeration may be a low finding. However, if a site has all three? That is a critical finding. If you can enumerate a list of valid usernames (just check LinkedIn for names and figure out the username format) and then throw the top 1000 passwords against a list of usernames, you’ll get in.

Some other stuff too, but also wrote the report and sent it in. Looking forward to the next one!

101 total views, no views today

New Pentester

I got a job as a penetration tester, which I think is really exciting. It is a job that I get excited about. One that causes frustration and a feeling of accomplishment. I’ll officially start on April 11th. My plan is to track my progress here, and document things that I learn, in general.

I contacted some other friends who are pentesters and asked for their advice, ideas on things they wish they knew when they got started. I was given two great pieces of advice on things to read or study up on. One was to read the publications on GitHub from Cure53. Today I read their whitepaper on X-Frame-Options and various ways to still bypass the clickjacking protection it provides. I’m looking forward to reading the others, once I finish the other recommendation…The Tangled Web! Continue reading

132 total views, no views today

Drupal

Pentesting Drupal

One thing that Drupal started doing well is masking the version of the core code. Early on, you could simply view the source of each page and right in a meta tag was the Drupal core version. Well, that makes it a little too easy for the bad guys (and pentesters) to get the known vulnerabilities for the site. It takes a little more digging. But when the site had it, it looked a little like:

<meta name=”Generator” content=”Drupal 7 (http://drupal.org)” />

I’m working on one that does not have the version in the meta tag, however the site has not merged, or consolidated the modules’ css files. That means right in the source, it lists all the modules that the site is using. It looks a little like:

<link type=”text/css” rel=”stylesheet” media=”all” href=”/sites/all/modules/cck/theme/content-module.css?Q” />
<link type=”text/css” rel=”stylesheet” media=”all” href=”/sites/all/modules/ckeditor/ckeditor.css?Q” />
<link type=”text/css” rel=”stylesheet” media=”all” href=”/sites/all/modules/ctools/css/ctools.css?Q” />

My thought on that was that the css probably changed a little when the Drupal core code changed and the module needed to be updated. So I downloaded the Drupal 6 and Drupal 7 versions of one of those css files for a module and did a comparison to what is on the site. What I found for one was that the site and Drupal 6 had the following line in the css file:

/** For IE we add the class via js; for other browsers we rely on :hover **/

The Drupal 7 version of this module’s css file does not have that line in it. So maybe the site is running Drupal 6, or maybe it’s just running an outdated version of that plugin. Not that that’s a bad thing either. But if you look a little further, we also see that each of those modules has its own README. Checking those and versions also gives a better idea of the versions.

Still, nothing rock solid, short of checking for SA-CORE-2014-005, which I will be doing too.

184 total views, no views today