Fraudulent Comodo Digital Certificates Affect Multiple Services

Earlier today news was made public regarding nine fraudulent digital certificates which were issued by a company named Comodo. The certificates were issued through a breached registration authority (RA), causing the applicant to be improperly verified. Mozilla, Google, and Microsoft (major browser vendors) have updated their applications, or put out patches, in order to block the certificates from being used. The certificates have already been revoked as of last week.

To provide a little background, browsers include a list of certificates which are 'blacklisted'. These certificates are ones which have been compromised through some method and no longer validate the authenticity of the person using it. Since they were reported as 'compromised', the browser vendors ship a patch, or updated version of the browser itself, which recognizes these certificates and blocks them from being used.

Users who don't use updated browsers or patched machines may be lead to malicious Web sites which are able to prove their fake identity. For example, someone with a stolen certificate for 'Company X' will be able to host a site wherever he wanted to telling people that he was indeed 'Company X'.

Why does it matter?

If we look at the list of certificates which are involved in this incident, we see a lot of legitimate and popular services being targeted, including but not limited to Google, Google Mail, Yahoo!, Microsoft Hotmail/Live Mail, and Mozilla add-ons.

The first theory which comes to mind is that the person behind the compromise wanted to somehow get credentials, and subsequent access, to mail and other communication accounts. According to this report from Comodo, the attack originated in Iran. The same article goes on to speculate that the perpetrators of this attack may have been state sponsored. While we don't have any information which could either support or dismiss this information, the incident reminds us of the issue which took place earlier this year in Tunisia where, allegedly, some entity was stealing its users' credentials. The Mozilla add-ons could have been targeted here to prevent usage of add-ons which circumvent censorship filters at the country's network perimeter. Anyway, I digress.

For end users, the key here is to somehow get alerted if they visit a Web site which isn't who it claims to be, using these stolen certificates. There are two ways by which certificates are revoked - Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).

If this incident is indeed state sponsored, then the revocation process has a few gaps to overcome. For CRL and OCSP to work effectively, there is a dependency on the network itself. OCSP requires a query to be sent to an authority, to check on the status of a certificate being used on a Web site. A similar process goes for the CRL method. A CRL is most effective when a computer has checked for the latest published CRL. Both techniques rely on the machine having accessibility to the revoking authority. If a state, any state, is behind such an attack, they can easily make changes to the network such that access to the revocation lists are blocked. Once that is done, the users wouldn't know that they are dealing with a impersonated Web site. Users affected by such a state-sponsored attack wouldn't even know about it.

Thus, to help mitigate scenarios where a system may not be able to reach revocation lists when presented with a fraudulent certificate, Mozilla, Google, and Microsoft have shipped updates that will locally recognize the fraudulent certificates without needing to query the CRL or OCSP.

At this point, we urge all users to update their browsers to the latest version, and make certain that they have this patch installed on Windows machines. The issue affects all operating systems and all browsers.

Mule-ing Over that Job Application?

Recently at Symantec Security Response, we came across a seemingly innocuous program which was being hosted at a number of different URLs. What flagged the file as unusual was the fact many different customers were submitting the same file for analysis.

The basic behaviour of the program is to run you through a job suitability questionnaire before redirecting you to one of the following URLs:

hxxp:// /registration/1

You cannot simply browse to these pages without first downloading and completing the suitability test.

This program generates a unique URL, giving you access to the registration page.

What is unnerving about this application is the level of detailed information they are requesting.

They even ask you for you online bank account details including the URL, your login, and your password for an extra $100.

As a final step, an email is sent to the supplied address whereby you are asked to sign an agreement and upload a scanned copy of your ID or a utility bill.

The contract states the purpose of the job:

“The Contractor undertakes the responsibility to receive payments from the Clients of the Company to his personal bank account, withdraw cash and to effect payments to the Company's partners by Western Union or MoneyGram money transfer system within one (1) day”

It also states the remuneration:

“The Contractor is engaged by the Company on terms of thirty-days (30) probationary period. During the probationary period the Company undertakes to pay to the Contractor the base salary amounting to 2300 USD per month plus 8% commission from each payment processing operation. After the probationary period the Company agrees to revise and raise the base salary to 3000 USD.”

And don’t forget the bonus $100 you can get from providing your online bank account details!

So called Money-Mules keep a cut of the transaction and wire the remainder of the cash to third-party accounts. This activity is illegal and many cases have already ended up in the courts.

Users should also be aware that during this scam all this important information is being sent over HTTP and not HTTPS, so their bank details are being transmitted in plaintext over the wire.

