Monday, April 23, 2018

Application Security Testing (the Wild West perspective)

Imagine running a bank in a small town. A small town in the Old Wild West. Gangs roam freely. Many people are poor and desperate. Law and enforcement exists, but is open for individual interpretation. Many crimes go unpunished. And you keep all the bank's money in the safe. Every night you try to sleep and not think about your safe - is someone trying to pry or blow it open at the very moment?

Now... imagine you want to make that safe more secure. Would you pay a bunch of thugs to crack it open by force and blow it up? Or would you prefer to pay a group of highly skilled engineers to disassemble it to pieces and carefully examine each one and explain how to fix all the weakness they find?

The Internet of today still functions much as the old Wild West - many laws that try to enforce order are either too broad or vary significantly from country to country. Not many law enforcement officials to be found. And there are a lot of people that roam around trying to gain some profit even if it means breaking the law.

Your applications and infrastructure is your secure safe. At least it should be secure. You can not be sure unless someone examines it thoroughly and helps you find and fix all the vulnerabilities before the bad guys do. Doing the examination of a running application is called DAST (Dynamic Application Security Testing). DAST is the equivalent of roughly shaking the safe, beating it with a large club, proceeding to cut it with a blowtorch, and finishing up with a bunch of explosives. It has it's own purpose and advantages, but will never be able to discover some of the weaknesses the careful disassembly and examination would. To check your applications in a thorough way you need to analyze it's source code. The best method to do it is called SAST (Static Application Security Testing).

To perform the static testing, you can employ two methods:

  1. Team(s) of highly skilled security professionals going through your source code line by line and trying to spot weaknesses
  2. Find some way to automate the procedure and have people only examine and verify the results

The first method (manual code review) gives best results if the team is skilled enough and has enough time to do it. Experienced security professionals are hard to find (read: not cheap) and time it takes to manually go through even medium application can take the whole team of people many months or years. Because of huge costs and time it takes, manual code review is seldom employed for anything but the applications of utmost importance.

Way to go is to automate the procedure and employ the help of your own computer to read and understand the source code. And notify you if there are any security vulnerabilities in there. That way you can check your code while still in early stages of development and spot the issues early enough. And avoid the costs of having to do a major redesign later on. If using automated tools, you can make a policy that says: "Every new version of the application that goes into production must go through the security review". That way you can sleep peacefully knowing that the latest deploy did not just open up a huge hole right in the middle of your application. A hole that you might hear about in the morning news while sipping your coffee. Might not be the way you want to make a debut for yourself and your company.

The question remains - if the source code review is so costly and time consuming, how can anyone afford doing it even once, let alone do regular checks every time something is changed or added? There are not many solutions and tools that help you, but we can assure you ours is one of the best there is. We call it ThunderScan. Almost 10 years in development, it grew to become one of the best and cost effective tools out there. Maybe even the best - we will let you decide.

We tried to find a way to compare it to the best tools there are. The most objective and acclaimed way to do it was to apply for the OWASP Benchmark Project. The OWASP Foundation one of the top authorities in IT security. Their Benchmark allowed us to examine the score of our SAST tool (ThunderScan) to the best tools in the world. And our results were impressive - we managed to find way more vulnerabilities than any other commercial tool.

We encourage you to try our tool yourself and make your own opinion. You can grab a free trial by clicking HERE. No credit card required. Really free of charge. Let us know how you like it by contacting us at

Kind regards,

DefenseCode team

We mentioned we also excel in the cost-performance. Well... That was not the whole truth. Although we do offer highest quality we do not charge highest prices. On the contrary - our prices are only a fraction of prices of the other top of the line tools, and we are so proud of it we made them public. You can check them out HERE

Tuesday, July 11, 2017

Multiple Buffer Overflow Vulnerabilities in IBM Database software (DB2 and Informix)

Hi Dear Reader,

During the last couple of weeks we have published security vulnerabilities in database tools related to DB2 and Informix databases.
We're sure that you (as responsible database admin) usually don't run arbitrary "attacker supplied" .SQL files on your database.
But even more, after security audit results of Informix and DB2 database tools, we're sure that you want to add extra care on that one, since we've discovered that poisonous .SQL files can overflow database tools memory buffers and execute arbitrary code on your system.

Links to our advisories follows...

Informix Security Advisory:

DB2 Security Advisory:

Kind Regards,
DefenseCode Team

Tuesday, June 6, 2017

ThunderScan Discovered Multiple Vulnerabilities in Google API Client Library for PHP


During the security audit of Google APIs Client Library for PHP multiple XSS vulnerabilities were discovered using DefenseCode ThunderScan SAST application source code security analysis platform. The Google API Client Library for PHP is designed for PHP client-application developers. It offers simple, flexible, powerful access to many Google APIs such as Google+, Drive, or YouTube.

The Cross-Site Scripting vulnerability can enable the attacker to construct the URL that contains malicious JavaScript code. If the administrator of the site makes a request to such an URL, the attacker's code will be executed, with unrestricted access to the site in question. The attacker can entice the administrator to visit the URL in various ways, including sending the URL by email, posting it as a part of the comment on the vulnerable site or another forum. Once the unsuspecting user has visited such an URL, the attacker can proceed to send requests to the API on the behalf of the victim from his JavaScript.

Full advisory can be read on the following URL:

DefenseCode Team

DefenseCode Is Looking for New Partners and Resellers

In order to additionally expand its rapid growth, DefenseCode L.L.C is currently looking to expand our world-wide partners and resellers for our software products and services. If you are interested in partnership with DefenseCode L.L.C for distribution of world's top class security solutions for Web Security Scanning and Static Source Code Security Analysis, as well as our security consulting services, we would be glad to hear from you.

Potential partners and resellers are encouraged to contact us over the e-mail We are looking forward to our new partners and more exciting business opportunities.

DefenseCode Team

Stealing Windows Credentials Using Google Chrome


Check out our new whitepaper about stealing Windows credentials using the most popular browser today - Google Chrome.


DefenseCode Team

Wednesday, April 12, 2017

High Risk 0-day Vulnerability Found in Magento eCommerce

During the security audit of Magento Community Edition, a highly popular e-commerce platform, a high risk vulnerability was discovered that could lead to remote code execution and thus the complete system compromise including the database containing sensitive customer information such as stored credit card numbers and other payment information. The vulnerability is based around an arbitrary file upload combined with a cross-site request forgery (CSRF) vulnerability as a main attack vector.

Despite the efforts of our team in notifying the vendor on more than one occasion since November 2016, the vulnerability remains unpatched.

Full vulnerability details are published as an advisory.

DefenseCode Team

Monday, April 10, 2017

Apache Tomcat Vulnerabilities Found Using DefenseCode ThunderScan SAST

During the source code security analysis of Apache Tomcat with DefenseCode ThunderScan SAST solution, two different security issues were discovered, ranked as medium risk.
When exploited, discovered vulnerabilities can be abused to disclose and retrieve arbitrary files on server, such as Apache Tomcat configuration file with plain text usernames and passwords or any other file which Apache Tomcat has permission to access.
Full vulnerability details are published as an advisory and include ThunderScan screenshots for better understanding of the vulnerability.
DefenseCode Team