13620 items (0 unread) in 75 feeds
As some of you may know, our wp-scanner project looks for common WordPress XSS issues but what about testing more advanced web sites and/or CMS (content management systems)?
Acunetix is one of the leading commercial web applicaton vulnerability scanners on the market. The reason I mention it (other then the fact that they are one of our sponsors) is that they provide a free XSS scanner - which my work collegue describes as "awesome". So if you have enjoyed wp-scanner or have a site you’d like testing for Cross-Site Scripting vulnerabilities I’d strongly recommend giving it a go.
For those of you looking for the full monty, Acunetix provides a reasonably priced full-featured web vulnerability scanner which I have used on a number of occasions and found extremely useful. I especially like the WSDL enumeration and testing (web services), SQL Injection fuzzer and the fact that version 5 is built around helping sites achieve the PCI standard. The interface is also very neat and extremely easy to use.
Check out some of the screen shots:
If you interested in more information go check out the latest version 5 features and tools.
I phoned my bank to activate my card the other day. The automated voice required a date of birth and the number of digits in my Mother’s maiden name. Lets assume an attacker can get this information, lets be realistic, what could really happen?
Lets explore some ideas of what an attacker could do with enough information about you:
The latest estimate is that identity fraud costs the UK economy £1.7 billion. Thats billion NOT million.
More information is available at Home Office Identity Theft web site.
Having fun with FeedBurner Awareness API.
The FeedBurner Awareness API (AwAPI) allows publishers of FeedBurner feeds to reuse the detailed traffic statistics we capture for any of their feeds. Third-party applications and web services that consume feeds can leverage this data to provide useful feed awareness statistics to potential subscribers… - awarenessapi
In October 07, BlogSecurity released an article titled, "Feedburner: Show me the money". Knowing your way around Feedburner can be really useful when looking for blog partners or blogs to place ads. Awareness API makes this a peice of cake!
What I also find interesting, is that these statistics could be used by attackers during the target profiling stage to find and sort high traffic sites with accuracy. In addition to this, a more subtle attacker may only want to deface or propogate an attack further by infecting a specific page. How would the attacker easily determine the page with the most traffic?
Enough chit-chat, lets see Awareness API in action by viewing Problogger’s stats:
http://api.feedburner.com/awareness/1.0/GetFeedData?uri=
ProbloggerHelpingBloggersEarnMoney&dates=2008-01-01,2008-04-02
<feed id="40080" uri="ProbloggerHelpingBloggersEarnMoney"> <entry date="2008-01-01" circulation="36533" hits="61608" downloads="1" reach="4918"/> <entry date="2008-01-02" circulation="37465" hits="73923" downloads="5" reach="6356"/> <entry date="2008-01-03" circulation="37161" hits="73702" downloads="1" reach="6525"/> <entry date="2008-01-04" circulation="36983" hits="71214" downloads="0" reach="5976"/> <entry date="2008-01-05" circulation="36559" hits="60201" downloads="0" reach="4338"/> ...
The boy is definately getting hits!
Specific posts can also be queried (although this didn’t work when I was playing the second time round):
http://api.feedburner.com/awareness/1.0/GetFeedData?uri=
ProbloggerHelpingBloggersEarnMoney&itemurl=
http://www.problogger.net/archives/2008/05/01/
what-you-say-is-what-you-are-the-problem-of-blogger-inferiority-complex/
<entry date="2008-04-30" circulation="47441" hits="87226" downloads="0" reach="7632"/>
We found that Feedburner enables this service when the feedCount service is enabled. The Awareness API service does not need to be activated for your site to be displaying this information. We had mixed results when testing. If this is the case, I think this is a bad configuration on Feedburner’s part.
Check out the Awareness API documentation for more uses.
I really love the Gravatar concept. Its simple, useful, powerful and centrally managed, but how secure is it to use on a blog or service?
Regular users may have already seen that we have implemented Gravatars onto BlogSecurity; so its safe to use then, right?
I made a point on our new BlogSec-News service a couple days ago when implementing Gravatars onto BlogSec. This article expands these points.
My first thought was, creating a malicious image link and posting this on Gravatar. Imagine placing a malicious peice of code as your profile picture. Every site that has approved your previous comments are all of a sudden vulnerable! However, this thought was quickly exhausted, as Gravatar does not permit third party links. All images are uploaded to Gravatar and centrally managed. Good move!
So what are the risks then?
Without looking at the service in great detail, there are two obvious risks with using this service, both of which you should understand and accept before using it.
Firstly and less likely: If the Gravatar servers are hacked, attackers could embed malicious code into links, which could be used in a variety of attacks including Denial of Service and may, although unlikely, lead to your blog being compromised. However, for this to happen, your site would have to be vulnerable to other attacks.
Second and more likely: Users control what rating their images receive. By accepting Gravatars, you accept the possibility that some users may use inappropriate images or images of a sensitive nature. Its also difficult to detect these images, unless you were monitoring every post comment on every post (impossible). The end result may be an unhappy user or visitor who blames your site, especially when they fail to understand how the Gravatar service work.
It is important that these risks are understood and accepted before using the service. As a community, hopefully we’ll look out for these images. When spotted, we could always inform Gravatar, who hopefully have a procedure in place to manage abuse.
We got an interesting comment from Dave today that made me reflect on the question of when to update or upgrade your blog software.
Until you folks on this site tell me I’m not doing the update. WP always has some security issues when its released.
It may seem like a fairly simple question, but when should one upgrade their software? I can imagine some would immediately answer, "just keep up with the latest release and you can’t go wrong!".
Debian is known to be one of the most stable Linux distributions around. Why? Without complicating the answer, Debian are painfully slow when it comes to releasing the latest version of its supported packages. In fact, 9 our of 10 times, they are running a much older version of a particular software package. However, keep in mind that although an older package is being run, the latest revision of that package will be available.
This presents a bit of a dilemma. By running a tested and proven version of software you are less likely to run into compatibility problems, and it is probably going to be more stable. However, sometimes, the new version has particular features that you really want which forces you to not only upgrade the software package but all its modules and libraries too.
In the example of WordPress, I remember when WP 2.3 was released. I waited a few revisions before upgrading. I was glad that I did. A number of bugs and security issues were found shortly after the install. You may also remember when WP 2.1.1 got released. A hacker had broken into WordPress and placed a backdoor in the new version of code. This may be unlikely to happen again (hopefully), but it raises the point; immediate upgrades are not always the best solution.
Fruit for thought!
Elazar recently released a buffer overflow proof of concept in Aurigma’s ImageUploader ActiveX plugin.
This ActiveX control is used by Facebook and I have seen it mentioned that MySpace is affected too. The vulnerability is only present for Internet Explorer users.
This vulnerability will allow an attacker to execute commands on your computer via your browser.
This has massive worm potential because no auto-update facility is available with ActiveX controls. Aurigma may be working on a fix, but it will be a long time before all users have upgraded. Furthermore, its ironic this vulnerability has been released now. BlogSec were a week or two away from releasing a similar advisory. As time permits we’ll look into this further, but in short, I believe their are a number of these vulnerabilities still waiting to be found in the Aurigma service.
To remove the risk: Go to "D:WINDOWSDownloaded Program Files" you’ll see all your currently installed Internet Explorer ActiveX controls. You are looking for "ImageUploader4". If it exists, right click and uninstall it.
Next time you go to upload Photos on Facebook, your browser will prompt you to reinstall it, this time installing the latest version.
Social network services such as Facebook and MySpace have a huge responsibility to their users. A similar vulnerability has been discovered before. This tells me that the vendor may only be patching the symptom rather then targetting the problem.
It really concerns me when services like Facebook with millions of users, provide and request that their users download and install software that in my opinion has not been security-tested or audited.
More info is available from Larry Lignan’s post on ZDNET here.
It seems that security tips for our software often extend to keep up to date with your software. This strategy alone, means two things:
What you really want is defense in depth
Benjamic Franklin’s famous quote seems relavent: By failing to prepare, you are preparing to fail.
For most of us, I think we can manage a few downtime days. BlogSec suffered from a DNS problem recently, which really threw a spanner in the works. We were able to recover, but I can’t help but think that we would have done well to heed Shakesphere’s words:
If you have tears, prepare to shed them now.
Creating a defense in depth strategy involves putting up a number of cyber-barriers or -checkpoints and making certain assumptions. A wise strategy will expect certain if not all areas to be breached.
In time of peace prepare for war.