7 ms·

Also notice the different attitudes of affected services: - OneDrive "[...] reiterated that the issues we discovered do not qualify as a security vulnerability

by jiiam 10y ago

Also notice the different attitudes of affected services: - OneDrive "[...] reiterated that the issues we discovered do not qualify as a security vulnerability" - Google Maps "[...] responded immediately. All newly generated goo.gl/maps URLs have 11- or 12-character tokens, and Google deployed defenses to limit the scanning of the existing URLs." Well done, Microsoft!

Artemis2 10y ago
Microsoft's Security Response Center (MSRC as mentioned in the article) is terrible. I've reported a security issue in Outlook.com and Outlook for Office 365 in July, and every month I get an email from the case manager telling me that "the team is still working on this". Mind you, I reported a similar bug three years ago and it got fixed in "only" two weeks. In both cases it's a trivial fix with mitigations already in place. I'm not even mentioning how hard it is to talk to someone about a bounty. I'm considering migrating away from Microsoft products because of this; they offer bounties for important bugs but the way they handle reports is horrible.
- mdpopescu 10y ago
  Microsoft is huge, and the teams behave differently. I have reported two different problems I had with Visual Studio 2015, using the included feedback mechanism, and received back email responses in a couple of hours. In both cases I was able to solve the problem I had and they actually followed up a couple of days later to make sure the problem was definitely fixed. True, none of those were security issues.
- billyhoffman 10y ago
  I worked with MSRC several times over the years and found them to be smart security professionals (and often former hackers) who care deeply about improving security. I suggest you take the long view and compare how Microsoft handled security disclosures in the past ("That vulnerability is entirely theoretical.") compared with today (inviting hackers to their oncampus Bluehat conference, sponsoring CanSecWest, etc). Things could always get better, but they've come a long way. More specifically, "only" 2 weeks to issue a security fix is actually pretty good for thick client/desktop software. It's less than ideal for something like a web app where they control all the machines that need to adopt the fix, but still. Also, the severity of reported issue is a factor in when something gets fixed. Consider looking at something like rfp's RFPolicy if you'd like guidance on how to disclose in a reasonable, timely way
  - louis-paul 10y ago
    I completely agree with you, in general they have come a long way (bounties, culture, recognition...). They're just not there yet (by there in mean Facebook-grade responsiveness). I was only voicing my personal experience, which has been very poor (maybe the team, or the seriousness of the bugs), but in general I have heard some good things, especially for truly critical issues.
    - danjoc 10y ago
      >Facebook-grade responsiveness When did Facebook become the pinnacle of security response? The last thing I read about them was pretty horrible. Much worse than the Microsoft response here. http://exfiltrated.com/research-Instagram-RCE.php http://exfiltrated.com/research-Instagram-RCE.php
      - gedrap 10y ago
        I remember this story, and people familiar with the industry (tptackek and friends) explained the situation quite well why Facebook did the correct thing, although not fair for unfamiliar with the industry readers https://news.ycombinator.com/item?id=10754194 https://news.ycombinator.com/item?id=10754194
  - ktRolster 10y ago
    "only" 2 weeks to issue a security fix is actually pretty good for thick client/desktop software. That's actually even more of a reason to migrate away from Microsoft.
  - milesskorpen 10y ago
    I think you misread his comment — the issue was reported _years_ ago and then fixed just two weeks back.
    - Artemis2 10y ago
      You misread it! I reported one a long time ago, which was fixed in two weeks (so relatively quickly). Another, very similar, reported nearly a year ago, still isn't fixed.
achow 10y ago
OneDrive has removed the short url. Verified in my account.
- basch 10y ago
  it says that in the article. it also says existing urls are still vulnerable
