A few days ago the Federal Trade Commission (FTC) has formally announced that they have notified almost 100 organizations about sensitive information that they have identified on P2P file-sharing systems. This data includes “health-related information, financial records, and drivers’ license and social security numbers” that has been inadvertently released by these organization’s employees. The notices were sent to both public and private organizations, ranging from very small (8 employees) to very large public companies with thousands of employees. It is believed that this data was released mainly through the user’s misunderstanding on how to properly configure the P2P software. This resulted in all files on their systems to be shared.
Alain Sheer, an attorney with the FTC’s Bureau of Consumer Protection, was recently quoted on ComputerWorld as saying “that as part of the investigations, the FTC will collect information from each company to see if they may have violated data privacy laws. Generally, such investigations are the first step toward a formal compliant being lodged against a company by the FTC.”
We’ve seen similar stories to this in the past as well, including where the plans of the President’s helicopter, Marine One, were found on a P2P network from a contractor. So the big question is how are these companies going to address this issue? Is this simply a user who downloaded the P2P software, and installed it on a work computer without knowing better? This could be addressed (at least from a due diligence perspective) with improved company security policies and user awareness training – possibly even going so far as blocking P2P ports at the network level. But what if this is a result of employees bringing work home, and working on it on their home computers because of all of the company cutbacks during the down economy? Most companies are asking all of their employees to do more with less these days. In either case, it will be interesting to see how the FTC continues with these investigations and what, if anything, will the organizations outside of the purview of the FTC do about these notices?
All in all, it goes to show how good security policies, that are well implemented, and backed with strong user awareness training should be a fundamental building block for any company – regardless of size, or number of employees.
Additional information from the FTC can be found here:
The Web Application Security Consortium (WASC) recently posted their Web Application Security Statistics Project results for 2008. I found this an interesting read because of the unique approach they took in collecting and analyzing the data where the results are separated by how the information was gathered: Automated Vulnerability Scanning, Black Box Testing, or White Box Testing. Not only are the results themselves interesting, but there were some interesting conclusions that were drawn about how certain types of vulnerabilities are best identified.
The statistics includes data about 12,186 web applications with 97,554 detected vulnerabilities of different risk levels identified. The WASC site provides their own conclusions, but the one that jumped out to me was that “the probability to detect a urgent or critical error in dynamic web application is about 49% by automatic scanning and 96% by comprehensive expert analysis”. This truly is the belief of Clear Skies Security and why we have developed our assessment services to be focused on manual assessment techniques over the simpler automated scanning. Customer’s are always questioning why our services seem to take so much longer (and therefore cost more), so it is nice to finally have some numbers to back up our approach – quite simply, expert analysis is going to find almost twice as many issues as an automated scanner. Tools simply can not replace the thought processes a potential malicious user would attempt to identify vulnerabilities.
Bottom line, when it comes to security there is never a silver bullet. Given that 13% of the sites were exploited with just automated scanning, it should be a given that all business that have custom web applications should perform automated scanning at a minimum. Then depending on risk level, more analysis should be done through manual exploitation attempts, or whitebox testing for the most sensitive of sites. And as the applications grow and change, security testing should be continually validating the sites for potential new vulnerabilities. By leveraging a true security life cycle model, starting in the development process, and maintained through regular assessments is the best process to keeping your data safe.
I’m often asked to comment on cloud security but it’s hard to generalize when no two clouds are the same. The security of a particular cloud provider really depends on its hardware, software, back-end implementation, and diligence and competence of the staff.
As an outside customer you generally have to trust that a vendor has implemented their version of a cloud properly and as they describe. The stability and reliability of cloud infrastructure has recently been tested with two significant data losses occurring in the last week or so.
First, the servers that support the SideKick cell phone, manufactured by Danger, Inc, had a major failure. Users who need to restore from the server found that they no longer have any of their data. Microsoft, who now owns Danger, recommended that users do anything in their power from having to restore from the server while they try to recover the system. As of Oct 20, Microsoft has released information on how to restore user’s contact information, with other information such as photos, notes, or to-do items still not recoverable. General repair information is in this Microsoft Announcement.
The second major failure was from SwissDisk a cloud storage provider that seemed to lose ALL user data. This was reported by The Register, with strangely no hint of a problem on the vendor’s website. It would appear that SwissDisk is asking users to re-upload all data to their system since they have ‘outsourced’ to a new cloud provider, presumably deciding not to use their own hardware anymore.
Many people believe the cloud to be an infallible platform for complete corporate infrastructure outsourcing. In reality, a provider needs to be carefully selected for their infrastructure and disaster planning. It suddenly feels like clouds can fall as easily as the corporate servers that they are replacing. The moral of the story is that “Cloud Providers Matter”, so make sure you learn about the company housing your data.
In follow up to the last posting regarding the logic flaws found in the Sears.com website, the NY Times was also recently tricked into serving Scareware through its online ad system. This is certainly not the first time something like this has been done, and probably won’t be the last…but in my opinion the interesting aspect to this whole story is that the individuals posting the ad followed proper ad channels – this was not your typical site hijacking where content was replaced.
According to the reports, the individuals placed an ad through the ad network systems for what appeared to be a legitimate ad for Vonage. The ad content was even reviewed and approved by the NY Times ad operations team. The flaw in the process was that they allowed an outside vendor to host the ad content through the use of iFrames. Since the ad appeared to be from a prior NY Times customer, Vonage, the outside vendor was not vetted any further.
Then the individuals waited for the weekend when the NY Times IT staff would be less likely to notice the activity, and the legitimate ad content on the hosted site was changed to push out Scareware. The Scareware was designed to try to scare people into believing their computers were infected and entice them to purchase fake anti-virus software. Given that most consumers are probably not that tech savvy, and they believed it was coming from a trusted site, many probably opted into buying the software. I have yet to see an analysis of the malware itself, but it would be the perfect vehicle to inject keystroke monitoring software to capture passwords or bank account information as well.
It just goes to show that it truly is the wild, wild, Internet – but more importantly security professionals in all industries have more and more attack vectors to watch out for and any short cuts they may take could have devastating effects.
A new vulnerability was recently found on the Sears.com website allowing external users to automate the validation process of potential gift card numbers and the associated PIN. With this kind of automated testing it is possible to brute force your way through identifying valid gift card numbers by determining which ones are not valid. Given that there really is not a lot of other controls around using gift cards this method is an easy way to collect gift card numbers for fraudulent online purchases.
The vulnerability was identified by an independent researcher who noted that the normal validation process solely relied on client side cookies to limit validation process attempts. By scripting an automated process directly to the server, bypassing the client side cookies, they were able to automate the validation process very quickly with no other limitations in place.
This is obviously a poor coding practice on many levels, but more importantly I believe it really validates the need for true manual penetration testing. In essence this boiled down to a logic flaw in how the process was implemented, which is not something that would necessarily be picked up by an automated application scanner. Clear Skies’ has always believed that the best assessment approach is to rely on a mixture of automated tools and manual testing by an experienced assessor (see prior post on SlideShow Pro as an example). This finding is yet another great real world example of why we strongly encourage clients to not just do the minimum when it comes to testing their applications, especially when there is significant amounts of home-grown code involved. And lastly, given that the Sears.com site appears to have been PCI certified, it further validates that being compliant (i.e the minimum) does not equate to being secure.
More information on the vulnerability can be found at these links:
Clear Skies recently published a vulnerability advisory for SlideShowPro Director. The vulnerability in this particular piece of software may not impact most people, but how the vulnerability itself was found is an interesting example of the benefit of good penetration testing.
The SlideShowPro Director software essentially constructs slideshows and creates XML objects referencing graphics, slide notes, audio, etc which is passed to a Flash client-side object. This was just one of many functions integrated into a customer’s web application. From a penetration test perspective, only the Flash player (a .SWF file) and the XML file is visible, which provides data like this snippet:
<?xml version="1.0" encoding="utf-8"?>
<!-- XML Generated by SlideShowPro Director v1.3.8 http://www.slideshowpro.net -->
<gallery title="masked" description="masked">
<album title="masked" description="" lgPath="http://masked/ssp_director/p.php?a=" tnPath="http://masked/ssp_director/p.php?a=" tn="http://masked/ssp_director/p.php?a=XF9VXiEyPSoqQFtFPzU2JzM6Iys%2BPiYyKzM5LTM%2BMiU%2BJzE%3D&m=1247688172">
<img id="991" src="XF9VXiEyPSQqQFtFPzU2Jzc8Jis9ODouNyoxMS4jKyAiPjQj&m=1247688169" file="IMG_2867.JPG" tn="XF9VXiEyPSQqQFtFPzU2JzM%2FJiswOyYzKzM5LTM%2BMiU%2BJzE%3D&m=1247688169" dims="640,480" fp="50,50" link="javascript:if (window.NewWindow) { NewWindow.close(); };
Multiple network and application vulnerability scanners were run against this installation and did not detect any problem here. And for the most part I wouldn’t expect them too either.
As a security professional, however, any data going into (or out of) a system is eyed with suspicion. Most data is obvious – it’s a number, a string, a flag, etc, so it’s usually simple to understand how it may be used by the application and how to test it. But what about odd looking base64 encoded values?? Well, that’s an unknown that immediately grabbed my attention as I needed to figure out what it is and how it’s used.
This particular function is written in PHP. One possible approach would be to get access to the PHP source code and read through it to see how the data is used. Performing a source code review would have found this issue, and some source code analysis tools may as well.
This software, however, was encountered on a remote penetration test, so reviewing source code was not an option. While that may seem like a problem at first, it really isn’t – at least not to experienced penetration testers/hackers/etc. It’s not like a good arborist needs to cut down a tree or a good mechanic needs to take apart your entire car to tell you if you have problems, right? Of course there will be issues that are essentially impossible to find without manually reviewing the application code, but from my experience, doing this for the last decade, the vast majority of issues you really need to worry about being exploited can be found through penetration testing.
So, the bas64 encoded values look like gibberish when they’re decoded. But comparing various values along with the other data for this function, there appears to be some similarities:
Value1a: YHdpb35mZHR2cjQ8cmViOmB/ZnN9IjgmPSYxJig5PSA3PzQqIT85OSQ7MCI0IDU=
Hex: 6077696f7e6664747672343c7265623a607f66737d2238263d26312628393d20373f342a213f3939243b3022342035
Value1b: adminimage1.jpg
Hex: 61646d696e696d616765312e6a7067
Value2a: YHdpb35mZHR2cjc8aHtiOmB/ZnN9IjgmPSYxJig5PSA3PzQqIT85OSQ7MCI0IDU=
Hex: 6077696f7e6664747672373c687b623a607f66737d2238263d26312628393d20373f342a213f3939243b3022342035
Value2b: adminimage2.png
Hex: 61646d696e696d616765322e706e67
Value3a: dnZmWSA9VmZ0e2BxbGB2c3NgKnZ+aCV0fXVwfzUkNjowJzA2PDc/Iz0nKSMoJSkjLSY0KiU/
Hex: 76766659203d5666747b60716c60767373602a767e6825747d75707f3524363a302730363c373f233d272923282529232d26342a253f
Value3b: web_02_selectusers.png
Hex: 7765625f30325f73656c65637475736572732e706e67
Looking at these values with a security eye, two things stand out: 1) the “scrambled” values are longer for longer inputs and 2) portions of the input with similar values seem to correspond to similar values in the “scrambled” output. Both of these are signs of some kind of encoding that is definitely not strong encryption. This opens the door from a pen-test perspective to do some analysis and determine exactly what the application is doing.
This couldn’t just be a substitution cipher since the same characters in the plaintext encrypted to different ciphertext depending on the position in the string. For example, the first “l” encodes to hex 65, while the second encodes to hex 6c. At the same time, the same letter in the same position in different inputs (such as the “g” at the end of the first two input strings) encodes to the same output value, which indicates there is some kind of big-flipping scheme being used.
So being a very manual type of person, next came a bunch of scribbles on paper to see how the characters were related. Consider one location in the three strings where there are different characters, such as the 1 in xsellerate1, 2 in xsellerate2, and e in xse_02_sele… Doing various binary math, one calculation stands out: the “exclusive or” of the string and the encoded value produce the same result for all three sets:
1:31 0011 0001 2:32 0011 0010 e:65 0110 0101
27 0010 0111 24 0010 0100 73 0111 0011
xo=0001 0110 xo=0001 0110 xo=0001 0110
This is a classic indication of a basic “XOR cipher”. The problem with that type of cipher is if you have both the plaintext and the output text, it is possible to determine the key that is being used. I’ll spare the gory details, but it’s really just a matter of doing the same calculations above for several different inputs. A simple program was written to compare the encrypted and plaintext value and return the associated key:
$ perl ssp-findkey.pl
Enter Ciphertext: dnZmWSA9VmZ0e2BxbGB2c3NgKnZ+aCV0fXVwfzUkNjowJzA2PDc/Iz0nKSMoJSkjLSY0KiU/
Enter Plaintext: web_02_selectusers.png
Key: asdfpoiuqwerxuevasdfpoet}upudvzpgpv|wc}gicheicmftj
The output begins to repeat after 16 characters, so the key is really the first part: “asdfpoiuqwerxuev”.
With this information, all of the other tests we’d normally perform in a penetration test can be performed using this key. We can now decode the full value of these parameters:
$ perl ssp-decode2.pl
Enter Ciphertext: dnZmWSA9VmZ0e2BxbGB2c3NgKnZ+aCV0fXVwfzUkNjowJzA2PDc/Iz0nKSMoJSkjLSY0KiU/
Decrypt: web_02_selectusers.png,album-13,1440,866,0,100,5,50,50
And do other things, like perform path manipulation to coerce the software to display unauthorized system files:
$ perl ssp-encode.pl
..\..\..\..\..\..\..\..\..\..\..\..\inetpub\wwwroot\site\docs\ssp_director\config\conf.php,test,1440,866,2,100,5,50,50
http://site/ssp_director/p.php?a=Lz1YKD5TJztNOStONjtZOC9PKihMISdJPzlZPDZJKzhdPSpaeWFsYWFiZ05vYnJkbnxwWmNmfXBNc2pxa0l2ZXFMYG9iamphfmVZcXd7Y39mT2dpfmknZXlnKWZ9ZnE6MCcwNjw3PyM9JSkjKCUpIy0m%0ANColPw%3D%3D%0A
This path manipulation is the core issue of the vulnerability that was brought to the attention and corrected by the software developer. While the weak encoding and the ability to break this was instrumental in finding other flaws, by itself it is not considered a flaw since the data encoded is not considered to be confidential or untamperable.
Bottom line, this is just one of many examples of the value an experienced professional brings to high quality penetration tests and application assessments. It is why these types of engagements (when performed properly) are much more than just running automated tools and interpreting the results.
According to Trend Micro a new variant of the Mac OS X Trojan, OSX_JAHLAV, has been found in the wild. The new version, OSX_JAHLAV.D, is a new variant from the .C release identified back in June of this year.
The malware presents itself as an updated video codec for the Quicktime player, and is pushed out by malicious websites as a required Quicktime update needed to view video content on the site. It is downloaded as a Mac Disk Image file (QuickTimeUpdate.dmg) and has an associated installer program for “MacCinema”. When run, the malware changes the DNS settings on the local machine allowing future web traffic to be redirected to sites of the hacker’s choosing.
Obviously to be infected by this Trojan requires downloading the file, running the installer script, and entering valid user credentials, and the overall impact of the trojan is pretty mild. However, what I find interesting about this particular threat is that it is clearly trying to take advantage of the less savvy Mac user’s belief that they are safe from all bad things on the net. And more importantly, I believe it reiterates the belief that the bad guys will continually find new ways to make money – although a simple attack, if successful, it can provide an easy avenue to potentially trick naive Mac users into buying things from these fake websites just because things are not working the way they expect. Given that, I believe we will continue to see more and more updates to this malware and others like it as the growing Mac community provides a new “green market” for malware.
More information on this trojan, and specifically IPs associated with the malware, can be found on Trend’s site.
Clear Skies Security has just posted an advisory for users of SlideShowPro Director. Anyone using this product that has not upgraded in the last 2 weeks is strongly urged to do so. Versions prior to 1.3.9 (released 7/23) can be exploited to access files directly through the web server.
This issue was found during a penetration test of a customer last month. Clear Skies has been working with the vendor directly to review the security risks, and corrective actions. Coming from a large security organization, it has been very refreshing to be able to follow through on these types of issues directly so our findings can benefit the public at large.
Lastly, Clear Skies would like to thank the vendor, Dominey Design. They were thankful to receive the vulnerability information and were very responsive, quickly addressing the issue and providing an update within days of initial contact.
For the more technically inclined, Clear Skies consultant, Scott Miles, will be posting a separate entry on how this kind of issue is found, which really highlights the value that a good penetration test should provide.
New research from Antivirus firm F-Secure has stumbled across the first SMS worm in the wild. Currently known as the “Yxe”, ” Sexy Space”, or ” Sexy View” the worm targets cellular phones running the Symbian based OS, which accounts for 49% of the smartphone market. Infection occurs when a user follows a link to a malicious website from within a SMS message. The message will appear to come from someone you know since the worm spreads by sending out new SMS messages to everyone stored in the address book of the infected phone – all text messaging fees incurred in generating the new traffic also apply. In addition to spreading, the worm also captures information from the infected phone and sends it away, including the IMEI number of the phone.
When the malicious link is followed the user will automatically receive a SIS installation package, which will display the prompt: “Install Sexy Space? Yes or No.” The package that is received is actually a “signed” package, which prevents any security warnings from being displayed on the phone. It is believed that the virus writer submitted the malware through the “Express Signing” procedure, where most applications are not inspected by humans. Although Symbian has now revoked these signatures it will take some time for the propagation to occur.
Although the infection is currently limited to China and the Middle East, if your company currently utilizes Symbian based smartphones it might warrant further investigation. More information about the virus and how to manually revoke these certificates can be found on the F-Secure site.
According to a recent news story, Trustwave has announced that they have identified new malware running on ATMs within eastern Europe. All of the infected ATMs are running the Windows XP operating system. Although this version of the malware does not appear to be self-propagating, it is believed that this could easily be an added feature in the next version, and would allow the malware to spread across the ATM network.
It appears that the systems were originally affected through some kind of an insider (employee at the bank, the ATM vendor, or a company that services the machines). The original infection seems to start with a dropper file (isadmin.exe – a Borland Delphi Rapid Application Development executable), and once executed produces the malware file lsass.exe within the C:\WINDOWS directory of the compromised system. The malware then manipulates the Protected Storage Service to point to the malware instead of the legitimate lsass service. The malware is also configured to automatically restart on a system crash to ensure it remains active.
Given that the ATMs were WinXP systems, I am not at all surprised that they were attacked by malware – it is not the first successful attack on an ATM and certainly won’t be the last. What I find surprising though, is the level of sophistication the malware already has built into it for compromising the ATM machine itself. The reports indicate that the malware is able to output the “harvested card data via the ATM’s receipt printer or by writing the data to an electronic storage device inserted into the ATM’s card reader. Analysts also discovered code enabling the malware to eject the cash dispensing cassette.” If that’s not surprising enough, the malware also has a built in management interface that can be triggered by a controller card being inserted into the card reader. Once triggered, the interface allows for complete control of the device using the ATM’s keypad to execute 10 built-in command options.
A standard ATM can hold up to $600,000 in cash at a time, and that would be reason enough to make them a prime target for this kind of exploitation. However, given the level of sophistication this malware already has developed, I would speculate that the prime motivation is to target the magnetic strip data and PIN number, which is also being captured.
Although it appears only about 20 devices in total have been infected to date, I would agree with the initial reports that this is only the beginning and it won’t be long before we start to see similar incidents here in the US.
More information can be found at cnet, Network World, and TG Daily.
