I recently had a client inquire about some of the potential risks associated with using a 3rd party web analytics tool.

Businesses normally want to use these tools to report on the behavior of users who visit their site in order to improve customer experience and measure sales performance. All that is required is for the business to include an innocuous JavaScript tag (provided by the 3rd party) into each page they would like to measure. If the user allows javascript to be run, the script is run each time a user visits the website calling a more advanced script back on the 3rd party server.

For example, let’s say I provided a web analytics service and you used me as a 3rd party. I would provide you with the below script and then you would place the following tag on every page of your website…

<script src=http://www.securitytechsience.com/sts.js” type=”text/javascript”></script>

The sts.js script on my server would then run in the user’s browser every time a user visited your site . I would then provide you a log-in page that generates pretty reports for you to see how your user base is behaving.

Sounds great doesn’t it? Now for the risks…

NB: The below risks are applicable for companies that house more than just browser ware web applications.

Integrity of the script – Maybe the script is OK today but what about tomorrow?

How could you be assured that the 3rd party wouldn’t change it? What if the 3rd party server was hacked and replaced with malicious code by someone else? If a change were to occur how long before you would notice? If you did notice then what?

The above questions really hit home to three of the core functions of information security within any organisation…

1. Change control: If the 3rd party wanted to change the script then they should notify you and this would be input to your change control process.
2. Audit & Monitoring: The 3rd party should provide this, but you could just as easily write a script that does an hourly download of the script and compares it to your known good script.
3. Incident Response: If the script were to change without prior change control notification then there should be an incident response plan to follow.

Integrity of the 3rd Party

How could you be sure that the 3rd party uses a level of security practices that are aligned with your organisation? How could you be sure that if things did go wrong you were covered?

The above questions are concerned with a breadth of business units such as operational risk & compliance, legal as well as information security. They would include questions such as…

1. Is there a contract between the third party and the organisation?
2. Does the contract include x, y, z to cover the organisaion in the event of a, b, c?
3. Does the contract include a SAS70 or equivalent?
4. Does the contract in include a monetary figure?
5. Has privacy been considered?

In most (if not all) 3rd party contracts, the above questions favour the 3rd party and not you.

Confidentiality of the Data

How can your be certain that any confidential data remains secure? How is the data (both confidential and non-confidential) transferred?

Although you may be using SSL (ie, https), the 3rd party may not and the data is transferred via http. If this is the case, then any sensitive data passed is transferred across the Internet in the clear.

Even if you are using SSL and the 3rd party is using SSL (ie, https) as well, what if the javascript is requesting http GET requests? In that case, the URI and it’s parameters are passed over the Internet in clear text. For example,

GET https://www.example.com/cc_valid.js?credit_no=123412341234&date=31122008&ccv=123

And finally, do you really want an external script running anywhere near your customer’s sensitive information?

Problem

As you can see the above solution adds some considerable overhead if you want to implement it securely in order to protect your customers data and your company’s reputation. As a business the benefits that were promised at the beginning of sales pitch may not be sounding so great anymore and you may be leaning toward building a solution in-house. Although it is a secure solution, you soon find out it comes at a much higher cost. So is there an alternative solution?

Solution

I would recommend copying the 3rd party script on a local organisational server so that the control of the script is now with you. The company is now forced to contact you when they would like to update the script. You could go even further and ask that the reporting funcitonality is housed on your network. That is, you provide the box and they provide the application. If they won’t allow you to house the application you could always set up a B2B channel with the 3rd party in the cases where sensitive data may be transferred – This channel could be over a dedicated link or VPN using an IPSEC tunnel.

I have just completed a tutorial on how to use the STS Scanner correctly. I believe it to be comprehensive with detailed commands and screen shots but your comments would be appreciated…You can download the pdf tutorial here.

On a side note, I found an interesting blog that mentioned the Security Technology Science site. I think it is worth mentioning that this site has some really detailed and interesting blogs. For starters, here is a link to their 10 day vulnerability assessment found here. You should also check out their blog on Security Testing Tools of 2007 found here.