zeveb 10y ago
Note that '11- or 12-character tokens' really aren't secure either: assuming mixed-case and digits, that's only 65- to 71-bit security; if it's case-insensitive, that reduces to 56- to 62-bit security. That's still pretty easily enumerable. For mixed-case and digits, one requires at least 22 truly-random characters to provide 128 bits of security (43 for 256-bit security).
- d--b 10y ago
  We're talking number of URLs, not number of CPU iterations. Exploring 2^56 URLs is not that easy.
  - brianwawok 10y ago
    Exploring 2^56 URLs is possible. Exploring it with anti-brute force detection from the keeper of said URLs? Good luck. They could easily limit any ip to 10 URLs per hour or something and make it impossible to scan.
    - d--b 10y ago
      Really? If you could make 1,000,000 requests per second, exploring 2^56 URLs would take you 2000 years.
    - zeveb 10y ago
      > They could easily limit any ip to 10 URLs per hour or something and make it impossible to scan. Then an attacker would just use a botnet. Granted, he can probably get interesting items off of the computers in his botnet too.
  - zeveb 10y ago
    > Exploring 2^56 URLs is not that easy. Not easy, but not impossible. And it's not the case that an attacker is looking for one interesting URL: he's looking for any interesting URLs. Depending on the number of URLs stored in the service, and the fraction which are at all interesting, it may very well be worth the attacker's bother. As an aside, why the heck is my post so heavily downvoted? It's factual: the given lengths are not long enough to be secure from brute-forcing; they probably will be brute-forced.
ladzoppelin 10y ago
You left out this: "As of March of 2016, the URL shortening option is no longer available in the OneDrive interface, and the account traversal methodology described above no longer works." Both companies still have not solved the existing link problem. Edit: As someone said below, Google still allows the short method with more entropy which is still insecure. MS does not allow shortening.
- chias 10y ago
  Except that, according to Microsoft, this change had absolutely nothing to do with the report, which they still consider to be not-a-vulnerability.
  - addicted 10y ago
    Maybe I'm missing something, but if the URL shortening feature doesn't exist anymore, how can it be a vulnerability? Edit: The issue would be with existing links, but it's difficult to change existing links for obvious reasons. Both MS And Google at this point have calculated that deleting existing vulnerable links would be worse than the security issues presented here.
  - ignoramous 10y ago
    To give them the benefit of the doubt, what they could have meant was that it was an onerous feature that swapped privacy for convenience. Besides, scanning of URLs should be prevented by bit.ly in this case, no? What's MSFT to do?
- scosman 10y ago
  What is insecure about more entropy + blocking scanners? By that rational any internet connected service with a password is insecure.
patcheudor 10y ago
The fact that anyone considers a shortened URL as a means to secure a piece of data outside of authentication saddens me. I think that should be the key point here. Did you just get a URL that gives you a bit of data without the need to authenticate? Then it's not secure.
- deleted 10y ago
  [deleted]
- matt4077 10y ago
  How is a URL with that's not linked anywhere different from a password?
  - skybrian 10y ago
    A secret kept in a URL is less likely to be treated as confidential, both by people and machines. For example, compared to a cookie, they're more likely to be shared or logged.
  - jakobegger 10y ago
    It is not. The problem is that short URLs are often only six characters long, so they are just as safe as a six character password (ie. not very safe)
    - patcheudor 10y ago
      Far less safe because you use a password in combination with a userID so to crack someone's account you must have their login name and password. Six characters are six characters, easy.
  - tedmiston 10y ago
    One difference is a GET is likely to have less/no rate limiting vs. a login POST, making it faster to brute force.
  - mikegerwitz 10y ago
    Are you confident that it doesn't appear anywhere else? There's two main concerns: the first being that you use a URL differently---and think of it differently---than a password; and the URL persists in various forms. Accessing a resource on the Web might be logged in numerous places---e.g. your web history and internal network logs or MITM if not over https---and might be sent as metadata, like a referer header to another website. Imagine if all of your passwords were logged by your client any time you entered them in.
gist 10y ago
> and Google deployed defenses to limit the scanning of the existing URLs I find it amazing that they didn't do this in advance and needed to have this happen to know to fix it. I remember way back in 1996 or 1997 being able to do URL scans of UPS shipping tracking numbers. It was trivial to bring up the ship to address for any given shipper (for all of there customers) as long as you had at least one of a shippers tracking numbers (then just alter to suit). [1] [1] So in other words if I received a UPS package with a tracking number for ABC company I could easily see every else that they were shipping to including names, addresses.
- tedmiston 10y ago
  There was a similar vulnerability with Delta boarding passes... in 2014. http://gizmodo.com/hacker-says-url-trick-grants-access-other-peoples-delta-1671747336 http://gizmodo.com/hacker-says-url-trick-grants-access-other...
