EasyGallery 'catid' Blind SQL Injection Explained

EasyGallery 'catid' Blind SQL Injection Explained
What this paper is
This paper describes a blind SQL injection vulnerability found in the catid parameter of the Myiosoft EasyGallery web application. The vulnerability allows an attacker to infer information from the database by observing the application's responses to crafted SQL queries. Specifically, it leverages the substring() function and conditional logic to determine characters within database version information.
Simple technical breakdown
The EasyGallery application uses a catid parameter in its URL to fetch category information. This parameter is directly incorporated into a SQL query without proper sanitization. An attacker can manipulate this catid parameter to inject SQL code.
The exploit uses a "blind" technique, meaning it doesn't directly display database errors or results. Instead, it relies on the application's behavior (whether it returns a "true" or "false" response, or perhaps a different page/content) to deduce information.
The core of the exploit is the and substring(@@version,1,1)=X part.
@@version: This is a SQL Server function that returns the version of the SQL Server.substring(string, start, length): This function extracts a part of a string. Here, it's used to get a single character (length=1) from the@@versionstring, starting at the first character (start=1).=X: This compares the extracted character with a specific valueX.
By sending requests with different values for X (e.g., '4', '5'), the attacker can determine if the first character of the database version matches that value. If the query returns a "true" response, the character matches. If it returns a "false" response, it doesn't. This process can be repeated to guess characters at different positions and build up the database version string.
Complete code and payload walkthrough
The provided "exploit" is not traditional code with a payload in the sense of executable shellcode. Instead, it's a series of crafted HTTP GET requests demonstrating the injection technique.
Exploit Snippets:
http://server/easygallery/index.php?PageSection=0&page=category&catid=22+and+substring(@@version,1,1)=4 > falsehttp://server/easygallery/index.php?PageSection=0&page=category&catid=22+and+substring(@@version,1,1)=5 > true
Walkthrough:
- Base URL:
http://server/easygallery/index.php- This is the target web application.
- Parameters:
PageSection=0: This parameter likely controls which section of the application is loaded. Its value might be part of the legitimate query construction.page=category: This parameter indicates that the category page is being requested. This is also likely a legitimate parameter.catid=22: This is the vulnerable parameter.22is a legitimate category ID.
- Injection:
+and+substring(@@version,1,1)=X+: Represents a space character in a URL-encoded request.and: This is a SQL logical operator. It's appended to the originalWHEREclause condition forcatid.substring(@@version,1,1):@@version: This is a system variable in SQL Server that holds the database version string. For example, it might be'Microsoft SQL Server 2000 - 8.00.194 (SP1)'.substring(..., 1, 1): This function extracts a substring.- The first argument is the string to extract from (
@@version). - The second argument (
1) is the starting position (1-based index). - The third argument (
1) is the length of the substring to extract.
- The first argument is the string to extract from (
- Therefore,
substring(@@version,1,1)extracts the first character of the database version string.
=X: This compares the extracted first character with the valueX.Xis a character that the attacker is trying to guess.
Mapping of Code Fragments to Practical Purpose:
http://server/easygallery/index.php?PageSection=0&page=category&catid=22: Legitimate Request Base - This is how a normal request to view category ID 22 would look.+and+: SQL Injection Entry Point - This signifies the start of the injected SQL code, appending a condition to the existingWHEREclause.substring(@@version,1,1): Information Extraction Function - This is the core of the blind technique, designed to retrieve a specific character from the database version.=4or=5: Conditional Check / Guessing Value - This is the attacker's guess for the character at the specified position. The application's response will indicate if this guess is correct.> falseor> true: Response Indicator (Implied) - The paper implies that the application will respond differently based on the truthiness of the injected condition. A "false" response means the condition was not met, and a "true" response means it was. This is the "blind" aspect – the attacker infers the result from the application's behavior, not direct output.
Execution Flow:
- The attacker crafts a URL with
catidcontaining a legitimate ID followed byANDand asubstringcondition. - The web server passes this URL to the EasyGallery script.
- The script constructs a SQL query, e.g.,
SELECT * FROM categories WHERE catid = 22 AND SUBSTRING(@@version,1,1) = '4'. - The database executes the query.
- If the first character of
@@versionis not '4', theANDcondition fails. The overallWHEREclause might evaluate to false or return no rows for category 22 under this condition. The application might display a generic "category not found" or a "false" indicator. - If the first character of
@@versionis '4', theANDcondition is true. The query might proceed to fetch category 22 information, or the application might indicate a "true" response. - The attacker observes the application's response and uses it to determine if their guess for the character was correct.
- This process is repeated for different characters and positions to reconstruct the
@@versionstring.
Practical details for offensive operations teams
- Required Access Level: Low (unauthenticated access to the web application).
- Lab Preconditions:
- A running instance of Myiosoft EasyGallery (or a similar vulnerable PHP web application).
- A web server (e.g., Apache, IIS) configured to serve the application.
- A database backend (likely SQL Server, given
@@version, but could be adapted for others). - Network access to the target web server.
- Tooling Assumptions:
- Web Browser: For manual testing and observation.
- HTTP Proxy/Interceptor (e.g., Burp Suite, OWASP ZAP): Essential for intercepting, modifying, and replaying HTTP requests. This is critical for automating the guessing process.
- Scripting Language (e.g., Python, PHP): To automate the sending of numerous requests and parsing of responses.
- SQLMap (or similar automated SQLi tools): While this paper demonstrates manual technique, tools like SQLMap can automate the entire process once the vulnerability is identified.
- Execution Pitfalls:
- Response Interpretation: The biggest challenge is reliably distinguishing between "true" and "false" responses. This might involve:
- Checking for specific content on the page.
- Observing HTTP status codes.
- Measuring response times (though less reliable for blind SQLi).
- Looking for the absence or presence of specific HTML elements.
- Database Type: The
@@versionfunction is specific to SQL Server. If the target uses MySQL, PostgreSQL, or Oracle, different system variables and functions would be needed (e.g.,version()in MySQL,version()in PostgreSQL,bannerin Oracle). - URL Encoding: Spaces and special characters in the injected payload must be correctly URL-encoded (e.g.,
+for space,%27for single quote). - Rate Limiting/WAFs: Frequent requests can trigger intrusion detection systems or web application firewalls, leading to IP blocking or request throttling.
- Character Set: The attacker needs to know or guess the character set of the database version string to correctly guess characters.
- Query Structure: The exact SQL query structure of the vulnerable application is unknown. The
22is assumed to be part of aWHERE catid = ...clause. If it'sWHERE catid IN (...)or similar, the injection might need adjustment.
- Response Interpretation: The biggest challenge is reliably distinguishing between "true" and "false" responses. This might involve:
- Tradecraft Considerations:
- Reconnaissance: Thoroughly map the application's structure and parameters. Identify all input fields that interact with the database.
- Manual Verification: Always start with manual testing to confirm the vulnerability before automating. This helps understand the response patterns.
- Stealth: Use a proxy to route traffic and consider techniques to evade detection (e.g., randomizing delays, using different user agents).
- Payload Evolution: If the initial
substring(@@version,1,1)doesn't work, try other functions or system variables to extract data. For example,user()ordatabase()for MySQL, orcurrent_userfor PostgreSQL.
Where this was used and when
- Context: This vulnerability was found in Myiosoft EasyGallery, a web-based photo gallery application.
- Approximate Year: Published in December 2009. This indicates the vulnerability existed and was likely exploitable around that time. Such vulnerabilities in older, unpatched web applications can persist for years.
Defensive lessons for modern teams
- Input Validation and Sanitization: This is the fundamental defense. All user-supplied input, especially parameters in URLs, forms, and cookies, must be treated as untrusted.
- Parameterized Queries/Prepared Statements: The most robust defense against SQL injection. Instead of concatenating user input into SQL strings, use parameterized queries where the input is treated as data, not executable code.
- Whitelisting: Only allow known-good characters or patterns for input.
- Blacklisting (Less Effective): While often used, blacklisting specific characters or keywords can be bypassed by attackers using encoding or alternative syntax.
- Least Privilege: Ensure the database user account used by the web application has only the minimum necessary permissions. This limits the damage an attacker can do even if they achieve SQL injection (e.g., they might not be able to access sensitive tables or execute administrative commands).
- Web Application Firewalls (WAFs): WAFs can detect and block common SQL injection patterns. However, they are not foolproof and can be bypassed by sophisticated attacks. They should be used as a layer of defense, not the sole solution.
- Regular Patching and Updates: Keep all web applications, frameworks, and server software up-to-date with the latest security patches. Vendors often release fixes for known vulnerabilities.
- Error Handling: Configure web applications to display generic error messages to users in production environments. Detailed database errors can leak sensitive information and aid attackers. Log detailed errors server-side for debugging.
- Security Audits and Code Reviews: Regularly audit web application code for common vulnerabilities like SQL injection.
ASCII visual (if applicable)
This vulnerability is purely a web application-level issue involving HTTP requests and SQL queries. There isn't a complex network architecture or system interaction to visualize with ASCII art. The core interaction is between the attacker's browser/tool and the web server.
+-----------------+ HTTP Request +-----------------+
| Attacker's Tool |---------------------->| Web Server |
| (Browser/Proxy) | (Vulnerable URL) | (EasyGallery) |
+-----------------+ +-------+---------+
|
| SQL Query
v
+-----------------+
| Database Server |
| (SQL Server) |
+-----------------+Source references
- PAPER ID: 10873
- PAPER TITLE: EasyGallery - 'catid' Blind SQL Injection
- AUTHOR: Hussin X
- PUBLISHED: 2009-12-31
- PAPER URL: https://www.exploit-db.com/papers/10873
- RAW URL: https://www.exploit-db.com/raw/10873
Original Exploit-DB Content (Verbatim)
Myiosoft easygallery (catid) Blind SQL Injection Vulnerability
___________________________________
Author: Hussin X
Home : www.IQ-TY.com<http://www.IQ-TY.com>
MaiL : darkangeL_G85@Yahoo.CoM
___________________________________
script : http://myiosoft.com/?1.105.0.0
Exploit :
_______
true & false
http://server/easygallery/index.php?PageSection=0&page=category&catid=22+and+substring(@@version,1,1)=4 > false
http://server/easygallery/index.php?PageSection=0&page=category&catid=22+and+substring(@@version,1,1)=5 > true
end
IQ-SecuritY FoRuM