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.
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:
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.
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.
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
Fetching yaml-0.1.4.tar.gz to /Users/johnpoulin/.rvm/archives
Extracting yaml-0.1.4.tar.gz to /Users/johnpoulin/.rvm/src
Error running ‘tar xmzf /Users/johnpoulin/.rvm/archives/yaml-0.1.4.tar.gz -C /Users/johnpoulin/.rvm/src ‘, please read /Users/johnpoulin/.rvm/log/ruby-1.9.3-p125/yaml/extract.log
Configuring yaml in /Users/johnpoulin/.rvm/src/yaml-0.1.4.
Error running ‘ ./configure –prefix=”/Users/johnpoulin/.rvm/usr” ‘, please read /Users/johnpoulin/.rvm/log/ruby-1.9.3-p125/yaml/configure.log
Compiling yaml in /Users/johnpoulin/.rvm/src/yaml-0.1.4.
Error running ‘make ‘, please read /Users/johnpoulin/.rvm/log/ruby-1.9.3-p125/yaml/make.log
Database file /Users/johnpoulin/.rvm/config/packages does not exist.
Installing Ruby from source to: /Users/johnpoulin/.rvm/rubies/ruby-1.9.3-p125, this may take a while depending on your cpu(s)…
ruby-1.9.3-p125 – #fetching
ruby-1.9.3-p125 – #extracted to /Users/johnpoulin/.rvm/src/ruby-1.9.3-p125 (already extracted)
ruby-1.9.3-p125 – #configuring
Error running ‘ ./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 ‘, please read /Users/johnpoulin/.rvm/log/ruby-1.9.3-p125/configure.log
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: WARNING: unrecognized options: --with-libyaml checking build system type... i386-apple-darwin11.3.0 checking host system type... i386-apple-darwin11.3.0 checking target system type... i386-apple-darwin11.3.0 checking whether the C compiler works... no configure: error: in `/Users/johnpoulin/.rvm/src/ruby-1.9.3-p125': configure: error: C compiler cannot create executables See `config.log' for more details dakota-marshall-2:ruby-1.9.3-p125 johnpoulin$ gcc -bash: gcc: command not found
./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
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?
configure: WARNING: unrecognized options: --with-libyaml
checking build system type... i386-apple-darwin11.3.0
checking host system type... i386-apple-darwin11.3.0
checking target system type... i386-apple-darwin11.3.0
checking whether the C compiler works... no
configure: error: in `/Users/johnpoulin/.rvm/src/ruby-1.9.3-p125':
configure: error: C compiler cannot create executables
See `config.log' for more details
dakota-marshall-2:ruby-1.9.3-p125 johnpoulin$ gcc
-bash: gcc: command not found
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.
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.