4 X Security Team

It would seem that people who are up to no good and want to get your machine infected, take less time to do so than in the past. By using information available to the general public, they are able to prepare an attack in a shorter time limit. Generally speaking, it takes about 24 hours from the moment a vulnerability is disclosed until an attack is already prepared and ready to launch. The thing is that most users find out about that particular vulnerability a lot later and consequently leave themselves exposed to infection.

In the past hackers and attackers of all sorts would spend quite a considerable amount of time looking for security vulnerabilities that they could exploit. In recent trends, this research work has been replaced by programs that generate automated attacks based on what information has been released about a security issue.

"The bad guys are not the ones actively finding vulnerabilities — they've shifted their business to standing on the shoulders of the security research community. They don't have to do the hard work anymore. Their job is packaging what's been provided to them," says Kris Lamb, operations manager for IBM's X-Force as cited by MSNBC.

Since the security experts do all the research and then by disclosing the findings basically make the attacker's work that much easier, a debate has been launched on how much information should be shared with the general public and how much should be kept private. If a researcher releases technical details as well as "proof-of-concept" exploit code, then a wrongdoer has all the necessary information to launch an attack, especially if said researcher has done so before a security fix could be issued by the software manufacturer.

Just to put things into perspective, in 94% of the cases a hacking exploit was ready in less than 24 hours after disclosing a vulnerability within various web browsers. Compared to 2007, one can notice a 24% increase.
[Source: softpedia]

Guest editorial by Oliver Day

In June 2008, StopBadware published a report with statistics (.pdf) based on our sample of infected website data from Google. In those statistics we noted that over half of the infections came from addresses originating in China. We’ve received some attention for these statistics and I’d like to delve a little further into this. This blog post should provide some insight into those numbers, provide some clarifications on common misconceptions and possibly open up new questions.

The percent of infections claiming to be from China are not an absolute measure and it is safe to assume that there are not only registrations originating from China claiming to be from other countries but also registrations from outside the country claiming to be Chinese. One of the general assumptions I’ve operated under is that the majority of the infections we see are not operated by those who profit from the infections. Those who do play in the underground economy of identity theft, botnets, etc are the ones who will generally spend the time to fake registration data. Another assumption is that those false registrations are relatively few compared to the bulk of accurate registrations.

In the paper, the authors suggest that many of the infections are from illicit material or from webmasters who cash out their existing web traffic by inserting the iframes themselves. In either case the numbers of infections are measurably high and finding out why is complicated by serveral factors. A staggering growth in online population, both a low per capita Internet Protocol address (IPV4), high relative IPV4 growth and majority of users without sufficient education add unaccounted for variables. With this background in place we can look at some measures of the Internet in China to try and inform our discussion.

The majority of my sources are from the Chinese Internet Network Information Center (CNNIC). They have published remarkably detailed statistics and histories of the Internet in China. One factor that seems relevant is the search market in China. According to a 2007 report issued by CNNIC a majority of Chinese users searching with Baidu instead of Google.

While these two engines matched evenly in the competition for the “high end market,” their 2007 report shows a very small amount of this classification of user on the Internet. 71.5% of Chinese internet users fall outside of this range. One of the points we made in a paper I published at WEIS was that the availability of malicious links in trusted gatekeepers, such as Baidu, increases the number of infections globally. Search engines have become manipulated to a degree and links from a credible gatekeeper are leading to Drive By Downloads. The Safe Browsing program virtually quarantines sites from users of Google’s search services. While Google isn’t able to prevent anyone from literally connecting to a website by typing the URL into their location bar the warnings contained in their interstitial seem to deter a majority of users. Anecdotally we at StopBadware have heard numbers as high as 80% reductions in traffic due to the interstitial program but are still creating a system to measure the true effectiveness on web traffic.

Another factor that complicates our understanding is the way China has setup their Autonomous System (AS) names. In the US AS names generally lead to either a hosting provider or a colocation service. In China however the top infected AS Names are huge backbone providers. When we group our data and find that 60,000 infections are coming from a backbone provider that doesn’t give us much to go on. In some US cases involving colocation services, we were able to use rwhois services to get a better idea of who to contact; however, in China there seems to be relatively few rwhois servers on the reported networks. Part of this could be due to the ownership of backbones in China or perhaps due to explosive growth. As shown below by statistics gathered by bgpexpert, the growth of IPv4 addresses in China in the last year exceeds 60%.

This post just scratches the surface for those who are interested in the Internet in China. There are still so many different questions left unanswered when it comes to infections in China and I am still learning how to derive answers. Currently I have been studying some published network maps to get an idea of the ISP landscape in China. I hope to combine this with maps I create using tools like scapy to produce some more answers to the questions I have raised.

* Oliver Day is a security researcher at StopBadware.org, a project of the Berkman Center for Internet and Society at Harvard University. He has over ten years experience in web and network security, working for companies including @stake, eEye, and Rapid7. He has presented on network security to dozens of Fortune 500 companies and educational institutions and is a staunch advocate of the disclosure process and providing shielding for security researchers. Oliver can be contacted at oday [-at-] cyber.law.harvard.edu.

