An update on our security incident • Hacker News Board

Re: An update on our security incident

#111

Post by tdhoot » Fri, Jul 31, 2020, 6:59 AM UTC

londons_explore wrote: post #104

ma2rten wrote: post #84

Earlier quoted context omitted.

Google requires its employees to use a security key for access to all internal systems including admin tools, source code and email. Every since google started enforcing this policy the number of successful phishing attacks has gone down to basically zero.

I believe the Twitter attack involved tricking a user into installing proxy software on their machine (to be in twitter's internal network). If that is the case, that same proxy software could proxy the security key requests too.

That can be prevented by restricting the software that can be installed on employee machines.

Re: An update on our security incident

#112

Post by thereyougo » Fri, Jul 31, 2020, 7:07 AM UTC

> We’re acutely aware of our responsibilities to the people who use our service and to society more generally. We’re embarrassed, we’re disappointed, and more than anything, we’re sorry. We know that we must work to regain your trust, and we will support all efforts to bring the perpetrators to justice. We hope that our openness and transparency throughout this process, and the steps and work we will take to safeguard against other attacks in the future, will be the start of making this right.

It's not easy to say those words about your own company.

I really believe them.

Re: An update on our security incident

#113

Post by [deleted] » Fri, Jul 31, 2020, 7:17 AM UTC

londons_explore wrote: post #104

ma2rten wrote: post #84

Earlier quoted context omitted.

Google requires its employees to use a security key for access to all internal systems including admin tools, source code and email. Every since google started enforcing this policy the number of successful phishing attacks has gone down to basically zero.

I believe the Twitter attack involved tricking a user into installing proxy software on their machine (to be in twitter's internal network). If that is the case, that same proxy software could proxy the security key requests too.

[deleted]

Re: An update on our security incident

#114

Post by hutzlibu » Fri, Jul 31, 2020, 7:21 AM UTC

bawolff wrote: post #41

idoh wrote: post #37

Earlier quoted context omitted.

Where I work there is training software that is somewhat effective at preventing phising - it actually sends out phising emails itself. Then employees who fall for it are given extra training (in a no fault sort of way).

Perhaps, but im also wary of these types of things, because i worry that people will feel embarassed at being tricked, and will (maybe subconciously) see the internal security team as the enemy, which is also a bad outcome. I also worry that the emails might not represent real attack emails, and we end up training users to identify the test emails but not real attack emails. (Not that i got any better solution)

Nothing is 100% secure. Having users fail to spot a pishing mail, is a very good training on general awareness, but no guarantee, that they will not make misstakes under pressure.

Re: An update on our security incident

#115

Post by FireBeyond » Fri, Jul 31, 2020, 7:23 AM UTC

sushshshsh wrote: post #20

iamleppert wrote: post #11

They should require hardware security devices (dongles). Really Twitter should be ashamed of their poor internal security.

Dongles are rare here in the US. But I know that bloomberg uses them. I was shocked when I learned that retail banks in Singapore give everyone dongles to log in. In the US that's tyranny Lol

When I worked at MSFT in 2006, remote access required a smart card plus credentials.

Re: An update on our security incident

#116

Post by m463 » Fri, Jul 31, 2020, 7:24 AM UTC

Shared404 wrote: post #70

rudolph9 wrote: post #60

Earlier quoted context omitted.

I can’t tell if this is trolling or a serious comment of how this will roll out?

It's a comment on government inefficiency.

Seriously I worked on projects subject to government scrutiny and it was ok, but you had to be the right kind of person.

Account for your time in 6-minute increments. Milestones I recall off the top of my head were preliminary design, detailed design, 3-5% of your time coding, software integration, hardware software integration, acceptance.

It was stable, predictable, and (to me) very soul-crushing.

Re: An update on our security incident

#117

Post by gsich » Fri, Jul 31, 2020, 7:26 AM UTC

whoisjuan wrote: post #17

nodesocket wrote: post #6

Earlier quoted context omitted.

Why are internal employee tools publically accessible? Minimum they should require VPN access, but really go further with Zero Trust.

AFIK, in a Zero Trust Architecture a VPN is considered a perimeter and therefore it becomes a vector of attack to access systems of authoritative decision. Many security researchers have already established that the benefits of a VPN especially in the modern distributed world are marginal at best. Basically, yes a VPN makes you a tiny bit safer but it also adds a lot of networking complexity and adds more friction to…

>Many security researchers have already established that the benefits of a VPN especially in the modern distributed world are marginal at best.

Yes, with the (wrong) assumption that after you have connected to a VPN, all other services are free for the taking, without any further authentication.

Re: An update on our security incident

#118

Post by Thorrez » Fri, Jul 31, 2020, 7:33 AM UTC

carstenhag wrote: post #54

Thorrez wrote: post #30

Earlier quoted context omitted.

Some password databases involve copy and pasting or autotyping. If you want automatic hostname verification you need a password database integrated with your browser. On mobile many browsers don't support extensions so integrating my password database into the browser would be hard. In short, I do not know my ebay password, but I could have fallen for this phishing attack.

On mobile this is possible even without browser extensions - enpass, lastpass etc work just fine in Chrome or any other app, if it detects a password field.

Oh, you're right. I didn't know Android had that feature. Apparently I was way behind the times. I can no longer edit or delete my comment.

Re: An update on our security incident

#119

Post by thaumasiotes » Fri, Jul 31, 2020, 7:37 AM UTC

_8j50 wrote: post #40

As someone who works to stop these, the most frustrating part is how even infosec people thik enough training or $vendor's email security solution will stop this. It's like boy scouts that think they will stop navy seals. There is too much focus on entry point of an attack,especially by news media.

Speaking from experience at a major infosec company, the impression I got internally was "we offer phishing tests, but we don't recommend them, because phishing succeeds 100% of the time".

So I'm confused by the idea "even infosec people think training will stop this".

Re: An update on our security incident

#120

Post by Thorrez » Fri, Jul 31, 2020, 7:45 AM UTC

qzio wrote: post #91

Thorrez wrote: post #21

Earlier quoted context omitted.

Note that not all hardware security devices are safe. U2F security devices are safe against phishing; OTP security devices are not safe against phishing.

what about a phishing attack that involves the attacker talking the target through a login, which also involves the u2f part? and then obtaining the session token from memory/disk instead of username/password

How would the attacker get something from memory or disk? Malware? If there's malware involved I don't consider that credential phishing. It's a matter of debate whether malware can be considered a form of phishing. Maybe I should be been more clear that U2F stops credential phishing, not malware phishing (if that even exists).

I guess one option would be to ask the victim to read out the token from memory or disk. That seems pretty hard though. It's debatable whether that would be considered credential phishing.

A more likely method would be to trick someone into going into devtools and copy and pasting something from there, possibly a curl command, like in this epic "bug report"[1]. That's also debatable whether it would be credential phishing.

[1] https://hackerone.com/reports/745324