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

The inception bar: a new phishing method

jameshfisher.com

Post reply on HN
Print view View original

171–180 of 238 posts

Re: The inception bar: a new phishing method

#171

Post by iforgotpassword »

IshKebab wrote: post #100
Waterluvian wrote: post #51

Earlier quoted context omitted.

In high school we would screenshot the windows 98 desktop, make it the wallpaper, hide everything, and watch people fluster about.

In high school I replicated the entire login UI of NT LAN manager (I think it was called) and had it save the password and then crash the machine (via c:\con\con). Asked the teacher to login for something and tada, admin password. If you ever wondered why you have to press ctrl-alt-del to log in, that is why (nobody ever fixed this for Linux).

> If you ever wondered why you have to press ctrl-alt-del to log in, that is why (nobody ever fixed this for Linux).

Seems you're not familiar with Linux. It had SAK since forever.

Re: The inception bar: a new phishing method

#172

Post by geuszb »

akersten wrote: post #68

With a little polishing this would be quite the "exploit" - trap the user in your fake browser, actually load pages that are entered into the fake URL bar, replace content only on certain patterns... The only solution here is a proper line of death [0]. It defeats the purpose of the LoD when it dynamically shrinks from user action. [0]: https://textslashplain.com/2017/01/14/the-line-of-death/

Thanks. This is a great reference indeed!

The challenge is preserving ability for content to control all pixels; without it, the content ecosystem ends up developing single-purpose, generally crappy apps, which isn't necessarily a better thing either...

I'm not sure it is the only solution either - what about "secure attention key" type ways to get the system's attention (in this case the browser's), bypassing any content interception? For example, what if there was a key combo guaranteed to always bring in the browser UI, and typing that key combo was necessary before inputting any password field?

Alternatively, the reliance on browser password management could provide some security if it can be trusted to always work...

Re: The inception bar: a new phishing method

#173

Post by Izkata »

afandian wrote: post #99

I can't help but think that this was made possible by the complete collapse in common UI standards. 'Apps' have stopped being OS-toolkit apps and moved onto the web, and of course each designer needs to have their own special on-brand widget style. This has leaked onto the few remaining desktop apps: Chrome rejects the standard Mac OS widgets and reimplements everything, from buttons to the print dialog. Spotify does…

Um, what? Standardization of UI is what makes this type of thing feasible large-scale, not the collapse of standardization.

Even just in this case - making it look like Chrome mobile results in a different bar than Firefox mobile. If they converge more though it'd take less effort to hit more people.

Re: The inception bar: a new phishing method

#174

Post by ehnto »

atomwaffel wrote: post #145
Macha wrote: post #143

Earlier quoted context omitted.

If the user says no to the real dialog, you can never bring up the real dialog again. Sites with fake dialogs in my experience ask again the next time you open the page.

It’s the same reason many iPhone apps implement their own dialogues to ask about allowing notifications. If the user chooses ‘Deny’ in the system-provided one, the app can never ask again and the only way to turn notifications on later is to have the user go digging around in the Settings app, which few people will bother to do. I take great pleasure in choosing ‘Allow’ in those custom dialogues and then ‘Deny’ when…

I would leave them alone entirely, as you can see from my comment they are actually sometimes attempts to compromise your browser.

Re: The inception bar: a new phishing method

#175

Post by CodeWriter23 »

emmelaich wrote: post #94
Waterluvian wrote: post #51

Earlier quoted context omitted.

In high school we would screenshot the windows 98 desktop, make it the wallpaper, hide everything, and watch people fluster about.

Older school even -- instead of logging out of (real hardware) terminal sessions, exec a program which prints `login: ` and disables keyboard interrupts. Read peoples creds and store somewhere, then issue a 'wrong password' msg and exit, resulting in the real login message. People will just assume they made a typo and continue as if nothing happened. I've argued before for a genuine out-of-band independent display on…

Mine would log you in. Of course the OS (Oasis) had a way to exec the login program and feed it the password. I stole the teacher’s password and then changed it.

He busted me by booting up the system from floppy and typed in the commend to format the hard drive and waited for me to return to the lab after school. I asked him what he was doing and he said he had no choice but to reinstall from scratch because someone changed the password. He then moved to hit the Enter key.

Not wanting my fellow students to lose their projects, I confessed. I logged him in and he changed the password.

He then gave my account admin privileges. I guess I had earned them.

Re: The inception bar: a new phishing method

#176

Post by atomwaffel »

ehnto wrote: post #174
atomwaffel wrote: post #145

Earlier quoted context omitted.

It’s the same reason many iPhone apps implement their own dialogues to ask about allowing notifications. If the user chooses ‘Deny’ in the system-provided one, the app can never ask again and the only way to turn notifications on later is to have the user go digging around in the Settings app, which few people will bother to do. I take great pleasure in choosing ‘Allow’ in those custom dialogues and then ‘Deny’ when…

I would leave them alone entirely, as you can see from my comment they are actually sometimes attempts to compromise your browser.

Oh absolutely, I was referring only to native phone apps.

Re: The inception bar: a new phishing method

#177

Post by akersten »

geuszb wrote: post #172
akersten wrote: post #68

With a little polishing this would be quite the "exploit" - trap the user in your fake browser, actually load pages that are entered into the fake URL bar, replace content only on certain patterns... The only solution here is a proper line of death [0]. It defeats the purpose of the LoD when it dynamically shrinks from user action. [0]: https://textslashplain.com/2017/01/14/the-line-of-death/

Thanks. This is a great reference indeed! The challenge is preserving ability for content to control all pixels; without it, the content ecosystem ends up developing single-purpose, generally crappy apps, which isn't necessarily a better thing either... I'm not sure it is the only solution either - what about "secure attention key" type ways to get the system's attention (in this case the browser's), bypassing any co…

