TGI Friday’s is an american style restaurant chain that is popular not just in the United States, but also in other countries all over the world.

My initial interest sparked when I received a marketing email from TGI Fridays promoting their new online ordering system.

While they don’t have a bug bounty program, I still had contacts with them from the previous IDOR issue I found, so I figured it would be interesting to dive in deeper to this new system to see how it worked.

After adding a menu item into my cart, I visited the checkout page and noticed the content type in the POST request was Application/JSON and was returning JSON in the responses as well. After changing the content type to Application/XML, I was greeted with a 400 Bad Request response error containing the following JSON.

At this point my tail started wagging. Hello Java XML parser!

XML attacks are nothing new and have been around for a long time, but one particular attack I’ve used in the past is called an XML External Entity attack, or XXE.

The XXE attack targets applications that parse XML input and have a poorly configured XML parser.

The XML 1.0 data standard defines a concept called an entity, which is a storage unit of sorts. There are several types of entities, but one in particular is called an “external entity”. External entities can access local or remote content via a declared system identifier. The system identifier takes the form of a URI that can be dereferenced (accessed) by the XML processor when the entity is processed. The XML processor then replaces occurrences of the named external entity with the contents dereferenced by the system identifier.

XML input containing a reference to an “external entity” can lead to the disclosure of confidential data, Denial of Service (trying to read /dev/null or /dev/urandom), Server-Side Request Forgery (SSRF), Cross-Site Port Attacks (XSPA), aka port scanning from the perspective of the machine where the parser is located, and in some cases, Remote Code Execution (RCE) via “php://” or “expect://” URI’s.

I quickly realized that attempts to execute Out-of-Band XXE attacks made successful requests to my webserver. After some trial and error, I found I needed to include

tags in the request to get a response other than a generic error message. When trying to return the contents of the /etc/passwd file, I found it particularly interesting that attempts to use the “http://” URI for data exfiltration were met with parsing errors due to newline characters. At this point I was only able to get file enumeration.

A quick Google search led me to slides from a very awesome BlackHat 2015 presentation called FileCry – The New Age of XXE by Xiaoran Wang & Sergey Gorbaty. These slides led me to trying the “jar://” and “netdoc://” URI’s. The “jar://” URI didn’t seem to like the “\n” character, but “netdoc://” ended up returning the contents of the file in the response underneath the error.

Here is the final PoC attack. I have redacted some of the contents of the response for obvious reasons.

The Request:

My out-of-band server contained a dtd file with the following:

The Response:

Remote Code Execution via “expect://” or “php://” URI’s was not possible in this case, but this type of attack still merited a very high severity.

The safest method to prevent these attacks is to completely disable external DTDs (External Entities) in the XML parser configuration. If it is not possible to disable DTDs completely, then external entities and external doctypes must be disabled in the way that’s specific to each parser.

More information on preventing XXE attacks can be found here: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

Disclosure Timeline

1/09/2017: Vulnerability Discovered.

1/09/2017: Sent initial email regarding the issue to Kathy Kotel, my contact from last time I discovered a vulnerability in TGI Fridays.

1/12/2017: Received response and sent detailed PoC report.

1/30/2017: Sent email checking on status.

2/07/2017: Resent email checking on status.

2/08/2017: Received reply that they have contacted the vendor and are working to get a timeline for the fix.

2/13/2017: Received confirmation that TGIF is actively working on the fix with the vendor. The anticipated timeline is by the end of February.

3/01/2017: Issue is fixed.

I would like to thank Kathy Kotel and the TGI Fridays IT Team for their rockstar efforts to quickly resolve this issue.