[Source: zdnet]

Another day, another unpatched Safari browser vulnerability.

According to this flaw warning found on the NVD (National Vulnerability Database), Apple’s flagship browser is vulnerable to session fixation attacks because of the way it handles cookies in country-specific top-level domains.

[ SEE: Microsoft issues Safari-to-IE blended threat warning ]

Heise Security breaks down the attack vector:

Apple’s Safari web browser, when handling cookies in multipart top level domains (TLDs), contains a vulnerability that potentially allows attackers to access the web services used by the victim. Safari handles multipart TLDs like .co.uk or .com.au differently from normal TLDs like .de or .com. According to a report, this allows attackers to inject the browser with a cookie which Safari will subsequently use for log-in authentication at other servers in the same TLD.

Alex “Kuza55,” a hacker who appeared at Microsoft’s Blue Hat summit, is credited with discovering this Safari vulnerability. It carries a CVSS Base Score of 6.8.

[Source: zdnet]

For the first time since the introduction of its quarterly Critical Patch Update process, Oracle has released an emergency alert to offer mitigation for a zero-day exploit that’s been posted on the Internet.

The emergency workaround, available here, addresses an unpatched vulnerability that’s remotely exploitable without authentication ( it may be exploited over the network without the need for a username and password) and can result in compromising the confidentiality, integrity, and availability of the targeted system.

[ SEE: Hacker finds 492,000 unprotected Oracle, SQL database servers ]

Oracle’s Eric Maurice says the vulnerability carries a CVSS Base Score of 10.0, the maximum severity rating:

When Oracle became aware of this issue, our security and development teams worked diligently to develop an effective workaround to prevent a successful exploitation of the vulnerability. Detailed instructions for this workaround have been posted on the eSupport site, and Oracle has already issued a Security Alert to all WebLogic customers to let them know about this workaround. In addition, Oracle will also issue an out-of-cycle security patch for this vulnerability as soon as the fix has been produced for all supported version-platform combinations. We expect this fix to be ready very soon, and we will issue an updated Security Alert to let customers know about its availability. In the meanwhile, we recommend that all customers implement the recommended workaround.

Unfortunately, the person(s) who published this vulnerability and associated exploit codes did not contact Oracle before publicly disclosing this issue. This means that the vulnerability was made public before providing Oracle an opportunity to develop an appropriate fix for this issue and notify its customers. In addition, the vulnerability was made public shortly after the publication of the July 15th Critical Patch Update, therefore prompting Oracle to issue an out of cycle security update.

This IBM ISS alert provides some technical details:

Oracle WebLogic Server (formerly known as BEA WebLogic Server) is vulnerable to a buffer overflow, caused by improper bounds checking by the Apache Connector. By sending a specially-crafted HTTP POST request, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the server to crash.

The emergency alert comes less than two weeks after the database server giant shipped patches for a total of 45 security vulnerabilities, bringing the vulnerability count for 2008 to a whopping 112.

* Photo credit: eMaringolo’s Flickr photostream (Creative Commons 2.0)

[Source: zdnet]

There’s growing speculation coming out of Europe that there’s a backdoor in Skype that allows remote eavesdropping of telephone conversations.

A report in the reputable Heise Online says the issue was discussed at a meeting with ISPs last month where high-ranking officials at the Austrian interior ministry claims “it is not a problem for them to listen in on Skype conversations.”

The report said a number of others at the meeting confirmed that claim.

Heise Online said Skype officials declined to give a detailed response to specific queries as to whether the popular Internet telephone service contains a backdoor and whether specific clients allowing access to a system or a specific key for decrypting data streams exist.

The response from the eBay subsidiary’s press spokesman was brief, “Skype does not comment on media speculation. Skype offers no further comment at present.” There have been rumors of the existence of a special listening device which Skype is reported to offer for sale to interested states.

Because the vendor has not revealed details of its proprietary Skype protocol or of how the client works, questions as to what else Skype is capable of and what risks are involved in deploying it in an enterprise environment remain open, the report said.

It also cited public broadcast reports that Austrian police are able to listen in on Skype connections.

* Photo credit: re-ality’s Flickr photostream (Creative Commons 2.0)

[Source: zdnet]

[Updated 07/24/2008: Gallery images of diffs of code revisions has been included and will be updated as things change, see here.]

Earlier today, noted researchers |)ruid and HD Moore released exploit code for the Metasploit tool for attacking the DNS flaw that was originally reported by Dan Kaminsky. The release was only part of the bigger picture of the exploit; however, and the second piece of exploit code has been released on the Computer Academic Underground blog and on Full-Disclosure. There is a subtle but important difference in the two pieces of exploit code, which is only readily apparent from reading the comments in the source code. Part 1 of the exploit, released earlier today, is commented as below:

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single malicious host entry into the target nameserver by sending random sub-domain queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for the domain which contain a malicious host entry for the hostname to be poisoned in the authority and additional records sections. Eventually, a guessed ID will match and the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached.

