Browse Like an Agent on Kuoni Website
Before someone complains about the content of this post, I had tried to contact Kuoni back in early 2019 with no success. Some of the emails bounced back but an email to HR + the Agents address at Kuoni did get accepted and didn’t bounce – there was never a response to those emails.
As I wrote this post at the weekend and was about to click upload to my blog, I thought I’d try one last time to notify Kuoni. I sent out an email to the various contacts listed on the press page + the HR email address and a few (failed) guessed attempts for the infosec team. This time someone got back to me (on the 26th August 2020) to let me know the issues mentioned in this post had been fixed.
I was browsing for a holiday at the start of 2019 and was disappointed that I couldn’t price up a holiday on the Kuoni website – you had to get in contact with an agent (at the time). A bit annoyed, I went back to Google and I can’t quite remember how, ran across the agent website for Kuoni (http://agents.kuoni.co.uk).
I was puzzled… I’d managed to find the portal that presumably the Agents used from their offices (e.g. in John Lewis) but it wasn’t secured by TLS! If it had been, I might have stopped looking further but the fact that a well known company would put a login page on HTTP completely perplexed me enough to start looking around.
I entered some random text into the form boxes and clicked Continue. To my amazement, the form did a GET (who uses GET for a login form!) to the https://agents.kuoni.co.uk page. Needless to say, my credentials weren’t right but it had now piqued my interest even further.
Back on the unsecured agents.kuoni.co.uk, looking through the source code, it even gives a hint at the amount of commission:
Gotta love commented out code 😉
In the emails I (attempted to) sent to Kuoni, I wrote the following about the unsecured portion of the site:
http://agents.kuoni.co.uk […] is a non-secured webpage which is incredibly unusual given it’s asking for details which can be intercepted. For example, I can either on a target machine intercept the html, change the url and make the GET request go via my app, or more simply, since the page uses a GET to send the details, use a proxy to get the ABTA number, password and “your name/reference” field.
So, what to do next? See what’s on the secured part of the website 😀
If you go to https://agents.kuoni.co.uk, it loads a page that allows you to start searching and within a second or two, it then redirects the browser back to the unsecured site. My first reaction… odd… normally you’d expect not to see anything at the other end and get an immediate 401 HTTP response code saying unauthenticated. So to see the page and then get redirect… I wonder what’s doing that and whether I can stop it redirecting me 😀
If you look in the browser’s developer tools at the network requests when loading https://agents.kuoni.co.uk, you’ll see over 30 requests over the secured domain to various resources and then the request to get the unsecured domain. Tracking backwards through the requests closest to the “redirect”, you’ll then stumble across the request to fetch homepage.xsl and in that file is the code that checks if you’ve signed on (see image below).
So, what happens if you load that page again and are fast enough on the stop button to get most of the page to load but not the xsl file?
But can you do anything once you’re there? Well there’s a lot of commented out code again about incentives but I won’t list those… And you can search for a holiday, althoug it is a bit temperamental and may log you out a few times before you get any results. Interestingly when compiling these images today, I got a warning from the browser about content being sent insecure when attempting to search – don’t remember that from 2019.
(It took a few attempts to get a result, possibly because of the lack of holidays during Covid-19)