By exploitdb papers bot•December 4, 2010•
papers
ASPSiteWare JobPost 1.0 SQL Injection Exploit Explained
ASPSiteWare JobPost 1.0 SQL Injection Exploit Explained
What this paper is
This paper details a SQL Injection vulnerability found in ASPSiteWare JobPost version 1.0. The vulnerability allows an attacker to manipulate database queries by injecting malicious SQL code into the iType parameter of the type.asp script. This can lead to unauthorized data access, modification, or deletion.
Simple technical breakdown
The type.asp script in ASPSiteWare JobPost is designed to display job postings based on a category identifier passed via the iType URL parameter. However, the script doesn't properly sanitize or validate the input from iType. This means an attacker can insert SQL commands directly into the iType parameter. When the script constructs a database query using this unsanitized input, the injected SQL commands are executed by the database, potentially allowing the attacker to bypass intended logic and extract sensitive information.
Complete code and payload walkthrough
The provided exploit paper does not contain any executable code or shellcode. It only describes the vulnerability and the affected URL structure.
Vulnerability Description:
- URL Structure:
http://server/JobPost/type.asp?iType=[Code] - Parameter:
iType - Vulnerability Type: SQL Injection
- Impact: Allows attackers to inject arbitrary SQL commands.
- URL Structure:
Code Fragment/Block -> Practical Purpose Mapping:
http://server/JobPost/type.asp?iType=[Code]-> This is the vulnerable URL endpoint. The[Code]part is where the attacker injects SQL.iType=[Code]-> TheiTypeparameter is the entry point for the SQL injection.
Payload Segments:
- No explicit payload bytes or shellcode are provided in the paper. The "payload" in this context refers to the crafted SQL injection string that an attacker would append to the
iTypeparameter.
- No explicit payload bytes or shellcode are provided in the paper. The "payload" in this context refers to the crafted SQL injection string that an attacker would append to the
Practical details for offensive operations teams
- Required Access Level: Network access to the target web server and knowledge of the application's URL structure. No prior authentication is explicitly required by the paper.
- Lab Preconditions:
- A web server hosting ASPSiteWare JobPost 1.0.
- A configured Access database for the application.
- A network connection to the target server.
- Tooling Assumptions:
- A web browser for manual testing.
- A web proxy (e.g., Burp Suite, OWASP ZAP) for intercepting and modifying requests.
- SQL injection tools (e.g., sqlmap) could automate the discovery and exploitation process.
- Execution Pitfalls:
- WAF/IPS Evasion: Web Application Firewalls (WAFs) or Intrusion Prevention Systems (IPS) might detect and block common SQL injection patterns. Attackers may need to use obfuscation techniques or alternative injection methods.
- Database Specific Syntax: The exact SQL injection syntax might vary slightly depending on the underlying database system (though the paper implies Access, which has specific syntax).
- Application Logic: The application might have some client-side or server-side validation that needs to be bypassed.
- Error Handling: The application's error handling might reveal information about the database structure or query execution, or it might suppress errors, making exploitation harder.
- Parameter Encoding: URL encoding might be necessary for certain characters.
- Tradecraft Considerations:
- Reconnaissance: Identify the target application and version. Map out the application's structure to find vulnerable endpoints.
- Probing: Start with simple, non-intrusive probes (e.g.,
','',OR 1=1) to identify if the parameter is vulnerable. - Payload Crafting: Develop payloads to extract specific data (e.g., usernames, passwords, database schema) or to perform actions (if permitted by the database permissions).
- Data Exfiltration: Plan how to exfiltrate any discovered data without triggering alerts.
- Covering Tracks: If necessary, consider how to remove logs or alter evidence.
Where this was used and when
- Context: This vulnerability was likely exploited against organizations using ASPSiteWare JobPost 1.0 for their job listing management.
- Timeframe: The exploit paper was published on December 4, 2010. Therefore, exploitation would have occurred around or before this date. It's possible it was used in the wild by attackers targeting small to medium-sized businesses that might have used such off-the-shelf web applications.
Defensive lessons for modern teams
- Input Validation and Sanitization: Always validate and sanitize all user-supplied input, especially data used in database queries. This includes checking for expected data types, lengths, and character sets.
- Parameterized Queries/Prepared Statements: Use parameterized queries or prepared statements provided by the database API. These separate SQL code from user data, preventing injected code from being interpreted as commands.
- Least Privilege: Ensure the web application's database user account has only the minimum necessary permissions. This limits the damage an attacker can do even if an injection is successful.
- Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common SQL injection patterns. Keep WAF rules updated.
- Regular Patching and Updates: Keep all web applications and their underlying frameworks and databases up to date with the latest security patches.
- Security Audits and Code Reviews: Conduct regular security audits and code reviews to identify vulnerabilities before they can be exploited.
- Error Handling: Implement generic error messages for users and log detailed errors server-side for debugging, but avoid revealing sensitive database information in error responses.
ASCII visual (if applicable)
This vulnerability is a direct manipulation of a web request's parameters. An ASCII diagram illustrating the flow is applicable.
+-----------------+ +-----------------+ +-----------------+
| Attacker's |----->| Web Server |----->| Database Server |
| Machine | | (JobPost App) | | (Access DB) |
+-----------------+ +-----------------+ +-----------------+
| |
| Request with | Query construction
| iType=[SQL_INJECTION] | using unsanitized input
| |
| v
| +-----------------+
| | Malicious SQL |
| | executed |
| +-----------------+
| |
| v
| +-----------------+
| | Data Leakage / |
| | Unauthorized |
| | Actions |
+------------------| (Response sent |
| back to client) |
+-----------------+Source references
- Exploit-DB Paper: https://www.exploit-db.com/papers/15681
- Author: R4dc0re
- Publication Date: 2010-12-04
- Software: ASPSiteWare JobPost 1.0
- Vulnerability: SQL Injection
Original Exploit-DB Content (Verbatim)
# Author: R4dc0re
# Exploit Title: ASPSiteware JobPost SQL injection Vulnerability
# Date: 04-12-2010
# Vendor or Software Link: www.aspsiteware.com
# Category:WebApp
#Version:1.0
#Price:40$
#Contact: R4dc0re@yahoo.fr
#Website: www.1337db.com
#Greetings to: R0073r(1337db.com), L0rd CrusAd3r,Sid3^effects and to rest of the 1337db members
Submit Your Exploit at Submit@1337db.com
########################################################################################
[Product Detail]
JobPost is an application ideal for the small or independent business or association who need a way to post
and update job openings internally or on the internet. Ideal for intranets Backend by Access database,
JobPost can store thousands of job postings in categories.
[Vulnerability]
SQL Injection:
http://server/JobPost/type.asp?iType=[Code]
########################################################################################