Microsoft has released its monthly security bulletin for November 2008 to address two vulnerabilities in Windows, one of them is critical. We strongly suggest applying the patches provided by Microsoft for these vulnerabilities.

Following is a summary of the security updates released by Microsoft:

Critical

Vulnerabilities in Microsoft XML Core Services Could Allow Remote Code Execution
This security update resolves several vulnerabilities in Microsoft XML Core Services. The most severe vulnerability could allow remote code execution if a user viewed a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Microsoft has already addressed this vulnerability with a patch. The patch and additional information are available here.

Important 

Vulnerability in SMB Could Allow Remote Code Execution
This security update resolves a publicly disclosed vulnerability in Microsoft Server Message Block (SMB) Protocol. The vulnerability could allow remote code execution on affected systems. An attacker who successfully exploited this vulnerability could install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Microsoft has already addressed this vulnerability with a patch. The patch and additional information are available here.

Despite being reported as “out of business” in late July/August, (see this blog, and this article as well), Neosploit, one of the most widely used tools by cybercriminals, clearly hasn't ceased to exist . In fact, we have recently confirmed a highly enhanced Neosploit 3.1 installation to be out and about, and serving Malweb to hundreds of legitimate Web sites worldwide. We are currently working with law enforcement from around the globe to identify infections and inform organizations.

It’s clear that Neospolit actually planned to create Neosploit 3.1 and has actually made it available for at least the last few weeks on a significant scale. It’s clear that Neospolit actually planned to create Neosploit 3.1 and has actually made it available for at least the last few weeks on a significant scale.

Another interesting thing to note here is that the recent increase in PDF exploits can hardly be attributed to some new toolkit or older kits attempting to capitalize on the toolkit market, but actually the work of this new 3.1 version. See statistics from an active neosploit attack server below:

What does all this mean? It’s a truly notable instance where the actual business side of running cybercrime operations pulled a fast one on the thousands of experts tasked with following the latest Web threats. They not only see the profitability of investing in development of newer versions – releasing cybercrime tools much like that of a typical software company. And it’s all proven by their greatly enhanced version of Neosploit 3.1 that was never anticipated by even the largest of security vendors. Instead, security vendors thought newly enhanced PDF exploits (actually a large part of Neosploit’s punch) was actually a new trend within itself – when actually it’s direct from Neosploit.

I would keep an eye on developments in the eCrime business market, for the rock-star of the Malweb toolkits to just disappear one day and declare retirement – does not really fit in to what is really happening in the business. Although the attempt to go under the radar has been greatly aided by reports of security researchers that the group has disbanded, it was hard to believe that they really went under with such a successful brand name and business behind it.

I’ll be covering some of the developments in Neosploit 3.1 at the upcoming BlueHat conference at Redmond next month, so if you are fortunate enough to get there – look for the opening talk.

As websites are getting to be treated more like applications, users, both end-users and especially business ones, are moving from traditional old-school desktop applications (remember when “client-server” architecture was the thing?) to Software as a Service (SaaS), in-the-cloud, and just plain web applications. Security has been shifting from securing the local operating system to securing the web channel.

This has been backed by the clear shift from email being the number one carrier of all things bad, to the web being the most prominent and efficient channel for cyber attacks. This shift – both the usability one, as well as the security one, brought in a lot of improvement in what we use to browse the internet today – our browsers. With the recent release of Firefox version 3, Google’s release of Chrome, and the upcoming Internet Explorer 8, browser makers are showing great improvements in both usability as well as security.

Nevertheless, the picture isn’t that pretty on the security front after all. Both Mozilla and Google are facing some major vulnerabilities that have been disclosed shortly after releasing the browsers. IE8 is lurking on the sidelines trying to make sure its release will go hopefully uneventful (on the security side of course).  History and reality are proving that as long as the web will keep providing such usability, we will still have to come up with more than just new versions of browsers, but with more elaborate ways to secure the web. Issues such as authorization, authentication, permissions, cross-site relationships, mashup data sharing (and these are just scraping the surface) – will have to be approached from a higher level, taking into account infrastructures, open protocols and APIs to be used across applications. Merely focusing on securing the endpoint (or now almost literally “window”) to the application is not enough, as corporations would have to deal with the actual essence of the data and applications handling it.

Don’t get me wrong – I highly appreciate the advancements that Chrome, FF3 and IE8 are making (and proud to be using all of them almost equally throughout the day), but let’s just remember not to keep living in a “whack-a-mole” security state of mind, and make sure we look at the whole picture.

 Recently I published to the Full Disclosure mailing list work regarding Alphanumeric shellcode encoding and detection.

It discusses the methods which attackers may use in order to evade intrusion detection systems, and generic detection possibilities.

To view the original post, follow this link: http://lists.grok.org.uk/pipermail/full-disclosure/2008-August/063632.html

It includes attached an Alphanumeric shellcode encoder and a decoder routine which is very difficult to detect using existing intrusion detection systems but the post discusses the generic detection possibilities of this specific encoder and others (including proof of concept detection code).

Here's a demo of the same shellcode (remote connect-back taken from metaspolit, encoded twice using the encoder.

Notice the beginning of the shellcode (the decoder routine) is different on each execution.

http://www.aladdin.com/csrt/alnum_encoding_decoding.avi 

Security researcher Dan Kaminsky had uncovered a major DNS flaw which enables hackers to easily perform cache poisoning attacks on any nameserver . Security experts worldwide hurried to patch the problem immediately.

Kaminsky says on his blog:

“Recently, a significant threat to DNS, the system that translates names you can remember (such as www.doxpara.com) to numbers the Internet can route (66.240.226.139) was discovered, that would allow malicious people to impersonate almost any website on the Internet. Software companies across the industry have quietly collaborated to simultaneously release fixes for all affected name servers.”

However, this fundamental vulnerability is in a design flaw in the DNS protocol itself, and there has been no complete patch or solution for it yet.

An attack of that nature would cause a corruption on a DNS server, so that, for example a user who types Google.com in his browser, would end up at a location of the attacker's choice. Once an attacker has managed to poison a DNS cache, there are a number of ways to take advantage of the situation.  An attacker can set up a website that looks enough like the original so as to not raise any suspicion. Then the domain is hijacked via cache poisoning for as many ISPs as possible, causing their traffic to hit the malicious website instead. Possible further attacks may be, for example, redirecting a popular search engine to a malicious domain or redirecting a bank website to gain access to user account credentials.

Zero-day attacks will definitely occur between the time security vendors release patches and DNS servers get patched. URL filtering based products will prove insufficient in dealing with this type of attacks. Generally speaking, since URL filtering products do not inspect the IP address of the domain their client visits, so a hijacked website may pass the URL filtering because of the fact that the domain is still trusted, although the IP addresses is untrusted.

However, since no solution is available in the meantime, eSafe, as a product which deeply scans web content will undoubtedly provide a reliable protection against the upcoming DNS flaw chaos. eSafe's real-time analysis and blocking of malicious web content such as malicious scripts, and HTML and HTTP exploits, regardless of their place of origin, with the ability to inspect ActiveX objects, Java applets, and encrypted SSL content would enforce comprehensive web browsing security policies immune to any potential hazards of cache poisoning attacks.