VWar 1.6.1 R2 Multiple Remote Vulnerabilities

Originally hosted at dmcdonald.net/vwar.txt and posted to the Full Disclosure mailing list. Disclosed to the developer in April 2008; the project was officially abandoned in response, with the developer publicly stating that VWar should no longer be used. Public release followed on 22 August 2010. Archived here on dmcdonald.net 2026-05-19, reproduced from the Wayback Machine capture of 4 June 2011 with light typo fixes. Full Disclosure post · original archive.

I'd just started my first pentesting role at NGS Secure when I wrote this. Marcus Pinto had recently taught me web application hacking. Marcus co-wrote The Web Application Hacker's Handbook and later co-founded MDSec. Fresh out of that training, I went hunting for the first PHP application I could get my hands on, found VWar, and worked through it methodically. Published and maintained here for nostalgia.

While VWar 1.6.1 R2 was the focus of this assessment, many of these issues exist in other versions of VWar.

As far as I am aware, no public version has corrected the most serious issue, issue 4.

1. SQL Injection

1.1 Summary

An SQL injection vulnerability has been discovered in the article rating system in http://mydomain.com/vwar/article.php. This issue could be used by an attacker to deface articles, deny service to other users (DoS), and other SQL-injection-related issues.

1.2 Technical Details

The bug itself is in vwar/article.php, line 44:

39  if (is_numeric($GPC["rate"])){
40       if ($GPC["ratearticleselect"] && $GPC["ratearticleselect"]
41           query("UPDATE vwar".$n."_article
42            SET
43             articleratingpoints  = articleratingpoints+".$GPC["ratearticleselect"].",
44             articlerated = articlerated+1
45            WHERE articleid = '".$GPC["rate"]."'");
46
47           $redirecturl = "article.php?articleid=".$GPC["rate"];
48           include ($vwar_root . "includes/get_header.php");
49           eval("\$vwartpl->output(\"".$vwartpl->get("message_confirmation")."\");");
50           include ($vwar_root . "includes/get_footer.php");
51           exit();
52       } else {
53       ...

A proof of concept can be seen in the following POST request, which results in the main body of the article being replaced with the text NGS TEST:

POST /vwar/article.php?rate=1 HTTP/1.1
Host: mydomain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://mydomain.com/vwar/article.php?articleid=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 64

ratearticleselect=5, article = char(78,71,83,32,84,69,83,84)

It is also possible to cause VWar to run out of memory when attempting to display the article by setting ratearticleselect to a high enough value, for example:

ratearticleselect=5%2b999999

When the article in question is requested by a user, VWar will run out of memory attempting to generate HTML containing vast numbers of <IMG> tags to display the star rating.

1.3 Workaround

There is no known workaround for this issue.

2. Stored Cross Site Scripting (XSS)

2.1 Summary

Five entry points for stored XSS have been found in the following locations:

  • http://mydomain.com/vwar/challenge.php
  • http://mydomain.com/vwar/joinus.php
  • http://mydomain.com/vwar/admin/admin.php?action=finishwar&warid=1
  • http://mydomain.com/vwar/profile.php

However, there are likely to be more, as VWar uses a common set of text parsers to protect against XSS and SQL code injection.

This issue can be used to attack other users of the VWar system, including the administrators, as data entered on these forms is often sent for administrator approval. The results can include session hijacking, which would allow an attacker to gain admin access.

2.2 Technical Details

  • Issue 1: http://mydomain.com/vwar/challenge.php (Additional Information input field)
  • Issue 2: http://mydomain.com/vwar/joinus.php (Additional Information input field)
  • Issue 3: http://mydomain.com/vwar/admin/admin.php?action=finishwar&warid=1 (War Report input field)
  • Issue 4: http://mydomain.com/vwar/profile.php (Nick input field)
  • Issue 5: http://mydomain.com/vwar/joinus.php (Contact information input field)

The VWar system filters out <script> tags to prevent XSS, but allows image (IMG) tags where JavaScript can be executed on the onload, onerror, and similar events. As these forms are often sent to users for approval, there is the potential for an attacker to hijack the session of another user, including a user with administrator access.

A proof of concept which works with all five issues can be seen by entering the following HTML in the vulnerable fields:

<img src="xyz" onerror="alert(1)" />

2.3 Workaround

Risk from issues 1, 2, 3, and 5 can be mitigated by turning the following settings to Off on the administrator's settings page:

  • HTML Code (Default On)
  • Enable Challenge Requests (Default On)
  • Enable Join Requests (Default On)

There is no known workaround for issue 4.

3. Broken Access Controls

3.1 Summary

There is a lack of access controls in http://mydomain.com/vwar/popup.php in the print view system, which allows an attacker to view articles normally restricted to users of the system.

3.2 Technical Details

It is possible to access member-only news posts by using the printnews action through the newsid field in popup.php. For example, assuming article 3 is hidden from public view, the following URL will allow access to a user who has not logged in:

http://mydomain.com/vwar/popup.php?action=printnews&newsid=3

Whereas http://mydomain.com/vwar/news.php?newsid=3 and http://mydomain.com/vwar/news.php correctly do not return the news article unless requested by a valid user.

3.3 Workaround

There is no known workaround for this issue.

4. Weak Password Generation

4.1 Summary

VWar has a fault with its random password generation function, which is used during account creation and the forgotten password functionality. Passwords generated this way are highly likely to be one of a set of 60 passwords.

VWar has no account lockout system in place to stop an attacker attempting to brute-force a password of a valid user, meaning that an attacker with an automated tool can gain access to an account with a randomly generated password in only a few seconds.

4.2 Technical Details

The bug is in vwar/includes/functions_common.php on line 724:

716  function createRandomPassword ($passlen=15,$chars="")
717  {
718      $chars = trim($chars);
719      if(empty($chars)) $chars = "aAb0Bc\$CdD1eEfF2gGh%3HiIj§J4kKl5Lm6MnNo7&OpPqQrR6sStTuUvV9wWxXyYzZ§$%&";
720
721      $charlen = strlen($chars);
722      for ($i = 0; $i < $passlen; $i++)
723      {
724          mt_srand(date("s", time() + $i * 4567));
725          $password .= substr($chars,mt_rand(1,$charlen),1);
726      }
727
728      return $password;
729  }

The mt_srand function is seeded with the number of seconds of the current system time, a limited set of 60 (00 to 59). As the seed predetermines the password which will be generated by this function, it is highly likely that the password will be one of a set of only 60.

It is possible (although unlikely) that createRandomPassword could run during the transition of one second to the next, meaning there is a total of 420 possible passwords which could be generated.

Combined with the user enumeration in http://mydomain.com/vwar/admin/index.php?login=1 and other locations, plus the forgotten password functionality, this makes it trivial to gain access to any account.

The user enumeration, no account lockout, forgotten password functionality, weak password generation, and the ability for admins to upload PHP scripts, when combined, allow an attacker with no credentials or knowledge to gain a shell on the host with the permissions of the Apache/IIS user.

4.3 Workaround

Panic.

5. Static Session Cookies

5.1 Summary

VWar's session cookies are static, meaning that a user will always be given the same session cookie. VWar will also allow authentication based solely on this cookie. If an attacker obtains a user's session cookie (trivial using finding 2), session timeouts and the logout function will not disrupt the attacker's activities.

5.2 Technical Details

The session cookie is created by running the PHP md5 function on the user's md5-hashed password, causing the session ID to be static.

5.3 Workaround

There is no known workaround for this issue.