5 ms·

Log.d("Facebook-authorize", "Login Success! access_token=" + getAccessToken() This is not wolf in sheep's clothing, it is wolf in wolf's furry clothing. Oauth

Log.d("Facebook-authorize", "Login Success! access_token=" + getAccessToken() This is not wolf in sheep's clothing, it is wolf in wolf's furry clothing. Oauth access token is pretty much as powerful as a password, and it is being written to debug log here. Amazing how this code passed code review!

inlined 15y ago
It's probably a shame that the technology is abbreviated OAuth(orization) because people think OAuth(entication) and forget to handle the string with the reverence it needs.
depoll 15y ago
;) Fair enough. At least we agree that it's a wolf!
- deleted 15y ago
  [deleted]
twiceaday 15y ago
); OCD kicking in.
ktizo 15y ago
Is that like a wolf squared, or is it just a really emphatic wolf that looks pretty pissed?
dirkdk 15y ago
the fact that my Android app can read log statements of other apps is also helping creating this security hole. Sandbox each app I would say!
- huggyface 15y ago
  http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS http://developer.android.com/reference/android/Manifest.perm... This was a similar issue with the CarrierIQ thing. Apps have to explicitly request this permission, and it's a strange one that should raise red flags unless it is explicitly intended for such a purpose. Indeed, the app that the author links to - https://play.google.com/store/apps/details?id=com.nolanlawson.logcat&hl=en https://play.google.com/store/apps/details?id=com.nolanlawso... - under permission there's the READ SYSTEM LOGS. Sadly a ridiculous number of apps demand it for questionable reasons (for instance https://play.google.com/store/apps/details?id=com.sirma.mobile.bible.android https://play.google.com/store/apps/details?id=com.sirma.mobi... -> Why does a Bible need to read from system logs?)
  - fpgeek 15y ago
    The Bible app is particularly strange because they explain some of the other permissions they use, but not why they need access to system log data.
    - joelhaasnoot 15y ago
      There are more apps out there that use this permission to submit crash reports and logs to the developer for debugging. The Bible app probably has a large enough scale, high adoption rate, and enough moving parts to make for a bad app if they didn't get that feedback. Edit: Have this app, contributed some translations. This app is pretty popular across many countries and locales, meaning the crash reports are essential for good user experience.
      - fpgeek 15y ago
        Yeah, that's something that should be fixed in Android, IMO. You shouldn't need system log permissions to capture a crash report - the OS should give you a standard way to say "I want crash reports" (might be as simple as an email address to send to). After a crash, the user should be given a dialog from the system (not the app) about whether or not they want to send the crash report data. I thought I'd seen something like that in the past, but it might have only been for system apps or something.
        tesseract 15y ago
        In some kinds of apps there can be issues that are not necessarily crashes, but where a log from the user's system is still helpful in diagnosis. Perhaps the answer is to make an app's own log and relevant system logs - but not the logs of other apps - available to that app.
        fpgeek 15y ago
        Good point, though the more I think about it the issues are tricky. Access to the app's own log seems like a reasonable convenience (since the app could have recorded that anyway). On the other hand, there are cases I can see (e.g. confidential documents in a word processor) where you don't want the app developer to have access to everything you do with the app (which is what giving access to the app's own log can easily turn into). The nice thing about the crash reporter case is that even if the crash report is ready-to-go the user still gets to decide whether or not to send it, so they still have direct control. Perhaps the right line would be an "own log" permission.
sk5t 15y ago
At least in OAuth 1.0a, the access token is only useful if you also know the consumer secret (provided the PLAINTEXT signature method is not in use). Of course, the consumer secret probably isn't difficult to fish out, and besides, this 'attack' relies on the user typing his password into an untrusted device... so, yeah.
- ajross 15y ago
  What? It relies on the user typing his password into a personal smartphone that just happens to have a trojan app installed. How much more "trusted" can you get? Relying on users never to install malicious software is not a valid security model (as witnessed by decades of experience in the PC market), and I'm shocked that you think so.
  - sk5t 15y ago
    Err... so you're okay with typing your username and password into a personal computer running software configured under another person's control? That's about as far away from "trusted" as possible. The author describes getting into other folks' FB accounts by having them log in on his own device. Not their own devices.
    - ajross 15y ago
      You've misunderstood the exploit. Logging into someone else's phone is an artifact of the test (because clearly he's not going to push a malicious app to the market!), not a requirement for the exploit. Any app with the log reading capability can do that. And any app can request that capability. As pointed out elsewhere there's a Bible app that does it.
      - sk5t 15y ago
        I follow the issue of defeating the purpose of the sandbox -- the token is sent to a log where other apps can read it, so an app that has "read sensitive log files" and "access network" rights could run amok over the user's FB. The article goes on to describe getting access to other folks' accounts, but only after convincing them to enter credentials. But there are already plenty of drawbacks to installing malicious apps on your own smartphone, and lots of reasons not to enter credentials on some random device.
bitops 15y ago
> Amazing how this code passed code review! This statement presupposes that a code review took place.

inlined 15y ago

It's probably a shame that the technology is abbreviated OAuth(orization) because people think OAuth(entication) and forget to handle the string with the reverence it needs.

depoll 15y ago

;) Fair enough. At least we agree that it's a wolf!

deleted 15y ago
[deleted]

twiceaday 15y ago

); OCD kicking in.

