4 X Security Team

Here’s a paradox - a technology originally meant to verify the sender of an email message for the sake of preventing spoofed messages from reaching the network, still hasn’t been embraced by the world’s biggest companies despite being around for years, but is actively used by adaptive spammers increasingly abusing legitimate services in order to take advantage of their identifiable email reputations.

A recently conducted study by Secure Computing’s TrustedSource reveals that, not only a mere 40% of the Fortune 500 companies use Sender Policy Framework and DomainKeys Identified mail, but also, that the ones who’ve implemented the countermeasures aren’t fully taking advantage of protection mechanisms offered at the first place.

“Out of the 2008 roster of Fortune 500 companies, a mere 202 appear to be using any of the forgery countermeasures provided by SPF, DKIM, or similar implementations. This poses a stark contrast to Sendmail’s Survey, claiming some 90% of Fortune 1000 companies, suggesting a sharp decline from Sendmail’s reported 282 companies. To make sure our results were accurate, we decided against using a random sampling and instead put together a list of all 500 primary domains used by the Fortune 500 and query them.

A mere 202 companies, when you account for the companies running both technologies - 40% of the Fortune 500. To make matters worse, only 65 of the 167 companies using SPF included the -all policy, which causes a fail result to be sent if the IP address is not found explicitly in the policy.”

And while the majority of Fortune 500 companies need to perhaps strategize better on how to built more authenticity in their communications and in fact prevent malicious attacks from reaching their mailboxes, spammers have been reportedly publishing SPF records since 2004, with MX Logic conducting a study into the tactic back then indicating that :

“In its preliminary study, MX Logic found that some spammers have embraced SPF in the hope that their unsolicited email messages will be viewed as more legitimate because the messages have an SPF email authentication record associated with them. In a sample of more than 400,000 unique spam email messages that passed through the MX Logic Threat Center from Aug. 29 through Sept. 3, 16 percent had published SPF records.”

Things are a bit different today, with spammers as active participants in the cybercrime ecosystem constantly demanding fresh malware infected hosts, and having embraced outsourcing as a concept a long time ago, they seem to have stopped investing resources into building legitimate infrastructure themselves, but have started to either renting such on behalf of someone else who build it, or abuse that of legitimate email providers by bypassing their authentication in place allowing them to easily take advantage of the provider’s trusted reputation.

Here’s an example of spammers sending DomainKeys Identified Mail from Yahoo’s SMTP servers in April, 2008, found in a report issued by MessageLabs, a practice made possible due to the successful breaking of these services CAPTCHA based authentication, either automatically or through human based CAPTCHA breakers :

“The spam mails are sent via SMTP using Yahoo!’s servers, ensuring the message is signed correctly using Yahoo! DomainKeys Identified Mail (DKIM). This is a sender authentication technique that uses a digital signature in the headers to indicate that the message is genuinely from Yahoo! and not spoofed as such. This approach further helps to ensure that mail generated in this way is harder to block using anti-spam methods based on the source IP address; as if it had been sent from genuine Yahoo! mail servers. In most cases the spam messages are routed through the premium Yahoo! “Plus” servers which are not listed in the Yahoo! webmail interface options page.

The Yahoo! accounts appear to have been generated programmatically, presumably defeating the Yahoo! CAPTCHA mechanism, because of the consistent format in all cases and all have from-domain of @yahoo.co.uk currently. At the time of writing around 1,127 unique Yahoo! User IDs were used in the distribution of this latest type of spam over 28 days, with around 40 new IDs per day being generated.”

As always, it’s never been about the lack of technological solutions to eradicate all the junk and malicious emails hitting an organization’s mailboxes and its customers. It’s always been about the lack of implementation of these solutions, and ensuring that abusing the now trusted services isn’t done as efficiently as it is for the time being.

[Source: zdnet]

If uTorrent is the client you use to download files, now might be a good time to hit that “check for updates” button.

According to security alerts aggregator Secunia, there’s a “highly critical” uTorrent vulnerability that could allow remote code execution attacks with rigged .torrent files.

From the advisory:

• The vulnerability is caused due to a boundary error in the processing of “.torrent” files. This can be exploited to cause a stack-based buffer overflow by tricking the user into opening a “.torrent” file containing an overly long “created by” field.
• Successful exploitation may allow execution of arbitrary code.
• The vulnerability is confirmed in version 1.7.7 (build 8179). Prior versions may also be affected.