As a general rule of thumb, users shouldn't share their personal information (passwords, bank account information, etc.) with anyone or any site unless the transaction was initiated by the user themselves, intentionally. Even when visiting such pages which require personal information, make certain that the site is using encryption by looking for an 'HTTPS' in the URL, along with a lock appearing in the browser. This indicates the use of SSL.

Symantec detects these survey applications as Fakesurvey.




Understanding the Role of File Permissions in Website Security

Often in discussions of website security or hackings the issue of file permissions comes up. Unfortunately, important information needed to understand what effect permissions have is often not explained and in many cases bad information is spread. Most of the bad information relates to limiting other’s access to the files in your account on a shared server.

First let’s explain the basics of what file permissions are made of. In Unix based operating systems, which is what most web servers are running on, file permissions are composed three type of permissions: read, write, and execute. The read permissions allow reading the file, the write permissions allows modifying the file, and the execute permissions allow a file to run (because of how PHP works .php files do not need to be executed to run).

Directories also have the same types of permissions, but they are somewhat different. The read permissions allows see a listing of the files in the directory, the write permission allows creating, deleting, or renaming files in the directory, and the execute permissions allows accessing the files in the directory.

Those types of permissions are set for three different classes: the owner, group, and others. The owner is normally the user that created the file, the group is whatever groups the owner is part of, and other involves any other users on the system.

The first important thing to understand in terms of security is how the files can be accessed in the first place, because for permissions to come into play the hacker first has to be able to access the files. This requires having login access to the server, a FTP login for example, or having found some exploit in software running on the server. Just by browsing the website they could not access the files. If the hackers gains login access to your account or exploits software on your website they will have the same access that you have, so restricting others access will have stop someone from accessing your files in those cases.

We sometimes see it suggested that to protect a website that is being repeatedly hacked in a way that modifies files, that the write permissions for the files should be removed. The idea is that because the write permissions are disabled the hacker would no longer be able to modify the files. The problem is that most instances the hacker would have the ability to change the permission so that the files are writeable again. For almost as long as we have been seeing it be advised to make the files unwriteable we have been seeing hacks in which the permissions set to be writeable during the hack, so this is not effective strategy. What needs to be done is determine how the hacker is gaining access to the files and stop that.

The most important thing to understand about file permissions is that on a shared server, no matter what the file permissions are set to other users should not have access to your files. One of the developers of WordPress put it this way:

A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.

If your hosting provider does not have proper access controls in place the need to add those or your need to find a new host.

While setting permissions as low as possible is not going to do any harm, in most cases where the file permissions are blamed it would not have mattered what the permissions were set as. This is due the fact the files were being accessed in way that file permissions would not have restricted access. For example, a recent hack involved exploiting the web server instead of individual websites. Once the hacker gained access to the server they had access to all of the files on the server.

Busy Month for Apple

This month, Apple published seven security updates resolving around 250 issues. The last patch is arrived yesterday; it addressed Mac OS X 10.6.7.

Adding the CVE IDs (for Common Vulnerabilities and Exposures) listed in each patch does not give us accurate view of the number of vulnerabilities involved. Several appear in more than one patch: For example, CVE-2011-0191 and CVE-2011-0192 are listed in five patches (Apple TV 4.2, iOS 4.3, iTunes 10.2, Mac OS X v10.6.7/Security Update 2011-001, and Safari 5.0.4).

After eliminating multiple entries, we discover that the 256 March issues are linked to 123 CVE references. Taking a look at 2010, we see 468 CVE covering the whole year. And I have not forgotten the one in January 2011.

CVE-2006-7243 is the oldest vulnerability covered by the 2011 patches. All others are from 2010 and 2011. Here’s what we’ve seen in the last 15 months:

  • 1 CVE from 2003 (CVE-2003-0063)
  • 2 CVE from 2006 (1 in Q1 2011)
  • 11 CVE from 2008
  • 68 CVE from 2009
  • 428 CVE from 2010 (41 in Q1 2011)
  • 82 CVE from 2011 (all covered in 2011)

Is it possible to make a comparison between Apple and Microsoft?

During the same period (from January 2010 to March 2011), Microsoft published 123 security bulletins and patched 298 software flaws (CVE).

We can quickly compare by the level of criticality. On the Apple side for 2011, only one vulnerability has a low rating. All the others (123) were named as critical (by Vupen) or highly critical (by Secunia). On the Microsoft side one vulnerability was labeled moderate, 20 important, and eight critical.

Thus in the last 15 months Apple has corrected twice the number of flaws as Microsoft.