POST method

[mhernes]

Hello, I have a problem trying to inject in a post parameter in mutillidae(broken web aplication OWASP).

url: http://10.0.2.19/mutillidae/index.php?page=dns-lookup.php

There is a input via POST that when i try it manually with work fine. I take the data with burp suite: post-data= "target_host=" The command is:

./xsser -u "http://10.0.2.19/mutillidae/index.php?page=dns-lookup.php" -p "target_host=" --user-agent "Googlebot/2.1 (+http://www.google.com/bot.html)" --threads 1 --timeout 30 --retries 1 --delay 0 --payload="" --cookie="PHPSESSID=41mfckj2obt9tju3m640j5r1p7; path=/, showhints=1"

XSSer is not working propertly!:

• Is something blocking connection(s)?
• Is target url ok?: (http://10.0.2.19/mutillidae/index.php?page=dns-lookup.php)

Mosquito(es) landed!

[*] Final Results:

• Injections: 1
• Failed: 1
• Sucessfull: 0
• Accur: 0 %

I have been testing others vulnerable web application and always having same error. I tried without cookies and without user agent.

I dont know if im making a mistake in the command or is a issue.

Thanks, Miguel.

[epsylon]

Hi,

I see... And reviewing you command, firstly it looks ok: ./xsser -u "http://10.0.2.19/mutillidae/index.php?page=dns-lookup.php" -p "target_host=" --user-agent "Googlebot/2.1 (+http://www.google.com/bot.html)" --threads 1 --timeout 30 --retries 1 --delay 0 --payload="" --cookie="PHPSESSID=41mfckj2obt9tju3m640j5r1p7; path=/, showhints=1"

I think GitHub is removing your XSS code from payload, but I understand that this blank space that you provide is when you attack something like: < script > alert ( 1 ) < / script >. Is it?

If not, you are injecting a "blank" payload, so normaly this haven't any effect on your target...

If yes, firstly, try to launch it again using verbose (-v) mode. Maybe we can have some clues.

On the other hand, I see that you are launching the attack to a local IP so, you have access to server side logs. Which requests are receiving your web server (ex: apache)?. This is interesting to see if payload is correctly injected.

More questions..

On which browser (vendor/version) are you trying to exploit that "classic alert" XSS script?.

Did you tried --auto to see if there are other XSS codes that works?.

Also try to review if there are any Anti-XSS measures activate...

Keep me tuned with your tests and many thanks for report your issue.

Regards.

[mhernes]

Hello again,

Yes the payload was the one you said. I also tried with --auto and i got same error. Im pretty sure that the server dont have any Anti-XSS because i have tried with WAVSEP virtual machine too.

Im a litle bit busy today, tomorrow i will send the output with verbose and the logs from the server.

Thanks you for your atention. Regards.

[mhernes]

Hi,

Im using kali linux(iceweasel) and XSSER version 1.7-1. Here you have screenshots from wireshark testing with xsser and manually. Also apache logs from mutillidae and the output with -v from xsser. I have the pcap files from wireshark if you need it. Im my opinion the injection is working, the problems is the check of the injection of xsser.

Image 1: acces.log from apache Image 2: wireshark capture of manual test Image 3: wireshark capture of xsser xsser_output.txt Image 4: xsser output with verbose

If you need others logs or something just tell it to me.

Regards.

[epsylon]

Ok, now I know exactly whats going on. Thanks for your time to upload that captures.

It is because XSSer is searching on target reply for 'XSS' (hashed) on code. And you are using a payload with "1". That means that XSSer is making injection but not reporting it correctly.

You have reason on your opinion.

Please, try to inject code changing "1" for "XSS". If that is not working (because some XSS only works with numbers), please try to encode your injection (payload has blank spaces to allow GitHub to show it). For example, using hexadecimal:

./xsser -u "http://10.0.2.19/mutillidae/index.php?page=dns-lookup.php" -p "target_host=" --user-agent "Googlebot/2.1 (+http://www.google.com/bot.html)" --threads 1 --timeout 30 --retries 1 --delay 0 --payload="< script > alert ('XSS'); < /script>" --cookie="PHPSESSID=41mfckj2obt9tju3m640j5r1p7; path=/, showhints=1" --hex

This should works... Tell me your advances, please.

About your report, I think that this will be fixed on next release. Is just question of replace value on report like a post-injection task...

[mhernes]

Well, i have tried with XSS intead of 1 and got the same error. Anyways i had tried with --auto that choose its own payload hashed(i think) and didnt work.

I have tried "< script > alert ('XSS'); < /script>" manually and work fine.

The injection is ok but xsser says that is a failed one.

[epsylon]

Mmmh. I see... We need keep debugging. Is strange, because server side logs are showing that POST method is used and parameter is correctly set. So, is not a problem on requests. Let's center our research at payload. Look, what about that comma after "path" sentence on cookie?. It should be a ; And same after "showhints".. ./xsser -u "http://10.0.2.19/mutillidae/index.php?page=dns-lookup.php" -p "target_host=" --threads 1 --timeout 30 --retries 1 --delay 0 --payload="< script > alert('XSS') </ script >" --cookie="PHPSESSID=e78dvtvj5sd9qdu4dth29dnvp2; path=/; showhints=1;" -v Should be nice also to have captures, not only of your requests, even of reply made by server. Finally, it is nice to have a transparent proxy between XSSer and your browser to see if payload (etc..) are correctly built. There are some at Kali (spikeproxy, squid3...). Try to use one on your tests.

[mhernes]

hi Epsylon, I dont forget this issue, sorry for the delay. I have been looking for the issue in the code but i coudnt find it. I have found somethink, in line 675 from the main, data have the correct html from the url with the payload injected. Anyways i need more time to debbug it becouse im studing and working :C I didnt use the transparent proxy becouse I thing that XSSER is working ok in te injection, just fail checking it. ¿Do you still think in use it?.

Regards.

[epsylon]

Hey! No problem about delay, we all have more stuff to do. Well, XSSer uses sometimes a second request to check it, so implement a proxy for debugging tasks looks best idea. I think this is related with "anti-false positives" code block. Sometimes, when you inject "something", server will replies you that "something". This doesn't means that parementer is vulnerable and XSSer tries to difference it -automagically- for you. This issue is also related with context of the injection. XSSer will search for some other tags arround your payload to see if really is "breaking" server code. By the moment, that search is related with XSS audit experiences but of course, should be more advanced. For example, applying some AI to results, adding more heuristic ways, etc.. Please keep reporting your advance. And many thanks for your time. Cheers.

[vojtapolasek]

Hi, I am facing a similar problem with Xsser and Mutillidae. I use: xsser -u http://172.17.0.2/index.php?page=add-to-your-blog.php -p "csrf-token=&blog_entry=XSS&add-to-your-blog-php-submit-button=Save Blog Entry" --auto After running this I can see various blog posts in Mutillidae, some of them look like buttons etc. so I think that XSS injection was successful. But Xsser says, that no XSS injection has been found. I am attaching capture of this communication. Do you have any idea what could be wrong? capture.zip This page should be vulnerable to XSS.

[epsylon]

Well, that target is replying you with a SQL error. I mean, looks that you have discovered "also" a SQL injection :dancer:

/app/classes/MySQLHandler.php on line 165: Error executing query:

connect_errno: 0
errno: 1064
error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '580d6f9edfba2d6c2f628a7b60b8fcb4')', now() )' at line 1
client_info: 5.5.46
host_info: Localhost via UNIX socket

) Query: INSERT INTO blogs_table(blogger_name, comment, date) VALUES ('anonymous', '"><SCRIPT>alert('580d6f9edfba2d6c2f628a7b60b8fcb4')</SCRIPT>', now() ) (0) [Exception]

So, I think XSSer cannot check for injected hash on reply because of that... I will review it.