Those are some good ideas too - "only solution" was a bit hyperbolic - but I do think our options are limited, especially on mobile.

The Secure Attention Key is interesting, but would need the user to know you press it. And on mobile, it would probably need to be a dedicated button on the device, since I could just fake the on screen keyboard too.

Password manager auto-fill failing would clue a savvy user that something was wrong, but I suspect many would just assume it's a glitch and manually enter their credentials.

I saw an reply in another thread suggesting customizable browser background images for the UI bar, which a website would have no way of replicating. In my opinion that's probably the best approach, although it might mean throwing away the ability for sites to set the background color of the UI to match their theme (arguably losing nothing of value :).

Re: The inception bar: a new phishing method

#178

Post by jimktrains2 »

afandian wrote: post #99

I can't help but think that this was made possible by the complete collapse in common UI standards. 'Apps' have stopped being OS-toolkit apps and moved onto the web, and of course each designer needs to have their own special on-brand widget style. This has leaked onto the few remaining desktop apps: Chrome rejects the standard Mac OS widgets and reimplements everything, from buttons to the print dialog. Spotify does…

> 'Apps' have stopped being OS-toolkit apps and moved onto the web, and of course each designer needs to have their own special on-brand widget style.

Which is also why they are so abombinally large. Picking on Skype, but they are by no means the only or worst, the Android app is 71MB. There is no sane reason it needs to be that large except for all of the custom assets and custom widgets.

Re: The inception bar: a new phishing method

#179

Post by yjftsjthsd-h »

DownGoat wrote: post #163
ldng wrote: post #161

Slightly OT, but it's HTTPS so it must be safe, right ? It's an example of why the "HTTPS everywhere" push annoys me, it gives false sense of security. Security resources should be better spent. Also, back on topic, Google should stop handing blindly the wheel to "Designers". Oversimplification instead of properly educating people lead to this crap.

HTTPS everywhere is a good thing. HTTPS was never about protecting against phishing, and has never protected you against phishing. There is no way to educate people about phishing, only way to protect against it is U2F. Education against phishing is not very effective, and only works short term.

Right, but it was pushed as "lock icon means secure" and end users don't distinguish threat models.

Re: The inception bar: a new phishing method

#180

Post by mastef »

CodeWriter23 wrote: post #175
emmelaich wrote: post #94

Earlier quoted context omitted.

Older school even -- instead of logging out of (real hardware) terminal sessions, exec a program which prints `login: ` and disables keyboard interrupts. Read peoples creds and store somewhere, then issue a 'wrong password' msg and exit, resulting in the real login message. People will just assume they made a typo and continue as if nothing happened. I've argued before for a genuine out-of-band independent display on…

Mine would log you in. Of course the OS (Oasis) had a way to exec the login program and feed it the password. I stole the teacher’s password and then changed it. He busted me by booting up the system from floppy and typed in the commend to format the hard drive and waited for me to return to the lab after school. I asked him what he was doing and he said he had no choice but to reinstall from scratch because someone…

Interesting reaction. What was the thought process behind it? E.g. what did you use them for
Post reply on HN