The premise of this challenge was similar to Hacker TS - we had input that was rendered into a PDF using wkhtmltopdf. However, our payload had to fit the following constraints:

  • name validated for alphanumeric characters

  • email uses RFC5322 validation

The email parameter is naturally more realistic to exploit, so I dived into RFC5322 and found the part that specified the allowed characters.

   addr-spec       =   local-part "@" domain

   local-part      =   dot-atom / quoted-string / obs-local-part

   domain          =   dot-atom / domain-literal / obs-domain

   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

   dtext           =   %d33-90 /          ; Printable US-ASCII
                       %d94-126 /         ;  characters not including
                       obs-dtext          ;  "[", "]", or "\"

The email is made up of <local-part>@<domain>, and interestingly the domain allows for a domain-literal format - [<any printable ASCII character>].

This allows us, for example, to use the following payload:[<h1>test</h1>]

My teammate Enyei then found that this endpoint was also vulnerable to SSTI - it seems that the input is first rendered into a Jinja2 template before being passed to wkhtmltopdf.

The following will render the email as test@[49], for instance:[{{7*7}}]

At this point, we can craft a payload that reads the flag.txt file:[{{}}]

Last updated