The issue was silently patched by the vendor in version 1.8 RC7. Rhys Kidd says the flaw is at least two years old.

[Source: zdnet]

Already burned by the discovery of serious security vulnerabilities in its SDK, the Android Security Team emerged from the shadows this week with an appeal to the security community for help fixing flaws in the Linux-based mobile platform.

In a note posted to several public mailing lists, the open-source group published a detailed FAQ covering its security philosophy and process and made a direct request for hackers to use responsible disclosure (.pdf) ethics when vulnerabilities are discovered.

[ SEE: Google Android SDK has multiple vulnerabilities ]

• As you may expect, building and maintaining a secure mobile platform is a difficult task. The Android platform team has put a great deal of work into trying to design a platform that balances our goal of open development and user choice with the unique challenges of securing a consumer-focused mobile system.
• While we have found and fixed many of our own bugs as well as flaws in other open source projects, we realize that the discovery of additional security issues in a system this large and complex is inevitable. That is why we would like to introduce ourselves today and let the security research community know how they can reach out and work with us.

The group provided an e-mail address for reporting bugs in Android (security-at-android.com) and a promise to respond to bug reports and keep reporters informed of the progress of an investigation.

• We do appreciate and encourage responsible disclosure, especially since Android will be deployed on many different devices that will require a large amount of coordination to patch. Help from security researchers in the form of usable bug reports and responsible time lines will greatly assist us in securing the ecosystem of Android devices as quickly as possible. Our vulnerability bulletins will credit responsible reporters of any flaws.

The Android security team, which is part of the Open Handset Alliance, plans to release more details of the security features of the Android platform over the next several months.

[Source: zdnet]

Opera Software has shipped a new version of its flagship Web browser with fixes for at least seven documented security problems but details on one vulnerability — a cross-site scripting issue reported by Chris Weber– is being kept under wraps.

Opera warned that one of the seven flaws is rated “extremely severe” because of the risk of arbitrary code execution.

The skinny on what’s included in Opera 9.52:

• Advisory #1 (extremely severe): When Opera is registered as a handler for a given protocol, it can be started by external applications. In some cases, being started in this way can cause Opera to crash. To inject code, additional techniques will have to be employed. This bug affects Opera for Windows.
• Advisory #2 (highly severe): Scripts are able to change the addresses of framed pages that come from the same site. Due to a flaw in the way that Opera checks what frames can be changed, a site can change the address of frames on other sites inside any window that it has opened. This allows sites to open pages from other sites, and display misleading information on them.
• Advisory 3# (currently a secret): Fixed an issue that could allow cross-site scripting, as reported by Chris Weber of Casaba Security: details will be disclosed at a later date.
• Advisory #4 (moderately severe): Custom shortcut and menu commands can be used to activate external applications. In some cases, the parameters passed to these applications are not prepared correctly, and may be created from uninitialized memory. These may be misinterpreted as additional parameters, and depending on the application, this could allow execution of arbitrary code. Successful exploitation requires convincing the user to modify their shortcuts or menu files appropriately, pointing to an appropriate target application, then to activate that shortcut at an appropriate time. To inject code, additional means will have to be employed. This flaw affects Opera for Microsoft Windows, Linux, FreeBSD and Solaris.
• Advisory #5 (less severe): When insecure pages load content from secure sites into a frame, they can cause Opera to incorrectly report the insecure site as being secure. The padlock icon will incorrectly be shown, and the security information dialog will state that the connection is secure, but without any certificate information.
• Advisory #6: (less severe): As a security precaution, Opera does not allow Web pages to link to files on the user’s local disk. However, a flaw exists that allows Web pages to link to feed source files on the user’s computer. Suitable detection of JavaScript events and appropriate manipulation can unreliably allow a script to detect the difference between successful and unsuccessful subscriptions to these files, to allow it to discover if the file exists or not. In most cases the attempt will fail.
• Advisory #7 (not severe): It has been reported that when a user subscribes to a news feed using the feed subscription button, the page address can be changed. This causes the address field not to update correctly. Although this can mean that that misleading information can be displayed in the address field, it can only leave the attacking page’s address in the address bar, not a trusted third party address.

