base under attack
ethical hacking, penetration testing, IT security and other news

The built-in Rails logging system contains a significant amount of information about the running application - such as record of all requests, parameters sent, and queries performed. By default, the production log contains full requests and the value of every parameter, with no discretion.

An attacker who obtains the Rails production log could stumble upon an absolute gold mine of sensitive information. The log could contain passwords to thousands of accounts, credit cart numbers, and personally identifiable information such as social security numbers or contact information. What’s worse is that there is rarely adequate protection on log files, as they are frequently overlooked by administrators and developers. Besides the obvious security hazards of leaving this sensitive information lying around - it is also mandatory to protect it if you are required to comply with standards such as the PCI DSS.

Although the log files should be protected, it’s better to not log sensitive data at all, if it is not entirely necessary. Fortunately, Rails provides a simple one-liner to filter out sensitive parameters from the logs. Place the following line in your ApplicationController, listing each sensitive parameter.

filter_parameter_logging :password, :password_confirmation, :credit_card, :ssn

This will replace the values of the specified parameters with “[FILTERED]” before they are logged to the production log. However, it will not filter out sensitive parameters that have already been logged! If you have been running your app in production before applying this fix, you will need to take additional steps to filter out the existing logs.

Filtering existing log files

The method above will not filter existing log entries. If you already have sensitive data in your production log, you will need to filter it out. Below is a simple ruby script to filter your existing production log.

# List of parameters to filter out of the log file. Should include
# passwords and personal data such as social security #, credit cards,
# etc.
filter_words = %w{ password password_confirmation address_1 address_2 }

# Read old log file into an array
dirty = *open(”production.log”, “r”)