Anyway, one thing I would like to clarify is a past article I wrote about screen scraping. I mentioned XPath to be “complex” when in fact I should have used different wording. I should have said that I find the use of XPath when crawling an unknown site to be “complex” in comparison to the solution below. What I mean by this is that using XPath to screen scrape a page that is known to me is indeed straight forward (as long as you understand the XPath syntax and the DOM structure), but what happens when you or your tool have never seen the page before? How do I know there is an anchor tag at html/body/div[4]/div/div[2]/ul/li/a/ and not at html/body/div[4]/div/div[2]/ul/a/? Anyway, maybe there is an easy answer to this and an algorithm has already been written but at the time it just seemed a lot easier in Ruby to get all the links on the one page with one line of code…

page.links.each do { |link| ... }

Finally, the STS Scanner uses Mechanize and Hpricot to parse and spider html pages. These libraries are not able to parse and idenitify JavaScript and/or Ajax code. A separate version of the STS Scanner is planned to be developed where the internal core does not rely on these libraries and hence they shall become obsolete. The core shall act more like an everyday browser (i.e., IE, Firefox, etc) so it can hopefully branch out into other applications such as Flash and web services. So those who thought I was going to solve the Web 2.0 problem with these libraries are mistaken…

After a few minor adjustments to the scanner and some additional tweaks to the web crawler, it is time to release the very first version of STS Scanner. All the information about the scanner and where to download is available online here

Requirements:

1. Ruby Interpreter and Ruby Gems
2. Hpricot Ruby Gem

Bugs:

Send all bugs to bugs [at ] securitytechscience [dot] com

Please test responsibly…

Hello everyone!

Sorry for the delay in the release but I have spent the last few months traveling around Asia and haven’t had much time for coding, testing, debugging, etc… Also, I have been spending my weekends down by the beach enjoying myself on Sydney’s sunny shores

I promise to have a release out very soon, possible a New Years Eve treat?

Anyway, one thing is for sure and that is coding is a winter sport.

The concept of writing your own tools has always appealed to me as it offers so many rewards. Apart from the obvious where automating a process provides more time to spend on other bleeding edge areas, some other benefits include:

- Putting into practice all the concepts you have learnt on the job or from whitepapers and presentations etc.

- Being able to share these ideas with a large audience via the Internet and the use of the GPL

- The journey that research and development takes you on and where you don’t really know where you may end up

I want to chat about the last point and some of the work I have been doing over the last month in the development of an application scanner. Continuing on from the educational scanners placed on our site, I have expanded on these ideas to see the difficulty in building an open source scanner that could be comparable to some of the proprietary scanners on the market. Read the rest of this entry »

Following on from the last post, extended scanner is capable of enumerating the back-end DBMS if it is MS SQL, Oracle or MySQL. If these DBMS are discovered, then the tool can enumerate the column number and data types. But what then? How do you use this information to exploit the vulnerability to extract sensitive information or takeover the server? What if the DBMS is say something other than listed above?

To solve this, there are plenty of tools out there (see below) but one pretty cool tool to brute force this information out from the vulnerable application is SQLMap. I recommend that anytime you find a blind SQL injection point, the next step should be to run this tool (or a similar tool) every time. All the information and downloads can be found here and there are plenty of examples in the README. Below is an example of how SQLMap performed on one of our vulnerable test servers.

If you are interested in checking out some other SQL injection tools then see http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners

Read the rest of this entry »

As promised the extended scanner has been released with more intelligent exploitation algorithms to enumerate the SQL backend database. Of course credit should be given where credit is due and the algorthms are all from Ch 9 Network Security Tools by Justin Clarke et al. The only thing I have added is the MySQL code as my demo app has a MySQL backend. Before I chat about this, the code can now perform the following:

