Learning from other's mistakes: Twitter Security

Unless you have been sleeping under a stone for the past four years then you must have heard about Twitter in some way or another. The original idea behind Twitter was to provide a social network where everyone can tell followers what he or she is up to. The only restriction with Twitter is that each message has to be 140 characters or less.

Most times it makes little sense to implement high security features for services that do not deliver sensitive content. The original concept behind Twitter was to simply deliver short text messages with little value and at first glance, a Twitter account does not seem to have much value. Twitter accounts are free and the only information that you send out using Twitter is supposed to be small talk (eg. “Made lemon vanilla cupcakes with..”).

However it didn’t take too long for politicians, organizations and consultants to start using it in their marketing strategies or as a way to stay in touch with a large number of people. Whenever a well known media personality joined Twitter (such as Oprah), a large number of fans would follow. As people and organizations started relying on the service more and more, Twitter’s value increased, while the level of security did not change much. During the US presidential elections, politicians used Twitter as a way to quickly update the public about the latest news. Some people might also exchange information that is sensitive in nature by making use of the private message feature. There are also payment methods that rely on Twitter such as Twitpay and Tipjoy. Twitter was never meant to be used as a payment service, yet people started creating ways to do just about that.

When security is given little importance from the start, web applications have a tendency to have vulnerabilities. In the recent months, Twitter has taken quite a beating when it comes to security. The service has been host to worm attacks, spammer and malware content. What sorts of vulnerabilities were exploited.

Earlier this month, a large number of Twitter accounts started linking to a particular website (StalkerDaily). The reason? A worm was making use of a cross site scripting (XSS) vulnerability in Twitter. The vulnerability was in the account settings page, where victim browsers could be forced to update their profile URL to include javascript code within their page. This javascript code would then do its job as a worm and attempt to infect new Twitter users who visit the infected profile. The vulnerability appeared to be quite a standard XSS security flaw. Even when Twitter said that they initially fixed the flaw, new rounds of a modified worm were infecting Twitter users.

XSS worms were not the only problem that Twitter faced. Some accounts on Twitter have more value than others, such as Barak Obama’s or Britney Spear’s twitter account. When these high profile accounts were compromised, the attackers could reach thousands and millions of followers and send them ‘funny’ messages as well as link to malicious code. These high profile accounts were compromised due to a weak password used by Twitter’s own support.

Then there are attacks that many other popular services are vulnerable to. Phishers have been known to target Twitter accounts where people receive direct messages on twitter linking to web pages that appear to be a Twitter login screen. When it comes to encryption, Twitter still does not enforce encryption by default. Even if one chooses to use HTTPS instead of HTTP, Twitter is still vulnerable to Surf Jacking and similar attacks that can downgrade an HTTPS session to HTTP and allow attackers to hijack Twitter accounts. Finally, spammers have acknowledged the value of Twitter and started using it as another platform to conduct their unsolicited “business”.

One lesson that we should have learnt by now is that for services, such as Twitter, that have potential for growth, security becomes an issue sooner or later. If it is not taken seriously from the start, then it will be much more expensive and generally harder to implement security once the service has taken off. In the case of the XSS worm, the vulnerability appears to be a classic XSS. Such vulnerabilities could be easily found through both automated testing and manual approaches. It would be a mistake to assume that such a web service only needs to be tested once. Websites, especially social networks are dynamic, alive and constantly changing. Any code or feature updates can introduce new security flaws and therefore periodic security reviews are required if such a service is to take security seriously.

OpenX 2.6.4 vulnerabilities were identified with Acusensor

If you are making use of OpenX, the following update fixes a number of security flaws that were identified when we made use of Acunetix WVS with the Acusensor technology enabled. Released an advisory detailing these vulnerabilities here. The SQL injection vulnerabilities abuse an INSERT statement and therefore an attacker, or normal web application scanner will not find such a vulnerability so easily.

Why not?

Unlike SQL injection of SELECT statements, when exploiting INSERT statements an attacker is not given any sort of feedback. With a SELECT statement an attacker might receive back errors from the SQL server or, in the case of a blind SQL injection, might change the logic of the result. The Wikipedia page about SQLi conditional responses explains this idea – an attacker knows that 1=1 will return a match, while 1=2 will not. This allows attackers and automated tools to confirm a blind SQL injection when the response page is as expected.

