Hacker News Reader

Comment by gruez | Hacker News Reader

Anyone have links to more of these images?

Also, if you search for the source for one of the images (mentioned in the article), you can find this tweet: https://twitter.com/UnderTheBreach/status/128349929454113177... which says the recent hacks were done through that tool.

View on HN

I saw this Imgur album linked in one of the original tool tweets. Not sure if fake or real obv.

https://imgur.com/a/2sqjNUo

I don't understand this angle because typically admin panels only let you manage the account; deactivate, manage email address, etc. As shown in the screenshots.

Tweeting on behalf of another user seems like an unnecessary feature to give admins.

Some suggested the admin panel can initiate a password reset, and that, coupled with email management would allow account takeover, effectively (without allowing 'tweet as user' functionality).

All the hacked accounts seem to have had the associated email changed. I think the attack goes admin panel -> change email -> reset PW -> tweet bitcoin scams.

https://twitter.com/sniko_/status/1283485972286656517

if this were true, youd think itd be trivial to review changelog for two affected users and deactivate the in-common admin account. not sure why this would take hours to solve.

You're assuming this internal tool was built securely and was feature complete.

My experience with internal tooling in general suggests otherwise.

changing emails is a common way to keep account owners out of their accounts. might not have anything to do with the mode of entry.

Given the number of accounts that were taken over, there must have been many people conducting the hack. Also considering that tweets were being deleted then re-tweeted, others must have been monitoring the tweets. Seems somewhat well coordinated.

The feature wouldn't be tweeting per-se but acting on behalf of the user, which can prove useful for support or debugging. The side-effect is that obviously it also allows tweeting if you wanted to.

I'm starting to think web facing site admin is a bad idea. Assuming that's what this is, I don't know.

But I'm surprised it's still a thing.

Is there a better solution? How do you airgap administration of a web facing service?

It's painful (although I suppose all airgap solutions are) but remote access protocols like RDP or SSH tunneling to a jump host which has access to the administration portal is one common(?) solution.

That's only safer from attacks that bypass the public admin portal authentication. Any social engineering attack that steals credentials directly won't be impacted.

It’s another layer of defense. Someone has to not only know your credentials but also know how to use them to get to the jump host, and from the jump host know what to do next (although unless it’s ephemeral, there are probably enough bread crumbs to find the proper url).

The point is, that's not an airgap; RDP and ssh tunneling are transititive and we're all logging on from home right now.

I don't know... I've seen a lot of forums that just put a login form in /admin and I just kind of assumed a site like Twitter would use a VPN or ssh or a custom app with its own secret sauce protocol or something... better than I could have whipped up in my PHP monkey days.

It's quite common to restrict connections to whitelisted IPs

IP restrict the admin console at the application or (better) firewall layer. This means you need to VPN in to use it offsite. Put MFA on your VPN. None of this will save you from a malicious internal actor.

What part of it's administration? For example, if it's a windows machine, you control it (or it's AD PDC) with a PAW (privileged access workstation), which has to connect from a specific interface, which is not on the internet (that is, you connect via a hard line, usually via a pair of dedicated encryption devices over a point to point telco link, like ISDN/MPLS etc).

If you mean "log onto the machine and change the config" then it isn't really an air gap anymore. Usually it's a group of VMs, you change the image master (via Chef, docker etc) and boot a new instance. Ideally it's architected so most admin tasks go through an API, with auth, access control, logging, change control, etc. If you have a standardised message bus for your API you can used a Trusted Guard, aka CDS, which is a carefully designed (for high assurance, formally verified) protocol inspector designed to only allow correct protocol messages to transit. If the guard and it's ruleset pass independent analysis it is considered airgap equivalent under govt rules.

Reply on news.ycombinator.com