Part 2 of the exploit, released just moments ago, is commented as follows:

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target domains nameserver entries in a vulnerable DNS cache server. This attack works by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and the nameserver entries for the target domain will be replaced by the server specified in the NEWDNS option of this exploit.

So let’s analyze this a bit, see if we can figure out what’s different. Good friend and noted researcher, Billy Rios, assisted me with some code review, and we tried to find as much as we could about this new twist on events. We found several things of note. The most obvious, the exploit just got worse. Now the code will use spoofed replies to hijack the name server entries for a target domain, allowing control over an entire domain, whereas the original hijacked an individual host. For example, before, we could hijack www.myaddress.com, now we can hijack all of myaddress.com.

Further, within the credits portion of the code, |)ruid adds credit to a new researcher for “helping with the NS injection” confirming the idea that this is now about attacking nameserver entries, and not just address records. The credits are listed below:

Credits
=======
Dan Kaminsky is credited with originally discovering this vulnerability. Cedric Blancher figured out the NS injection method and was cool enough to email us and share!

Rios and I suspect that Cedric probably made use of the following from RFC 1035:

NS authoritative name server, code 2. Specifies a host name (which must have an A record associated with it), where DNS information can be found about the domain name to which the NS record is attached. NS records are the basic infrastructure on which DNS is built; they stitch together distributed zone files into a directed graph that can be efficiently searched.

Next, Rios clued me into a very interesting observation… as he said, “it went from rev 5585 5591 that’s 6 different changes in a few hours… it’s still being tuned.” Which means it’s going to get faster. Dan originally stated he could pull this off in a matter of seconds. With able programmers refining the existing code, it’s only a matter of time before this exploit becomes lightning quick.

Work to make the exploit quicker may be confirmed by noting that there has been changes to the rand code for the xidbase.

So things are getting worse. If you have not patched by now… well, you’re on your way to being pwned, so I’d get to it ASAP.

[Source: zdnet]

Security researcher Aviv Raff (left) has discovered a pair of basic design flaws that could turn your iPhone into easy bait for malicious phishing and spamming attacks.

According to an advisory from Raff, the iPhone’s Mail and Safari applications are susceptible to a URL Spoofing vulnerability which allow attackers to conduct phishing attacks.

By creating a specially crafted URL, and sending it via an email, an attacker can convince the user that the spoofed URL, showed in the mail application, is from a trusted domain (e.g. Bank, PayPal, Social Networks, etc.).

When clicking on the URL, the Safari browser will be opened. The spoofed URL, showed in the address bar of the Safari browser, will still be viewed by the victim as if it is of a trusted domain.

[ SEE: Apple hasn’t learned from past security mistakes ]

iPhone Mail and Safari on firmware 1.1.4 and 2.0 are affected by this vulnerability. Apple’s security team has confirmed the vulnerability. Raff says he is withholding details until after a patch is released. In the meantime, iPhone users should avoid clicking on links in the Mail app that refers to trusted sites.

A second vulnerability in the iPhone Mail application that could help spammers was also reported and acknowledged as a security issue by Apple. Raff describes this as “a basic security design flaw which might already be exploited in-the-wild.”

I have seen proof-of-concept code for both vulnerabilities and can confirm that the iPhone is potentially a phisher’s/spammer’s best friend.

ALSO SEE: Apple caught neglecting iPhone security

[Source: zdnet]

The short answer is being paranoid about tackling a known vulnerability. It’s 2001, and Daniel J. Bernstein (DJB), author of the then popular djbdns security-aware DNS implementation, is applying basic math principles to raise awareness on what’s to turn into the “sky is falling” critical Internet vulnerability in 2008, in an email on the unix.bind-users newsgroup :

“I said “cryptographic randomization.” The output of random() is not cryptographically secure. In fact, it is quite easily predictable. This is a standard exercise in first-semester cryptography courses. Randomizing the port number makes a huge difference in the cost of a forgery for blind attackers—i.e., most attackers on the Internet. It’s funny that the BIND company has gone to so much effort to move from the first line to the second, but now pooh-poohs the third line. Do you think that “RSA” is a magic word that makes security problems disappear? Without a central key distribution system—a system that doesn’t exist now and won’t exist for the foreseeable future—DNSSEC doesn’t stop forgeries.”

The skeleton from the closet makes another appearance in January 2005, according to Marcus H. Sachs, Director, SANS Internet Storm Center, in the face of Ian Green’s GIAC Security Essentials Certification (GSEC) submitted paper detailing the same vulnerability :

“Three years ago Ian Green, then studying for his GIAC Security Essentials Certification (GSEC), submitted a paper that details the same DNS spoofing vulnerability, the SANS Institute’s Internet Storm Centre notes.In order to spoof a DNS request it’s necessary to “guess” both the Query ID and the source port. The query ID is 16 bits long, and the UDP source port also has over 60,000 potential option. But as Green noted back in January 2005, DNS transactions are incremented by one for each subsequent query while the UDP source port remains the same during a session.”