ktizo 15y ago

Is that like a wolf squared, or is it just a really emphatic wolf that looks pretty pissed?

dirkdk 15y ago

the fact that my Android app can read log statements of other apps is also helping creating this security hole. Sandbox each app I would say!

huggyface 15y ago
http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS http://developer.android.com/reference/android/Manifest.perm... This was a similar issue with the CarrierIQ thing. Apps have to explicitly request this permission, and it's a strange one that should raise red flags unless it is explicitly intended for such a purpose. Indeed, the app that the author links to - https://play.google.com/store/apps/details?id=com.nolanlawson.logcat&hl=en https://play.google.com/store/apps/details?id=com.nolanlawso... - under permission there's the READ SYSTEM LOGS. Sadly a ridiculous number of apps demand it for questionable reasons (for instance https://play.google.com/store/apps/details?id=com.sirma.mobile.bible.android https://play.google.com/store/apps/details?id=com.sirma.mobi... -> Why does a Bible need to read from system logs?)
- fpgeek 15y ago
  The Bible app is particularly strange because they explain some of the other permissions they use, but not why they need access to system log data.
  - joelhaasnoot 15y ago
    There are more apps out there that use this permission to submit crash reports and logs to the developer for debugging. The Bible app probably has a large enough scale, high adoption rate, and enough moving parts to make for a bad app if they didn't get that feedback. Edit: Have this app, contributed some translations. This app is pretty popular across many countries and locales, meaning the crash reports are essential for good user experience.
    - fpgeek 15y ago
      Yeah, that's something that should be fixed in Android, IMO. You shouldn't need system log permissions to capture a crash report - the OS should give you a standard way to say "I want crash reports" (might be as simple as an email address to send to). After a crash, the user should be given a dialog from the system (not the app) about whether or not they want to send the crash report data. I thought I'd seen something like that in the past, but it might have only been for system apps or something.
      - tesseract 15y ago
        In some kinds of apps there can be issues that are not necessarily crashes, but where a log from the user's system is still helpful in diagnosis. Perhaps the answer is to make an app's own log and relevant system logs - but not the logs of other apps - available to that app.
        fpgeek 15y ago
        Good point, though the more I think about it the issues are tricky. Access to the app's own log seems like a reasonable convenience (since the app could have recorded that anyway). On the other hand, there are cases I can see (e.g. confidential documents in a word processor) where you don't want the app developer to have access to everything you do with the app (which is what giving access to the app's own log can easily turn into). The nice thing about the crash reporter case is that even if the crash report is ready-to-go the user still gets to decide whether or not to send it, so they still have direct control. Perhaps the right line would be an "own log" permission.

sk5t 15y ago

At least in OAuth 1.0a, the access token is only useful if you also know the consumer secret (provided the PLAINTEXT signature method is not in use). Of course, the consumer secret probably isn't difficult to fish out, and besides, this 'attack' relies on the user typing his password into an untrusted device... so, yeah.

ajross 15y ago
What? It relies on the user typing his password into a personal smartphone that just happens to have a trojan app installed. How much more "trusted" can you get? Relying on users never to install malicious software is not a valid security model (as witnessed by decades of experience in the PC market), and I'm shocked that you think so.
- sk5t 15y ago
  Err... so you're okay with typing your username and password into a personal computer running software configured under another person's control? That's about as far away from "trusted" as possible. The author describes getting into other folks' FB accounts by having them log in on his own device. Not their own devices.
  - ajross 15y ago
    You've misunderstood the exploit. Logging into someone else's phone is an artifact of the test (because clearly he's not going to push a malicious app to the market!), not a requirement for the exploit. Any app with the log reading capability can do that. And any app can request that capability. As pointed out elsewhere there's a Bible app that does it.
    - sk5t 15y ago
      I follow the issue of defeating the purpose of the sandbox -- the token is sent to a log where other apps can read it, so an app that has "read sensitive log files" and "access network" rights could run amok over the user's FB. The article goes on to describe getting access to other folks' accounts, but only after convincing them to enter credentials. But there are already plenty of drawbacks to installing malicious apps on your own smartphone, and lots of reasons not to enter credentials on some random device.

bitops 15y ago

> Amazing how this code passed code review! This statement presupposes that a code review took place.