File.open(”clean.log”, “w”) do |clean|
dirty.each do |line|
# Filter out each parameter specified in filter_words[]
filter_words.each { |word| line.sub!(/\”#{word}\”=>\”.*?\”/, “\”#{word}\”=>\”[FILTERED]\”")) }
end
end

A common cross site request forgery protection method is requiring a unique token to be submitted with each request. Rails uses a token that is submitted only with POST requests, and that token stays the same throughout the entire session, regardless of what form is being submitted. This is an effective way to mitigate most CSRF attacks because an attack launched from another site cannot feasibly know the unique token for that session.

However, if a XSS vulnerability exists on the same site, it becomes trivial to circumvent this protection. Why? Because if you can put javascript on the page, you can grab the token right off the page and submit it with your forged request automatically.

Of course, this attack vector requires the XSS to run on the same site as the CSRF. Ok, maybe it’s not cross site anymore, but it’s still request forgery. Imagine a blog application having a XSS vulnerability in the comment feature. An unprivileged user could submit malicious code, and when an administrator views that comment, it would make the forged request using the token off that same page. Remember, when Rails’ protect from forgery is enabled, it uses the same token for all forms in that session, so you could grab the token off of one page and use it to forge a request to another.

Is this a flaw in Rails CSRF protection? I don’t think so. As in many other attacks - XSS serves as the enabler. Combining XSS with CSRF is not only a way to automate the process (sometimes to the extent of creating a worm), but it also allows you to bypass some protection methods.

Null byte has posted a very simple web application “firewall” using only .htaccess mod_rewrite rules. It can effectively mitigate some basic web application attacks by filtering requests by patterns in the query string, such as XSS and command injection, as well as some of the more dangerous HTTP verbs. While it is definitely no substitute for secure coding practices, and will not protect against more advanced (or unknown) attacks, it may help protect against the typical “low hanging fruit’ vulnerabilities.

As these rules run at the web server level, they’re completely language and application agnostic. Thus, these simple rules can protect from a variety of exploits on a variety of web applications now and in the future.

It also filters requests based on user agent, such as scripting languages, fuzzers, and common scanners. Although this is an effective way to cut down on malicious traffic generated by automated scanners, bots, and less skilled attackers - it is important to remember that it can easily be circumvented. User agent headers are trivial to spoof - most scripts and tools can be modified to make the request appear to come from a Mozilla-compatible browser.

One note on filtering by HTTP verb - if you are using an application with a REST interface, you will probably want to allow the “DELETE” method, as this is used in REST API calls. It is not typically used when accessing a REST application over the web, as most browsers do not natively support the “PUT” or “DELETE” verbs through HTML. Frameworks such as Ruby on Rails overcome this limitation by using a “POST” request with a hidden field containing the actual HTTP verb.

The full article and .htaccess file are here.

Introduction to CSRF

Cross-site request forgery, or CSRF, is a common attack vector for web-based applications. In a nutshell, it allows the attacker to execute [destructive] actions in an application (through a HTTP request) on your behalf. It makes the assumption that you are already authenticated and have a valid session, and then makes the request either transparently or by tricking you into making the request yourself (such as through a misleading link).

The attack could be carried out in the following way:

1. You authenticate to the web application by logging in, and initiate a session that is stored in a cookie or otherwise persisted somehow.

2. You visit a malicious website or read a malicious email, while your session is still active.

3. The malicious site initiates a request to the web application where you are still logged in, through a method such as:

a. An image tag that makes a request - <img src=”http://example.com/app/user/delete/1″>

b. An iframe

c. A direct link

The impact of this attack is that the attack can execute destructive or otherwise malicious actions in the web application using your existing session. Examples include deleting a record from the database, updating or manipulating other data, or otherwise making unauthorized changes to the state of the application.

Ruby on Rails CSRF Protection

As of version 2, Ruby on Rails ships with a system for preventing CSRF attacks. It uses an implementation of form based authentication tokens - which are submitted as a hidden field along with POST requests. This effectively prevents the attacker from making a cross site request, as the attacker does not know the unique token which is to be submitted with each form.

CSRF protection can be activated by placing the following line in your controller (prefererably application.rb - so all controllers will inherit it)

protect_from_forgery :secret => ‘choose your own secret here’

Once this line is in place, the Rails form helpers will automatically insert the authenticity tokens in your forms. In the event that an unauthorized request in made (i.e., the token is incorrect), Rails will throw a ActionController::InvalidAuthenticityToken exception.

Application Design Considerations

It is important to understand that this CSRF protection only works with POST requests, not GET requests. If you are using a REST-style implementation in your Rails app, this will protect PUT and DELETE requests as well, since Rails just “fakes” these requests by using a POST along with a hidden field.

In order to effectively protect your application from CSRF, it is important to use only POST, PUT, or DELETE requests for destructive actions, or any other actions that change the state of the application. GET requests should only be used for “safe” and non-destructive actions, such as a “show” or “index” method.

I have blogged about Maltego before (when it was called Evolution). It’s an amazing tool for reconnaissance, and the amount of information you can collect and display just from the web is amazing. It was so good, I had feared that like many great free and open source tools, the project would die unexpectedly and no longer be maintained.

Well, that’s definitely not the case with Maltego. I had the privilege of attending the talk at this year’s Black Hat Europe in Amsterdam, and Paterva gave an excellent presentation on using Maltego. It is still very active and is evolving (no pun intended) nicely.

To learn more about, check out the Maltego site. I’d also recommend viewing their presentation from Black Hat, which they have kindly posted on their site.

A group of Russian hackers has broken Yahoo’s Captcha (a computer program can read it). It has about 35% accuracy, which is somewhat low, but enough when considering that the program could be run hundreds of thousands of times per day.

Although many Captchas have been broken before using computer vision techniques, this is, to my knowledge, the only project that actually released the code.

In case you’ve never heard the term Captcha - it’s the obfuscated numbers and letters you are required to identify when filling in many web forms. It helps distinguish between a human and computer. Captcha has been commonly used in web forms for years. Although the average person has no idea what they’re for - there are many benefits to them. They help cut back on spam, brute force attacks, denial of service attacks, and some forms of phishing - all by preventing bots from automatically submitting forms.

Insecure.org has announced the release of Nmap 4.50. There have been a significant amount of changes since 4.00 (and even 4.20). Among these include a new scripting engine, 2nd generation OS detection (and tons of new signatures for OS’s and service versions), and a new GUI. NmapFE has been dumped and replaced with a new python-based cross platform GUI called Zenmap.

Download information here.

Remote-exploit.org stuck to their word and released the Backtrack 3 Beta on schedule. There are a ton of new features and improvements in this version.

I will be posting a review of some of the new features once I finish testing it out. I will most likely not be covering any more automated wireless cracking tools or things like “autopwn.” There is a difference between proof of concept, and arming every 15 year old punk with a one-click tool to steal his or her neighbor’s wireless or blow up the office network. I can’t think of any legitimate use of these tools in a penetration test or security audit, especially if you are testing live networks. You would never fire up a tool that blindly selects targets and attempts to exploit.

Anyway, downloading should go pretty smoothly now with all the mirrors that have been put up (not to mention the surge of script kiddies has died down slightly)

http://remote-exploit.org/backtrack_download.html

Truecrypt is a free and open source on-the-fly disk encryption system. It supports both Windows and Linux, and offers several options for encryption. The first type is the virtual encrypted disk - a regular file that can be mounted as an actual disk, with all encryption done on-the-fly and transparently - the mounted disk functions like any other. The other option allows you to encrypt an entire disk or removable media such a a USB drive.

Several encryption modes are available - AES-256, Twofish, Serpent, and Triple DES. Additionally, you can use up to three at the same time. For the key - you can use a regular password, or an entire file of any type.

This is an amazing tool. I have been using it for several months for everything from client data on virtual encrypted disks, to encrypting my USB drives and even a 320GB external HD. It’s completely transparent and I have not noticed any degrade in disk performance.

I highly recommend this for anyone dealing with sensitive data - especially on laptops or removable media. Not only is it free, but it is more flexible than many proprietary disk encryption systems.

If you’re interested in security, you’ve probably already heard about OpenBSD. It’s a Unix-like operating system whose primary focus is security and cryptography (it’s based in Canada, so no export restrictions). Out-of-the-box, it is arguably the most secure Unix, and is commonly used for firewalls and other appliances. Of course, it’s also a fully fledged Unix with which you can do just about anything you could do with any other Unix.

Installing on VMware is surprisingly easy and straight forward even though VMware has no OpenBSD option (we use the FreeBSD option instead - close enough).

OpenBSD does not have a graphical installer. Its install is expert-mode only, but that doesn’t necessarily mean it’s difficult.

Just follow these easy steps to get up and running:

1. Download the OpenBSD 4.2 ISO image from OpenBSD.org. We will be using the i386 image.

2. Create a new virtual machine. Select Other > FreeBSD as the operating system. Use the default for the disk, and then select NAT for the networking (unless you want to give it an external interface, in which case you need more than one IP address).

3. Go to Edit Virtual Machine Settings, select CD-ROM, Use ISO Image, then select the ISO for OpenBSD 4.2

4. Start the virtual machine. After a load of blue text, you will be asked to Install, Upgrade, or take a Shell. Press I for Install and hit enter.

5. Hit enter to keep terminal type vt220

6. kbd(8) mapping corresponds to your keyboard mapping. Press L and enter for a list, then select your mapping (for example, if you’re in the US, type “us”). Hit enter.

7. Type “yes” and hit enter to proceed with install.

8. Press enter to select wd0 as the root disk.

9. Type “yes” and hit enter to use all of the disk.

10. Now the fun stuff - partitioning the hard drive. I wanted to keep this simple and didn’t really care about properly slicing up the drive as this system isn’t going to be used in production and is just a VMware virtual machine. We’ll put everything on one big slice. This assumes you made the drive 8GB when setting up the vm. Enter the following commands:

a a

<enter>

7168M

<enter>

<enter>

/

<enter>

a b

<enter>

<enter>

1024M

<enter>

<enter>

q

<enter>

11. Type “yes” and hit enter to format the drive.

12. Choose a hostname and hit enter.

13. Hit enter to configure the network. Hit enter again to select pcn0. Hit enter to keep the hostname. Hit enter for no. Type “dhcp” and hit enter - VMware has built in DHCP when you use NAT. Hit enter 7 more times to select all the defaults - it should have figured out what to use from DHCP.

14. Enter your root password, then hit enter.

15. Hit enter 3 times to select the CD to install the sets.

16. A default set of packages is selected. Use the on-screen instructions if you want to change this list. When done, hit enter to install the sets.

17. OpenBSD installs itself while you eat a cheeseburger or something.

18. Hit enter for done, then hit enter to start sshd by default, then hit enter for no NTP server.

19. Running X? Enter yes.

20. Answer defaults to the next several questions, then enter your timezone.

21. Type halt and hit enter to shutdown the system. Now, restart the virtual machine and you should be up and running with OpenBSD!

You now have a basic installation of OpenBSD in VMware. With only two exceptions in its history, the default OpenBSD install has had no known remote exploits.

To learn more about your new system, head on over to OpenBSD.org. The project has excellent documentation for getting up and running and installing additional packages.