Brute force attack is a well-known technique of trial and error attempts used by attackers to gain access to unauthorized data. It can be leveraged against servers as an online attack and also against files as a local attack.

The common denominator of all these types is that the same pattern is almost always the same:

In most cases the attacker would have to know two major keys from the diagram – let’s take for example a common scenario where the attacker tries a brute-force attack on the login interface of an applicaiton in order to find the correct credentials of a certain account. The known keys would be:

Something I know – In this case, the username of the account that the attacker wants to hijack.

The result – On each attempt, the attacker receives an indicator of failed/successful result.

Preface How do we adjust the SDL (Security Development Lifecycle) process for the growing use of open source in internal/external systems we develop and maintain? This is a question I hear a lot lately from our customers in some recent SDL projects we (AppSec Labs) carried out for our customers. After we did some research, […]

In almost every Android application, developers expose activities without sufficient protections. Exposing activities can lead to various attacks. For example, an attacker or a malicious app installed on the same device, can call those exposed activities to invoke internal pages of the application. Calling internal pages puts the application at risk of phishing by manipulating […]

Many different client technologies such as web, mobile, cloud and more – send messages to business applications using XML. In order for the application to work with these self-descriptive XML messages, it has to parse them and check that the format is correct.

This article will describe XML External Entity (XXE) injection attack and its basics in order to provide you with a better understanding of the attack and how to deal with it.

Since we will be talking about XXE injection, first we should understand the meaning of external entities and what they allow us to achieve.

External entities refer to data that an XML processor has to parse. They are useful for creating a common reference that can be shared between multiple documents. Any changes that are made to external entities are automatically updated in the documents which contain references to them. Meaning, XML uses external entities to fetch information or “content” – into the body of the XML document.

There are a few cases when preparing a PoC for brute-force attack on the login page can be complicated. It is no longer uncommon to find a login form based on web sockets, or which implements some sort of client-side encryption with JavaScript. In these cases, configuring a brute-attack quickly with a middle proxy (e.g. Burp’s Intruder) is not possible. It also happens that clients request for the penetration testings to be conducted on a specific machine, without access to common attacking tools.

For these reasons, I wrote a very minimalistic brute-force tool that runs inside the browser (the source code, following this post, has to be copy-pasted into browser’s JavaScript console).

Most of us are familiar with the ‘Open Redirect’ vulnerability; an OWASP top 10 vulnerability that takes advantage of a situation in which the application receives a parameter from the client and uses it to build the URL location to which the user is redirected, without performing sufficient validation on the received input.

Typically, attackers can exploit vulnerable applications in order to perform phishing attacks, redirecting the victims to phishing sites that look exactly (or partially) like the vulnerable application. The victims tend to believe they are still in the original website, and provide their credentials in order to perform the required login. Unfortunately, these credentials are sent directly to the attacker.

A Classic Open Redirect Scenario

The following image demonstrates a vulnerable website (victim-site.com), which is vulnerable to the common open redirect scenario; a login page that will redirect the user to the page specified in the ‘returnURL’ parameter after successful login (the rectangle outlines the URL of the index page):

In Net beans 8, during debugging (in my case, smali debugging), you cannot change char sequence variables, they are shown as read-only strings. An example of usage is Android text-elements (EditText) whose value is stored in Obj.mText.mText in a char sequence. The following screenshot, shows a Tree view, but you cannot change the field in table view either.

So, I tried do the same with Net beans 6.8 and I found that it let me edit char-sequence variables. After some research I figured out that in order to enable editing of those variables I need to disable the auto formatting. You do this in tools menu -> options and remove the V of Default Char sequence formatter:

Introduction to negative subtracting
We all know about the negative subtracting issue. For example, if I transfer money to you, it is reduced from my account and added to your account. The code looks something like:

Now, what happens if I transfer a negative value to your account? We know that subtracting two negatives give a positive, so if I transfer minus one hundred to you, my account will increase by one hundred and your account will be reduced by one hundred.

Another example is an online roulette game. The house always wins eventually, because the chances are against the player. But we can turn it simply by betting a negative value. Now, each time we lose, we lose a negative value which means that we actually win…

Up until here it is clear and simple and I hope that everyone knows it.

Example of (in)secure code
I recently came across a code that looked secure at first impression, but only upon second glance I understood that it is not secure at all. Let me start by showing you the code (C language), I modified it to become like a hacme game…:

Almost every website today provides social, financial or informative detail to the internet users. Websites that contain sensitive data about users, such as banks, social networks and online stores, restrict the access to private data by using access-control measures such as authentication, authorization encryption mechanisms and more.
However, hackers are still able to find their way to the “prize” with very clever attacking techniques, as their primary target is usually the sensitive data behind the application.

In the following post we will review an unusual injection type, with a great potential to cause some SERIOUS DAMAGE if initiated. Well… how can it be initiated? It depends, primarily on the web application programmers, BUT also on the user himself.

Let’s start by saying that every application uses untrusted data.

Since the application is intended to be used by the public – we don’t know whether the user is a legitimate one, or a hacker trying numerous types of attacks in order to hijack user sessions, credentials and/or sensitive data such as credit card numbers.