Of the above points, the last point is a little dubious when it comes to MySQL. You see, to enumerate the data type of a MS SQL column, you first try a string. If there is no error then it is a string. If not then try a date. If there is no error it is a date. If not then try an integer. Hopefully it is an integer, otherwise the code throws an error. MySQL behaves a little differently when employing the above algorithm. Say you have an integer and you try a string, unlike MS SQL the MySQL databse will have a warning in the backend (which is not visible via the app) but will allow the string. Hence, all columns are enumerated as strings even if the actual backend contains an integer. Nonetheless, the reason to identify the string columns is important so that you can later inject a query to retrieve sensitve information via these string columns. So if MySQL allows strings through integer columns, theoretically then it may not matter if it is a string or an integer and you can retreive the data via any column…this is yet to be tested.

Might chat with Justin to see if he can incorporate MySQL into his tool SQL Brute. For those unaware, when you find the above SQL injection, all you need to do is point his tool at the string columns and it will enumerate (via brute force) the rest of the database procedurally. That is, database names, database tables, database columns and finally database data. You can find a real nice howto here.

Note that I did not incorporate my other promises of more advanced Ruby libraries and better object oriented design schemas. I have kept the code as close to the original so that you at home can follow along with the book. Sorry for those who wanted something with a little more grunt but you are going to have to wait a little while longer…

Nearly forgot: To download click here

SimpleScanner is a Ruby port of the Perl version of SimpleScanner presented in Ch 8 of Network Security Tools by Justin Clarke et al. Refer to www.oreilly.com/catalog/networkst/ for the sample chapter and Perl source code – You can use the chapter to follow along with the source code. You may also want to buy the book as I recommend it to any serious security professional.

Note: This project is more useful as a learning tool and providing insight into the fundamentals of web application testing. But in saying that, it would be better to run this tool on one of your applications then to run nothing at all

I decided to re-write the code in Ruby to pay homage to a friend of mine (Brian Holyfield), who was the original author of the code. There is nothing cutting edge about the scanner today as it only checks for 3 types of vulnerabilities:

1. SQL Injection

2. Cross Site Scripting

3. Directory Listing

Realistically it was just nice to put the Browser::WebGet library I wrote to use in order to show what it could be used for.

You can view the API documentation here.

To download click here.

Things to come…

As I own a copy of the book, it is really the next chapter (9) that is of most interest as it delves into intelligent exploitation algorithms. Using the above code as a baseline, I will extend the current functions in order to build the ExtendedScanner. Along the way I am planning on employing more advanced Ruby libraries and Object Oriented schemas to improve the overall extendability of the code.

Around this time last year I decided to switch languages and regress back to Python.  I guess the main reason was all the add-ons that were being discussed and I wanted to double check I wasn’t missing out on anything since I had left a year or two earlier. At the time I had no real inspiration to write anything in particular, so I focused on writing a wrapper for the Pyton urllib libraries. The idea was to make an object that acted much the same as a lite browser. Basically you could load it up with a URL and any authentication necesary (basic auth, ntlm, cookies, etc) and feed it file paths – The browser should just handle the rest.

The high level plan was to write a wrapper that handled HTTP requests and then place a front-end on it (command line and later a GUI). I drew most of my inspiration from mechanize to build the wrapper and noticed the front-end was just another (albeit smaller) version of cURL. In the end I decided to drop the project due to the rejection of PEP 268 - Due to Python’s design, it is impossible to tunnel anything over a proxy and keep the the same level of authentication and/or SSL.

FYI, I called the project WebGet and the only conceivable use for it is code re-use in other projects. It is licensed under GPL and you can find it here.

Anyway, enough about the past…

This long weekend I decided to take a couple of hours out and based on the above design I ported WebGet over to Ruby. Once it has passed unit testing I will release it in the resources section of the web site.   

After a recent scare with WordPress 2.1.1, I thought it would be a good idea to list out some of the threats to owning a web server…namely mine. Before I continue I want to make it clear that I am not giving permission to perform this on this server or any server for that matter. This is some useful information you should be aware of if you are hosting or paying some entity to host your web service. You should perform this on your own server regularly to see if you are vulnerable to attack.

Server Level
Performing a banner grab of the this domain reveals the following:

curl -I www.securitytechscience.com

