My wife and I were selling our home last year and we ended up being pretty satisfied with our Realtor team, partially due to their adoption of technology. One example was their use of ShowingTime, which is a Real Estate Showing Management System that, among other things, allows sellers to easily confirm or reschedule showing requests from an app or the web. We used the software frequently over the span of a few weeks, so naturally I took a closer look. My research revealed multiple vulnerabilities, including the ability for an attacker to completely compromise Real Estate Agent accounts.
Here’s the email the seller receives after an agent has requested a showing on behalf of his potential buyer:
Clicking one of the links above opens up the web-based appointment center.
The seller is able to access all of his requested showings as well as see feedback from previous showings. I found several Insecure Direct Object References in this web application, but these only allowed access to the reports of other home owners. Though those vulnerabilities were still privacy issues that needed to be patched, something else caught my attention.
Note that clicking any of the above links in the email did not require a login. Looking a bit closer, I found that ShowingTime was using a custom URL shortener that allowed for “single click” confirm or decline responses to showing requests. Their URL structure was in the form http://showingti.me/XXXXXX , meaning all URLs were created with only six characters from the traditional URL shortner character set (numbers and uppercase/lowercase letters), resulting in just 52 billion distinct URLs. Here’s a look an example request:
GET http://showingti.me/XXXXXX HTTP/1.1 Host: showingti.me Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8
The response then redirected to a route request, which set a cookie and logged me in:
GET http://showingti.me/account/route?l=re:22434255:Reports%2fListingActivityReportOwner%2f25665217:***REMOVED*** HTTP/1.1 Host: showingti.me Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Cookie: ASP.NET_SessionId=***REMOVED***
It was important to consider the number of unique URLs that had already been taken and whether or not they would eventually expire. Given that both realtors and sellers receive similar emails (the former obviously having higher permissions), and at least six unique URLs are created per showing request (three for the seller and agent), it was evident that the design posed a substantial risk; they were blatantly trading convenience for security.
Below is a simple script I wrote to demonstrate the issue:
while(TRUE)
{
$key = generateRandomString();
$url = "http://showingti.me/$key";
$r = curl($url);
if(strpos($r, "The URL is expired or incorrect") === FALSE)
{
echo "$url\n";
exit();
}
}
Running this script produced a successful hit in less than a minute. While this may have just been luck, I was reasonably confident that there were enough existing URLs in their database to make this a serious vulnerability– a much more serious vulnerability if an attacker found a realtor’s URL, which obviously would allow him to cause a lot more damage.
I reached out to ShowingTime and reported these issues to their CIO, who was very responsive and open to the discussion. He was very appreciative of the reports and worked with me on patch timelines.
Disclosure Timeline
2014-08-19: Initial report of IDOR vulns
2014-08-22: Acknowledgement of vulns, working on fixes
2014-09-02: Additional IDOR vulns reported
2014-09-19: Additional vulns acknowledged, fixes scheduled for 9/22
2014-09-22: Confirmed patches released
2014-09-23: Report URL shortener flaw w/ PoC
2014-09-24: Flaw acknowledged, but fix is “long term”
2015-07-10: Follow up on URL flaw, tested as still existing
2015-07-13: Acknowledgement and explanation, mitigation scheduled for end of August
2015-08-18: Mitigation attempts released
That’s not a typo. Almost a year later, I followed up and found the URL issue still hadn’t been resolved. It was understandable that it would take some time to solve since ShowingTime used the short URLs in their SMS alerts to customers (limited to 160 characters), but almost a year seemed too long. I requested another follow-up and a firm date of resolution. When I was notified that the resolution was released, I found that rather than address the design flaw directly, they opted to mitigate the risk of abuse by instituting tougher WAF rules. I expressed concerns with this approach adamantly, but ShowingTime was content with the relatively “low-risk” of abuse and exploitation from their perspective.
Share this:
