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.

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

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!

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.

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.

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

• 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

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 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.

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.

So what is the reason that such vulnerabilities materialize and do not get fixed? Two months ago I too reported a XSS vulnerability to a Bank’s security team. The case was very similar to the security hole in American Express’ website. The vulnerable script was a search script that echoed back the search string. After being told that they knew about the vulnerability, I asked “why not fix it?”. The reason? The Cross Site Scripting vulnerability does not affect the sensitive website (ebanking site) which is on a different server.

In the network security world, this would have been a good answer especially when the servers are segregated. However when it comes to Web Application Security, the situation is a bit different. If the secure ebanking site shares the cookie with the other websites on the same domain (eg. secure.bank.com and www.bank.com share the same cookie), then the risk is immediately understood. Cross Site Scripting on one site affects the other site. Even when that is not the case, Cross Site Scripting can cause trouble. Attackers have previously exploited XSS to launch very convincing phishing attacks on an Italian Bank or to increase their google ranking. Besides that, reputation is easily hurt if (like AmEx) your organization is trying to project the image that it takes security seriously!

A new version of the popular scripting language, PHP includes a couple of security fixes (taken from the Changelog):

• Upgraded PCRE to version 7.8 (Fixes CVE-2008-2371)
• Fixed missing initialization of BG(page_uid) and BG(page_gid)
• Fixed incorrect php_value order for Apache configuration
• Fixed a crash inside gd with invalid fonts (Fixes CVE-2008-3658).
• Fixed a possible overflow inside memnstr (Fixes CVE-2008-3659).
• Fixed security issues detailed in CVE-2008-2665 and CVE-2008-2666.
• Fixed bug #45151 (Crash with URI/file..php (filename contains 2 dots)).(Fixes CVE-2008-3660)
• Fixed bug #42862 (IMAP toolkit crash: rfc822.c legacy routine buffer overflow). (Fixes CVE-2008-2829)

Additionally, Stefan Esser described a vulnerability that was silently fixed in PHP 5.2.8.

Obviously this update not only includes security updates but also a large number (170) of bug fixes that probably makes it worth the update. Many of these non-security fixes solve stability issues and make this update worth it. However the security issues fixed in this version may in some cases force your organization to upgrade some or all of its PHP installations depending on the case. In this post I will be describing these vulnerabilities in more detail so that one can easily prioritize application of this PHP update.

Upgraded PCRE to version 7.8 which addresses CVE-2008-2371

What is CVE-2008-2371 about? The Changelog from PCRE gives the following description:

11. An option change at the start of a pattern that had top-level alternatives
    could cause overwriting and/or a crash. This command provoked a crash in
    some environments:

      printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest

    This potential security problem was recorded as CVE-2008-2371.

To exploit this vulnerability an attacker needs to be able to pass regular expressions to the pcre_* functions. The most obvious case where this is an issue is when a PHP script allows regular expressions to be defined by the user. For example, plugin for WordPress called Search Regex might expose this vulnerability. If this particular WordPress plugin only available to the administrator who is doing a WordPress migration, then the vulnerability is somewhat contained. There are cases where the website administrator or webmaster is not given system access to the website. In this context, this vulnerability will indeed affect the PHP installation. Another possibility is that an attacker can target the administrator by making use of an additional vulnerability such as Cross Site Request Forgery (XSRF).

Fixed missing initialization of BG(page_uid) and BG(page_gid)

Details of this vulnerability were published by SecurityReason on Bugtraq and various security mailing lists. The advisory describes a vulnerability where the first Apache child process will incorrectly set the uid to 0 which is normally assigned to the root user on UNIX and Linux systems. The correct behavior would be to assign the uid to the correct user, typically the “www” user for Apache. By making use of this vulnerability, an attacker may be able to bypass certain security restrictions that PHP’s safe_mode is meant to apply. So who can this attacker be? It will have to be someone who can modify the php flags (modify php.ini or htaccess), which is typically someone with access to modify .htaccess or php.ini. I am waiting for feedback from the security researcher who discovered this vulnerability, so this description is subject to change.

ZipArchive::extractTo() silent fix

As described before, PHP fixed a vulnerability that was reported by Stefan Esser in the zip extraction functions. This is a traditional directory traversal vulnerability that allows attackers to dump their files anywhere that the Apache user can write to. In this case, the attacker will upload a zip file to the PHP script in question which includes compressed files with filenames such as “../../../var/www/backdoor.php”. PHP scripts that extract uploaded zip files on the fly would expose this vulnerability. Websites allowing such functionality should be immediately upgraded to the latest version of PHP which fixes this vulnerability.

