Vulnerabilities

You are currently browsing the archive for the Vulnerabilities category.

NewsandObserver.com Weak Authentication

February 16, 2010 in Hacking, Vulnerabilities | 5 comments

Recently I decided that I would no longer maintain my subscription to the local newspaper, .  Like many people I find that I get most of my news online these days and didn’t want to continue paying for something I didn’t use.  I decided to look at their web site to see if I could cancel my subscription online.  This is where I discovered that the newsandobserver.com uses a terrible authentication mechanism that can lead to the disclosure of personal information and unauthorized changes to paper delivery and other subscription options.

The crux of the problem is that the web site relies on publicly available information to authenticate subscribers.  Below is a screenshot of the subscriber login screen.

As you can see, all that is required to login to a subscriber account is a phone number and house number.  Both of these pieces of information are easily obtained online for most people.  After authentication, you have access to the subscriber’s account where you can gain additional information about the them.  The most important information that you can get access to is the subscriber’s email address.  This would be useful to scammers who could setup a fake site that resembles the real newsandobserver.com, send the subscriber an email telling them that they need to update their account information, and then obtain their credit card or other financial account data.  Below is a screenshot of my account home page.

Another thing that you can do within the subscriber section is manipulate delivery options.  For example, you can put stops on delivery or extend your subscription.  This would allow an unauthorized person to put a hold on someone else’s paper delivery or even change the length of their subscription, both of which could have a financial impact on the subscriber.  Below is a screenshot showing the ability to change these options.

Lastly, subscribers are able to change their personal information such as email address and phone number.  There is also a check-box to disable email notification of account changes.  A scammer could use this option to prevent notifications from being sent to the subscriber after he made changes to the account.  By updating the email address and phone number to one of his choosing, he may even be able to use social engineering to obtain credit card information from an N&O customer service representative.  Below is a screenshot of the page that allows a subscriber to change personal information.

Such a weak authentication mechanism is inexcusable for the second largest newspaper in the state of North Carolina.  With over 750,000 print and online readers, there are many opportunities for scammers to use this weakness to obtain subscribers’ personally identifiable information and potentially additional financial information.  It would not be difficult to automate a process for gathering phone numbers and house numbers for prominent people in North Carolina, many of whom are likely to subscribe to the News and Observer, attempt to login as these individuals, and obtain their email addresses.  With such a list in hand, it would be possible to send them fake emails appearing to be from the N&O that could trick them into divulging their credit card numbers.

I have contacted the NewsandObserver.com to report this vulnerability to them.  Remediation is not difficult.  There are many types of authentication mechanisms that work well and the OWASP has a dedicated to this topic.  I hope that they take advantage of it to correct this issue.

Mac Users Beware

January 18, 2010 in Browser security, malware, Vulnerabilities | 1 comment

apple-chains

The conversation usually goes something like this:

Me:  “Hey, have you heard about that new phishing attack targeting Bank of America customers?”

Mac User:  “Oh, I’m not worried about that.  I use a Mac.”

Me: “Well you know, just because you use a Mac doesn’t mean you are safe from an attack.”

Mac User: “Ha.  Everyone knows that Macs are waaaay more secure than Windows systems.”

If I had a nickel for every time I have heard a Mac user make some type of statement to this effect, I would not have to buy any more lottery tickets.  There is a widespread belief that Mac OS X is inherently more secure than Windows and that by using a Mac, one is protected from all threats.  Unfortunately, not only is this not true, but it is dangerous as it leads people to not take appropriate precautions to protect their computers and information.

Let’s start with some basic facts.  I performed a search of the and found the below data regarding Windows and OS X vulnerabilities:

Year # of OS X Vulns # of Vista Vulns
2007 152 61
2008 117 61
2009 101 106

These numbers represent the total number of vulnerabilities published for each of the last 3 years for Mac OS X (all versions) and Microsoft Windows Vista (all versions).  It is clear that OS X has had more total vulnerabilities in the last 3 years than Vista has.  These vulnerabilities provide potential avenues of attack for hackers which can lead to system compromise and data disclosure.

But that is only the tip of the iceberg.  Phishing scams, trojans, drive by downloads and other threats don’t depend on any vulnerability in software in order to be successful.  The weakness they exploit is in the user of the computer.  It doesn’t matter whether you use a Mac, a PC, a Next, or a Cray.  If you fall victim to one of these types of attacks that relies on social engineering to get users to divulge their credentials or install malware, using a Mac doesn’t offer you any protection at all.

Given the fact that Mac OS X has plenty of vulnerabilities, it might seem surprising that there is not more malware in the wild that exploits these weaknesses.  I believe the answer to this riddle can be found in the relative percentage of Windows to Mac users.  Most studies have found that Apple has between 7% – 12% market penetration, while Microsoft maintains nearly 85% market share.  If you are a hacker hoping to exploit vulnerabilities, it clearly makes more sense to devote your time and resources to the Windows platform since your odds of success will be much higher.  However, as the percentage of Mac OS X users grows, the number of exploits that target OS X will also grow.  So Mac users take note.  Do not be lulled into a false sense of security.  Be sure to follow for protecting your computer and your data in order to minimize the risk of a successful attack.

