Soon to be expected...

Hi folks,

We're working very hard on new stuff and security research, so very soon DefenseCode will release some interesting stuff... Like...

- Cisco Linksys remote preauth 0day root exploit
- Vulnerabilities in software from NASA
- Free Internet tricks....
- ThunderScan Source Code Security Analysis software for Android apps
- Web Security Scanner
- BlackTitan Internet Security with advanced JavaScript Malware analysis engine

Stay tuned.. :)

Regards,
DefenseCode

Vulnerabilities in WP E-Commerce plugin for WordPress

DefenseCode released Security Advisory DC-2012-11-001 to address an issue that affects Wordpress WP E-Commerce Plugin, one which has more than 2 million downloads and is one of the most popular for WordPress. Advisory covered multiple vulnerabilities that were discovered during the security audit of the mentioned plugin. All vulnerabilities were discovered using DefenseCode's ThunderScan PHP, web application source code security analyzer. Bugs found by ThunderScan are High risk SQL injections and Cross Site Scripting which attacker can use to compromise the targeted system. DefenseCode has contacted the vendor and the vulnerabilities are fixed in the latest WP e-Commerce release (3.8.9.1).

You can find more details about the advisory here.

Soon, we’ll release a lot more vulnerabilities discovered by our ThunderScan software. Also, we’ll release a few interesting 0day vulnerabilities not related to web applications, so make sure that you’re subscribed to our RSS feed.

Regards,
DefenseCode

Announcement: DefenseCode ThunderScan v1.1 - Web Application Source Code Security Analysis

We are proud to present you a new product for comprehensive Web Application Security Scanning.
DefenseCode ThunderScan v1.1 for Web Application Source Code Security Analysis is available now.

Demo run against Mutillidae v1.3 can be seen here:
http://www.youtube.com/watch?v=dcml2stPYNM&hd=1

DefenseCode ThunderScan products are designed for comprehensive security assessment of web application source code in
order to discover critical security vulnerabilities that hackers could exploit to compromise web application security.

More information about the product is available here:
http://www.defensecode.com/subcategory/thunderscan-8

ThunderScan v1.1 supported languages:
- ASP.Net C#
- PHP
- Java/JSP
- VB.Net
- Classic ASP

Thunderscan v1.1 will scan web applications for a wide range of security vulnerabilities like:
- SQL Injection
- File Disclosure
- Page Inclusion
- Code Injection
- Shell Command Execution
- Cross Site Scripting
- File Manipulation
- Arbitrary File Upload
- Dangerous Configuration Settings
- Arbitrary Server Connection
- XPATH Injection
- LDAP Injection
- HTTP Response Splitting
- Information Leak
- Mail Relay
- Misc. Dangerous Functions
- Dangerous File Extensions
- And more


ThunderScan v1.1 New Features:
- Tainted input flow track interactive analysis
- Automated discovery of custom input functions
- Improved custom functions analysis
- Improved filter detection
- Custom filtering functions detection
- Improved large multiline code handling
- Improved input tracking across multiple functions
- Fixed bug in XML reporting
- Improved Java and C# class detection
- Improved Java and C# class analysis
- Advanced PHP static inclusion algorithm
- Improved PHP PEAR tracking functions base
- Added Java JSON-RPC support

We are continuously working on improving our products and keeping them up to date
so you can be sure that all the latest threats get detected.

Kind Regards
--
DefenseCode Team
ThunderScan - Scan your Web Application For Security Vulnerabilities
http://www.defensecode.com/subcategory/thunderscan-8

Diving into recent 0day Javascript obfuscations

Introduction

One of the most common ways for an attacker to infect system over the Internet is using Javascript. Typical Web exploitation frameworks like Blackhole utilize polimorphic Javascript as a personalized payloads for every victim. By employing various obfuscations they are able to evade static signatures and reduce anti-virus detection rates.

In this post we will analyze one of such Javascript obfuscators called Dadong's JSXX that was used to obfuscate the payload of a recent Java 0day (CVE-2012-4681) exploit that was found in the wild and has since been patched by Oracle and it is recommended that you apply the security patch to ensure maximum protection.
DefenseCode BlackTitan Internet Security customers are protected from described exploit with BlackTitan malware signatures BTSIG9612, BTSIG9613 and BTSIG9615.

Analysis of Dadong JSXX obfuscated payload

Let's first take a look at the fully obfuscated JavaScript code that is generated by the attacker. The following code is generated by the attacker for each visit of the web page serving the exploit which is then responsible for exploiting Java vulnerability and installing malicious software:

First thing we can notice is that this code was not designed to be easy to understand and analyze. In fact it is designed to thwart static analysis and automated deobfuscation tools so that it can stay undetected longer.

While looking at the obfuscated code several things become obvious:

• Code alignment and flow structure is not preserved
• Original variable and function names are replaced by random strings
• Various additional obfuscations introduced to additionally deter analysis