However these methods do not work with SQL injection in INSERT statements, since they do not usually change the way that the page is handled. Acusensor bypasses these limitations by hooking the vulnerable PHP script and identifying SQL injection when it occurs. Information from Acusensor is sent back to the Acunetix WVS, thus providing a full trace of where the vulnerability is, at which line and what the SQL statement looks like.

Watch the demonstration to see for yourself how Acunetix WVS made finding these flaws easy.

Click here for high quality version

When Google claims that “This site may harm your computer”

This warning does not refer to this particular site (Acunetix.com) but to quite a few websites out there. This is a notice that will show up when a Google search lists websites that are flagged as dangerous. Google’s search engine works together with StopBadware.org to prevent website visitors from visiting websites that may attempt to install malware on their computers.

This is all well and good, but what about the other side of the equation i.e. the website? By making this service available for everyone, Google has made it more of an incentive for website owners to make sure that their websites are not serving harmful or malicious software. Legitimate websites stop receiving traffic from Google searches when their website is added to the blacklist. While browsing the Linkedin Security Answers page this morning, I came across the question: “What is the solution to overcome security(Hacking/Virus attacks) to the start-up job portal?“. It appears that the question was posted by someone who runs a job portal website that was linking to a malware site. When Google started blocking visitors to his website, the website owner became concerned about the security issue that his site might be vulnerable to.

On which criteria does Google block such sites?

Many times the website being blocked does not host the malware itself, but rather redirects visitors to another website that tries to install malicious software. Such sites usually hosting code that exploit security vulnerabilities in web browsers and client software (such as Adobe Acrobat Reader). The victim website (the one being blocked by Google) is often running web applications that are vulnerable to common security flaws. Examples of such flaws that are often exploited by malicious hackers include SQL injection and Remote File Inclusion. By making use of these vulnerabilities, attackers are able to inject their own HTML code such as IFRAMES pointing to the malicious website, or insert Javascript code which essentially does the same thing.

The below is an example of how the HTML source of one particular hacked website looks like:

How to get off the blacklist

The FAQ at Google’s webmaster/site owner help explains how to making sure that your site is removed from their blacklist. The following is a summary of what needs to be done:

1. Fix the problem (which is what we’re interested in, therefore the next section)
2. Request a malware review: this involves logging into Google’s webmaster tools, selecting your victim site and asking for a review

Fix the problem

This tends to vary depending on the case, but many times attackers (hackers) are known to insert HTML in the SQL database, within the HTML files themselves and also leave backdoors (eg. rogue PHP scripts) to be able to gain access to the server again. Here are some suggestions to identify and fix the security holes:

• Remove public access for the web pages serving malware to prevent your visitors’ computers from become infected
• Backup and analyze any log files available to identify the entry point
• If the web applications installed are publicly available (freeware / open source) or commercial, make sure that there are no known vulnerabilities for the installed version
• Scanning your custom web applications (or even public ones) with a vulnerability scanner is always a good idea – Acunetix WVS with Acusensor can even help you identify backdoors inserted by the hackers
• Sometimes websites are not hacked through web application flaws, but through known credentials, eg. FTP passwords – change all access passwords
• There are times when the service provider itself is compromised; this is especially common in shared hosting environment where one server may be hosting hundreds of (possibly vulnerable) sites; contacting your provider is a good first step
• Once the entry point is identified, clean up all traces of the malicious content that was added to your site; this involves editing the database, html files; Scrubbr is one freely available OWASP tool that may help here
• Finally get help from security professionals in fixing the problem if need be

Hope that this post proves to be useful for anyone running a website that becomes victim to online attacks, and an eye opener for the rest!

A quick security analysis of Facebook’s Album Privacy

Most social networking sites have privacy options which allow users to share photo albums with selected people or groups. Such features encourage end users to upload possibly compromising photos, for example photos of last night’s party. The idea is that it is acceptable to share certain photos with your friends, but not with your future employer. These same privacy features have previously been found to be insufficient and have been bypassed. For example, a year ago MySpace’s privacy features hit the news when a 17 gigabyte download was available containing thousands of photos obtained from MySpace which were supposed to be private. According to this report by Wired.com, these bugs had been abused by “self-described pedophiles and run-of-the-mill voyeurs” for quite a while.

