Dotted Decimal URL Obfuscation

Spamming with dotted decimal URL (a dotted decimal URL refers to the four-byte IP address notation as a sequence of four decimal numbers separated by dots) is one of the most often seen URL-obfuscation techniques employed by spammers. Unfortunately, to the computer, an IP address is just a 32-bit binary number, and a dotted decimal is just one out of the many numeral systems for IP address expression. With this flexibility in interpretation, spammers have developed a new way to obfuscate their URLs; they start converting their dotted decimal URLs into different numeral systems.

Below are some of the IP address numeral system obfuscation techniques Symantec has observed of spammers. (All of the samples below are just different numeral representations of the IP address for Symantec.com)

An IP address converted to hexadecimal format. (Hexadecimal is a base-16 numeral system.)

An IP address converted to dotted hexadecimal format.

An IP address converted to dotted octal format. (Octal is a base-8 numeral system.)

A combination of Hexadecimal and Octal

Previously, spammers only took advantage of hexadecimal obfuscation in their attacks.

However for the past few days, the number of “hexadecimal and octal” combination-obfuscation attacks have increased drastically.   

Fortunately or unfortunately for the average email user, most Web browsers or email applications will translate these numeral encodings; furthermore, dotted decimal URLs are often associated with virus attacks. For this reason, end users should, as usual, not click on links to Web sites they are not familiar with.

Here are some best practices to try and limit the impact of spam attacks.

  • Be selective about the Web sites where you register your email address.
  • When entering personal or financial details online, ensure the Web site has SSL encryption (look for https, a padlock, or a green address bar).
  • Avoid clicking on suspicious links in email or IM messages as these may be links to spoofed Web sites. We suggest typing Web addresses directly in to the browser rather than relying upon links within your messages.
  • Always be sure that your operating system is up-to-date with the latest updates, and employ a comprehensive security suite. For details on Symantec’s offerings of protection, visit http://www.symantec.com.
  • Do not open unknown email attachments. These attachments could infect your computer.
  • Do not reply to spam. Typically the sender’s email address is forged, and replying may only result in more spam.
  • Do not fill out forms in messages that ask for personal or financial information or passwords. A reputable company is unlikely to ask for your personal details through email. When in doubt, contact the company in question through an independent, trusted mechanism, such as a verified telephone number, or a known Internet address that you type into a new browser window. Do not click or cut and paste from a link in the message.
  • Do not buy products or services from spam messages.
  • Do not open spam messages.
  • Do not forward any virus warnings that you receive through email. These are often hoaxes.

Thanks to Dylan Morss for contributed content. 

Microsoft Patch Tuesday – May 2011

Hello and welcome to this month’s blog on the Microsoft patch release. This is very light month —the vendor is releasing two bulletins covering a total of three vulnerabilities.

One of the issues is rated ‘Critical’ and it affects Windows Internet Name Service (WINS). A remote attacker may be able to exploit this issue to completely compromise a vulnerable computer. The remaining issues are rated ‘Important’ and affect PowerPoint. As always, customers are advised to follow these security best practices:

- Install vendor patches as soon as they are available.

- Run all software with the least privileges required while still maintaining functionality.

- Avoid handling files from unknown or questionable sources.

- Never visit sites of unknown or questionable integrity.

- Block external access at the network perimeter to all key systems unless specific access is required.

Microsoft’s summary of the May releases can be found here.

The following is a breakdown of the issues being addressed this month:

1. MS11-035 Vulnerability in WINS Could Allow Remote Code Execution (2524426)

CVE-2011-1248 (BID 47730) Microsoft Windows Internet Name Service (WINS) Failed Response Remote Code Execution Vulnerability (MS Rating: Critical / Symantec Rating: 7.5/10)

A remote code execution vulnerability affects Windows Internet Name Service (WINS) because it fails to sufficiently validate data structures in WINS network packets. An attacker can exploit this issue by sending a specially crafted packet to a vulnerable computer. A successful exploit will result in the execution of arbitrary attacker-supplied code in the context of the affected service. This may facilitate a complete compromise of the affected computer.

Affects: Windows Server 2003 SP2, Windows Server 2003 x64 Edition SP2, Windows Server 2003 with SP2 for Itanium-based Systems, Windows Server 2008 for 32-bit Systems, Windows Server 2008 for 32-bit Systems SP2, Windows Server 2008 for x64-based Systems, Windows Server 2008 for x64-based Systems SP2, Windows Server 2008 R2 for x64-based Systems, and Windows Server 2008 R2 for x64-based Systems SP1

2. MS11-036 Vulnerabilities in Microsoft PowerPoint Could Allow Remote Code Execution (2545814)

CVE-2011-1269 (BID 47700) Microsoft PowerPoint (CVE-2011-1269) Remote Code Execution Vulnerability (MS Rating: Important / Symantec Rating: 7.1/10)

A remote code-execution vulnerability affects PowerPoint because it does not properly handle memory during certain function calls. An attacker can exploit this issue by tricking an unsuspecting victim into opening a malicious PowerPoint file. A successful exploit will result in the execution of arbitrary attacker-supplied code in the context of the currently logged-in user.

Affects: Microsoft PowerPoint 2002 SP3, Microsoft PowerPoint 2003 SP3, Microsoft PowerPoint 2007 SP2, Microsoft Office 2004 for Mac, Microsoft Office 2008 for Mac, Open XML File Format Converter for Mac, and Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP2

CVE-2011-1270 (BID 47699) Microsoft PowerPoint (CVE-2011-1270) Remote Buffer Overflow Vulnerability (MS Rating: Important / Symantec Rating: 7.1/10)