Apparently, OpenDNS, PowerDNS and MaraDNS were all aware of the possibility for abuse here, and took action long before the recent vulnerability disclosure and coordinated multi-vendor patching initiated by Dan Kaminsky took place. How did they do it, and what’s the current state of the coordinated patching campaign across the Internet?

On July 8th, David Ulevitch at OpenDNS posted a statement that OpenDNS isn’t vulnerable :

“I’m very proud to announce that we are one of the only DNS vendor / service providers that was not vulnerable when this issue was first discovered by Dan. During Dan’s testing he confirmed (and we later confirmed) that our DNS implementation is not susceptible to the attack that was discovered. In other words, if you used OpenDNS then you were already protected long before this attack was even discovered.

In fact, for those of you who were listening in on the Microsoft press call this morning, you’ll note that OpenDNS was suggested as the easy and simple solution for anyone who can’t upgrade their DNS infrastructure today. Pointing your DNS servers to forward requests to OpenDNS and firewalling all other DNS traffic off at your server will help mitigate this risk.” Bert Hubert, author of PowerDNS, alerted me to the fact that PowerDNS was also not vulnerable when this issue was discovered. That’s not surprising considering Bert is one of the authors of the wonderful DNS forgery resilience Internet Draft that has recently been published. :-) I updated the statement in bold appropriately.”

On July 9th, Sam Trenholme at MaraDNS pointed out that the service is too, immune to the new cache poisoning attack :

“MaraDNS is immune to the new cache poisoning attack. MaraDNS has always been immune to this attack. Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago. The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun).”

And while these DNS services and secure DNS implementations like MaraDNS in this case, weren’t susceptible to the DNS cache poisoning, during that time, across the Internet a synchronized patching was causing a lot of DNS anomalies, the direct effect of the ongoing patching in progress. According to Narus’s Supranamaya Ranjan, they saw a 1000x increase in aggregate volume of anomalous DNS traffic between Julu 7th and 11th :

“Look at the figure below, which shows the aggregate volume (in Mbits/hour) over time for the DNS anomalies seen between July 7th and 11th. Clearly, before the CERT announcement and release of the patches, there were no anomalies. But after the announcement on July 8th, NSS saw a 1000x increase in aggregate volume of anomalous DNS traffic. NSS defines a traffic event as an anomaly if the amount or behavior of traffic heading to an ip-address exhibits sudden changes. A further analysis of the sources of these queries shows that they were being originated from open DNS proxies on the Internet and from DNS clients from well-reputed institutions from around the world. The reputation of the anomaly sources leads to the conclusion that these anomalies were not really attacks, but a side-effect of the synchronized patching.”

The most recent study on the state of patching vulnerable DNS servers, was released today courtesy of Austria’s CERT, stating that :

“The conclusions are rather grim so far – more than two thirds of the Austrian Internet’s recursive DNS servers are unpatched while at the same time the upgrade adoption rate seems rather slow. Our findings are matched by the observations of Alexander Klink of Cynops GmbH who analyzed the results of the online vulnerability test on Dan Kaminsky’s doxpara site.”

The big picture? It seems that it’s not just At&T’s DNS servers which are susceptible to DNS cache poisoning, but many other like the following according to a request for self-auditing initiated by the Register :

“Skybroadband, Carphone Warehouse Broadband, Opal Telecom, T-Mobile, Videotron Telecom, Roadrunner, Orange, Enventis Telecom, Earthlink, Griffin Internet and Jazztel.”

With three publicly available exploits for remote DNS cache poisoning released during the last three days “in the wild”, it remains yet to be seen whether or not malicious attackers would take advantage of the window of opportunity, or continue using the “cybercrime as usual” attack tactics.

[Source: zdnet]

Digital media delivery firm RealNetworks has shipped a high-prority patch to cover four gaping holes in its flagship RealPlayer software, warning that the vulnerabilities could put users at risk of code execution attacks.

The patch comes a few hours after Secunia released an advisory warning for one of the vulnerabilities, a heap-based buffer overflow caused by a design error within RealPlayer’s handling of frames in Shockwave Flash (SWF) files.

According to RealNetworks, at least one of the four bugs affects all platforms — Windows, Mac OS X and Linux.

[ SEE: IE users beware: RealPlayer zero-day flaw under attack ]

Details are only available for these two vulnerabilities:

• CVE-2008-1309: The RealAudioObjects.RealAudio ActiveX control in rmoc3260.dll 6.0.10.45 in RealNetworks RealPlayer 11.0.1 build 6.0.14.794 does not properly manage memory for the Console property, which allows remote attackers to execute arbitrary code or cause a denial of service (browser crash) via a series of assignments of long string values, which triggers an overwrite of freed heap memory. CVSS Base Score 9.3.
• CVE-2007-5400: The vulnerability is caused due to a design error within the handling of frames in Shockwave Flash (SWF) files and can be exploited to cause a heap-based buffer overflow. Successful exploitation may allow execution of arbitrary code.