So when I saw this blog post titled “Access any album on any Facebook profile” on the Security Ninja Blog, I decided to give this a quick look. In the blog post, Dave described how the privacy protection can be broken. He showed how he made use of a tool to launch a bruteforce attack and guessing a secret made up of 5 hexadecimal characters. A similar attack can be demonstrated by making use of  the HTTP Fuzzer in Acunetix WVS, and you can watch a demo of this feature being used to attack a similar case of weak authentication.

How does the Facebook attack work?

The album.php script on Facebook requires 3 parameters:

1. “id” : this is the user’s id, which is publicly available and can be guessed by simply searching for that user
2. “aid” : the album’s id – which is always -3 when the album is the public profile
3. “l” : this is the secret

Therefore the only unknown ID to view the public profile is the “l” parameter. I will be referring to this parameter as the secret. While the album id (aid) is always -3 when the target album is a public profile, the album id for other albums is not so predictable. Non-public profile albums tend to have a long numeric id. During my brief research I saw album id’s which were 3 characters long, and others which were 6 or 7 characters long. So I decided to get a better idea of how the album id is generated. I created a new Facebook account and started adding new albums. The album id’s that were automatically generated were 2001832, 2001833, 2001834, 2001835, 2001836. Anyone will notice the sequence. Although a Facebook user who is not on the victim’s friends list cannot see what albums are available, public albums can be accessed if the album URL is known.This is intended behavior and the Facebook Help page has this to say about it:

“Please note that the “Everyone” privacy setting allows anyone on Facebook to view the album if they are linked to it.”

I did some more testing of my own…

So I created another Facebook user and started creating more albums. The id’s given to these albums were 2007969, 2007970 and so on. A very similar pattern but does not follow the sequence of the previous user. What I did next was to let some time pass and create yet another album. The id skipped a number, so that if the previous ID was 2007970, then the new one was 2007972. This behavior might indicate that Facebook uses time when generating new the album IDs or that some other user was assigned the album id 2007971 if album IDs are unique to the system. This seems to show that the album id (”aid” parameter) is easily guessable especially if one knows any particular album ID that is associated with the target user.

The Security Ninja blog post also mentioned that for an attacker to view all albums of the victim, the attacker would have to bruteforce both the album id and the secret (”l” parameter). This sounded too complex and a malicious user using this attack would have to generate tens of thousands of requests just to view an album. However by default, albums are public and one can assume that most users will have at least one public album and only set specific interesting albums as private. This means that by default, album URLs do not require the secret. Therefore what an attacker can do is locate a few public albums for a specific user to get a rough idea of the range of album IDs that are assocaited with the victim. This means that the attacker can limit the bruteforce attack to a much smaller number of album IDs.

I also decided to take a look at the secret (”l” parameter) and get an idea of how it is generated. This parameter is normally used when someone shares an album with privacy settings with a non-facebook user by sending the other user an email or an instant message with the link. During the testing I noticed that the secret is static unique for each private album. This means that each private album is directly associated with the secret. When the album privacy settings change, the secret remains the same. If this secret is generated based on some public property of the album (for example, the album id and user id), then an attacker may generate a large number of albums and analyze the resulting secrets to find out how they are generated. At this stage I do not know if this is the case, but would be interested in hearing other people’s input.

My conclusions:

1. Even if the attacker is not within the social network of the victim, the album id is susceptible to bruteforce and the attacker can then view victim’s public albums
2. Since album ids follow a certain pattern, an attacker may be able to target a range of album IDs to find out the secret and gain access to these private albums

Public albums should be treated as public and the secret is not much of a protection; my suggestion is to avoid uploading photos that might embarass you. Unfortunately, as with many other free services, end users cannot do much to protect themselves other than not sharing compromising content. By their nature, social networking sites tend to be open and the idea is to share information. Therefore it is likely that we will keep seeing similar issues in Facebook and other social networking sites.

How can low privilege bugs lead to a server compromise?

To address a large number of security concerns, it is often recommended that web applications make effective use of “the principle of least privilege“. The idea is that one should only grant the privileges on the basis that they are needed. In a previous post, I suggested that Kaspersky’s database compromise would not have been so bad if they made better use of separation of privileges on their databases. The fact that the same database user apparently had access to so many SQL tables is what caused concerns for some security professionals. Similarly, correct server permissions might be able to prevent a server compromise when an attacker tries to execute custom PHP or Perl scripts through a vulnerable upload script.

