<![CDATA[[SecurityRatty] tag: browsers]]> http://securityratty.com/tag/browsers Mon, 08 Sep 2008 16:18:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[New Web Malware Exploitation Kit in the Wild]]> http://securityratty.com/article/b14bf267debe94a6c65be57f5460b9a5 http://securityratty.com/article/b14bf267debe94a6c65be57f5460b9a5
Oops, they keep doing it, again and again - trying to cash-in on the biased exclusiveness of web malware exploitation kits in general, which when combined with active branding is supposed to make them rich. However, despite the low price of $300 in this particular case, this copycat kit is once again lacking any signification differentiation factors besides perhaps the 20+ exploits targeting Opera and Internet Explorer included within.

Marketed for novice users, despite lacking any key features worth being worried about, it's still managing to maintain a steady infection rate of unpatched Opera browsers. Such statistics obtained in an OSINT fashion always provide a realistic perspective on publicly known facts, like the one where millions of end users continue getting exploited due to their overall misunderstanding of today's threatscape driven by the ubiquitous web exploitation kits. 

Related posts:
Modified Zeus Crimeware Kit Gets a Performance Boost 
Zeus Crimeware Kit Gets a Carding Layout
Web Based Malware Emphasizes on Anti-Debugging Features
Copycat Web Malware Exploitation Kit Comes with Disclaimer
Web Based Malware Eradicates Rootkits and Competing Malware
Two Copycat Web Malware Exploitation Kits in the Wild
Copycat Web Malware Exploitation Kits are Faddish
Web Based Botnet Command and Control Kit 2.0
BlackEnergy DDoS Bot Web Based
A New DDoS Malware Kit in the Wild
The Small Pack Web Malware Exploitation Kit
The Nuclear Grabber Kit
The Apophis Kit
Nuclear Malware Kit
The Random JS Malware Exploitation Kit
Metaphisher Malware Kit Spotted in the Wild
]]> Wed, 19 Nov 2008 01:15:01 +0000 malware malware exploitation kit web based malware nuclear malware kit ddos malware kit zeus crimeware kit wild key features worth metaphisher malware kit New Web Malware Exploitation Kit in the Wild <![CDATA[Adobe Redirects Surfers To Malware Installing Malicious Sites]]> http://securityratty.com/article/487ff9b3f59a6b59f933a7dd6df9aa1f http://securityratty.com/article/487ff9b3f59a6b59f933a7dd6df9aa1f Thu, 16 Oct 2008 18:05:45 +0000 instructs users browsers install malware vulnerable machines silently install web page redirects adobe fixed visitors Adobe Redirects Surfers To Malware Installing Malicious Sites <![CDATA[Researchers reveal 'clickjacking' attack info]]> http://securityratty.com/article/bf140c79511e5c50afca2687e037f697 http://securityratty.com/article/bf140c79511e5c50afca2687e037f697 Wed, 08 Oct 2008 20:00:00 +0000 weeks ago web sites popular plug-ins bug tuesday security researchers variants vulnerabilities browsers Researchers reveal 'clickjacking' attack info <![CDATA[Researchers reveal 'clickjacking' attack info]]> http://securityratty.com/article/d51afa16b8839bcc2324b12c3bf873ef http://securityratty.com/article/d51afa16b8839bcc2324b12c3bf873ef Add to digg Add to StumbleUpon Add to Twitter Add to Slashdot
]]> Wed, 08 Oct 2008 00:00:00 +0000 weeks ago flaws browser plug-ins jeremiah grossman security researchers web browsers details robert Researchers reveal 'clickjacking' attack info <![CDATA[New Cross-Site Request Forgery Attacks]]> http://securityratty.com/article/97352e193bff92587f51944a500f9de1 http://securityratty.com/article/97352e193bff92587f51944a500f9de1 Interesting:

CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.

If a user visits an attacker's website, the attacker can force the user's browser to send a request to a page that performs a sensitive action on behalf of the user. The target website sees a request coming from an authenticated user and happily performs some action, whether it was invoked by the user or not. CSRF attacks have been confused with Cross-Site Scripting (XSS) attacks, but they are very different. A site completely protected from XSS is still vulnerable to CSRF attacks if no protections are taken.