In its advisory, RealNetworks also lists CVE-2008-1309, a RealPlayer ActiveX controls property heap memory corruption; and CVE-2008-3064, a local resource reference vulnerability.

[Source: zdnet]

Recently, the DNS flaw discovered by Dan Kaminsky made all the headlines, first of all because of its gravity, and secondly because the Director of Penetration Testing for IOActive would not release specific, technical details about the flaw. Kaminsky stated on numerous occasions that he would disclose all the information on the 6th of August, at the BlackHat Security Conference in Las Vegas. But it seems that Thomas Dullien, CEO and head of research with Sabre Security has figured it all out, even though he admits he is not an expert in DNS.

This is the message posted on the Matasano Security blog in regard to Dullien's discovery: "The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat". Halvar Flake is the hacker alias used by Thomas Dullien. It must be noted that the blog post presented above was posted for about five minutes and then it was taken down.

Thomas Ptacek from Matasano Security has posted another statement on the site, saying that they "dropped the ball" and it was all a regrettable error. "Earlier today, a security researcher posted their hypothesis regarding Dan Kaminsky’s DNS finding. Shortly afterwards, when the story began getting traction, a post appeared on our blog about that hypothesis. It was posted in error. We regret that it ran. We removed it from the blog as soon as we saw it. Unfortunately, it takes only seconds for Internet publications to spread," says Ptacek.

According to Halvar Flake, there is no good reason behind Kaminsky's request not to publicly speculate on the DNS vulnerability. He agrees that Kaminsky did the right thing by not disclosing the vulnerability and getting the industry heavyweights to come up with a fix, but by not speculating you are not buying the user any time. "In a strange way, if nobody speculates publicly, we are pulling wool over the eyes of the general public, and ourselves," says Halvar Flake.

Dan Kaminsky did not confirm or deny the fact that Hlavar Flake had indeed discovered the DNS vulnerability that he came upon earlier this year, and he is urging all users to update, if they haven't done so already. On the 24th Kaminsky will do a webcast for BlackHat, but he says this opportunity will not be used to disclose details on the DNS vulnerability. All those interested in the issue will have to wait until the 6th of August.

[Source: softpedia]

[ UPDATE: Kaminsky has all but confirmed that, yes, the cat is out of the bag ]

It looks very much like the nitty gritty of Dan Kaminsky’s super-secret — and heavily hyped — DNS cache poisoning vulnerability has been figured out by reverse engineering guru Halvar Flake.

Clearly irked by a demand request from Kaminsky and others to avoid speculating on the details of the flaw until the patch is fully deployed, Flake (left) published a reliable method to forge and poison DNS lookups.

Flake, CEO and head of research at Sabre Security, said his speculation was driven by the need to discuss the vulnerability in public instead of a one-month embargo that culminates with Kaminsky’s presentation at the upcoming Black Hat conference.

[ SEE: Dan Kaminsky breaks DNS, massive multi-vendor patch coming ]

“In a strange way, if nobody speculates publicly, we are pulling wool over the eyes of the general public, and ourselves,” Flake argued, before posting the following hypothesis:

Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver for gmx.net is ns.gmx.net. Mallory’s IP is 244.244.244.244.

Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com … to ns.polya.com.

ns.polya.com doesn’t have these requests cached, so it asks a root server “where can I find the .com NS?” It then receives a referral to the .com NS. It asks the nameserver for .com where to find the nameserver for ulam00001.com, ulam00002.com etc.

Mallory spoofs referrals claiming to come from the .com nameserver to ns.polya.com. In these referrals, it says that the nameserver responsible for ulamYYYYY.com is a server called ns.gmx.net and that this server is located at 244.244.244.244. Also, the time to live of this referral is … long …

Now eventually, Mallory will get one such referral spoofed right, e.g. the TXID etc. will be guessed properly.

ns.polya.com will then cache that ns.gmx.net can be found at … 244.244.244.244. Yay.

After the publication of Flake’s summation, Kaminsky gave a no-comment to The Register’s Dan Goodin.

Nate Lawson, head of Root Labs, had this to say: “It’s very plausible; I think he’s nailed it.”

[ SEE: Kaminsky and Ptacek comment on DNS flaw ]

Goodin, one of the more thorough security writers around, made a great point that if Flake’s speculation is unrelated to Kaminsky’s earlier discovery, then there are now two separate issues at play. Only one of the two has been patched!

Perhaps it’s time for Kaminsky to throw his self-imposed embargo out the window and help all of us understand the true severity of this vulnerability.

[Source: zdnet]

In what appears to be either a common scenario of “when the security solution ends up the security problem itself”, or a product launch basing its strategy on outlining the increasing number of critical vulnerabilities found in competing antivirus products, the IT/Security consulting firm n.runs AG claims to have discovered approximately 800 vulnerabilities within antivirus products based on exploiting a standard malware scanning process known as “parsing” :

