Real world example – discovering new vulnerabilities during penetration testing
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.
