Maybe I’m feeling like a victim, and quite possibly Yahoo have done nothing wrong. But I’ve heard many cases about Yahoo and how they deal with security, and in my personal experience, it isn’t pretty. Today, I will be releasing a conversation between me and the Yahoo Security team about an open redirect vulnerability. It is on the top 10 of OWASP’s threats and should be well known for any security team. Before anyone goes mad because I’m publicly disclosing a vulnerability, well, I’m not. It has been removed mysteriously and I’ve had a message back saying they suddenly cannot reproduce the vulnerability I had encountered. What a funny situation we have here, so let’s trawl through the break up of me and the Yahoo Security team, prepare, it ain’t a pretty one.

If you are unfamiliar with Hackerone, it is a place which facilitates responsible disclosure, and I’m all for it. I found a vulnerability in a site which is run by Yahoo (It powers the search and other functionality of the site) and simply branded as AT&T.  Here is my initial report to Yahoo, alerting them on such a vulnerability.

Initial Response

Fairly normal report, I could obviously have given more information and admittedly hackerone had changed the encoding of some of the characters which didn’t help in reproducing the vulnerability. Which is why I was fine with the first response I got, I don’t mind that it was very late from initial response, maybe they have a lot of work, I don’t mind that.So here I have given them a Google shortened version which preserves the characters so that they can get it to redirect appropriately. I fully understand that open redirects aren’t the RCE of the vulnerability world. But it’s good not to have them. The next response from Yahoo, I was completely fine with, maybe they don’t really understand why it’s pointing to a parked area.

He wanted me to redirect it to his site. The way this vulnerability works is that I’ve simply added exploitpoc.clouddns.biz to the end of the domain in the redirecturl parameter. You need to have the whitelisted domain in the redirecturl for it to work. The vulnerability requires an A record of the exploit domain to be liketotally80s.com, which I thought was fairly common knowledge in websec. I also gave a tamper data screenshot to give definitive proof that the exploit works. I used my domain because I simply did not want to have a connection error due to his domain not having liketotally80s.com A record. What I did is I created another redirect to his site, fairly common and a lot of companies I’ve also reported to understood it.

Tamperdata capture

Here we can see the GET requests which show that att.net redirects to liketotally80s.com.exploitpoc.cloudns.biz, but he has the shortened domain, so he will see this too.As I’ve previous stated in the first part of my report, I had been exploiting the redirectURL validation. Even if I had redirected to yours I still needed a redirect from att.net to make it work. I thought I gave an extensive explanation as to why I did this. At this moment, I thought this was a slightly bit tedious and really felt that this was just a prolonged two and fourth from me and this employee. To say the least, I was ready for throwing in the towel at this point.

So the next image gives me pain, after all that explanation I get this response, it is quite clear they have been able to reproduce the vulnerability, but are arguing that due to me redirecting again to another site, this isn’t a open redirect. They talk about the enc value being checked and it working on my domain, a simple fix of validation in the redirecturl would of done this job nicely. I think I’ve given my best here, and for a couple of days I didn’t respond. Today, Yahoo come back asking for video evidence or something similar. I thought open redirects were well known right?

The timing on this response is very peculiar, because I had a honeypot on reddit for anons running on this exploit (It was simply to show how some people don’t see how easy it is to gather information on them) , it would run through my site give me the IP and other information. Here some verification it uses the exploit.

Here’s some proof I used an A record to redirect to the anonpot

And guess when it was last working? Yesterday, my log file was last modified yesterday by a Google bot viewing the link. It’s kind of suspicious in the timing of things to say the least. So what’s happened now?

I thought I’d give enough proof to show that it does log and everything. You can check that they have removed the functionality by simply putting the dork site:”att.net” inurl:”redirect” click on any of these links and it won’t work. The timing is very funny indeed.

To add insult to injury they admit they removed the functionality but say they couldn’t verify the vulnerability. Even though they could reproduce it well enough to see it was somehow bypassing the enc value. Maybe it’s me with a slight anger for Yahoo right now but I’m calling bullshit on all of this straight away, he could be right though, maybe it’s all a matter of coincidence. Unfortunately with other reports to Yahoo I’ve had similar problems and shall be disclosing any future Yahoo vulnerabilities publicly. I see it as a complete slap in the face for them to add “do you have any additional information for us at this time?”

Anyway, my rant is over, the choice is yours, decide which of us are in the wrong. It’s safe to say you’re like the crazy ex-girlfriend Yahoo, never again.