“During the past few months, specialists from the n.runs AG, along with other security experts, have discovered approximately 800 vulnerabilties in anti-virus products. The conclusion: contrary to their actual function, the products open the door to attackers, enable them to penetrate company networks and infect them with destructive code. The positioning of anti-virus software in central areas of the company now poses an accordingly high security risk. The tests performed by the consulting company and solutions developer n.runs have indicated that every virus scanner currently on the market immediately revealed up to several highly critical vulnerabilities. These then pave the way for Denial of Service (DoS) attacks and enable the infiltration of destructive code – past the security solution into the network. With that, anti-virus solutions actually allow the very thing they should instead prevent.”

In between the ongoing efforts put by malware authors to obfuscate their binaries, release as many as possible in the shortest time frame achievable, or ensure that they bypass the most popular personal firewalls before releasing them by applying quality assurance to their malware campaigns, can antivirus products be a security issue themselves? But of course, and the increasing number of vulnerabilities discovered is clearly indicating the increasing interest in proving the point in general.

How did n.runs manage to discover the vulnerabilities they claim they found? By following the very same logic on which a great deal of the current vulnerabilities are based on, the way in which the scanner parses the file it’s supposed to scan :

“In this context, n.runs was able to make out so-called “parsing” as one of the main causes of this boomerang effect. The principle functions as follows: virus scanners must recognise as many “Malware” applications as possible – and thereby comprehend and process a large number of file formats. In order to be able to interpret the formats, an application must partition the corresponding file into blocks and structures. This separation of data into analysable individual parts is called “parsing”. Mistaken assumptions in the course of programming the parsing code create constellations which enable the infiltration and subsequent running of programme code. Moreover, the quick reactions time expected by developers (regarding threats) contributes to a decrease in the quality of the code. In short: the more parsing that takes place, the higher the recognition rate and the degree of protection from destructive software, but at the same time, the larger the attack surface – which makes the anti-virus solution itself a target.”

The research they cite is based on Secunia’s tracking of advisories affecting antivirus products, as well as research conducted by the University of Michigan emphasizing on the severity of the vulnerabilities on a per product basis. For instance, between 2002 and 2005 there were 50 advisories regarding vulnerabilities affecting antivirus products, but between 2005 and 2007, there’s been an increase of 240% with 170 advisories. Moreover, according to a research paper by Feng Xue, presented at this year’s Blackhat Europe, according to the U.S national vulnerability database, 165 vulnerabilities within antivirus products have been reported during the last 4 years. It’s even more ironic to point out that the now fixed remote code execution vulnerability in Panda Security’s online virus scanner, further proves that the security solution can indeed end up the security problem itself.

With the increasing interest and success into finding critical security vulnerabilities within antivirus products, are we going to see more abuse of these “windows of opportunity” by malware authors themselves? I don’t think so, at least not on a large scale. What they are going to continue researching are ways in which to shut down the antivirus solution silently, prevent it from reaching its hard coded update locations, and most importantly ensure the malware has been pre-tested against the most popular security solutions before it’s released in the wild - precisely what they’ve been doing for the last couple of years.

[Source: zdnet]

Security alerts aggregator Secunia has raised an alarm for a “highly critical” vulnerability that puts users of the BlackBerry Enterprise Server at risk of code execution attacks.

Technical details of bug are not available but Secunia says it is caused by an unspecified error in the BlackBerry Attachment Service when processing PDF files.

The vulnerability is reported in versions 4.1 Service Pack 3 (4.1.3) through 4.1 Service Pack 5 (4.1.5). Other versions may also be affected. It carries a CVSS Base Score of 9.0.

A separate advisory from Research in Motion (makers of the BlackBerry smart phone) says the flaw is in the PDF distiller of the BlackBerry Attachment Service and confirms that a malicious hacker could use a specially crafted PDF file attachment in an email message to cause arbitrary code to execute on the computer that the BlackBerry Attachment Service runs on.

If a BlackBerry smartphone user on a BlackBerry Enterprise Server opens and views the specially crafted PDF file attachment on the BlackBerry smartphone, the arbitrary code execution could compromise the computer.

The company says the issue has been escalated internally and urged BlackBerry users to be wary of PDF files that arrive from untrusted sources.

Pre-patch workarounds are available.

* Image source: Research in Motion.

[Source: zdnet]

Update 07/16/2008: Apparently I neglected to mention that this has been patched already. Reading over it again and a heads up from a reader pointed out the error to me. As always, great job by Window Snyder and the Mozilla Security Team for getting this patched quickly.

Billy Rios is at it again. Rios, Rob Carter, and I have made a year and more of our research into exploiting URI/protocol handler vulnerabilities on numerous operating systems and applications, and it appears Rios has ANOTHER one to go with all that previously reported, as well as his most recent vector, which was used against Opera.

From Mozilla:

Security researcher Billy Rios reported that if Firefox is not already running, passing it a command-line URI with pipe (”|”) symbols will open multiple tabs. This URI splitting could be used to launch chrome: URIs from the command-line, a partial bypass of the fix for MFSA 2005-53 which was intended to block external applications from loading such URIs (that vulnerability remains fixed, however).