However even with these precautions, a skilled attacker may be able to compromise a server through an SQL injection vulnerability. The truth is that most backend software has traditional security flaws such as buffer overflows. PHP 5.2.8 fixed various buffer overflow bugs that could affect scripts on the server to run arbitrary code in memory. Most database servers have previously issued fixes for memory corruption, for example in 2007, MySQL issued patches for privilege escalation issues. Oracle and MSSQL had their fair share of similar issues.

This leads us to the conclusion that web application security is a process that involves different people. In the case of a custom application, developers need to make it easy for the administrator to implement the principle of least privilege. They also need to test their code to reduce the chances that attackers will not be able to find security flaws in their code. However security does not stop there. The systems administrators need to keep the backends abreast the latest threats. They would also do well to test their servers with security scanners (such as Acunetix WVS) to identify system flaws and to confirm that the web applications were carefully audited. Finally, those making business decisions need to make sure that their options do not jeopardize the security efforts of those designing and implementing their systems.

SQL injection sneaks into Kaspersky’s support website

The recent compromise of Kaspersky’s (the Antivirus vendor) support database left the company with a bit of explaining to do. The hacker published a blog post on hackersblog detailing stunts with Kaspersky’s USA support website. Kaspersky also published their own account based on their log files and the hacker’s (nicknamed unu) blog post.

Summary of what happened

The following is a summary of what appears to have happened:

1. Unu scanned Kaspersky’s website using an automated tool, possibly Acunetix WVS (take a look at the screenshots)
2. The scanner identified SQL injection vulnerabilities on usa.kaspersky.com
3. The hacker manually verified the SQL injection vulnerability by injecting SQL statements that reveal the version of the database server (MySQL)
4. The vulnerable PHP code appeared to be using a high privileged SQL account and Unu then proceeded to list all tables that he/she had access to

So how bad was this security incident for Kaspersky? For one thing, it appears to have affected the organization’s reputation. Security companies tend to loose credibility when they too become victims of the sort of threats that they are trying to prevent. Luckily for Kaspersky, it seems that the hacker had good enough intentions and was only interested in fame. The screenshots indicated that by abusing this vulnerability, a real criminal could have stolen customer details, product activation codes, lists of bugs. Gunter Ollmann of IBM’s Internet Security Systems also mentioned that the attacker could have updated the database to direct the customers to malicious software rather than Kaspersky’s security software.

Was Acunetix WVS Free edition used?

There were claims that Acunetix the free edition was used as part of the attack. It is more likely that a pirated version of the full scanner was used since the free version does not support scanning for SQL injection vulnerabilities.

What could have prevented this attack?

It is always important to learn from such security incidents. I think the following would address similar issues with many websites that are publicly exposed to SQL injection attacks:

• When performing vulnerability assessment, do not stop at the main website (eg. www.company.com) but also test subdomains; usa.kaspersky.com was not the main site, yet it had access to sensitive or important information
• Kaspersky’s incident could have been greatly mitigated if the SQL account did not have access to so many tables; when developing web applications design them with proper access control in mind
• Many websites are under constant development and improvement and therefore it is useless to only check its security once; it makes sense to  scan web applications periodically to identify any flaws that are introduced with the constant application changes

Embedded devices can be hacked through the web interface

Anyone who has tested even a small number of web configuration interfaces on embedded devices, such as managed routers, VoIP gateways and wireless routers, knows that these devices are notorious for web application vulnerabilities. It is not uncommon for these devices to be vulnerable to Cross Site Scripting and similar attacks. Recently Cisco published a fix for an XSS vulnerability which affects the Cisco IOS HTTP server. The following would be the attack scenario:

• A network operator (the victim) who is logged (or has saved his credentials) into the Cisco IOS web interface visits a malicious site
• The malicious site redirects the victim to the “ping” utility web page on the Cisco box which ends up displaying HTML code set by the attacker
• From that point on, the attacker has access to the victim’s authenticated session and can do a number of things, such as resetting the administrator’s password

Additionally, Cisco IOS also appears to be vulnerable to a yet unpatched Cross Site Request Forgery vulnerability. By forcing a victim network operator to visit a page such as ‘http://cisco-box/level/15/configure/-/enable/secret/a-new-password’, the password is reset to “a-new-password”. This is not new information and has been previously mentioned in the advisory by ProCheckUp recently and elsewhere back in January 2008.