ThomPete 10y ago
Microsoft famously used the term "non event" for several of their hick ups. Gotta give them credit for their retorical skills :)
krick 10y ago
Except Microsoft is kinda right: it is not a security vulnerability. If somebody can access given url just by guessing it — well, it it unprotected, so implicitly it is supposed to be accessed by anyone. No matter how long it is. I could've found it via google, you might have exposed it by sending it via email/skype/whatever. For what it's worth I can bruteforce 12-character urls as easily: if you don't know where do you want to get, it doesn't matter which road you take, so as long as I get at least some valid urls by random guessing — it is virtually as insecure, as if every url would be valid. Praising google and blaming microsoft on that is actually stupid and harmful — this "concerned about security" image is nothing but marketing move for naïve people. If shortened urls are twice as long as before, does it mean that now it's safe to have some confidential information assigned to them left without authentication? I bet it doesn't. But it sort of implies so. The url shortening service just got worse, by being twice less efficient in what it's supposed to do: shorten urls. But not more safe, not at all.
- tetrep 10y ago
  > If somebody can access given url just by guessing it — well, it it unprotected, so implicitly it is supposed to be accessed by anyone. No matter how long it is. Let's see what happens when we apply this logic to cryptography... If somebody can access you data just by guessing it's key — well, it it unprotected, so implicitly it is supposed to be accessed by anyone. No matter how long the key is.
  - krick 10y ago
    Except you don't expose passwords to the third party (and bit.ly, email provider and stuff all are third parties), and if you do — it's your fault you've got fucked. And you can chose arbitrary length key or password, and do not get randomly generated 6/12 char password for you. And, uh, I almost forgot, passwords are supposed to protect some information, and urls are supposed to show somebody the road to where this information is stored. It's pretty much by definition, if you unwrap the abbreviature. That's why you have logins and passwords in the first place, not just longer logins: the first is supposed to be public (to be shared if need to be) and is used to access some resource, and the second is supposed to be kept private and is used to authenticate that access. And url shorteners are supposed to make urls short and nothing more. And in fact your comment and the fact that you think these things are comparable is exactly what is dangerous about the situation, and not the damn short urls themselves. It's like some guys forcing drillmakers to start making drills out of rubber, because some idiot tried to pick his teeth with turned-on drill and got killed. See how dangerous drills are! Well, yeah, they are pretty dangerous, but how about just not picking your teeth with the fucking drill, and not applying "toothpicking logic to drillmaking"? By the way, the guy with rubber drill still can kill himself with that — it's just less efficient for both drilling wood and killing idiots. Exactly like what it is with "longer shortened urls.

by jiiam 10y ago

Artemis2 10y ago

Microsoft's Security Response Center (MSRC as mentioned in the article) is terrible. I've reported a security issue in Outlook.com and Outlook for Office 365 in July, and every month I get an email from the case manager telling me that "the team is still working on this". Mind you, I reported a similar bug three years ago and it got fixed in "only" two weeks. In both cases it's a trivial fix with mitigations already in place. I'm not even mentioning how hard it is to talk to someone about a bounty. I'm considering migrating away from Microsoft products because of this; they offer bounties for important bugs but the way they handle reports is horrible.

mdpopescu 10y ago
Microsoft is huge, and the teams behave differently. I have reported two different problems I had with Visual Studio 2015, using the included feedback mechanism, and received back email responses in a couple of hours. In both cases I was able to solve the problem I had and they actually followed up a couple of days later to make sure the problem was definitely fixed. True, none of those were security issues.
billyhoffman 10y ago
I worked with MSRC several times over the years and found them to be smart security professionals (and often former hackers) who care deeply about improving security. I suggest you take the long view and compare how Microsoft handled security disclosures in the past ("That vulnerability is entirely theoretical.") compared with today (inviting hackers to their oncampus Bluehat conference, sponsoring CanSecWest, etc). Things could always get better, but they've come a long way. More specifically, "only" 2 weeks to issue a security fix is actually pretty good for thick client/desktop software. It's less than ideal for something like a web app where they control all the machines that need to adopt the fix, but still. Also, the severity of reported issue is a factor in when something gets fixed. Consider looking at something like rfp's RFPolicy if you'd like guidance on how to disclose in a reasonable, timely way
- louis-paul 10y ago
  I completely agree with you, in general they have come a long way (bounties, culture, recognition...). They're just not there yet (by there in mean Facebook-grade responsiveness). I was only voicing my personal experience, which has been very poor (maybe the team, or the seriousness of the bugs), but in general I have heard some good things, especially for truly critical issues.
  - danjoc 10y ago
    >Facebook-grade responsiveness When did Facebook become the pinnacle of security response? The last thing I read about them was pretty horrible. Much worse than the Microsoft response here. http://exfiltrated.com/research-Instagram-RCE.php http://exfiltrated.com/research-Instagram-RCE.php
    - gedrap 10y ago
      I remember this story, and people familiar with the industry (tptackek and friends) explained the situation quite well why Facebook did the correct thing, although not fair for unfamiliar with the industry readers https://news.ycombinator.com/item?id=10754194 https://news.ycombinator.com/item?id=10754194