To get a better understanding of the code we will tackle all of the mentioned observations in a attempt to fully understand it.

Recovering code alignment and flow structure

Most development editors and environments have basic code prettify functionality that will allow you to format code into a more readable structure. Malzilla is described as a "malware hunting tool" and has ability to format obfuscated javascript code into a much nicer layout. Some manual formatting or regex replacements may be necessary to do some final touches on the formatted code until we are fully satisfied with the results. After we are satisfied with the code layout we can proceed to the next step.

Recovering function and variable names

While analyzing the code we uncover semantics of functions and variables and should rename them as we advance trough the code. Every new renamed variable/function will speed up further analysis and reduce the time to cover all the code. Names should be concise and have clear meaning associated with them so all subsequent encounters of that variable/function are quickly recognized and can be skipped.

Following is an example of code before and after renaming process.

Obfuscated code:

Renamed code:

Common JavaScript obfuscations

After code has been properly formatted we can see additional obfuscations introduced to the code. Let's now examine common JavaScript obfuscations on this sample.

Hiding use of eval()

One of the most commonly used JavaScript obfuscations is using eval() function to run code stored as a string in a variable. This obfuscator is no different and uses several different eval() obfuscations.

To hide uses of eval() the code will assign function to various randomly named variables in an attempt to disguise eval usage. The following code snippet shows several steps used to hide eval() from static analysis.

This technique of hiding functions is not reserved just for eval() but it is typically used to obfuscate usage of all functions that could be used to statically identify malicious code.

Slightly more advanced example of assigning eval to a variable is use using string transformations to build eval string. One such example is inserting junk characters in between eval letters and then removing them dynamically with regular expressions. With this simple rule it is possible to generate polymorphic eval assignments.

Previous expression will remove all characters from the string except those listed in the regular expression, which is equivalent to the following:

eval2=eval('eval');

Opaque predicates

Opaque predicate is defined as an expression for which outcome is predetermined to be always true or false. Most simple example of this is expression if( true ). Malware authors use opaque predicates to thwart static analysis tools by constructing expressions that are not so simple to determine without evaluating them inside the targeted environment. Dadong JSXX uses mathematical functions to build opaque predicates which are then used as arguments in loops. Let's examine one of the expressions used as opaque predicate:

We can divide the expression into groups and evaluate each of the logical expressions:

Inserting the results into original expression we have:

~(0 | ( 1 | 0 & 0)) = ~( 0 | 1 ) = ~1 = 0

So the previous complicated expression will always evaluate to 0 and can effectively be rewritten as:

fExpression_eq0 = 0;

Chaining multiple opaque predicates in different variables makes it harder to statically determine what actually is an opaque predicate and what is a non-reducible expression.

Self-referencing decryption

One very interesting method against code formatting is using self referencing decryption. Let's examine the following code snippet:

Rewritten for easier understanding:

aCodeAsString, originally named sBtEp6, is referencing itself inside the string that is evaluated so any modification or formatting of the aCodeAsString will result in unsuccessful decryption of the final payload effectively preventing any modifications to the code.

Encrypted code

All the previous obfuscations serve to make the static decryption of the final malicious payload hard. Variable vlWWlBt3 from the original obfuscated snippet contains hex encoded encrypted JavaScript code. As the decryption algorithm has to be contained in the script previous obfuscations make sure that detection and analysis of the algorithms are complicated. Encryption algorithms is XOR based where the decryption key is generated from the self-referencing string so it implement simple type of tamper-proof protection. Decrypted code is then simply evaluated by eval() and executed inside the browser.

Final functionality contains the malicious payload that will launch the Java exploit and install malware on the compromised system.

Summary

JavaScript language with it's loose syntax offers variety of ways for the attackers to generate polymorphic wrappers for the malicious payload which effectively hinders traditional anti-malware signatures. By understanding techniques employed by the malware authors we can provide the best protection to our customers with BlackTitan Internet Security.

Cross-Site Request Forgery against applications that use JSON RPC

Cross-site request forgery is common and well known web application vulnerability. Most of the time exploiting these vulnerabilities is relatively straightforward. You just need to set up a proper HTML form or even use a simple URL. Sometimes, however, things can get a little more complicated. One such example is when the targeted application is using JSON-RPC.

JSON-RPC is a simple mechanism for issuing a remote procedure call using JSON notation and HTTP. When issuing a JSON-RPC request browser will send a POST request to some URL and the body of the request will be a JSON encoded data, like this:

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}

More on JSON-RPC can be found here

Now, the problem is how do you create a CSRF attack against an application that is expecting these kinds of POST requests. Using Ajax (XMLHttpRequest) will not help you since the browser will check for permission to do a cross-domain request (using OPTIONS request).

