Just the other day one of my coworkers (@Meowris) made an interesting discovery that I thought was worth mentioning.

Here’s the story: On our team we have several email accounts set up that are strictly for internal communication. A coworker of ours (we’ll call him Bob) forwarded part of our team an email regarding a service he found interesting, and thought we might like to investigate. The email Bob forwarded us was a simple newsletter containing nothing of value – or so he thought.

@Meowris was interested in learning more, so he clicked the gray button to learn more. Upon being redirected to the company website, he noticed something interesting – it was asking him to reset his password. Furthermore, he discovered that he was actually logged in on Bob’s account. After bypassing the “Reset your password” prompt, we discovered we could entirely take over his profile.

Upon first glance, this email seems entirely harmless, and certainly worthy of a forward to interested parties. However, let’s take a look at the link for the gray button:

There are three GET parameters that are being defined within the url: $_GET[‘u’], $_GET[‘id’], and $_GET[‘e’]. Changing any of the variables in the slightest results in a page response stating “No URL found for this tracker ID.” Playing around a little more, I noticed that successful requests resulted in a HTTP 302 response code, which means one thing: enumeration.

Using a tool such as Burp Suite, it may be entirely possible to enumerate valid user accounts.

Regardless of the service, it is extremely bad practice to initialize sessions in such a manner. Without having an active session, anyone clicking on that link should be either A) requested to login if the content is private, or B) displayed the content without actively loading the user account.

In this case, Bob didn’t even know that @Meowris and I were able to access his account. In fact, if we so desired, we could have also reset his password too, because they don’t handle password resets properly, either.

Read @Meowris‘s story, here.

I was recently testing a fresh WordPress install, and I realized that there is a flaw in the authentication system, which allows for enumeration of active usernames.

If you enter an invalid username when attempting to login, you will see the following message:

If you enter an invalid password for a valid user account you will see this message:

It is typical practice to provide a more generalized message for invalid authentication systems. A message such as We’re sorry, it looks like your username or password is invalid. Please try again. will alert the user of the incorrect authentication attempt. With this message it’s impossible to identify whether the error was with the username, or with the password.

For an end-user who is unsure whether it is their username or password that is invalid, wordpress makes it easy to identify, providing for a better user experience. Unfortunately, that comes with a cost. Attackers are able to leverage this WordPress “feature” to determine a list of valid user accounts.

What’s the big concern? What can someone do just by knowing a username? Having access to a list of valid usernames for a website is good place to start for any attacker. With this knowledge the attacker can attempt to determine valid passwords for a specific username through phishing or brute-force attacks.

Most systems have preventative measures to protect against online brute-force attacks, such as Captchas or account lockouts. Unfortunately though, WordPress doesn’t include either of these by default. Therefore, on a poorly configured server, it is possible to launch a brute force attack against a specific username on a live wordpress website.

This is a common case of sacrificing security for user experience.

I have developed some Proof of Concept wXf modules that will facilitate this process. These modules are available in our repository, or can be downloaded from this commit.

As I mentioned recently on twitter, there are some big changes coming to the wXf core. These changes will accomplish two things: 1) Dramatically Increase performance when handling bulk HTTP requests and 2) Provide more functionality for HTTP requests.

• Patch our code base to support JRuby-1.7.0. Upgrading to JRuby-1.7.0 will allow us to continue using some of our gems(such as Mechanize), and add newer gems that don’t have support for JRuby-1.5.6. Maybe it’s about time we get our GUI working, too
• Remove Mechanize from our repo. There’s really no need for us to continue hosting our own private copy of Mechanize. The original reason we decided to host our own copy was to ensure that our users were always running the same version of Mechanize to prevent conflicts. We’re decided that it makes more sense to use gemsets to handle this.
• Upgrade to Mechanize 2.5.1. With the use of gemsets it will be easy to upgrade to 2.5.1. 2.5.1 has tons of features that will prove beneficial to module development.
• Implement Celluloud. Celluloid is a Ruby gem that provides a simple way to develop fault-tolerant, concurrent Ruby apps. In wXf, Celluloid will be used to wrap around HTTP requests providing concurrency. As a brief example: sending 1000 HTTP requests with the current wXf HTTP libraries will take on the order of several minutes. By wrapping these requests into Celluloid we’re able to perform the same requests on the order of seconds.

So stayed tuned! Hopefully within the next few weeks we’ll be looking at v2.0

In an effort to install Dradis, I have been running into several issues installing Ruby 1.9.3, as required. The official Dradis Mac OS X install guide suggests running the following command to install Ruby 1.9.3 through RVM.

rvm install 1.9.3

However, with this command I have been receiving configuration errors that have not been allowing me to move forward.

johnpoulin$ rvm install 1.9.3

There has been an error while running configure. Halting the installation.

After Manual inspection of the failed configuration, it seemed that the culprit was a missing C compiler.

./configure –prefix=/Users/johnpoulin/.rvm/rubies/ruby-1.9.3-p125 –enable-shared –disable-install-doc –with-libyaml –with-opt-dir=/Users/johnpoulin/.rvm/usr

configure: WARNING: unrecognized options: --with-libyaml

-bash: gcc: command not found

Imagine my surprise, when I noticed that my Macbook of two years didn't have a C compiler. How has this never caused an issue before?

After doing a little research, it looks like a recent uninstall of Xcode may have removed GCC.  To fix this problem I simply reinstalled the most recent version of Xcode (in this case 4.3.2), with hopes that GCC would be magically installed... No luck.

 The solution required me to install the Command Line Tools component available through the Xcode download preference panel.

One of the largest issue’s I have had with wXf development is testing quick fixes to modules I have written. For example, I’ve been debugging a module and each time I go to run the module I close and re-execute wXf. This becomes annoying quick.

In an attempt to design a solution to this problem, I realized the solution already exists. The reload command does exactly what I was looking for.

– Just a quick note

An interesting discovery was announced at 28C3 this year that impacts a large number of web-servers across the world. This DoS vulnerability is caused by a poor implementation of Hash Tables across server-side programming languages such as PHP, Java and ASP. For more details watch the presentation here.

That being said, I wrote a wXf module that leverages this vulnerability, and it’s available in the repository, or via download here.

Before executing the module, you will need to set the count option. I recommend setting this to a value of 100 or higher. When running the module you’ll notice it takes several minutes to generate the payload, and after this is complete it will start sending requests.

If the server is configured with a post_max_size >= 4MB this module should spike the servers CPU usage to 99-100%. Give it a try!

Over the past couple of weeks I have been working on a module to provide recursive site enumeration for the Web Exploitation Framework. The goal of this plugin was to provide an auxiliary module that allows a tester to recursively build a sitemap for a given website.

The idea behind this module was that websites often contain links to pages that should normally be kept hidden, such as administrative login pages. This module allows a tester to sit down, and analyze linked pages on a given website. The tester can also specify how many times we would like to recurse through pages.

In the future I will be adding email parsing capabilities and also robots.txt parsing. These features will allow a tester to recover some additional information, such as possible usernames, private directories protected by the robots.txt file, etc.

Anyway, take a look at the module.