In this discussion, we are simply walking through the nature of JavaScript obfuscation and camouflaging in order to understand the
importance of dense code.Views By:- RB and AKSJavaScript is a widely used language for developing application and websites on internet. JavaScript is used for positive as well as for nefarious purposes. Since it is a client side scripting language, most of the time the scripts are available for walking through them to understand the purpose. However, JavaScript obfuscation is used heavily for making JavaScript readability a hard process and at the same time beating automated detection tools. Overall, the purpose of JavaScript obfuscation is to hide the source code so that it is not possible to steal it. At the same time, this technique is also used for malicious purposes by the attacker to bypass antivirus engines in order to execute rogue code successfully. These are the two main reasons for the wide usage of JavaScript obfuscation.
Exploit Placement and Detection:Most of the Browser Exploit Packs (BEP's) use browser JavaScript rendering engine and heap spraying techniques to exploit vulnerabilities in browser. The aim is to exploit the heaps using JavaScript capabilities. Another thing that should be taken into account is the way exploit is developed and the way it is supported by JavaScript obfuscation. Consider an exploit; if it is wrapped and placed in [HTML] and [Body] tags, the antivirus engine definitely detects it. Is there a difference between handling scripts and executables by antivirus engines? Based on our analysis, antivirus engines follow a similar approach which is signature based pattern matching. A unique signature is created for antivirus engine and it is matched against the malicious script. If we talk about polymorphic code which carries self decrypting routine to reverse the script automatically, detection is not an easy process. However, for normal scripts the detection mechanism is easy. Considering the capabilities of JavaScript, being a client side language , it can be forced to execute scrambled code.
Camouflaging - Dense CodeCamouflaging (increasing data density) is a very robust approach of making JavaScript’s undetectable. The critical functions such as
EVAL/ENESCAPE are something that antivirus engines always look for. Primarily,
UNESCAPE is used for making a readable string out of escaped data. The unescaped string is harder to read from user perspective but antivirus engines possibly detect this and flag it as malicious. Another similar functions is
EVAL, which is used collectively with UNESCAPE to design malicious scripts. For generic JavaScript obfuscation these are used but it is executed as
EVAL(UNESCAPE(............)) in the code and combination is easily fetched as malicious. The question is these functions are required explicitly to run the code in hidden manner. Camouflaging is an art that is used by referencing these functions to different names or completely random names. A generic example is
as follows
var FGHTY678 = eval;
var VFGBH432 = unescape;These variables can be generated dynamically because JavaScript supports on the fly variable referencing. For hard scenarios, a robust algorithm can be structured which provides random naming of variables that points to crucial functions. We will stick to our generic examples. At this point if we use the code as follows it is still not that hard to detect by antivirus engines
var VFGBH432 = unescape;
return FGHTY678(VFGBH432(....))It performs the similar functionality except we can make variable names random. This process changes the signature and it makes the process tough for antivirus engines to detect it (cannot say purely undetectable). Another case which is easily detectable is as follows
function FGHTY678(FGATH789) { return eval(FGATH789);}
function VFGBH432(XCVTH789) { return unescape(XCVTH789);}Only variable names are changed but function calls remain intact and hence signature detection is easy. The above discussed points do not provide reliable way of obfuscation. One must remember that even if we have camouflaged the function calls, the escaped code is still present as argument in the
UNESCAPE function. It is readable by the antivirus engines. Overall, the code is not fully camouflaged and obfuscated. Now let's talk about hexadecimal encoding (you can choose anyone). The question is, "How the hexadecimal encoding impacts the obfuscation?". For example: if we encode the following string "JavaScript Obfuscation", the hexadecimal looks like as
"4a617661536372697074204f62667573636174696f6e"Even though for humans, it is hard to read but for computer programs it is not a big deal. Can we use JavaScript to make it more obfuscated? Yes, there are certain inbuilt string manipulation functions that we can try on. JavaScript functionality can be used to design extensible and robust codes. Mere simple encoding does not hide the signatures. JavaScript functions like
REPLACE is of much use. This function is used heavily in normal purposes because of its versatile nature. for example: a relative code can be structured as
var GHJKO786 = eval;
var KJLHM890 = unescape;
var FGHBN345 = "JavaScript-Obfuscation1JavaScript-Obfuscation2JavaScript-Obfuscation3JavaScript-Obfuscation4JavaScript-Obfuscation5JavaScript-Obfuscation6JavaScript-Obfuscation7";
KJLHM890.replace(/JavaScript-Obfuscation/gi,"!@#$%^&*");
GHJKO786(KJLHM890(FGHBN345));The above stated code looks rigorous but it is using inbuilt JavaScript functions.
"JavaScript-Obfuscation" is replaced with a metacharacter string
"!@#$%^&*". The
"gi" option in REPLACE function is used to replace the string case sensitive and it is applied as global level. Further, it is also possible to use
MATH.ROUND and
MATH.RANDOM functions to randomize the custom function names.
Garbage Data ManglingGarbage data serves useful with extra logic is used to place raw data in JavaScript code. The main idea behind this technique is to make the process harder for filtering actual data. Generally, it is of no use and it is not vital. This helps in resisting the signature matching process. We basically talk about logic flow in which certain logic remain true forever and scripts are placed inside that logic which execute all the time. A similar example can be used as follows
var GHJKO786 = eval;
var KJLHM890 = unescape;
if (VBNHJ789 != "7890")
{
FGHBN345 = "JavaScript-Obfuscation1JavaScript-Obfuscation2JavaScript-Obfuscation3JavaScript-Obfuscation4JavaScript-Obfuscation5JavaScript-Obfuscation6JavaScript-Obfuscation7";
}
var KJLHM890.replace(/JavaScript-Obfuscation/gi,"!@#$%^&*");
GHJKO786(KJLHM890(FGHBN345));In reality, the logic
(VBNHJ789 != "7890") is never true and hence FGHBN345 string is always true and viceversa. another example can be discussed as
function RTGHY123
{
var FGHYU009 = "Rocky";
for (temp =1 ; temp <= 20 ; temp++)
{
FJKLM765 = document.write;
}
if(FGHYU009 == 5678)
{
FJKLM765("HEYA");
}
}The function RTGHY123 is a garbage function and does nothing but results in creating mess for the analysts and anybody.
At last, there are several other methods possible for obfuscation. Our sole purpose is to discuss the effectiveness of density in encoding mechanism in JavaScript that can be used to design better obfuscator.
Nothing is impossible until it is proclaimed so.
We have recently encountered a heavy set of email traffic spreading HP scanning email with non legitimate links. No doubt, this campaign is a traffic infection process by sending plethora of emails around the internet. It is not a big deal of getting email addresses nowadays. It is just a walk-around in the park for the phishers or attackers. This HP scanning email looks like as presented below
The world has changed dramatically with the evolution of malware. A similar set of vulnerabilities ( web attacks specific) such as SQL injection can be used to compromise the malware driven server. Some time ago, we talked about Blind SQL Injection in SpyEye Version 1.0 in which we presented about the vulnerability in the SpyEye code. Since then we dint get the time to present it as a complete case study. In this post, we are going to talk about the step by step approach to compromise the SpyEye database server. One can do lot of different attacks such as Local File Inclusion (LFI) there by reading the configuration credentials. However, we are sticking to the SQL injection to show how well we can inject and take control of malware server.
Well, malware has many facets and there is no doubt in that. In this post, we are going to raise a point about the SpyEye RDP back-connect plugin and its working. During out talk at Hack In The Box (HITB) - AMS, we presented about the details of SpyEye botnet and its ability to work with modular plugins. The RDP plugin in SpyEye works on the same benchmarks as FTP and SOCKS. 
We are in the process of analyzing the enormous set of web injects log and real client side code. During analysis, we found that third generation botnets (Zeus and SpyEye) use an explicit technique of injecting rogue content in the web pages of bank websites. The content is injected as inline but the plugins that are used to complete this process follows a certain set of parameters and procedure. In this post, we are going to talk about the metrics that are used to perform web injects successfully. The plugin communicates with installed bot on client side and a specific steps are followed as a part of hierarchical infection in order to trick the browser.
All third generation botnets have specific functionality of grabbing content in the forms present in the web pages. Bots take control of victim machines and use the concept of key-logging to steal data. It depends a lot on the browser architecture and design; how effective the form grabbing technique is applied. This is because malware needs to have full control of the sockets interface and the dependent modules on it. For example:- Internet Explorer uses WININET.dll and Mozilla uses NSPR4.dll. For these browsers, well designed form grabbing key-loggers have been seen in the wild. Zeus and SpyEye bots have inherited functionality that supports form grabbing in IE and Firefox. However, very less infections have been noticed in Google Chrome considering this functionality. This is because Google Chrome architecture is different from other browsers and the low level HTTP request/response handling is done in a bit different way. The question is the possibility of hooking Google Chrome socket interfaces in order to take control of the data that in POST and GET requests mainly. For security reasons, critical data is sent using POST in forms. That's a generic fact.
In this paper, we propose a taxonomy of browser malware.We classify browser add-ons, emphasizing their privileges. Since privileges impact the capability of malware, we use the resulting classification as a basis for our taxonomy. We hope that this taxonomy will provide better insight into the techniques and tactics used by browser malware, and assist in the development of defences.
Since the origin of browser exploit packs, we have noticed a serious change in the effectiveness of exploitation ratio due to origin of critical vulnerabilities. However, we have noticed and observed recently about the explicit use of Java vulnerabilities by Browser Exploit Packs (BEP's). Java has become the most prominent exploitation vector now a days. BEP's such as BlackHole and Phoenix are using Java exploits explicitly for triggering infections. Consequentially, the highest infection rate is an outcome of these Java exploits. 
Web anti virus engines are used explicitly to perform behavioral analysis on the active malware. Is it possible for us to run some controlled binary in order to trace all the information of cloud infrastructure of virtual machines that collaboratively perform analysis of malicious executables? We have proved that in the past it is possible to hijack (information extraction) from the hidden servers in the cloud used for malware analysis. 
In our last post about TDL rootkit, we discussed about the some of the generic features of TDL rootkit. As we know, all of the rootkits somewhat use DLL Hijacking technique. Same is true with TDL rootkit too. DLLInject function is presented below. 
With the advent of new and sophisticated malware, the modes of infection has become more efficient from previous times. The spreading of web malware takes place through web vulnerabilities which further impacts the browser interface to drop malware. Reflective XSS vulnerabilities are exploited heavily to spread malware. In last year OWASP AppSec USA conference, we presented SQLXSSI technique which has become the preferred choice of attackers to infect databases with malicious iframes and payloads. 
In this discussion, we are simply walking through the nature of JavaScript obfuscation and camouflaging in order to understand the importance of dense code.
