This will prove to be interesting as it's directly related with a previous discussion on hijacking or shutting down someone else's botnet through exploiting vulnerabilities in their code :
"During each day of the Month of Bug Bugs McAfee Avert Labs will provide analysis of flawed malicious code (aka bugs). These are viruses that don’t spread, password stealing Trojans that can’t leave the stable, drive-by attacks that crash and burn, phishing attacks that phlop, denial of service attacks that are denied, etc. Our analysis will highlight the errors made by authors, and show how these threats can be fixed and in most cases optimized for maximum potency."
Have you ever imagined that as a pen tester or security consultant you'll have to exploit XSS vulnerabilities in a botnet's web C&C in order to take a peek inside? Botnet polymorphism in order for the botnet to limit the possibility of establishing a communication pattern -- an easily detectable one -- is just as important as is the constant diversification towards different communication platforms. Despite that malware authors are consistently creative, and efficiently excelling at being a step ahead of the security measures in place, they're anything but outstanding programmers, or at least don't put as much efforts into Q&A as they could. Aren't malware coders logically interested in benchmarking and optimizing their "releases", do they have the test bed in terms of a virtual playground to evaluate the effectiveness of their code, or are they actually enjoying a "release it and improve it on the fly" mentality? It's all a question of who the coders are, and how serious are their intentions.
In a very well structured paper courtesy of Symantec, the author John Canavan looks are various bugs in popular malware such as the Morris worm, Sobig, Nyxem, OSx.Leap, as well as Code Red Worm, W32.Lovgate.A@mm, W32.Logitall.A@mm, VBS.SST@mm, VBS.Pet_Tick.N, W32.Beagle.BH@mm, W32.Mytob.MK@mm. Rather interesting fact about the much hyped Nyxem :
"However something that was overlooked in a lot of reports at the time was this bug in the code, which meant that the worm would not overwrite files on the first available drive found. For example if the first available drive is the C drive, the worm will overwrite files in available drives from D to Z."
Looking forward to seeing the bugs due to be highlighted in the MoBB.
No comments:
Post a Comment