Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS Privacy: Easily get a user's Apple ID password, just by asking

krausefx.com

Post reply on HN
Print view View original

261–270 of 326 posts

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#261

Post by kelnos »

amelius wrote: post #252
tolmasky wrote: post #212

When the iPhone X notch was first announced I thought it would be a fantastic security UI opportunity: What if the top of the screen was only writable by the system? It would normally be black or show the time, but whenever there is a password dialog, it turns green with a security lock. This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole scree…

Great idea. Except, I'm not sure if the average user would benefit from this. Would they be aware of this feature? (Of course, no question that for us hackers this would be a very useful improvement!)

Not initially, but just as users can be 'trained' to automatically enter in their password when they see a popup, they can eventually be trained to expect a new UI element to indicate it's secure.

Seems like in browsers, the lock icon and (for EV certs) company name in the location bar has been a plus, so there's certainly precedent for this sort of thing.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#262

Post by seiferteric »

TylerE wrote: post #216
seiferteric wrote: post #197

Earlier quoted context omitted.

Ya there are some solutions, like you can prefix a '\' before a command to make sure you are running the real command and not a alias, so in your example running: \sudo would defeat your attack. But few are in the practice of doing that.

Would it? If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?

Isn't the login shell set in /etc/passwd? So you would need root to either modify that, or to overwrite the shell binary.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#263

Post by ecesena »

jon889 wrote: post #232
ecesena wrote: post #110

On iOS the test of pressing the home button and see if the app goes in background seems a pretty strong one. Perhaps in a future Apple can make you press the home button as part of the verification, so it’s kind of implicit.

Perhaps when you put your finger on the home button it would read your fingerprint and authenticate you like that and the user wouldn't have to enter their password into a box that might steal it.. I can spend thousands using just my fingerprint, but authorising my Apple ID so I can buy a 99p app or login into iMessage requires my Apple ID password...

It's already like that - I assume the phishing only works for people that don't use fingerprint, or don't notice the difference.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#264

Post by seiferteric »

slrz wrote: post #237
seiferteric wrote: post #197

Earlier quoted context omitted.

Ya there are some solutions, like you can prefix a '\' before a command to make sure you are running the real command and not a alias, so in your example running: \sudo would defeat your attack. But few are in the practice of doing that.

> But few are in the practice of doing that. Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.

I'm sure there are plenty of tricks. I could be wrong, but I think the \ is a shell builtin thing, so I don't think creating a \sudo or the like would work. You could set the PATH and put a fake sudo in a secret directory in there that precedes the /usr/bin/sudo though, so that would be a problem.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#265

Post by MichaelGG »

jychang wrote: post #254
andrewla wrote: post #249

Earlier quoted context omitted.

Not really. From the GP > This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole screen's buffer means you can fake a logged out screen asking you to log in, or any other number of phishing attacks. In Windows, I can render the whole screen, so I can put up a fake login dialog. To some extent, Windows users are used to requiring a ctrl-alt-delete…

No, he's correct. Ctrl-Alt-Delete on windows is a privileged hotkey that goes directly to the kernel. A phishing program can't intercept it once it has been pressed. If you know that Ctrl-Alt-Delete has been pressed, you are already privileged as the kernel and would be able to compromise a hypothetical protected screen buffer anyways. https://i.imgur.com/BE0xN3i.png The Windows login screen here doesn't allow you to…

Programs can detect Ctrl alt del somehow, because RDP clients do it. But they can't intercept it.

But a phishing program can just show the enter password screen, without the ctrl alt del prompt. Few users understand the security need to press ctrl alt del. And in newer Windows, it doesn't seem to prompt unless you enable it via GP.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#266

Post by andrewla »

jychang wrote: post #254
andrewla wrote: post #249

Earlier quoted context omitted.

