Every day around the world, dozens of vulnerabilities are found by security researchers or by hackers. The cyber arms race takes place every day. Researchers act in conjunction with manufacturers to assess and correct any security flaws to protect their users from harm. Conversely, hackers often seek to gain financial advantage by reselling vulnerabilities to other malicious users or use them directly against their victims. We will discover in this article how a recent incident response to a customer was handled and how we discovered an otherwise publicly unknown vulnerability that was never reported by the manufacturer which left thousands of users unprotected from this security flaw.

Initial situation

A few weeks ago, one of our customers noticed an anomaly in one of his systems and decided to contact us to clarify the situation.

The client used an external SMTP server (a third-party service used to send a huge number of emails) and a web application called "Interspire Email Marketer" (IEM). This tool allows the management and monitoring of promotional email campaigns. The client’s account had been blocked because it was spotted sending spam. Once connected to the service, it was clear that the monthly quota of the account was almost reached and that the latest emails sent shown on the dashboard had content that were clearly spam.

First actions

In this kind of situation, the first thing to do is to change the login credentials of the concerned service in order to limit the damage. We now know that misuse was done through this service.

At this stage, several hypotheses are credible:

The third-party SMTP service itself suffers from a vulnerability that allows an attacker to arbitrarily take control of accounts. But in this case, the claimant should have communicated the problem to its customers since their quota would be exhausted - unlikely. The customer’s login credentials have been stolen by phishing or other methods. Another system or application suffers from a vulnerability allowing an attacker to retrieve SMTP connection credentials.

However, we cannot stop here because it’s important to know how much the attack has affected our customer and the action range of the pirates, in order to assess the risk. For this, we need to go back to the origins of the attack and to deduce the cause, the course and the goal of the attacker. Was it an opportunistic attack or targeted against our client?

First analyses

Once access to the service was secured, we chose to privilege lead number 3. That’s why, we obtained the logs of the web server hosting the IEM tool mentioned earlier. We focused primarly on the days before the spam was sent from the third-party SMTP service. Our investigations quickly confirmed an intrusion from an IP address, localized in the Philippines. Below are the interesting events from logs.

In the blue box, we can see the value of the "Referer" field which indicates that the attacker seems to have arrived from Google Philippines. This may indicate that the attack was probably opportunistic and the attacker has found a list of vulnerable servers through Google (we will exercise our turn later in this article). The underlined parts in red indicate the access method and the resource requested by the attacker. We can see that he simply loaded the main page with a login form. The shaded part is not important, it shows the loading of various resources related to the graphic layout of "index.php". The most interesting information here is in the green boxes, this value indicates the size of the page in bytes. Indeed, we can notice that the size of the same page drastically changes between the two queries. We have therefore implemented the same application in a local virtual machine to do our tests. It turns out that when the page "index.php" displays the login form, it has a volume of about 5,000 bytes. On the other hand, when it displays the administration interface (which means, after successful authentication), this time it has a volume of about 30,000 bytes. Conclusion, the attacker managed to access the administration interface in two GET requests and didn’t use the login form. He probably didn’t know the username or the password and didn’t need it to proceed the attack. These elements suggest that the vulnerability is probably related to a cookie or to the cookies management. It may also be possible that the attacker has managed to steal a session cookie from a legitimate user, but the chances for this are usually very low. So, we will assume that the application has a vulnerability in its cookies management.

Application source code analysis

At this point we decided to analyse the source code of the application and especially the part of the code processing the authentication cookies. The application (IEM) is coded in PHP, a popular web programming language. Unfortunately, it is built in such a way that it’s easy for a novice programmer to make mistakes leading to vulnerabilities.

A quick search with the "grep" tool makes it possible to easily find parts of the code dealing with cookies.

The code comments found by the tool seem to indicate that the file "init.php" contains the code we are looking for. We will start by analysing this file and especially the code area found by grep.

