Wednesday, August 31, 2011

Google Chrome sandbox exploit


French security research group, VUPEN, announced earlier today that they have managed to subvert Google Chrome's sandbox to permit execution of code.
The announcement, which is light on details, and a demo are available on VUPEN's website. The most interesting aspect of the announcement was the declaration "This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services." Apparently this list does not include Google. Definitely an interesting twist on responsible disclosure.
“While Chrome has one of the most secure sandboxes and has always survived the Pwn2Own contest during the last three years, we have now uncovered a reliable way to execute arbitrary code on any installation of Chrome despite its sandbox, ASLR and DEP,” the advisory notes. ASLR and DEP are two of the key security defenses built into Windows Vista and Windows 7
Google spokesman Jay Nancarrow said the company was unable to verify VUPEN’s claims, because VUPEN hadn’t shared any information about their findings. “Should any modifications become necessary, users will be automatically updated to the latest version of Chrome,” Nancarrow wrote in an email to KrebsOnSecurity.
Chaouki Bekar, VUPEN’s CEO and head of research, confirmed that the company had no plans to share any details about their findings with Google, nor was it aware of any steps users could take to mitigate the threat from this attack.
“No, we did not alert Google as we only share our vulnerability research with our Government customers for defensive and offensive security,” Bekar wrote in response to an emailed request for comment. “Unfortunately, we are not aware of any mitigation to protect against these vulnerabilities.”
Jeremiah Grossman, a Web application security expert and chief technology officer for the security consultancy WhiteHat Security, called the news “quite serious.”

Sunday, August 28, 2011

Mcafee website vulerability


Cross site scripting found in Mcafee knowledge base site...
Url: https://kc.mcafee.com/corporate/index?page=content&id="; alert(1); //

Sunday, August 21, 2011

Browser update checking tool from Qualys


Exploiting the browser vulnerabilities has been a easiest among the attacks that is taking place..Latest one to get world wide attention was Com modo SSL Certificate issue. Where it is possible for a malicious individual to post a fake gmail or hotmail page with bogus SSL Certificate and trick user to trap their credentials.
Two easiest way to combat similar kind of threat is to ensure our OCSP (Online Certificate status protocol is enabled and working properly. Second one is to update the browser with the latest Certificate revocation list (CRL) which is in-turn in the hands of browser vendors to send a quick patch to update the CRL list.
Browser vendors are pretty quick in that regards to send an update, but how many of the home users be keen in updating and a good chance they might know know whether they have already updated or not. Here is the usual tool from Qualys helps individual to ensure whether their browser is the most update or gives the ability to update it..
Why do I need to install the BrowserCheck Plug-in to scan?
Plugin based scan provides more details and accurate results than using a non-plugin based scan. Please note that plugin based scan is available only for IE, Firefox and Chrome on Windows platform.
  • It shows complete location of the checked file in the details
  • It can read the complete version of the installed plugins to determine the status more accurately.
  • It can also determine security status based on the version of associated files and not just the plugin file. One such example is Foxit Reader.
  • It can also perform OS based dependent checks such as Service Pack information in determining the security status of some plugins such as Windows Media Player.
  • It can do more comprehensive checks than what is provided by the browser via javascript.
The Qualys BrowserCheck tool checks your browser as well as browser plugins and add-ons to identify insecure and out-of-date versions that put you at risk. It also checks if your Windows operating system is supported by Microsoft. Microsoft security updates cannot be installed on unsupported operating system versions. These items are detected:
Click here for online scan
Click here for more info on the tool: Qualys

Win 32 Assembly Cheat sheet

Thursday, August 11, 2011

Another XSS vulnerability


Vulnerability located in the Shop for memory, an european specialist computer online supplier shop is a possible XSS attack candidate.. Date of writing their site had this vulnerability...
Keyword: <script>alert(document.cookie)</script>
Attack URL: http://www.shop4memory.com/search/?k=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E
For those who are new to XSS, it is
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
How to get rid of Input validation errors:
(aka: sanity checking, input filtering, white listing, etc.)
Input validation is one of those things ranted about incessantly in web application security, and for good reason. If input validation was done properly and religiously throughout all web application code we’d wipe out a huge percentage of vulnerabilities, XSS and SQL Injection included. I’m also a believer that developers shouldn’t have to be experts in all the crazy attacks potentially thrown at a websites. There’s simply too much to learn and their primary job should be writing new code, not to become web application hackers. Developer should only have to concern themselves with the solutions required to mitigate any attack no matter what it might be. This is where input validation comes in play.
Input validation should be performed on any incoming data that is not heavily controlled and trusted. This includes user-supplied data (query data, post data, cookies, referers, etc.), data in YOUR database, from a third-party (web service), or elsewhere. Here are the steps that should be performed before any incoming data is used:
Normalize
URL/UTF-7/Unicode/US-ASCII/etc decode the incoming data.
Character-set checking
Ensure the data only contains characters you expect to receive. The more restrictive the rules are the better.
Length restrictions (min/max)
Ensure the data falls within a restricted minimum and maximum number of bytes. Limit the window of opportunity for an attacks as exploits tend to require lengthy input strings.
Data format
Ensure the structure of the data is consistent with what is expected. Phone should look like phone numbers, email addresses should look like email address, etc.