OpenX 2.8.1 Vulnerability

November 24, 2009 in Vulnerabilities | No comments

The following information was recently posted to a well known information security mailing list.

OpenX adserver version 2.8.1 and lower is vulnerable to remote code execution. To be exploited, this vulnerability requires banner / file upload permissions, such as granted to the ‘advertiser’ and ‘administrator’ roles.

This vulnerability is caused by the (insecure) file upload mechanism of affected OpenX versions. These would check magic bytes of an uploaded file to determine its MIME type, and erroneously assume this information to be reliable. Additionally, while the file name of uploaded files is changed, the file extension is not.

As such, it is possible to upload image files with embedded PHP code and .php file extension. Unless PHP script execution is explicitly prevented for the file upload location (which has not been documented in the OpenX manual so far and it is not the result of a default installation), the PHP code will execute as soon as HTTP access to the file location will cause it to be executed by the web server.

To clarify, an attacker exploiting this security issue does require prior access to OpenX, i.e. exploitation is only possible after successful authentication. On the other hand, advertiser access is a rather low permission level and should not allow for system access.

If these bugs were not hidden from OpenX’ bug tracker, you could read up more about issue X-5747 here:

OpenX 2.8.2 has already been released in October to fix this issue and can be downloaded from

Credit goes to for disclosing this vulnerability.

Putting the TLS Vulnerability Into Perspective

November 9, 2009 in Cryptography, Vulnerabilities, Web | 2 comments

Introduction

Late last week it was disclosed by security researchers Marsh Ray and Steve Dispensa that a design flaw in TLS (the IETF implementation of SSL) could allow an attacker to successfully inject data in an encrypted session using a man-in-the-middle (MITM) attack.   The primary problem occurs during the renegotiation of the TLS channel when client certificates are employed.  Their documents the vulnerabilities in the TLS protocol as well as how the vulnerabilities could be exploited to violate the integrity of the data stream between a web client and server.  Even though the encrypted data cannot be read by the attacker, it is possible to inject arbitrary data into an authenticated session and it will be treated by the server as if it came from the client.  I will discuss the risks associated with this important discovery and outline some potential attack scenarios.

Putting the Risk Into Perspective

  • As mentioned previously, this vulnerability primarily affects sessions in which client certs are in use.  The vast majority of secured TLS sessions today do not involve client certs which limits the impact of this vulnerability.  For example, if you are shopping online or connecting to your bank over the Internet, it is almost certainly the case that a client cert is not in use.  Where client certs are sometimes used is in enterprise applications such as external access to corporate email.  Some companies require the use of client certs in this scenario.  Also, TLS sessions between systems used as part of a web application (e.g. SOAP calls) sometimes utilize client certs for greater security.  However, for most users client side certs are a non-issue which limits the scope of this vulnerability.
  • Another limiting factor of this vulnerability is the fact that it can only be exploited via a MITM attack.  MITM attacks are fairly difficult to successfully execute as it requires the interception of the network traffic between the client and the server.  While this is not impossible, it certainly would require some additional work.  In many cases, the hacking that would be necessary just to pull of the MITM attack would lead to greater potential rewards than the hacking of the TLS connection.  Some examples of MITM techniques include:
  1. Compromising the network of either the client or the server (e.g. ARP poisoning)
  2. Manipulating the DNS server of the client
  3. Taking advantage of an unsecured WIFI network connected to either the client or the server
  4. Using social engineering to compromise either the client or the server
  5. Compromising a proxy server used by either the client or the server
  • The results of an attack against this vulnerability do not allow the attacker to see any encrypted data sent by the client or the server.  It could allow an attacker to inject commands into the session which the server would believe came from the client and would execute.  However, the attacker would not be able to see the results which limits the impact of this vulnerability.  This situation clearly violates the integrity of the session, but the amount of damage that can be done is limited.
  • This vulnerability does affect more than just HTTP.  This is the most common protocol to use TLS, but others do as well (e.g. IMAP).  The shear scope of applications and protocols that rely on it warrants a fix to ensure that developers and end users can be confident in the behavior and security of their applications.

Summary

The vulnerability in the TLS protocol disclosed on November 4, 2009 is not likely to lead to a great deal of exploitation.  The primary reasons are the difficulty required to successfully launch an attack and the limited nature of the vulnerability and the how it can be exploited.  Most attacks today are financially motivated and are conducted by groups that understand how to perform a cost benefit analysis.  I suspect that they will look at this vulnerability and decide that there are easier ways to exploit systems for monetary gain and it will not be worth their time to devote resources to develop exploits for this one.  The pay off is simply not high enough.  In sum, I believe the risk to most individuals and organizations is fairly low.  Fixes are already being rolled out, but given the extent to which TLS is used today, it will likely be many years before all applications and devices have been remediated.  Even still, I will be surprised if we read about any significant compromises in the future that are attributable to this vulnerability.

Sources for Additional Reading

DreamPoll 3.1 Vulnerabilities