That’s it for now. Part two of this post coming up soon!

These measures address security issues associated with passwords by introducing an additional secret that is not static. The problem with passwords is that they can be easily copied and abused. Additionally, it is not easy to choose a unique and hard to guess password for each service that you subscribe to.  That makes passwords one of the major security nightmares for services such as PayPal and your local bank. Two factor authentication addresses these concerns.

What two factor authentication does not target is web application security flaws. One of the questions that I have been asked when presenting my Surf Jacking research was “but doesn’t the security token prevent stealing other user’s credentials?” The answer to that is that yes it does but that does not prevent this particular attack. If your web application has a security flaw such as Cross Site Scripting then the attacker never needs to get your credentials. Such attacks usually happen after the victim has authenticated by supplying his username, password and secret key. Once clients authenticate to a web application, the web application assigns a session cookie to the web client. Many account hijacking attacks target this behavior by stealing the session cookie rather than the password or the secret 6 digit key. What this means is that at the end of the day, the overall security of a web application does not only rely on strong authentication methods, but also on the security of the web application itself.

An internal attacker who exploits vulnerabilities on an internal web application, or even one that is external and visited frequently by internal employees, has a number of options. Cross Site Scripting is usually used to steal session cookies, deface websites or inject javascript that attempts to exploit browser vulnerabilities. But what if the vulnerable website starts redirecting internal users to a malicious HTTP server on the internal network that asks for the NTLM authentication? What happens is that it will negotiate and send the NTLM credentials!

What is NTLM? (based on this Wikipedia article)

NTLM (NT LAN Manager) (not to be confused with LAN Manager) is a Microsoft authentication protocol used with the SMB protocol. MS-CHAP is similar and is used for authentication with Microsoft remote access protocols. During protocol negotiation, the internal name is nt lm 0.12. The version number 0.12 has not been explained. It is the successor of LANMAN (Microsoft LAN Manager), an older Microsoft authentication protocol, and attempted to be backwards compatible with LANMAN. NTLM was followed by NTLMv2, at which time the original was renamed NTLMv1.

What can an attacker with NTLM credentials do?
These are a few of the ideas:

• Traditionally attackers would use a password cracker like Cain and Abel to obtain the user’s password from the hash. From there they would proceed to further attacks. However breaking passwords can be a time consuming job.
• With new tools such as Squirtle and Smbrelay3 one no longer needs to obtain the passwords. Instead these attack tools allow malicious users to make use of the NTLM credentials to login as the victim on a target server of their choice. NTLM credentials can then be used on network shares, IMAP servers, SQL servers and any other software that supports this authentication scheme.

Very recently Microsoft published a security patch (MS08-068) that mitigates some of the issues associated with NTLM authentication. This means that if a victim running the latest patches sends his / her NTLM credentials to an attacker’s malicious HTTP server, the attacker can no longer replay these credentials on the victim’s workstation or server. However this patch only protects against this particular scenario, and therefore the attack would still work if the attacker simply accesses a different machine with the victim’s credentials.

What can one do to mitigate this security issue?

From a web application security point of view, it is important to threat internal web applications as part of the attack surface. Although Cross Site Scripting is not the only way of luring victims into automatically sending their NTLM credentials on an internal network, it definitely is one of the most effective. Therefore fixing such vulnerabilities in your internal web applications can help mitigate this and many other attack vectors that may apply to your organization.

This is not the first worm to make use of social networking sites for distribution. Social networking sites are the perfect way of distributing worms in the Web 2.0 world. By their nature, social networking is virulent – very much like malware – and can help reach a large group of people.  Some worms previously made use of web application attacks like Cross Site Scripting (XSS) and Cross Site Request forgery (CSRF). In fact the more complex and popular social networking sites become, the more chance that such sites are used as a platform to launch malware. Usage of technologies such as Ajax make the websites more useful and easier to use. As a side effect, they also tend to expose such sites to new risks that were previously not thought to be a security issue.

For example, Facebook supports online Apps that have been found to hide malicious code. One particular malicious Facebook App called ‘Secret Crush‘ was discovered to be spreading early 2008. It attempted to install adware on the victim computers. Web application vulnerabilities together with a bit of social engineering can proof to be a very effective weapon in a malware writer’s arsenal.

Other posts that mention Koobface:

• Facebook Worm
• Koobface Facebook worm still spreading