Arbitrary tweets made by TheGingerDog up to 02 August 2020
Continue reading “Automated twitter compilation up to 02 August 2020”
Linux, PHP, geeky stuff … boring man.
Arbitrary tweets made by TheGingerDog up to 02 August 2020
Continue reading “Automated twitter compilation up to 02 August 2020”
Arbitrary tweets made by TheGingerDog up to 11 August 2019
Continue reading “Automated twitter compilation up to 11 August 2019”
Arbitrary tweets made by TheGingerDog up to 19 August 2018
Continue reading “Automated twitter compilation up to 19 August 2018”
Arbitrary tweets made by TheGingerDog up to 01 February 2015
Continue reading “Automated twitter compilation up to 01 February 2015”
On a random mailing list there’s a report of an EE broadband box being delivered with a QR sticker on the side.
Which when scanned gives something like :
SN:J32xxxxxxx;MAC:88-03-55-xx-xx-xx;USER:admin;Pass:xxxxxx;SSID:EE-BrightBox-xxxxxx;WPA:xxx-xxxx-xxxxx
Guess that makes it handy for the postman to use your broadband.
Today, I finally looked at Wapiti, which is a web application vulnerability scanner. It operates on a black box basis (i.e. it doesn’t see the underlying PHP/ASP/Java source code), and effectively tries to ‘break’ any forms on a page.
In order to get it to do anything useful, you’ll probably need to provide it with a cookie file to use. Unfortunately, I couldn’t originally get the provided ‘getcookie.py’ file to work, as the application in question just posted the login form details to ” (i.e. <form action=” method=’post’>)…. after a bit of hacking I fixed this, but it took some time.
Installation is relatively easy – download the .zip file, extract it and change directory into it (e.g. cd wapiti-2.0.X)
Anyway, given we have “webapp” installed at http://orange/webapp, and we wish to test it, we might do something like the following :
#LWP-Cookies-2.0
Set-Cookie3: PHPSESSID=3d20841af5de43c718732d80e5d78fe3; path=”/”; domain=”orange”; path_spec; expires=”2010-01-04 22:42:47Z”; version=0
Now we can use wapiti to test any urls ‘behind’ the login screen (as it were) :
wapiti http://orange/webapp/search.php –cookie ~/cookie.txt -v 2 -o ~/report -x http://orange/webapp/logout.php
(We need to exclude the logout page, else our session will get destroyed when wapiti spiders that page…)
Depending on how good the application is, you may see output like :
Found permament XSS in http://orange/webapp/search.php
attacked by http://orange/webapp/search.php?area=on&client_id=on&county=on with fields county=crzbl79tqr&status=x57cjl7m14&website=vk59qqbgmp&name=<script>alert(’11byq04xd1′)</script>&client_id=on®ion=on
and similar for the other vulnerabilities.
If I point my web browser at file:///home/david/report I’ll see a nice HTML report listing the vulnerabilites and so on – similar to the below…
Wapiti appears to detect:
I’m a bit annoyed I’ve only found this tool now – but also glad I’ve finally found it. I’ve been looking for something that can pick up XSS holes for ages (SQL Injection stuff I could already test using SQLMap, and ensuring I only ever used prepared statements).
Update (July 2011) – cookie file format has changed to xml –
<?xml version="1.0" encoding="UTF-8"?> <cookies> <domain name="uk"> <domain name="co"> <domain name="palepurple"> <domain name="david"> <cookie name="PHPSESSID" path="/" value="vmabdv5giph334aq33vb0add67" version="0"/> <cookie name="globdisc" path="/" value="yes" version="0"/> </domain> </domain> </domain> </domain> </cookies>