Potential Skype worm propagating.

12.18.2006 - 3:08 PM
Websense Security Labs has had reports of a new worm that uses Skype to propagate. We are still investigating the issue but here are the details so far: * users receive messages via Skype Chat to dow...
Read more »

2027 Security Predictions

12.15.2006 - 9:07 AM
A couple days ago we did our annual 2007 security predictions for what we believe will come in the following year, today we are releasing a "tongue and cheek" look 20 years into the future with our 2027 predictions. Enjoy ! YouTube video is also linked at the bottom of the alert. Robot BOT&rsquo;s While 2019 was the year that the total number of BOT&rsquo;s in the world outnumbered the total number of humans, 2027 will see the emergence of BOT&rsquo;s that control Robots. Using C&amp;C, home users Robots will be targeted first and will be used for energy theft and compromising genetic credentials. This will be followed by corporate attacks where Google Robots will be targeted.&nbsp; &nbsp;<...
Read more »

2007 Security Predictions

12.13.2006 - 6:54 AM
Websense Security Labs 2007 Security Predictions &nbsp; First let&rsquo;s recap our 2006 predictions from: http://www.websense.com/securitylabs/blog/blog.php?BlogID=14) &nbsp; 2006 RECAP &nbsp; Web borne worms: This definitely was an accurate prediction as we saw several high-profile web-based worms. &nbsp; RSS Malcode: We did not see what we expected in 2006 with RSS exploits. We believe this is partly due to the delay in technologies such as IE and Office, both of which will support RSS natively. &nbsp; Trojans outpace Worms: This was definitely an accurate prediction as there was minimal high-profile worms released. Trojan Horses on the other hand are being released in abundance daily. <span style...
Read more »

MOTW: HTML/JS Obfuscation Part II

12.08.2006 - 1:25 PM
A few months back, we talked about some strategies for handling obfuscated HTML and JavaScript. We covered the trivial case of decoding using a regex, and the more involved case of needing to reconstruct the JavaScript code and safely run it inside a command-line JavaScript interpreter. If you have not read this or are otherwise unfamiliar with the concepts presented here, you can reference the original blog entry: HTML/JS Obfuscation Part I Spiders vs. Monkeys The next step in the de-obfuscation process is to examine how we can safely analyze JavaScript that is difficult to handle using the previously discussed strategies. Our goal is to be able to run the script unchanged, which means that we cannot perform the cut-and-paste cleanup step outlined in Part I. There are several reasons why we might encounter this limitation: The script is too long to reformat or clean up by hand The script uses advanced obfuscation techniques. One example is using information about the context in which the de-obfuscation routine is evaluated. This context is then used as part of the decoding algorithm. If the routine is reformatted or otherwise changed, then the decoding algorithm no longer operates. Heavy use of browser-specific features, such as DOM objects, window/document state, and so forth. Once again, we will use Mozilla's SpiderMonkey JavaScript engine (http://www.mozilla.org/js/spidermonkey/) as our command-line interpreter. Hand Over the Document and Nobody Gets Hurt In order to run a potentially malicious script unchanged, we will have to supply definitions for the objects and variables that it uses to perform its function. This means that, if it uses browser-specific function calls, we have to supply a default implementation of that function that does something useful. If we control the implementation, we can also trap attempts to use the object in a malicious or deceptive way, and these trapped attempts can supply information to the researcher about the potential risk of a given script. In our example, we supply a default implementation of the function call document.write. This consists of two parts: an object state for document. implemented methods and properties inside the document object In JavaScript everything is an object. Functions are objects, so the object declaration is basically a function that contains other functions (methods) and members (properties). In the simplest case we have the following, which contains one method and one property. // declare the document class function my_document { &nbsp; // a property (initialized to string) &nbsp; this.m_property=""; &nbsp; this.write=function(string) &nbsp; { &nbsp; &nbsp; &nbsp;print("my_document::write"); &nbsp; &nbsp; &nbsp;print(string); &nbsp; } }; // declare a globally-accessible document object var document=new my_document(); This doesn't do a whole lot, yet. There are a couple of things of note that are different from common OO syntax. The body (block) of my_document is the constructor. Statements in the constructor are either property or method declarations, and can be in any order. JavaScript objects have no explicit destructor. By creating the document object before the target script runs, we therefore intercept all calls made by the script through our own object. A Series of Unfortunate Events Let's cut to the chase. Our example document, as delivered to us straight from the web page, is a giant block of obfuscated JavaScript in between a script tag. Not exactly well-formed, but browsers will load it anyway. Here is how the document starts: <...
Read more »

MOTW: Malware Collection: Passive Honeypots

12.05.2006 - 11:30 AM
This week I will be discussing one type of tool we utilize to collect malicious binaries currently active in the wild: passive ("low interaction") honeypots. Passive honeypots function by simulating vulnerable services to entice an attacker out of hiding. Should an attacker attempt to compromise the simulated service on this machine, the attack is intercepted and the malicious payload is collected. This type of honeypot differs from an active ("high interaction") honeypot in that our computer is not actually compromised. I can&rsquo;t go into too many details on the proprietary honeypots we use internally. Fortunately, the concepts used by all passive honeypots are similar and there are a number of freely-available honeypot projects that aspiring researchers have access to. Nepenthes Nepenthes ( http://nepenthes.mwcollect.org/) is one of these public honeypot projects, and one that I personally took a liking to. It allows me to quickly collect a variety of samples and determine certain patterns in known and unknown shellcode as it is sent across the network. Once installed, Nepenthes can be configured to listen on a wide range of ports. These services are not actually running on this computer; Nepenthes is simulating vulnerable services in the hope that an attacker comes along and attempts to compromise the server. More often than not, the attacker is an auto...
Read more »