- ktRolster 10y ago
  "only" 2 weeks to issue a security fix is actually pretty good for thick client/desktop software. That's actually even more of a reason to migrate away from Microsoft.
- milesskorpen 10y ago
  I think you misread his comment — the issue was reported _years_ ago and then fixed just two weeks back.
  - Artemis2 10y ago
    You misread it! I reported one a long time ago, which was fixed in two weeks (so relatively quickly). Another, very similar, reported nearly a year ago, still isn't fixed.

achow 10y ago

OneDrive has removed the short url. Verified in my account.

basch 10y ago
it says that in the article. it also says existing urls are still vulnerable

zeveb 10y ago

Note that '11- or 12-character tokens' really aren't secure either: assuming mixed-case and digits, that's only 65- to 71-bit security; if it's case-insensitive, that reduces to 56- to 62-bit security. That's still pretty easily enumerable. For mixed-case and digits, one requires at least 22 truly-random characters to provide 128 bits of security (43 for 256-bit security).

d--b 10y ago
We're talking number of URLs, not number of CPU iterations. Exploring 2^56 URLs is not that easy.
- brianwawok 10y ago
  Exploring 2^56 URLs is possible. Exploring it with anti-brute force detection from the keeper of said URLs? Good luck. They could easily limit any ip to 10 URLs per hour or something and make it impossible to scan.
  - d--b 10y ago
    Really? If you could make 1,000,000 requests per second, exploring 2^56 URLs would take you 2000 years.
  - zeveb 10y ago
    > They could easily limit any ip to 10 URLs per hour or something and make it impossible to scan. Then an attacker would just use a botnet. Granted, he can probably get interesting items off of the computers in his botnet too.
- zeveb 10y ago
  > Exploring 2^56 URLs is not that easy. Not easy, but not impossible. And it's not the case that an attacker is looking for one interesting URL: he's looking for any interesting URLs. Depending on the number of URLs stored in the service, and the fraction which are at all interesting, it may very well be worth the attacker's bother. As an aside, why the heck is my post so heavily downvoted? It's factual: the given lengths are not long enough to be secure from brute-forcing; they probably will be brute-forced.

ladzoppelin 10y ago

You left out this: "As of March of 2016, the URL shortening option is no longer available in the OneDrive interface, and the account traversal methodology described above no longer works." Both companies still have not solved the existing link problem. Edit: As someone said below, Google still allows the short method with more entropy which is still insecure. MS does not allow shortening.

chias 10y ago
Except that, according to Microsoft, this change had absolutely nothing to do with the report, which they still consider to be not-a-vulnerability.
- addicted 10y ago
  Maybe I'm missing something, but if the URL shortening feature doesn't exist anymore, how can it be a vulnerability? Edit: The issue would be with existing links, but it's difficult to change existing links for obvious reasons. Both MS And Google at this point have calculated that deleting existing vulnerable links would be worse than the security issues presented here.
- ignoramous 10y ago
  To give them the benefit of the doubt, what they could have meant was that it was an onerous feature that swapped privacy for convenience. Besides, scanning of URLs should be prevented by bit.ly in this case, no? What's MSFT to do?
scosman 10y ago
What is insecure about more entropy + blocking scanners? By that rational any internet connected service with a password is insecure.

patcheudor 10y ago

The fact that anyone considers a shortened URL as a means to secure a piece of data outside of authentication saddens me. I think that should be the key point here. Did you just get a URL that gives you a bit of data without the need to authenticate? Then it's not secure.

deleted 10y ago
[deleted]
matt4077 10y ago
How is a URL with that's not linked anywhere different from a password?
- skybrian 10y ago
  A secret kept in a URL is less likely to be treated as confidential, both by people and machines. For example, compared to a cookie, they're more likely to be shared or logged.
