Author Archives: Mike Beiter

User provided input, phising, and stolen SSL certificates

It is a well-known security best practice to validate user provided input before accepting it for further processing. There are a lot of resources in particular for web application developers on how to sanitize user provided input, how injection attacks like SQL injection or LDAP injection work, and what a cross-site scripting attacks is. A very good resource is the OWASP project, with their overview on data validation and their input validation cheat sheet.

Most guides around input validation focus on how to properly validate the syntax of the submitted data. While this is a very important step, it is also important to keep the underlying business logic in mind and consider how the semantics of the user provided input could compromise the underlying business logic.

Today, I came across a security hole that emerged although the application was correctly validating the syntax of the user provided data. However, the data sanitation mechanism did not take into account how that data would be used in the downstream components, and what an attacker could do with a seemingly harmless email address.

The application in question provides services to a user, and allows the user as an extra gimmick to register a customized or “vanity” email address in the form of user_chosen_part@service-name.com. The team made sure that the email address always has the correct syntax, and even used a standard validation library with a well-tested regular expression instead of crafting their own.

However, although the validation ensured that the submitted addresses are syntactically correct, the seemingly harmless input can lead to a significant security hole that can enable a major phising attack on the application.

In this application, an attacker could simply request a seemingly “trusted” email address such as hostmaster@service-name.com, and then use that email address to exploit other users on the system. As an example on how this attack could work, an attacker could request an anonymous SSL certificate from a third party (such as “comodo free SSL”) using such a “trusted” email address. In this example, the third party (comodo) would validate the ownership of the domain by sending an email to one of several “trusted” email addresses, and then grant the attacker an SSL certificate if he can prove that he has access to such a “trusted” email address.

The attacker can then use that certificate to create a spoofed website (in this case: www.service-name.com) and phish users’ data – and the users would find it very hard to even notice the attack, because the SSL certificate from comodo (“trusted by 99.9% of browsers”) would be valid and actually be made out to the original server name!

To prevent this form of attack, the service in question would have to ensure that specific, usually “trusted” email addresses such as hostmaster@service-name.com would not be available for a user to register.

In the case of comodo, the list of “trusted” email addresses available to choose from for domain ownership validation includes:

  • admin@service-name.com
  • administrator@service-name.com
  • hostmaster@service-name.com
  • postmaster@service-name.com
  • webmaster@service-name.com

It is of course a really good idea to extend this list of prohibited addresses in the application with other addresses that are commonly abused for phising, including (but not limited to):

  • support@service-name.com
  • help@service-name.com
  • sales@service-name.com
  • security@service-name.com
  • order@service-name.com
  • info@service-name.com
  • etc

In this specific example, the connection between the potentially malicious user input and usage of this input in the business logic is fairly straight forward. However, this is often not the case, which makes it really necessary to keep downstream components and their business logic in mind when doing input validation.

HP Fortify manual rule pack update

With the Fortify products, HP has acquired a great suite of security tools for security static code analysis (“Fortify SCA”). But HP’s security product line-up also includes other tools, for instance for runtime analysis (“Fortify Runtime”, which analyzes code while it is in production) or HP WebInspect for automated black box security testing.

The Fortify SCA products include tools like the “Audit Workbench” that are available to developers, but also server products that are more suitable for a continuous integration environment.

I discussed the Audit Workbench with a couple of developers today, and, during the walk through, came across the auto-update feature. Fortify regularly provides updates to the rule packs, and so makes new scan capabilities available to the users. The update is automated (the default is to check for updates every 15 days, see “Options” -> “Options” menu), but sometimes one wants to trigger the update manually.

It took us a couple of minutes to find it in the documentation, but a look in the bin directory of the installation quickly helped: one can either use rulepackupdate or fortifyupdate to trigger the manual update. While rulepackupdate still works in the current release, it is deprecated and replaced by the new fortifyupdate.

If you are connecting to the Internet through a proxy server: the settings for configuring the proxy hostname and port are in the “Options” -> “Options” menu, under “Server Configuration”.