3

Let's say you have a app which uses passwords. During development, you want to troubleshoot some things, and use NSLog() to print out the password to see if it is working properly.

At a certain moment you are happy and everything is working. You send your app to Apple and finally the app is accepted and submitted to the App store.

You forgot to remove the NSLog() which output the password....

Is there any way this can be bad? Or is there any way a hacker can listen to those NSLogs()?

jscs
  • 63,694
  • 13
  • 151
  • 195
  • 1
    It's possible to view the NSLog output from Xcode. Even in a production build. Window>devices. This is bad since phones can be stolen! – Eyeball Feb 12 '15 at 17:04
  • 2
    (Yes, it was a fairly serious error on your part, depending on how critical this password is.) – Hot Licks Feb 12 '15 at 17:06
  • This is very bad practice. Don't use NSLogs for debugging. Use break points that output to the console or, even better, Activity Tracing. – Robotic Cat Feb 12 '15 at 17:38
  • @RoboticCat - Nothing wrong with using NSLog for debugging, and, in fact, I don't know how you'd debug without it. But one should have a macro defined for debug-mode NSLogs, so they automatically get compiled out when the product is compiled for distribution. – Hot Licks Feb 12 '15 at 21:53
  • @HotLicks: Without getting into a big debate you end up with source code commits with just `NSLog` comments and some get left in (as per OP). Also, here's a link on how to log to the console and debug without putting `NSLog`'s directly into your code: http://stackoverflow.com/q/8059919/558933 . It's been covered several times at WWDC as well and there are videos on it. Apple also now offer Activity Tracing. See the WWDC 2014 Video `#714 Fix Bugs Faster With Activity Tracing`: https://developer.apple.com/videos/wwdc/2014/#714 – Robotic Cat Feb 12 '15 at 22:03

4 Answers4

3

Yes, this could be very bad, if your app crashes. Once users sync their device, the crash logs will make their way to their computer, along with the content of NSLog. This makes plaintext passwords available to anyone with a binary file reader.

For example, if Alice gives her phone to Bob, then Bob enters his password, completes his task, logs off, and gives Alice her phone back. Then your app crashes. Once Alice syncs her phone, she gains access to Bob's password.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • 1
    Also anyone can download a free console reader and attach the device while running an app to see whatever NSLog is outputting. – ChrisH Feb 12 '15 at 17:04
  • But in that case it depends on how safe your computer is. It's not possible to read remote log files. – Berendschot Feb 12 '15 at 17:04
  • @Maarten1909 That's assuming that someone else is "the bad guy". I am assuming that "the bad guy" could be you (in my example, that would be Alice). – Sergey Kalinichenko Feb 12 '15 at 17:06
  • @dasblinkenlight That's true, but I trust my friends :-) – Berendschot Feb 12 '15 at 17:07
  • @ChrisH Please tell me more. What console reader and can I do that with an iPad (or whatever) without entering the passcode? –  Feb 12 '15 at 17:08
  • http://lemonjar.com/iosconsole/ will let you read the logs that your ios device is outputting in real time. – ChrisH Feb 12 '15 at 17:15
2

Yes, this is bad. I have seen discussions in which attackers quickly asked about device console logs. Using the strings from those logs, they can quickly search the executable binary for similar strings, like the format string used for part of the log entry. Example: 

NSLog(@"user entered password '%@'", passwordString)

Finding the format string, they can quickly find the part of code that actually uses that string, and thus they have found the part of code that processes passwords. They can then analyze the relevant code to bypass the password altogether or do whatever they want.

Even if the device does not hold a lot of console data for long, all an attacker might need to do is connect a stolen device to a computer, start the app and enter a random password. If the app logs the password (correct or incorrect), then the needed strings are still captured and the attack begins.

Of course, if the log line is still in the device console data, an attacker also gets the actual password for an actual user. And if that user reuses user names and passwords (as many people do) the attacker may now have the credentials to a user's other accounts on the internet, which may be more sensitive.

Many programming discussions advise against using NSLog directly and recommend using a macro like DEBUGLOG which will compile out of release builds. If that is used for debugging, then the app will not leave such clues for an attacker to use.

Walt Sellers
  • 3,806
  • 30
  • 35
  • Last paragraph exactly. There should be no NSLog whatsoever in your source code, unless you _intend_ that the user finds out how to open the log files, to read the NSLog output, and to act on it. – gnasher729 Feb 12 '15 at 17:45
0

It depends on what kind of passwords your storing. I believe that log files are stored on your iPhone. But I'm quite sure that reading these files without connecting the actual device to a computer is impossible.

Extra note: If I have to be honest, I wouldn't reject my app for reviewing at this moment. It's a good idea to prepare a patch and when your app is reviewed you should upload the new version as soon as possible. However if your saving passwords that connects the app to some sort of database, I would reject it.

Berendschot
  • 3,026
  • 1
  • 21
  • 43
0

I guess . device log would contain that password !! this can be seen at xcode-window-device/device logs .

Saket Kumar
  • 1,157
  • 2
  • 14
  • 30