New XSS Facebook Worm Allows Automatic Wall Posts

Currently a new and unpatched cross-site scripting (XSS) vulnerability in Facebook is being widely used to automatically post messages to other user’s walls. The vulnerability was used for some time in some smaller cases; however, it is now widel…

Currently a new and unpatched cross-site scripting (XSS) vulnerability in Facebook is being widely used to automatically post messages to other user’s walls. The vulnerability was used for some time in some smaller cases; however, it is now widely being used for the first time by many different groups—especially in Indonesia, where we are seeing thousands of infected messages being posted by unknowing users.

The vulnerability exists in the mobile API version of Facebook due to insufficient JavaScript filtering. It allows any website to include, for example, a maliciously prepared iframe element that contains JavaScript or use the http-equiv attribute’s “refresh” value to redirect the browser to the prepared URL containing the JavaScript. Any user who is logged into Facebook and visits a site that contains such an element will automatically post an arbitrary message to his or her wall. There is no other user interaction required, and there are no tricks involved, like clickjacking. Just visiting an infected website is enough to post a message that the attacker has chosen. Therefore it should be of no surprise that some of those messages are spreading very fast through Facebook. Some are posting links to infected websites, creating XSS worms that spread from user to user.

Unfortunately since the attack is very easy to recreate we have already started seeing a few dozen copy cats starting new attack waves with different messages.

We informed Facebook’s security team and they are working on a fix for this issue.

This attack works if you have enabled the SSL option in Facebook or not. Therefore it might be a good idea to currently log out of Facebook while you are not using it, or use security tools to protect or block you from going to infected sites. For example, the NoScript extension for the Firefox browser is able to detect this XSS worm attack.

UPDATE (March 29, 2011): Facebook has informed us that they have patched this XSS vulnerability. In addition, they are currently working on steps to remediate damage caused by the attack.

Securing osCommerce 2.2 and 2.3

osCommerce continues to be one of the most exploited pieces of web software. Back in October we wrote about the need to secure osCommerce to prevent these exploitations. Since then we have seen a lot of bad information on securing … Continue reading

osCommerce continues to be one of the most exploited pieces of web software. Back in October we wrote about the need to secure osCommerce to prevent these exploitations. Since then we have seen a lot of bad information on securing osCommerce against these exploitations as well as questions on securing osCommerce 2.3, which was released in November, so we have put together additional information on securing osCommerce 2.2 and 2.3.

osCommerce 2.2

There are several vulnerabilities in osCommerce 2.2 that are being exploited. The simplest and most effective method to protect against the exploitation of these vulnerabilities is to rename and password protect the admin directory. Doing this is also recommended by osCommerce.

Renaming the admin directory requires changing the name of the directory and changing the DIR_WS_ADMIN and DIR_FS_ADMIN lines in the /includes/configure.php file located in admin directory with the new admin directory name in place of admin.

The easiest way to turn enable password protection is using the HTACCESS from osC admin menu add-on (this is add-on has also been integrated into osCommerce 2.3) following these steps:

  1. Install the add-on, make sure to install the files located in the admin folder in the add-on to the renamed admin directory.
  2. Login into the admin area.
  3. In the left hand menu, click on Administrators link in the Configuration section.
  4. Click edit.
  5. Enter your current password in the New Password field and select Protect With htaccess/htpasswd.

You can find information on extra security measures you can take in the osCommerce forum thread How to secure your osCommerce 2.2 site.

For existing osCommerce 2.2 based websites that do not already have these protections in placed it is likely that the website has already been hacked. Many of these hacks only involve placing a backdoor script, which allows the hacker to run commands from and access files on the website. With the backdoor script in place they can come back later and use the website for malicious purposes. Other hacks involve using the website for spam, malware, or other malicious purposes.

The best way to insure that any code added by hacker has been removed is to revert to a clean backup of the website. Because osCommerce have been being hacked for so long it is unlikely that a backup that was made of the website from the last year or two would be clean at this point. If you have a copy of the website that was never placed on the website you could use that, you would need to add any new files you created since then, such as images.

Another method to clean the website is to remove the malicious code and files that the hackers have added. Malicious code is often added to the index.php and /includes/header.php. Backdoor scripts can be placed throughout the website; our Basic Backdoor Script Finder will find some of the most popular ones. You can also look for any .php files in the images folder and for files that begin goog1e located in the root directory of the osCommerce installation as the will be backdoor scripts.

osCommerce 2.3

osCommerce 2.3 included fixes for the vulnerabilities in osCommerce 2.2  and at this point there are no known vulnerabilities in 2.3.1 (there was an incorrect advisory that claimed there was one), so it would be safe to run the software without additional protection, but it is still recommend rename and password the admin directory.

It is possible to rename the admin directory during the installation of osCommerce 2.3. If the admin directory was not renamed during the installation it can be done by changing the name of the directory and updating the DIR_WS_ADMIN and DIR_FS_ADMIN lines in the /includes/configure.php file located in admin directory with the new admin directory name in place of admin.

Password protection is integrated into osCommerce 2.3, it can be turned on following these steps:

  1. Login into the admin area.
  2. In the left hand menu, click on the Administrators link in the Configuration section.
  3. Click edit.
  4. Enter your current password in the New Password field and select Protect With htaccess/htpasswd.

You can find information on extra security measures you can take in the osCommerce forum thread How to secure your osCommerce 2.2 site (most of the information applies to 2.3 as well as 2.2).

osCommerce 2.3 also includes a number of security enhancements. The Portable PHP hashing framework has been added to more securely hash passwords, this software is also used in WordPress. A customer session token has been added “to forms to protect against Cross-Site Request Forgeries (CSRF)”. A new section of the admin, Security Directory Permissions, displays the current write permission of the various osCommerce directories and what the recommend permissions are. A built-in version checker allows for checking if a new version of osCommerce has been released.

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….

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…

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://groupinc-upland.biz/registration/1
hxxp://artby-group.biz/registration/1
hxxp://artby-gorup.net/registration/1
hxxp://callisto-ltdco.net/registration/1
hxxp://kresko-group.biz/registration/1
hxxp://kresko-group.net/registration/1
hxxp://targetmarket-groupllc.net /registration/1
hxxp://neoline-llc.net/registration/1
hxxp://neoline-groupco.cc/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.

http://www.theregister.co.uk/2010/09/30/zeus_money_mules_charged/

http://www.wired.com/beyond_the_beyond/2010/10/the-zeus-money-mules-the-federal-complaints/

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.

http://us.norton.com/security_response/writeup.jsp?docid=2011-032307-1016-99&tabid=2