HTTP/1.1 200 OK
Date: Fri, 16 Mar 2007 23:54:28 GMT
Server: Apache/1.3.36 (Unix) mod_gzip/1.3.26.1a mod_jk/1.2.14 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.27 OpenSSL/0.9.7a PHP-CGI/0.1b
X-Powered-By: PHP/5.0.5
Content-Type: text/html

Taking a quick look at the SecurityFocus vulnerabilities page for Apache 1.3.36, I found 2 vulnerabilities that are not applicable to this server. Firstly, it is not running mod_rewrite and I know my costs are to low for them to be running Windows.

Lesson learned:

1. Always stay up-to-date with the latest version of you server and perform regular patching.
2. Do not run any unnecessary services or unnecessary modules within that service.

Application Level Type 1 – Underlying Supporting Code

The above banner also reveals that PHP 5.0.5 is installed. Once again, taking a look at SecurityFocus vulnerabilities page for PHP 5.0.5 this time reveals 30 vulnerabilities…mmm. Apart from being more than a little pissed with my hosting company, two things come to mind right now. One, whether any of these vulnerabilities are exploitable remotely and two, which one’s are local vulnerabilities.

Successful remote exploitation obviously means the server would be turned into a phishing or warez site within a matter of seconds. duh!

But local exploitation means that I can own all the content on the server including the other websites that share their hosting with me and vice versa they could also own me. My site has no sensitive or confidential information so if the server gets 0wned then I lose only reputation if they deface my site. But what if I were malicious and were to own my neighbours sites and they perform e-commerce functionality or store confidential information? Totally different story.

Lesson learned:

1. Always stay up-to-date with the latest version of your application.
2. Do not host your site in a shared environment if it contains information that is either confidential or sensitive.
3. If you pay some entity to host your site be well aware they may not be security conscious. Check before you buy as you may not be lucky enough to share your domain on the same server as the security conscious

Note: An email has already been sent to my provider about the PHP issue before I finished writing this blog.

Application Level Type 2 – Add-on Applications

Recently I updated my version of Word Press just at the wrong time. The Word Press dev server was hacked recently and additional code was added to version 2.1.1 which allowed remote PHP code execution. You can read more here. Anyway, I have updated to version 2.1.2 and deleted all my files and updated all the files from my local server that is not Internet accessible.

Lesson learned:

1. Keeping up-to-date doesn’t mean you are 100% safe/secure either. There is no such thing as 100% secure.
2. Always store multiple backups of your data which are recoverable in case of data loss or data corruption.

Application Level Type 3 – In-house Code

There are a number of pages that rely on PHP. I won’t specify which one’s but it is pretty apparent that if parameters are being passed around there needs to be something other than HTML moving these parameters around. My main concern here always comes down to “Injection” attacks. I don’t store any data so SQL injection is not an issue. I don’t use XML or authentication so LDAP and XML injection is also not an issue. But I do take my data from an untrusted source (securityfocus) and redisplay it back to the end client browsing my site. It is not far fetched that if someone were to own the security focus site and inject malicious code (JavaScript, VBScript) into their RSS feeds then the end user and possibly the server could be open to attack. That is, the attacker injects code into the RSS feed. I take the RSS feed in a nightly batch and when someone browsers to my site I display this information to them. Luckily for all involved (except Security Focus) I perform both input and output filtering on all data involved. If the code I wrote doesn’t like the look of the data then it gets dropped.

Lesson learned:

1. Always validate input data from an untrusted source
2. Always validate output data being redisplayed to the end user

Conclusion

What I find most interesting here is that the www.securitytechnologyscience.com domain is only one site with mostly static information, a small amount of dynamic information and a blog. The avenues of attack are not small but we are only talking about a small site. I think it is worth thinking about this and comparing it to a site that has an authentication modules, must enforce authorisation on components, interacts with other services such as a database back-end or web services. Let’s also mix in a little AJAX to top it off and we end up with something that could be easily exploited if the appropriate controls are not put in place during development and managed throughout the system life cycle.