This vulnerability could also be used by an attacker to pass URIs to Firefox that would normally be handled by a vector application by appending it to a URI not handled by the vector application. For example, web browsers normally handle file: URIs themselves, or block them from web content altogether, but this flaw enabled attackers to pass them from another browser into Firefox. In Firefox 2 scripts running from file: URIs can read data from a user’s entire disk, a risk if the attacker could first place a malicious file in a guessable location on the local disk. Rios demonstrated that the so-called “Safari Carpet-bombing vulnerability” could be used for this, as well as other techniques that do not rely on that now-fixed Safari vulnerability.

In Firefox 3 scripts running in local files have limited access to other files, almost entirely mitigating the file: attack. However, combined with a vulnerability which allows an attacker to inject script into a chrome document the above issue could be used to run arbitrary code on a victim’s computer. Such a chrome injection vulnerability was discovered in Firefox 3 by Mozilla developers Ben Turner and Dan Veditz who showed that a XUL based error page was not properly sanitizing inputs and could be used in this attack. In the absence of the attack described by Billy Rios this injection attack would not run with any special privilege and would be at best a spoofing vulnerability.

It will be interesting to see if Rios provides proof of concept code, but if you look at the protocol handler registered on the operating system, and how it interacts with Firefox, it may be straightforward. URI and protocol handler abuse continues to be an extremely viable option of attack.

[Source: zdnet]

The Black Hat group on Twitter provided a message today alerting people to a webcast to be put on by Dan Kaminsky on the DNS vulnerabilities that I’ve heavily covered as follows:

• Dan Kaminsky breaks DNS, massive multi-vendor patch coming, details at Black Hat Vegas ‘08
• Kaminsky and Ptacek comment on DNS flaw
• Don’t doubt Deputy Dan

The story has also received extensive coverage over at Securosis, where Rich Mogull has provided a podcast on the subject. The Black Hat webcast details are listed below, including the registration information:

Registration Now Open for BH Webcast number 2 With Dan Kaminsky

It’s all over the news: Dan Kaminsky found a major, fundamental flaw in DNS that renders practically any name server vulnerable. He’ll be speaking in depth on this discovery in August at BH USA, but he’s agreed to discuss it a few weeks early. Get your best questions ready - the webcast will be live Thursday, July 24 at 1pm PT/4pm ET.

Join Dan Kaminsky, director of penetration testing for IOactive; Jerry Dixon, former director of the National Cyber Security Division at DHS; and other experts to discuss the largest synchronized security update in the history of the Internet. Dan will tell the story behind the discovery, and the process of creating and deploying the fix.

I’ll be there, as it’s always interesting and entertaining to hear Dan talk. Also, you should note that Dan’s talk at Black Hat is followed up by my talk with Heasman and Rob Carter in the exact same room. Might I suggest you just hang out and see our devastating talk as well? With a title like “The Internet is Broken“, you can imagine we have a lot of interesting stuff to deliver. Shameless plug, I know, but we’ll make it worth your while.

[Source: zdnet]

More details coming out on the Oracle patches that were released last week, see Ryan Naraine’s write up here. David Litchfield, noted security researcher from NGSSoftware, released details of one of the vulnerabilities on the Full-Disclosure email list today, and the details are staggering. The flaw allows potential unauthenticated remote exploitation resulting in full control of the database server. One thing that I think is key to note here is that this vulnerability was reported in October of 2007 and is just now getting patched in July of 2008. End result is, if you are using Oracle, get patched ASAP.
Read the details below…

Litchfield’s details are provided below:

Name: PLSQL Injection in Oracle Application Server
Systems Affected: Oracle Application Server 9.0.4.3, 10.1.2.2, 10.1.4.1
Severity: Critical
Vendor URL: http://www.oracle.com/
Author: David Litchfield [ davidl@ngssoftware.com ]
Reported: 9th October 2007
Date of Public Advisory: 15th July 2008
Advisory number: #NISR15072008
CVE: CVE-2008-2589

Overview
********
Oracle has just released a fix for a flaw that, when exploited, allows an unauthenticated attacker on the Internet to gain full control of a backend Oracle database server via the front end web server.

Details
*******
Oracle Application Server installs a number of PLSQL packages in the backend
database server. One of these is the WWV_RENDER_REPORT package and it is vulnerable to PLSQL injection. This package uses definer rights execution and therefore executes with the privileges of the owner, in this case the highly privileged PORTAL user.

Specifically, the SHOW procedure takes as its 2nd argument the name of a function to execute and this is embedded with a dynamically executed anonymous block of PLSQL without first being sanitized. Because it is a block of anonymous PLSQL, an attacker can exploit this flaw to run any SQL statement, for example, create new users, grant dba privileges, delete or
modify data. This is achieved by wrapping the statement(s) within an “execute immediate” statement and specifying the autonomous_transaction pragma.

[Source: zdnet]