- jakobegger 10y ago
  It is not. The problem is that short URLs are often only six characters long, so they are just as safe as a six character password (ie. not very safe)
  - patcheudor 10y ago
    Far less safe because you use a password in combination with a userID so to crack someone's account you must have their login name and password. Six characters are six characters, easy.
- tedmiston 10y ago
  One difference is a GET is likely to have less/no rate limiting vs. a login POST, making it faster to brute force.
- mikegerwitz 10y ago
  Are you confident that it doesn't appear anywhere else? There's two main concerns: the first being that you use a URL differently---and think of it differently---than a password; and the URL persists in various forms. Accessing a resource on the Web might be logged in numerous places---e.g. your web history and internal network logs or MITM if not over https---and might be sent as metadata, like a referer header to another website. Imagine if all of your passwords were logged by your client any time you entered them in.

gist 10y ago

> and Google deployed defenses to limit the scanning of the existing URLs I find it amazing that they didn't do this in advance and needed to have this happen to know to fix it. I remember way back in 1996 or 1997 being able to do URL scans of UPS shipping tracking numbers. It was trivial to bring up the ship to address for any given shipper (for all of there customers) as long as you had at least one of a shippers tracking numbers (then just alter to suit). [1] [1] So in other words if I received a UPS package with a tracking number for ABC company I could easily see every else that they were shipping to including names, addresses.

tedmiston 10y ago
There was a similar vulnerability with Delta boarding passes... in 2014. http://gizmodo.com/hacker-says-url-trick-grants-access-other-peoples-delta-1671747336 http://gizmodo.com/hacker-says-url-trick-grants-access-other...

ThomPete 10y ago

Microsoft famously used the term "non event" for several of their hick ups. Gotta give them credit for their retorical skills :)

krick 10y ago

Except Microsoft is kinda right: it is not a security vulnerability. If somebody can access given url just by guessing it — well, it it unprotected, so implicitly it is supposed to be accessed by anyone. No matter how long it is. I could've found it via google, you might have exposed it by sending it via email/skype/whatever. For what it's worth I can bruteforce 12-character urls as easily: if you don't know where do you want to get, it doesn't matter which road you take, so as long as I get at least some valid urls by random guessing — it is virtually as insecure, as if every url would be valid. Praising google and blaming microsoft on that is actually stupid and harmful — this "concerned about security" image is nothing but marketing move for naïve people. If shortened urls are twice as long as before, does it mean that now it's safe to have some confidential information assigned to them left without authentication? I bet it doesn't. But it sort of implies so. The url shortening service just got worse, by being twice less efficient in what it's supposed to do: shorten urls. But not more safe, not at all.

tetrep 10y ago
> If somebody can access given url just by guessing it — well, it it unprotected, so implicitly it is supposed to be accessed by anyone. No matter how long it is. Let's see what happens when we apply this logic to cryptography... If somebody can access you data just by guessing it's key — well, it it unprotected, so implicitly it is supposed to be accessed by anyone. No matter how long the key is.
- krick 10y ago
  Except you don't expose passwords to the third party (and bit.ly, email provider and stuff all are third parties), and if you do — it's your fault you've got fucked. And you can chose arbitrary length key or password, and do not get randomly generated 6/12 char password for you. And, uh, I almost forgot, passwords are supposed to protect some information, and urls are supposed to show somebody the road to where this information is stored. It's pretty much by definition, if you unwrap the abbreviature. That's why you have logins and passwords in the first place, not just longer logins: the first is supposed to be public (to be shared if need to be) and is used to access some resource, and the second is supposed to be kept private and is used to authenticate that access. And url shorteners are supposed to make urls short and nothing more. And in fact your comment and the fact that you think these things are comparable is exactly what is dangerous about the situation, and not the damn short urls themselves. It's like some guys forcing drillmakers to start making drills out of rubber, because some idiot tried to pick his teeth with turned-on drill and got killed. See how dangerous drills are! Well, yeah, they are pretty dangerous, but how about just not picking your teeth with the fucking drill, and not applying "toothpicking logic to drillmaking"? By the way, the guy with rubber drill still can kill himself with that — it's just less efficient for both drilling wood and killing idiots. Exactly like what it is with "longer shortened urls.