A remote code-execution vulnerability affects PowerPoint due to a memory-handling error. An attacker can exploit this issue by tricking an unsuspecting victim into opening a malicious PowerPoint file. A successful exploit will result in the execution of arbitrary attacker-supplied code in the context of the currently logged-in user.

Affects: Microsoft PowerPoint 2002 SP3 and Microsoft PowerPoint 2003 SP3

More information on the vulnerabilities being addressed this month is available at Symantec’s free SecurityFocus portal and to our customers through the DeepSight Threat Management System.

TA11-130A: Microsoft Updates for Multiple Vulnerabilities

Original release date: May 10, 2011
Last revised: --
Source: US-CERT

Systems Affected

  • Microsoft Windows
  • Microsoft Office

Overview

There are multiple vulnerabilities in Microsoft Windows and Office. Microsoft has released updates to address these vulnerabilities.


I. Description

The Microsoft Security Bulletin Summary for May 2011 describes multiple vulnerabilities in Microsoft Windows and Office. Microsoft has released updates to address the vulnerabilities.


II. Impact

A remote, unauthenticated attacker could execute arbitrary code, cause a denial of service, or gain unauthorized access to your files or system.


III. Solution

Apply updates

Microsoft has provided updates for these vulnerabilities in the Microsoft Security Bulletin Summary for May 2011. That bulletin describes any known issues related to the updates. Administrators are encouraged to note these issues and test for any potentially adverse effects. In addition, administrators should consider using an automated update distribution system such as Windows Server Update Services (WSUS).


IV. References



Feedback can be directed to US-CERT.


Produced 2011 by US-CERT, a government organization. Terms of use


Revision History

May 10, 2011: Initial release

Facebook Applications Accidentally Leaking Access to Third Parties – Updated

Third parties, in particular advertisers, have accidentally had access to Facebook users’ accounts including profiles, photographs, chat, and also had the ability to post messages and mine personal information. Fortunately, these third-parties may not have realized their ability to access this information. We have reported this issue to Facebook, who has taken corrective action to help eliminate this issue.

Facebook applications are Web applications that are integrated onto the Facebook platform. According to Facebook, 20 million Facebook applications are installed every day.

Symantec has discovered that in certain cases, Facebook IFRAME applications inadvertently leaked access tokens to third parties like advertisers or analytic platforms. We estimate that as of April 2011, close to 100,000 applications were enabling this leakage. We estimate that over the years, hundreds of thousands of applications may have inadvertently leaked millions of access tokens to third parties.

Access tokens are like ‘spare keys’ granted by you to the Facebook application. Applications can use these tokens or keys to perform certain actions on behalf of the user or to access the user’s profile. Each token or ‘spare key’ is associated with a select set of permissions, like reading your wall, accessing your friend’s profile, posting to your wall, etc.

Figure 1. illustrates some of these permissions.

Figure 1

During the application installation process, the application requests the user to grant permissions to these actions. Upon granting these permissions, the application gets an access token as seen in Figure 2.

Figure 2

Using this access token, the application can now access the user’s information or perform actions on behalf of the user.

By default, most access tokens expire after a short time, however the application can request offline access tokens which allow them to use these tokens until you change your password, even when you aren’t logged in.

How does the access token get leaked?

By default, Facebook now uses OAUTH2.0 for authentication. However, older authentication schemes are still supported and used by hundreds of thousands of applications. When a user visits apps.Facebook.com/appname , Facebook first sends the application a limited amount of non-identifiable information about the user, such as their country, locale and age bracket. Using this information, the application can personalize the page.

The application then needs to redirect the user to a permission dialog page, as seen here.

Figure 3

The application uses a client-side redirect for redirecting the user to the familiar application permission dialog box. This indirect leak could happen if the application uses a legacy Facebook API and has the following deprecated parameters, "return_session=1" and "session_version=3", as part of their redirect code, as seen in Figure 4.

Figure 4

If these parameters are used, Facebook subsequently returns the access token by sending an HTTP request containing the access tokens in the URL to the application host.

 The Facebook application is now in a position to inadvertently leak the access tokens to third parties potentially on purpose and unfortunately very commonly by accident. In particular, this URL, including the access token, is passed to third-party advertisers as part of the referrer field of the HTTP requests.

For example, if this application’s first page was requesting resources from an external URL using an iframe tag from an advertiser, then the access token will get leaked in the referrer field. This is illustrated in Figure 5.

Figure 5

Conclusion

Needless to say, the repercussions of this access token leakage are seen far and wide. Facebook was notified of this issue and has confirmed this leakage. Facebook notified us of changes on their end to prevent these tokens from getting leaked.

There is no good way to estimate how many access tokens have already been leaked since the release Facebook applications back in 2007. We fear a lot of these tokens might still be available in log files of third-party servers or still being actively used by advertisers. Concerned Facebook users can change their Facebook passwords to invalidate leaked access tokens. Changing the password invalidates these tokens and is equivalent to “changing the lock” on your Facebook profile.

Nishant Doshi and Candid Wueest from Symantec are credited with the discovery of this issue.

Facebook has recently announced an update to their Developer RoadMap. The details of this update can be found here: https://developers.facebook.com/blog/post/497.

Update May 17th, 2011: For the last several weeks, we've been in touch with Facebook over the risk that certain applications that integrate with Facebook's Platform could have permitted third parties to access information Facebook users had shared with those applications. We would like to reiterate that once the issue was reported to them, Facebook took corrective action to eliminate this risk. To our knowledge, no Facebook users were impacted by this issue. Facebook also just posted the following article for its developers, guiding them towards secure coding standards.