We at DefenseCode would like to share a little trick that we use in our penetration tests. You can use this trick to construct an HTML form that will force the browser to submit a proper JSON RPC request to the target application.

Problem with HTML forms is that input elements need to have a name, without a name, browser will not send the data even if you specify value of the element. To get around this you can set only the name of the input element without a value. For example:

<input name="test_name" />

Browser will send "test_name=" (without the quotes) to the server. Now, if you could set the name of the element to the body of the JSON-RPC request browser will send it. Since the body of the JSON request contains special characters you should put it inside an HTML using single quotes or you can use a little JavaScript, like this:


function modifyForm() {
    document.forms[0].elements[0].name = "{\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42, 23], \"id\": 1}"; return true;
}
<form name="csrf_form" method="POST" action="https://example.com/rpchandler" onsubmit="modifyForm();">
    <input name="test" />
    <input type="submit" />
</form>


This form will cause the browser to send the JSON-RPC data in the body of the POST request to our target URL (with an equal sign on the end). Only one little problem remains. By default browser will urlencode the body and this will break the JSON-RPC parser. To get around that we can use the enctype="text/plain" attribute in the form. text/plain will cause the browser to skip urlencoding. It will only turn spaces into + signs, but luckily we don’t need spaces in JSON :) So, our form for attacking a JSON RPC web application will look like this:


function modifyForm() {
    document.forms[0].elements[0].name = "{\"jsonrpc\":\"2.0\",\"method\":\"subtract\",\"params\":[42,23],\"id\":1}";
    return true;
}
<form name="csrf_form" method="POST" action="https://example.com/rpchandler" enctype="text/plain" onsubmit="modifyForm();">
    <input name="test" />
    <input type="submit" />
</form>

DefenseCode @ FSEC - FOI Security Symposium 2012

FSEC, Security Symposium (http://fsec.foi.hr) held at Varazdin's FOI was the only proper information security event held this year in Croatia where IT security specialists could gather and discuss the latest trends in information security.

DefenseCode experts attended the symposium to present and share their findings and expertise on topics connected to information security.

The first keynote was given by American cryptographer and computer security specialist Bruce Schneier. DefenseCode's CEO Leon Juranic held a presentation concerning security product development. Delivering from his own firsthand experience in security software development, Juranic covered the development process and its different phases in IT security context concentrating on crucial details that may make or break the project.

Leon also covered more technical aspects of security software development and presented new DefenseCode products including the ThunderScan source code analyzer and the DefenseCode Web Scanner intended for blackbox security audits.

You can download the presentation at the following link:

http://www.defensecode.com/public/DefenseCode_Security_Products_Development_Presentation.pdf

A short insight into ADSL security

Recently, one of our security researchers has been working on a project related to ADSL security.
During his research with various ADSL routers, cameras, and other devices, he also created a simple program that will perform brief on-line test of ADSL device security.

Program (in fact, a script) will try to connect to your ADSL modem and perform two security checks:
1. It will try to determine if remote administration interface is enabled
2. It will also try to login with default password

If these two checks return positive results it means that your ADSL modem is not properly configured, and it is wide-open to hacking attacks.

Check how secure is your ADSL router...
Script is available here:
http://www.defensecode.com/cgi-bin/adsl-security-check.cgi

Regards,
Leon Juranic
CEO

Welcome!!!

Dear visitor, hello and welcome to our blog :)

DefenseCode is an IT start-up focusing on information security. Our goal is to develop products to
automatize detection of vulnerabilities in web application code and to provide information security
services to a wide variety of internet businesses.

We are a relatively young company made up of seasoned IT/information security professionals
interested in anything and everything even remotely related to information security.

This is why we started this blog. Here we will analyze, comment and share developments from all
branches of information security business. We're going to write about computer security, security
research, web application security, penetration testing and broader general topics.

To begin with, web application security is widely underappreciated aspect of information security.
Where companies spend millions of dollars securing their information infrastructure from malicious
programs, spending lots of money and man power perfecting their firewalls, hardening their
communications, analyzing routers and demilitarized zones, often enough they spend zero time on
the one thing that remains open to the Internet – their web applications, usually connected to the
databases containing data vital to their businesses.

This is where we fit in – and we're going to share our experiences and the knowledge we gained from working in the field that helped us shape and implement our products. We are going to talk about safe programming practices, and why they are often neglected or misunderstood.

While there are many different kinds of vulnerabilities in modern web application code, there are
some that are more prominent than others. By exposing these often found errors in code that leave
your system vulnerable, we hope to demonstrate DefenseCode software abilities and provide you
with explanation why these vulnerabilities occur and how to avoid or mitigate them in the future.

This blogspace will hopefully provide you with insight and accurate advice information security wise. We are always available for consultation and advice, so feel free to contact us here or through our website.

Kind Regards,
Leon Juranic
CEO

DefenseCode Blog

Hello World. :-D