Paper here.

]]> Mon, 06 Oct 2008 01:42:04 +0000 attacks user cross-site site user visits csrf attacks sensitive action action site completely New Cross-Site Request Forgery Attacks <![CDATA[New clickjacking affects all browsers; cause remains unknown]]> http://securityratty.com/article/4ac9fabb0e40c13e46c0f49a1546b8b0 http://securityratty.com/article/4ac9fabb0e40c13e46c0f49a1546b8b0 Sat, 27 Sep 2008 00:30:02 +0000 tonightthe boogeyman presentation exploit researchers slim details newly moment walk New clickjacking affects all browsers; cause remains unknown <![CDATA[New clickjacking affects all browsers; cause remains unknown]]> http://securityratty.com/article/31975e2aa5e77f4c853b2e42224b9b75 http://securityratty.com/article/31975e2aa5e77f4c853b2e42224b9b75 ]]> Sat, 27 Sep 2008 00:30:02 +0000 tonightthe boogeyman presentation exploit researchers slim details newly moment walk New clickjacking affects all browsers; cause remains unknown <![CDATA[Computer users overeager to click popup 'OKs']]> http://securityratty.com/article/3141fe93bb0accb02791c7888b187442 http://securityratty.com/article/3141fe93bb0accb02791c7888b187442 Wed, 24 Sep 2008 20:00:00 +0000 error messages click web surfers standard reaction web browsers week research hope disappear Computer users overeager to click popup 'OKs' <![CDATA[Adult Network of 1448 Domains Compromised]]> http://securityratty.com/article/b59ef363ba68bebcc5fe86d449081e0c http://securityratty.com/article/b59ef363ba68bebcc5fe86d449081e0c
With millions of malware infected PCs participating in a botnet, the probability that a high profile end user whose domain portfolio consisting of over 1,400 high trafficked adult web sites, would end up having his accounting data stolen, is gradually increasing.

That seems to be the case with the CPanel of the Bang Bros network of adult web sites, the accounting data for which was obtained through a botnet in which the administrator seems to have been unknowingly participating in. None of the sites have been embedded with malware so far, however, taking into consideration the high traffic this adult network attracts as well as the fact that he person managing the domains portfolio is part of a botnet, that may change pretty fast.

A single malware infection always triggers the entire malicious effect, from the malware automatically SQL injection vulnerable sites, and providing infrastructure for scams and fraudulent activities, to allowing the botnet master to parse the huge log of stolen accounting data and look for Cpanels and anything allowing him to efficiently compromise a network of sites he wouldn't have been able to compromise if it wasn't the "weakest link" centralizing the entire portfolio in a single location.

And whereas for the time being, propositions for selling compromised CPanel accounts are mostly random, in the long term, fueled by the demand for compromised domains, we may witness the emergence of yet another market segment in the underground economy, with price ranges based on the pagerank of the domain in question, the type of browsers and the traffic sources visiting it. Until then, SQL injections through search engines reconnaissance executed through a botnet, will remain the efficient tactic of choice for abusing legitimate domains as redirectors to malicious ones.
]]> Mon, 15 Sep 2008 03:54:19 +0000 network adult web sites sites domains bang bros network malware botnet master botnet single malware infection Adult Network of 1448 Domains Compromised <![CDATA[SDL and the XSS Filter, Revisited]]> http://securityratty.com/article/716886a1157dce9a26be34d638f2a814 http://securityratty.com/article/716886a1157dce9a26be34d638f2a814 Bryan here. Since Steve called me out in his post on the XSS Filter last week, I feel obligated to clarify my position. ☺ I believe that the SDL blog is mainly for development teams; after all, development is the D in SDL. Now, development teams are made up of more than just developers. Development teams include everyone involved in the development process from management on down. But development teams don’t include end users. While XSS Filter is a great, innovative XSS defense technology, there’s really nothing that development teams can do to take advantage of it. Users alone make the decision as to whether they’re going to take advantage of XSS Filter: they either use IE8 and get it, or they use another browser and don’t get it.

 

That being said, there are some interesting implications that XSS Filter and other user-specified defenses have for the SDL. Given that XSS Filter is effective in stopping many types of reflected XSS attacks, should we relax the SDL coding and testing requirements around server-side XSS defense? Of course not. For one reason, the SDL requirements are effective in preventing forms of XSS that XSS Filter does not address, like persistent XSS. For another, not everyone uses IE 8. If we were to relax server-side requirements now, we would jeopardize IE 7 users, as well as Firefox, Safari, Opera, Chrome, and all the other browsers’ users.

 

But what if these conditions change? What if David and others on the security science team develop a new version of XSS Filter that’s effective against all forms of XSS? And what if all the browser manufacturers develop similar technology and implement it in their browsers? (Or alternatively, what if every user on the planet switches to IE 8? ☺) Then would we relax the server-side XSS defense requirements? Yes, we probably would.

 

I’ve always been more of a security pragmatist than a security purist. While the security purist in me would want to keep the requirements around to prevent developers from falling back into bad habits, the security pragmatist in me would recognize that development teams have a limited amount of bandwidth, and making them defend against rare, obscure vulnerabilities is a poor use of their time. Unfortunately, we’re not likely to face this scenario any time in the near future, so the SDL will continue to require server-side input validation and output encoding to prevent XSS attacks.

 

We now return you to your regularly scheduled development-focused blog.

]]> Mon, 08 Sep 2008 16:18:00 +0000 xss xss filter persistent xss server-side xss defense development teams include development teams development sdl sdl requirements SDL and the XSS Filter, Revisited