October 7, 2009 in Research, Vulnerabilities, Web | No comments

hack

During a recent security audit of the DreamPoll 3.1 software by , I discovered a number of XSS and SQL Injection vulnerabilities in the application.  These vulnerabilities could be exploited to make unauthorized changes to a web site or compromise a client accessing a site that utilizes the application.  Details of the vulnerabilities are as follows:

XSS
————————-
File: index.php
Variable: recordsPerPage
Example: GET /index.php?action=login&sortField=poll_default&sortDesc=1&recordsPerPage=1>”>

Blind SQL/Xpath Injection
————————-
File: index.php
Variable: sortField
Example: GET /index.php?action=loginsortField=poll_default+and+31337-31337=0&sortDesc=1&recordsPerPage=20

Blind SQL Injection (Timing)
————————-

File: index.php
Variables: sortField, sortDesc, pageNumber
Example: GET /index.php?action=loginsortField=poll_default+and+sleep(3)%23&sortDesc=1&recordsPerPage=20

While not specifically tested, it is likely these vulnerabilities exist in earlier versions of this application as well.  The vendor was notified on 09/28/2009 and a fix was released the same day.  If you are a current user of this software, contact the vendor for the available fix.

Comments on Patch Tuesday

September 8, 2009 in Patch Management, Vulnerabilities

patchtuesday

The second Tuesday of the month is always a busy day for IT and security pros.  That, of course, is the day Microsoft releases their regular security updates.  And this month’s list of advisories reminds me how far we have to go before we get an upper hand on the bad guys who exploit vulnerabilities for a living.  Microsoft, like so many other software vendors, continues to release vulnerable software and we continue to apply patches to fix those vulnerabilities.  All the while, systems are exposed and often get compromised due to this game of reactive patch management.

Microsoft released 5 security advisories today to address 8 vulnerabilities:

  • – addresses a vulnerability in Jscript (KB 971961)
  • – addresses a vulnerability in Microsoft Windows (KB 956844)
  • – addresses a vulnerability in Microsoft Windows (KB 973812)
  • – addresses a vulnerability in Microsoft Windows (KB 967723)
  • – addresses a vulnerability in Microsoft Windows (KB 970710)

The first three patches address vulnerabilities that allow a malicious web site to compromise an unpatched machine simply by browsing the web site.  These drive-by exploits are undoubtedly already setup on rogue web servers, compromising vulnerable systems even as I write this.  Microsoft rated MS09-045 and MS09-047 as critical and MS09-046 as important.

The other two, MS09-048 and MS09-049, are more interesting and potentially more problematic.  Both of these vulnerabilities are rated as important by Microsoft, but I would not be surprised if exploits for these two end up doing more damage than the others.  The reason for this is that both of these patches address vulnerabilities in the network stack and do not require any intervention by the end user for exploitation.  This makes them good candidates for exploitation via a worm which increases the criticality of these advisories.  Microsoft believes these vulnerabilities are most likely to be exploited via a denial of service attack as it is difficult to reliably achieve remote code execution.  But denial of service attacks can be very damaging and it is not inconceivable that someone could write a exploit that can smash the stack, resulting in remote code execution.

Microsoft is not alone in releasing regular security patches and expecting us, the end users, to manage the process of performing the updates.  Apple, Adobe, Red Hat, Sun and every other software vendor does the same thing.  While I understand that software development is a complex endeavor, vendors must get better at implementing security testing and vulnerability analysis into their software development life cycle.  But until they do, keep applying those patches.

Security Vendors Lacking Good Security

February 15, 2009 in General Information Security, Vulnerabilities

kettle

In two separate incidents ealier this month, well known security companies had their web sites breached as a result of SQL injection vulnerabilities.  The first was Kaspersky Labs, an anti-virus vendor which on February 9.  Two days later, it was reported that BitDefender, another anti-virus vendor also had their web site hacked by the same Polish hacker who had successfully breached the Kaspersky site.  Again, a SQL injection vulnerability was the cause.

If you do not pay attention to reported incidents and vulnerabilities, you might assume that security vendors would not frequently be the victims of web hacks or have vulnerabilities found in their software.  However, nothing could be further from the truth.  I have been in the security industry for over 13 years and sadly, the companies that are selling security software and services seem to be just as likely as everyone else to be on the wrong end of a security problem.  McAfee, Trend Micro, Barracuda, Cisco and Check Point (to name just a few) all reported serious vulnerabilities in in their products in 2008.  And now we are seeing security companies falling victim to web application attacks as well.

We should demand more from our security vendors.  These are the companies that are securing our infrastructures and protecting our data.  They need to ensure that the products they are selling are secure, because as a consumer of these products, I cannot afford to take the chance that my environment will be compromised due to a weakness in their systems.  And I certainly don’t want to be in a situation where I am frequently applying security patches to my security systems.  I for one will avoid purchasing products from any security vendor that has a poor track record of providing quality, secure products.  This is the only way that they will get the message that we expect more from the vendors that we entrust with the security of our data.

Copyright © 2011 InfoSecStuff.com — All Rights Reserved