Not really. From the GP > This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole screen's buffer means you can fake a logged out screen asking you to log in, or any other number of phishing attacks. In Windows, I can render the whole screen, so I can put up a fake login dialog. To some extent, Windows users are used to requiring a ctrl-alt-delete…

No, he's correct. Ctrl-Alt-Delete on windows is a privileged hotkey that goes directly to the kernel. A phishing program can't intercept it once it has been pressed. If you know that Ctrl-Alt-Delete has been pressed, you are already privileged as the kernel and would be able to compromise a hypothetical protected screen buffer anyways. https://i.imgur.com/BE0xN3i.png The Windows login screen here doesn't allow you to…

There are two vectors here; the one that the post was talking about is the fact that as long as an application controls the screen, they can show whatever they want -- for example, an app (or a full-screen web site) could render a pixel-perfect version of this:

https://i.stack.imgur.com/LHDfV.png

And the user would say "oh, another stupid UAC prompt", enter their password, and that would be that -- UAC doesn't stop and say "press ctrl-alt-delete to enter your password". If it did, then that would significantly decrease the risk here.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#267

Post by jakemor »

Well written. I wrote a similar article over a year ago here — https://medium.com/@jakemor/how-someone-can-steal-your-iclou...

It highlights the same exact security issue. The solution is simple: only ask for passwords in the SETTINGS app. Have the alert route users there.

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#268

Post by shabble »

seiferteric wrote: post #264
slrz wrote: post #237

Earlier quoted context omitted.

> But few are in the practice of doing that. Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.

I'm sure there are plenty of tricks. I could be wrong, but I think the \ is a shell builtin thing, so I don't think creating a \sudo or the like would work. You could set the PATH and put a fake sudo in a secret directory in there that precedes the /usr/bin/sudo though, so that would be a problem.

untested, but I think you could possibly bypass it with a malicious .inputrc binding for , although making it conditional such that it only removed a leading \ could be tricky.

In Bash there might also be a way to do something cunning with a 'trap DEBUG' hook to modify the command between submission and it actually being run.

Or you could just exec into a terminal multiplexer like screen[1] to intercept & rewrite/suppress both commands and output.

Edit: It's much easier than that.

The function:

    echo () { command echo "hax" $@; }
will still be called by '\echo test' (The 'command' prefix stops it becoming a forkbomb :)

[1] or maybe just hijack stdin/out FDs from the shell?

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#269

Post by jsjohnst »

intoverflow2 wrote: post #161
jsjohnst wrote: post #114

Earlier quoted context omitted.

On my iPhone it does. It goes from a light grey (normal keyboard) to a dark grey (system password entry keyboard).

Try it in a few more apps it's the choice of the app dev so basically random. Not that a user should have to know "only enter your password into the black keyboard", which can also be faked mind.

Yes, I know about UIKeyboardAppearance and how apps can influence that, this isn't what I am talking about. When I say "system password" dialog, I am talking specifically about requests for my iCloud/iTunes/phone password. Unfortunately I can't seem to trigger it now, but I distinctly remember in the past the keyboard looked slightly different than the dark keyboard theme. Maybe I am wrong!

Re: iOS Privacy: Easily get a user's Apple ID password, just by asking

#270

Post by matwood »

jedberg wrote: post #111
mikeash wrote: post #50

Earlier quoted context omitted.

If someone finds my phone, it'll be locked and they won't be able to install anything. If they can unlock the phone then it's already game over for me.

You’re using the phone and set it down, it hasn’t auto locked yet. They have your lock screen password but not your iTunes password. You thought they were a friend and let them borrow your unlocked phone. Even for a security conscience person there are plenty of situations where someone could get your unlocked phone. And most people aren’t security conscience. It’s to protect them, not you.

> You’re using the phone and set it down, it hasn’t auto locked yet.

I'm not even security conscious, and always lock my phone before setting it down. I think it started because turning off the screen as soon as you're done saved significant battery life on the phones prior to them knowing if they were laying flat.

Post reply on HN