HTTP is not the only way to inject HTML code into a web interface (leading to XSS). ProCheckUp had previously released a paper which describes exploitation of SNMP write access to change values that are displayed in the Cisco IOS Web configuration. By inserting HTML code as the name of the Cisco device, the Web Interface turns into a backdoor that the attacker can control. During my tests I was able to find embedded VoIP devices that have similar vulnerabilities when they display the user input such as the “caller-id” in the logs.

It seems that these web configuration interfaces have a long way to go in terms of Web Application Security and the repercussions can be decremental in the case of a targeted or drive-by attack on your organization. My recommendations are:

• Disable the HTTP interface if possible; some organizations have a policy to disable the Cisco IOS Web interface
• Limit the number of people that have access to the HTTP interfaces of embedded devices; this limits the number of people that may be victim to a Cross Site Scripting or Cross Site Request Forgery attack
• Make use of separate web browser to configure your embedded devices; i.e. use Internet  explorer for your embedded device and Firefox for your normal browsing

Image upload forms used to hijack websites

In the past days I came across a stimulating blog post titled “Dissecting a Multistage Web Attack that uses the recent IE7 0day”. The authors described how a vulnerable web application was then able to infect web browsers visiting the infected website. The attackers, who used an IP that originates from China, made a lot of attempts (presumably using automated tools) to inject SQL statements (SQL Injection) through the web application. The attacker’s favorite method of penetration appears to be SQL injection probably since it is so prevalent. However this particular web application was not vulnerable to SQL injection and therefore they had to move on to a different attack vector.

The attackers looked around for vulnerable ASP pages and identified a library that allows users to upload images. Attackers are known to exploit upload forms by uploading CGI scripts such as EXE, PHP or ASP files to the web server. When these files are accessed through the web server, the web server tries to interpret or execute these files as legitimate CGI or ASP. This means that code is executed on the server side and this code can be anything from a normal web application to a backdoor allowing remote access to the server. In this case, this library had taken precautions to only allow certain file types to be uploaded. The image library made sure to only allow files with certain file extensions (.gif, .jpeg etc) and possibly checked the contents of the files to make sure that it is indeed an image.

So how were the attackers able to execute remote code on the victim web server?

The attackers made use of a filename with the extension .CDX. Such files can refer to various file types, one of which is a graphics file type used by Corel Draw. Additionally, by default IIS interprets CDX files as ASP scripts. This image library allowed users to upload files with this extension and store it on the web server. However the image library could also check if the contents of the file contain an image or not. To bypass that check, the attackers included the contents of a real GIF file and embedded some VBScript code. The image library would detect the GIF file and allow the upload to take place, while the IIS server would interpret the VBScript code just similar to any other ASP script on the server. This combination keeps everyone (both IIS and the image library) happy, and therefore the attacker gets execute his or her custom VBScript code on the IIS server just as if he had uploaded an ASP file!

Once the CDX file was uploaded, the attacker then started sending it commands. In this particular case, the attacker uploaded a variation of a well known ASP backdoor that is typically used by Chinese speakers. From this point on the web pages were modified to include code that exploited a security hole in Internet Explorer. This meant that visitors who went to the infected website could end up running arbitrary code on their desktop computers. Such code usually installs backdoors and spyware on the victim machines. To keep tabs on this story and how it develops visit the Attack research blog which should be posting a juicy update soon.

How does one prevent similar attacks?

Since filtering by file extension was bypassed, it might appear that an appropriate fix would be as simple as making sure that CDX files are not successfully uploaded to the server. However this fix is not hacker proof and it alone does not provide a complete solution. Such a solution will only be sufficient until attackers find another way of bypassing this security mechanism.

To solve this issue we should be looking at the source of the problem. Allowing files in the “images” or “uploads” directory to be executed by the server is probably the main culprit. Setting the correct permissions on the web server to only read such files would be a good solution to this issue. Additionally, if anonymous uploads are not needed, then it is a good idea to avoid providing that functionality in the first place.

Note that this solution does not do much to prevent the GIFAR attacks that target the client-side rather than the server-side. But that will be for another post.

How can any web page log you off all other websites?

A recent post on “Full-Disclosure” mailing list referenced a web page called “Session Destroyer”. This web page is a demonstration by Kristian Erik Hermansen that promises to make logging off various popular websites very easy.