Ah, this is a fun little trick. I’m not sure if it represents a vulnerability, but certainly I expect Google will try to get rid of this feature. The SecuriTeam blog has reported that it is possible to expose the full name of the user who registered a GMail account. This is, of course, contingent on the fact that the person who registered the GMail account didn’t use a fake first and last name, but still, an interesting trick.

The reason this vulnerability exists is due to the strong tie-ins between GMail and all of Google’s other services, such as Google Calendar, Blogger, and Google Code AND the strong desire for Google Apps to be able to share data with people. This isn’t the first time, the second time, or the last time the strong tie-ins have produced interesting results, see my post on Billy Rios’s Google Code exploit, Billy’s taking ownership (pwnership) of content attacks against Google Spreadsheets, Billy and I stealing documents from Google Docs, and see my talk at Black Hat for more.

The steps to accomplish this are as follows:

1. Sign up for Google Calendar
2. Go to the ’share this calendar’ tab
3. Enter the email address in the ‘person’ box
4. Click ‘add person’ and ’save’
5. When you return to this screen you will see the first and last name along with the gmail address

Read the rest of this entry

[Source: zdnet]

WordPress, one of the fastest growing blog software providers, has shipped a new update with fixes for nearly 200 bugs and a major security-related change to disable remote publishing protocols by default.

With WordPress 2.6, the open-source software promises to be more secure out-of-the-box with full SSL support in the core, and the ability to force SSL for security.

Even more importantly, WordPress has disabled the Atom Publishing Protocol and the variety of XML-RPC protocols by default to shut down a potential security risk.

The software upgrade also comes with “a number of proactive security enhancements, including cookies and database interactions,” and about 194 bug fixes, some security-related.

WordPress lead developer Ryan Boren has published more details on SSL and cookie handling.

If you manage a WordPress blog, this should be considered an important update. You should also pay close attention to Matt Mullenweg’s security recommendations.

* Image source: Nikolay Bachiyski’s photostream (Creative Commons 2.0)

[Source: zdnet]

Kris Kaspersky, author of numerous books on reverse engineering and software engineering, will be presenting his research on remote code execution through Intel CPU bugs at the upcoming Hack in the Box Security Conference in Malaysia. If his proof of concept code consisting of JavaScript or TCP/IP packet attacks on Intel based machines succeeds, given Intel’s dominant market share on the market the potential outbreak could be enormous since as he claims, the PoC is OS independent, namely all operating systems running Intel chips are said to be vulnerable. Here’s an abstract from his upcoming presentation :

“Intel CPUs have exploitable bugs which are vulnerable to both local and remote attacks which works against any OS regardless of the patches applied or the applications which are running. In this presentation, I will share with the participants the finding of my CPU malware detection research which was funded by Endeavor Security. I will also present to the participants my improved POC code and will show participants how it’s possible to make an attack via JavaScript code or just TCP/IP packets storms against Intel based machine. Some of the bugs that will be shown are exploitable via common instruction sequences and by knowing the mechanics behind certain JIT Java-compilers, attackers can force the compiler to do what they want (for example: short nested loops lead to system crashes on many CPUs). I will also share with the participants my experience in data recovery and how CPU bugs have actually contributed in damaging our hard drives without our knowledge. “

Intel will be keeping an eye on his upcoming research :

“George Alfs, a spokesman for Intel, said he has not yet seen Kaspersky’s research, nor has he spoken to him about it. “We have evaluation teams always looking at issues. We’ll certainly take a look at this one,” said Alfs. “All chips have errata, and there could be an issue that needs to be checked. Possibly. We’d have to investigate his paper.”

BIOS based rootkits are nothing new with John Heasman’s research into Implementing and Detecting a PCI Rootkit, published in 2006. And with the possibility of malware hiding at the lowest possible level already a fact, what will be very interesting to monitor is a universal remote code execution based on chip’s manufacturer. Everything is possible, the impossible just takes a little longer.

[Source: zdnet]

Database server giant Oracle plans to ship patches for a total of 45 security vulnerabilities on Thursday (July 17), bringing the vulnerability count for 2008 to a whopping 112.

Since January 2006 (this CPU included), Oracle has shipped fixes for a total of 572 vulnerabilities.

According to a pre-release analysis, the vulnerabilities affect hundreds of products, including all supported Oracle Database, Oracle Application Server, and Oracle E-Business Suite versions.

This is the first Critical Patch Update that includes fixes for BEA WebLogic, Hyperion BI, and TimesTen Database.

In this patch batch, Oracle will provide patches for 11 Oracle Database vulnerabilities. According to Integrigy CTO Stephen Kost, some of the database flaws can be exploited using only PUBLIC privileges accessible by all database accounts.

The July CPU will also cover 9 new Oracle Application Server vulnerabilities, all of which are remotely exploitable without authentication. For the Oracle E-Business Suite 11i and R12 products, there are 6 new vulnerabilities, some of which can be readily exploited by an unprivileged user.

Kost recommends that this quarter’s security patches should be deemed critical.

[Source: zdnet]