A quick reading of this code snippet provides a rough understanding of the logic: Getting the cookie named "IEM_CookieLogin" (red box), checking if it’s not empty, then comparing a value named "rand" to its value in the server memory. If the value is the same, the user is authenticated and can access the administration interface. However, an element draws our attention in the blue box, to see it one must know a PHP subtlety. Here is an extract from the PHP documentation that talks about it (http://php.net/manual/en/language.operators.comparison.php):

In summary, the difference between the double and the triple equal sign is the consideration of the type. For greater clarity, here is a concrete example of several comparisons.

We can see in these examples that when a double equal sign is used, it is possible to compare a string of characters to a "true" boolean and to obtain the "true" result. This means, in the case of the code above (blue rectangle), that if it’s possible to put a Boolean value in this "rand" cookie field, we can pass the authentication without even knowing the actual expected value and thus bypass the authentication.

To understand how we can inject a Boolean value into this cookie, it is necessary to analyse its format. So we will analyse the code behind the "IEM :: requestGetCookie ()" method used in the extract shown above.

A "grep" search like the previous one finds the definition of the requestGetCookie function in a file named "IEM.class.php".

The capture above shows the methods for defining or retrieving a cookie from the user. What is especially interesting here is the fact that the cookie is serialized and encoded in the base64 format when it’s created and de-serialized and decoded during its recovery. In programming, serialization consists in transforming an instance (table, object and other data structures) into a string, which allows it to be stored (file system, database) or to be transmitted (GET/POST, web-service, cookie, etc.).

Now let's see what our cookie looks like in its decoded and serialized form. This cookie is normally created only if the authentication is successful and if the user ticks the box "Remember me". So, we will log on to our test instance to retrieve and analyse this cookie.

Here is the cookie in its original format:

And here is the cookie once decoded:

The serialized cookie value is highlighted in red. We can see our famous "rand" value in the green rectangle. The principle of this string is as follows. Each information is defined by its type, its length and its value. For example, the string "s:4:'user';" means type "string", length of 4 and value 'user', and so on.

We must put a positive Boolean value in the "rand" variable to bypass the authentication. Let's take the cookie back and change the value we are interested in.

In the capture above, the green part shows the normal value of the 'rand' variable and the red part shows a 'maliciously' modified version to bypass the authentication. We now have to re-encode the whole string and create a new cookie named "IEM_CookieLogin" having the value that we just generated. And then, all we need to do is to visit the login page to test our payload.

Here's the home page, at least how it should normally be:

And here is the home page if we use our new cookie:

As highlighted in the red box on the capture above, we are actually logged in as an "admin" user.

Origins and correction of vulnerability

According to our research, the application designer, Interspire, corrected the vulnerability with the version 6.1.6 in November 2015, but has never communicated anything about this vulnerability to its customers. The vulnerability seems to have appeared in version 6.1.0 in 2010. In other words, the application was vulnerable for 5 years. Unfortunately, the problem is still not solved for most customers. Indeed, Interspire's business model requires the customer to buy a maintenance contract and renew it every year, otherwise it will not have access to the updates. However, when a customer who no longer has a maintenance contract performs a check for updates, here is the result returned by IEM:

The application claims without further information that the user has the latest version, which is obviously not the case. The message should look something like "You do not have the latest version (6.1.3), please purchase a maintenance contract to update your application (6.1.6)." This can potentially mislead some users who wrongly think they have the latest version and that it probably doesn’t have any vulnerability.

To help users of this product to realize that they are vulnerable, we published the vulnerability (yet unknown to the public) to MITRE, in charge of keeping a comprehensive database of known vulnerabilities. This vulnerability is now identified as CVE-2017-14322.

Vulnerable IEM versions around the world

It’s interesting to do a quick search to find vulnerable IEM instances on the internet. For this we used a simple Google search with a certain syntax allowing us to find an important amount of vulnerable applications running on the web.

There are probably at least 2,230 vulnerable instances of the Interspire Email Marketer application running right now.

Attribution

Now that the investigation is ending, we can issue some certitudes. The persons behind this attack are probably working for a spammers organization. They opportunistically target vulnerable instances and steal SMTP credentials to take advantage of the victims’ servers to send SPAM and steal the victim's email address lists with the aim of feeding their own spammer address database.

Conclusion

In this article, we were able to see how a case of incident response led us to publish a critical vulnerability, "hidden" by the manufacturer and actively used on the web for data theft and takeover of SMTP servers. This could have been less serious if the manufacturer had taken the trouble to alert its customers and offer a free vulnerability correction update. Of course, the user is also responsible to ensure that his software and servers remain up to date. However, when an administrator has a large pool of servers and applications to maintain and the application claims to be up-to-date, who would go further as verifying the veracity of that on the manufacturer's site?

Infoteam Security offers you a comprehensive range of IT security testing and recommendations to ensure the availability of your information systems. You can consult our presentation slides or our website for further information about our services.

Do you want to receive our last news ? Subscribe