How does it work? This static html page simply contains IMG tags that link to the logout url for various websites including Facebook, Gmail, Ebay, Youtube and Yahoo. If an unwary user visit this web page then he or she will instantly get logged out of these popular websites. While this is a nuisance, it is not considered a serious security hole and knowledge of this issue is widespread throughout the security community.

In fact this sort of issue has a name – Cross Site Request Forgery or CSRF / XSRF, and can have very serious repurcussions. This security flaw relies on the fact that web browsers will happily go to any URL that is referenced by any website, even if the URL refers to a totally different website. If the URL performs an action, (eg. logs out the user or transfers some money to another bank account) AND the URL’s parameters are predictable, then that web application is typically vulnerable to a CSRF attack. Major sites such as Gmail were previously found to be vulnerable to CSRF. In the case of Gmail, attackers were able to add an email filter that forwarded the victim’s emails to their own email address.

To solve this issue, web developers usually create a secret that the attacker cannot predict and that is known between the web application and the legitimate user. Making use of POST requests is not a solution to CSRF since attackers can force web browsers to submit forms. The solution is to make use of a challenge token for each request – or at least those requests that execute a sensitive action.

Why upgrade PHP to 5.2.8? Part 2

To read part 1 of this article please refer to the previous post.

Note: a large number of vulnerabilities described in this post can be exploited to bypass safe_mode. It is not recommended to rely on this PHP functionality for the security of your web servers. Only use safe_mode as a supplement to PHP code that has been truly audited (with AcuSensor technology of course).

Not all vulnerabilities described are simply a safe_mode bypass. The IMAP toolkit crash is more than just a crash!

Incorrect php_value order for Apache configuration

This vulnerability affects sysadmins that rely on the safety features of safe_mode to protect their servers against users executing malicious php code on the server. This security flaw was reported by SecurityReason. In their advisory, SecurityReason show how it can be exploited by attackers who can modify the PHP configuration by editing the Apache configuration (httpd.conf) or .htaccess. In the case that error_log directive is already set to a php script, if the php script can be edited by the attacker, then the attacker can also bypass PHP’s safe_mode feature. This is a local exploit.

Fixed a crash inside gd with invalid fonts (CVE-2008-3658)

GD handles image processing in PHP. It can also be used to read font files through the imageloadfont() function. This particular function suffers from a buffer overflow which can be used to execute arbitrary code or cause a denial of service. This vulnerability would affect any PHP code that calls this function and supplies it with user defined font files (normally *.gdf files).

Fixed a possible overflow inside memnstr (CVE-2008-3659)

An attacker can execute arbitrary code if he or she can specify the delimiter in the explode() php function. Although usage of the explode() function is very common, it is not common behavior nor recommended to make use of user defined delimiters. Therefore most applications should not be vulnerable to this. However this vulnerability can be locally exploitable to bypass safe_mode restrictions.

Fixed security issues detailed in CVE-2008-2665 and CVE-2008-2666

CVE-2008-2665 detailed another vulnerability that can be used to bypass safe_mode. The vulnerability is a directory traversal issue in the PHP function posix_access() which allows one to check permissions of a file. CVE-2008-2666 describes an even more subtle bypass where chdir and ftok functions can allow access to files that should not be accessible through safe_mode if the directory starts with the string “http:”.

Crash with URI/file..php (filename contains 2 dots) (CVE-2008-3660)

If you are making use of FastCGI module then users accessing your webserver could cause a Denial of Service by simply supplying two or more dots in front of the php extension. This vulnerability could easily be triggered unintentionally so it is highly recommended to update if the web server is making us of FastCGI.

IMAP toolkit crash: rfc822.c legacy routine buffer overflow). (Fixes CVE-2008-2829)

PHP made use of old code written in 1988 which did not handle large buffers, thus leading to a classic buffer overflow. How can this be exploited? If you are making use of PHP code that reads messages from an IMAP server, then that code is exposed to a buffer overflow. By exploiting this security hole attackers can crash the HTTP server and execute arbitrary code and gain access to the server. Emails exploiting this vulnerability will typically consist of large address lists in the To or CC email header. This vulnerability is described in the PHP bug report and could easily be triggered unintentionally and intentionally if one is making use of PHP applications that use the PHP IMAP functionality such as TWIG.

When upgrading make sure that you go for version 5.2.8 (or greater) which was issued to fix a flaw that was introduced in version 5.2.7.