[Source: zdnet]

In addition to this long list of missing Microsoft patches, there are at least three serious (unpatched) vulnerabilities in the Microsoft Office productivity suite.

On August 12, the same day Microsoft released a slew of Office patches, TippingPoint’s DV Labs published a bare-bones advisory warning about a new high-risk Office flaw that allows code execution attacks.

From the DVLabs pre-patch alert:

• This vulnerability allows attackers to execute arbitrary code on vulnerable installations of Microsoft Office. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

[ SEE: Where on earth are these Microsoft patches? ]

The company also has two additional unpatched Office bugs on its list:

• July 8, 2008: This vulnerability allows attackers to execute arbitrary code on vulnerable installations of Microsoft Office. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

• May 5, 2008: This vulnerability allows attackers to execute arbitrary code on vulnerable installations of Microsoft Office. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

Vulnerability discoveries made by TippingPoints DV Labs are different from those purchased by the company’s ZDI (Zero Day Initiative).

[Source: zdnet]

According to published reports, Nokia and Sun have both confirmed the existence of serious security problems in the Series 40 and Java Platform Micro Edition (Java ME) , giving instant credibility to the claims by Polish hacker Adam Gowdiak.

Gowdiak (left), one of the four LSD researchers who discovered the MS03-026 flaw that was later exploited in the Blaster worm attacks, triggered widespread controversy earlier this month demanding 20,000 Euros each from Nokia and Sun for access to his full research but it now appears that he handed over enough information for the companies to reproduce/confirm the issues.

[ SEE: Researcher discovers Nokia S40 vulnerabilities, demands payment ]

Here’s Nokia’s response:

• Nokia has been a week or two getting back to us, but this morning admitted that they have “been investigating the allegations made, using our normal processes and comprehensive testing… We can confirm that both claims are valid in some of our products.”

From a Sun Micrososystems spokesperson:

• According to Sun, most of the “security explorations” carried out by Gowdiak were specific to the Nokia phone stack’s implementation of J2ME, rather than J2ME itself. “Sun can confirm that there are a couple of potential vulnerabilities outlined in [Gowdiak’s] post that are specific to [J2ME] but those are limited to older versions of [J2ME],” Sun’s spokesperson said. “In addition, these vulnerabilities would be extremely difficult to exploit because they would require device-specific information that is not readily available.”

It it not yet known if either company paid for Gowdiak’s research.

[Source: zdnet]

The United States Computer Emergency Response Team (US-CERT) has raised an alarm for a serious vulnerability in Apache Tomcat, warning that a proof-of-concept exploit is publicly available.

The code, posted to Milw0rm.com, exploits a directory traversal vulnerability vulnerability in the way Apache Tomcat handles malformed requests.

From the advisory:

• If a context is configured with allowLinking=”true” and the connector is configured with URIEncoding=”UTF-8″ then a malformed request may be used to access arbitrary files on the server.

The vulnerability (CVE-2008-2938) affects Apache Tomcat versions 4.1.0-4.1.37, 5.5.0-5.5.26, and 6.0.0-6.0.16.

The open-source group has shipped a fix in Apache Tomcat 6.0.18, an update that also fixes three additional security issues:

CVE-2008-1232 (cross-site scripting): The message argument of HttpServletResponse.sendError() call is not only displayed on the error page, but is also used for the reason-phrase of HTTP response. This may include characters that are illegal in HTTP headers. It is possible for a specially crafted message to result in arbitrary content being injected into the HTTP response. For a successful XSS attack, unfiltered user supplied data must be included in the message argument. This affects 6.0.0 - 6.0.16

CVE-2008-1947 (cross-site scripting): The Host Manager web application did not escape user provided data before including it in the output. This enabled a XSS attack. This application now filters the data before use. This issue may be mitigated by logging out (closing the browser) of the application once the management tasks have been completed.

CVE-2008-2370 (information disclosure): When using a RequestDispatcher the target path was normalised before the query string was removed. A request that included a specially crafted request parameter could be used to access content that would otherwise be protected by a security constraint or by locating it in under the WEB-INF directory. This affects: 6.0.0 - 6.0.16.

[Source: zdnet]