A former Gizmodo writer changed name to 'Slackbot', stayed undetected for months | Hacker News Reader

A former Gizmodo writer changed name to 'Slackbot', stayed undetected for months

theverge.com

363 pointsmfiguiere133 comments

I knew an ex-employee back in the day (not me I swear) who created a dialup/ISDN provisioning profile called 'Ringing' in the modem rack controller module (not the Radius server, that would be too obvious), such that a glance at the modem rack status page showed everyone who was connected, and one that was 'Ringing', just like any other incoming call that hadn't been picked up yet. It went completely undetected, yielding 128Kbit ISDN service for well over a year.

Obviously I do not advise this, especially now that the CFAA has been interpreted to include things like changing URL parameters and flicking boogers on the carpet.

You got a reference on the CFAA? On the contrary, I found that it was probably not a problem to change a URL parameter

"We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code-or password-based barrier to access. See State v. Riley, 988 A.2d 1252, 1267 (N.J. Super. Ct.Law Div.2009). Although we need not resolve whether Auernheimer’s conduct involved such a breach, no evidence was advanced at trial that the account slurper ever breached any password gate or other code-based barrier. The account slurper simply accessed the publicly facing portion of the login screen and scraped information that AT&T unintentionally published."

https://law.justia.com/cases/federal/appellate-courts/ca3/13...

Exactly correct. Nonetheless, a prosecution was indeed brought, and the opinion you're citing is an appeal. Without the EFF's financial support, weev would not be a free man.

That's one way to go. Yolo on a prank.

There is a massive difference between scraping unintentionally published information on a public website and cloaking your account to subvert your employer revoking access to its systems and continuing to access them when you know you're not allowed to be.

> cloaking your account

This seems like a bit of strech for “cloaking”. (Like wearing vaguely similar colored t-shirt as employees do)

> continuing to access them when you know you're not allowed to

This part is rock solid.

What happens if you put on a police costume and go policing?

Intentionally deceovit about your identity, in order to obtain access to a something of value that you are forbidden to access, is a clear crime, as it should be.

Being deceptive about your identity during the commission of a crime is illegal?

If I dress up as a Best Buy employee and drag a television out of a loading dock and into the bed of a truck, that's definitely illegal, but I don't think it's any more illegal than if I did it in jeans and a T-shirt.

Impersonating a police officer is its own charge though, so while impersonating a best buy employee isn't going to get an extra charge applied, impersonating a cop, is.

I spent months passively waiting for a former employer to evict me from Slack. It was genuinely bizarre, almost a year later I still had full access to a ton of internal channels.

They are friends, but this was not them being friendly, it was just because slack account management integration with Google Office is a dumpster fire.

I've got one up on this. I kept my insurance from a past company for nearly 2 years after I got laid off. Would have rather they cancelled it, as it caused a massive headache around the time my son was born

Did you notify them and ask to have it cancelled?

Reminds me a little of sneaking into a Warcraft II LAN game of 2 of my brothers by calling myself “Computer” when they were playing a co-op game against computers.

What’s the story about cfaa and boogers? My google-fu is failing me and can’t find a reference on it.

Simple exaggeration.

This reminds me of a glorious day at my consulting company ca. 2016 when we discovered that we could change each other's names on Slack. At one point everyone was just named dad.

Love it but I will insist on grandad or I will set the girls (grand-daughters) on you ... and they are merciless 8)

There was a phase where folks were riffing on phonetic variants: dad, sad, brad, chad, glad.

I miss whimsy at work. Not in the code, never in the code, but at work absolutely. Nowadays either I'm older, or the environment is different, or people are less funny. Hard to tell.

This sounds a lot like when my kids realized anyone can edit Netflix/Disney+ profile names and pictures.

All the accounts are filled with the maximum number of ‘djehebdxineEbsuan’ profiles. And my son is asking why there’s a limit ;)

I've been playing this for a while now with our daughter. She wakes up in the morning and finds some absurdity written on my account,then she changes it and the cycle repeats on the following day:)

... is this still possible?

(my college frisbee team is on slack)

I can still set my own handle in $corp slack, but not anyone else's.

A lot of people advise ways of locking down name changes, but this doesn't really solve the problem. I'm sure there's someone out there whose first name is actually Jira.

I worked for $company where customer dashboards were set up on a wildcard - https://*.$company.com, e.g. https://foo.$company.com. Guess what happens when someone picks a dashboard slug that conflicts with an actual record, like `www` or `blog`? Their dashboard becomes completely inaccessible. Of course, the setting to change the prefix is also on https://$dashboard.$company.com, so the customer is unable to fix it themselves and requires support. Of course, support's tools don't expose the ability to change the $dashboard prefix directly...

Figuring out how to build the denylist isn't really trivial. Of course, there's pre-existing DNS entries. Then there's pre-existing $dashboard prefixes that already exist. Then there's dirty language, Unicode symbols, Punycode (i.e. xn-- prefixes)... then there's setting up redirects from the old prefix and reserving it so that nobody can claim it in the future...

I'm not surprised Slack has holes here, it's a fundamentally hard problem.

Limit usable characters, and just literally check the page doesn't resolve already before allowing the change. Customers will never be locked out and characters can't impersonate others.

If you want to allow some symbols you can either whitelist or check if usernames are an appropriate levenshtein distance away from core names (like say slackbot) and either ban such things or flag to a human "hey this could be an issue".

It's fundamentally hard to stop everything, but it's not hard to stop the biggest issues.

> just literally check the page doesn't resolve already before allowing the change

It's a wildcard DNS record, it always resolves, even if it's not saved in the system.

There's a general rule of thumb: when someone on HN tells you to "just" do something, they generally underestimate the amount of effort involved in doing it properly.

It’s not hard to check, I did this recently for a script. I just resolve “(25 generated random chars).example.com” and if “interesting-subdomain.example.com” resolves to the same, then I know that the interesting one is actually only resolving because of a wildcard. If it resolves differently I know it’s taken by a real record.

In this particular case, the wildcards all intentionally resolved to the same address, regardless of whether or not they were already taken. Business logic was handled by looking at the Host header.

My partners work has an employee named 'Admin'. IT struggles with what to do thee.

huh, real life Bobby Drop Tables, huh? Wonder what name would cause the most damage to flimsy tech while still sounding like a relatively normal name?

I have met a few Admins in my life and, needless to say, there's all sorts of things they have to work around to do normal things online. For example, set the first name to "Admi" and "N" as the middle name to be able to receive a package. And good luck looking them up on places like LinkedIn or Facebook that require but do not accept their actual name.

It's not exactly a common Muslim first name, but it's not unheard of.

I’ve worked with someone named True, who, when I went to go add her to some event or another, something along the way helpfully changed it to “TRUE.”

I also worked with a guy whose last name was Null. His email was null@ for a period of time.

Radiolab did an episode about people in this pickle. https://radiolab.org/podcast/null

he should have married an Indian and named a child Dev. :)

Zendesk for example puts their customer dashboards on a direct subdomain of their own main domain. They allow people to use their own domains as well. To use your own domain you have to make it a CNAME for the subdomain that they gave you. https://support.zendesk.com/hc/en-us/articles/4408838571930-...

I think it’s better to do like GitHub and Shopify and many others do. Have a separate domain at least that customer pages are made subdomains of.

GitHub uses GitHub.com as their own domain, and they use GitHub.io as the pages domain with subdomains for users.

Shopify uses Shopify.com for their own site and myshopify.com for customer subdomains.

The main advantages of using a separate domain for customers include:

- You don’t have as many pre-existing or future subdomains that you want for yourself. (You still need to filter so that people don’t use offensive words or misleading words etc.)

- You can have that domain added to the Public Suffix List, which avoids some potential problems you might otherwise run into https://publicsuffix.org/

Also if you set cookies in your app with the scope of your main domain with the hope that they are visible to all of the subdomains you provide for your customers, these cookies are also accessible by 3rd party services that use your subdomains.

So if you run acme.com and give our subdomain to your clients you could end up with client1.acme.com and client2.acme.com. You decide to store cookies on acme.com. The. You decide that you will use SupportCorp’s helpdesk software and host it on support.acme.com. If a logged in user goes to support.acme.com they will send their cookies to SupportCorp’s servers. This might include session ids and other highly sensitive info.

"Don't have colliding fundamentally different namespaces" is not really a hard problem to resolve in this case, though.

You're really going to make excuses for Slack here? 'o'/'о' is just about the easiest possible homograph attack (https://en.wikipedia.org/wiki/IDN_homograph_attack) that there is:

> When it was his time to leave, McKay swapped out his existing profile picture for one that resembled an angrier version of Slackbot’s actual icon. He also changed his name to “Slackbot.” You can’t just change your name on Slack to “Slackbot,” by the way, as the service will tell you that name’s already been taken. It does work if you use a special character that resembles one of the letters inside Slackbot, though, such as replacing “o” with the Unicode character “о.”

And in fact, this exact pair of English/Cyrillic was used in one of the first published homoglyph attacks: https://web.archive.org/web/20200102175251/http://www.cs.tec... back in 2001!

In 2022, Slack had a valuation of something like $20b and had been in operation for almost a decade. And their business is username-based software for people who need security ie. organizations/businesses.

Best place to hide is something that looks like a service account everyone is afraid to touch for fear of what will break if disabled. Well played!

Reminds me of popular malware and their process names.

On the other hand, an over-zealous IT guy at my job just deleted our Jira automation account (because he didn't know what it was there for and got sketched out by the name $CompanySecretary). Cue (a few days later) a large pile of pain as we tried to find and fix every workflow and ticket that formerly referred to that user before something really important broke.

Institutional knowledge and documentation is not free, but it has a cost!

Apparently the cost of reading the documentation, asking anybody, or just looking at the account's activity was too high.

Aah, he took down Chesterton's fence and found the reason of its existance!

(https://en.wiktionary.org/wiki/Chesterton%27s_fence)

More than once I have taken down a Chesterton's fence that I myself had originally put up

Sounds like a few good stories....

Chesterton's key more like.

Dang. Our scream test was just "disable if nobody could tell what it was for."

At my previous job, we had an entire system aptly named Pandora whose entire role was keeping track of which ssh keys were permitted to be found on servers. It had a bot that would crawl through every server, and if it found a key not in it's database, it nuked it. Every new person or automation key had to first be registered fomarlly, with an end date. A bit of a hassle but definitely necessary for the space the company was in.

That’s a good idea although I’d probably be paranoid enough to have a human do the deletions, out of fear of the failure mode where it deletes all the keys everywhere and nobody can log into anything.

There is a future where they're locked out of the servers.

Why not use ssh certificates at that point?

I assume op’s system was to allow A to ssh to B, but not to C. (With lot of different As and Cs)

Where “but not to C” is the reason for existence.

How certificates simplify that part?

(Never used them, but my understanding they are usefull when you want x1,x2,… ssh’ing into y1,y2,…; two uniform sets; if set sizes approach 1, then cert usefullness aproach zero)

I would have been a good use case, but unfortunately no, if your key was registered it would be left alone on all servers (though you had to place it, and access control was done by way of bastions).

Ssh certs weren't used because the system was put in place before they became commonplace.

> Of course, not every company will fall for this trick

The company can have the last laugh: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

This was my first thought on the "silly prank" line.

well, Slack is the one having the last laugh, since they get their hands on a lot of "sensitive business data".

That’s why he waited two years to say he did it which just so happens to be the CFAA statute of limitations.

IANAL, but as far as I can tell that's only for civil actions (and it runs from the date that the damages are discovered, not necessarily the time of the offense).

For criminal charges, I believe you'd use the default 5 year statute of limitations for noncapitcal federal crimes (18 U.S.C. § 3282)

But the company can't force the state to pursue criminal action whereas it can sue in a civil court any time it wants.

Replacing ascii with similar-looking unicode characters is an old trick. There's a bunch of these characters out there. You can use it in the code to prank your colleague developers - April 1st is nearing!

I even made a vim plugin that highlights these "dangerous" characters: https://github.com/vim-utils/vim-troll-stopper

I've never been pranked with unicode characters, but I've had a situation at work where a consultant from Japan unintentionally used some "japanese space" characters in a translation file, and that broke our app. Since I have my vim plugin running all the time it didn't take me a lot to see what's going on.

The accidental crap can go a long way. I recall someone using a superscript ‘O’ as a degrees symbol in a medical report. This then got converted to a non—superscript character and rather changed the meaning. Extra unhelpful was that they wrote the word ‘degrees’ after the attempt at the symbol too.

There's also the Spanish superscript a and o symbols (used for ordinals) that can be confused for this.

“patient’s temperature was approaching 100O degrees”

Very nice error :D

It was a measurement of angle for an ortho surgeon. However as you point out, wrong by a x10 multiplier has the sanity checks kicking in.

Lots of apps have helpfully started turning two dashes (—-) into some sort of Unicode long dash that is more aesthetically pleasing, while also breaking command line tools.

Looks like that happened to you in your comment.

The em dash doesn’t exist to be aesthetically pleasing, it has a meaning in writing.

https://en.wikipedia.org/wiki/Dash#Em_dash

What you’re seeing is the result of software being more typographically conscious and replacing the incorrect characters we got used to typing in our keyboards with the correct ones. Same reason why " is replaced with “ and ”.

But you’re right that is annoying in a programming environment.

The em dash glyph is an aesthetically version of the em dash digraph.

Heh, I kinda don't like these typing replacements (also, "smart" quotes).

If I type `--` it's because I want `--` (or even `-------` but some software† insists on changing that to a sequence of en-dash), especially I can type them easily on macOS:

- minus key: minus char -

- Option+minus: en dash –

- Option+Shift+minus: em dash —

Similarly, opening and closing single and double quotes are on bracket keys.

† yes there are OS-level settings for that (at least on macOS) but other software do it in addition to the SO, and you can't disable it plus it plays badly with undo.

Indeed “smart” quotes are a nuisance and it’s a small tragedy that curved quotes go typically unused. I gave myself a dedicated `“` key to make it the default in everyday use.

         “ → “
   Shift+“ → ”
  Option+“ → "

That's one of the reasons I abandoned Google Docs for keeping notes on administering my home computer lab. I use Linux so much of what I did involved typing commands in a terminal window. I would copy the text into document and later copy back to a terminal. It often didn't work due to the way Google transmogrified the text in ways not obvious to the eye.

I now use Markdown (and store notes on a private server) so commands can readily be replayed.

I’m sad and annoyed that Google Docs somehow manages to disable the Mac text substitutions feature (which has custom entries I want to use for frequent, difficult to type things at work) when you’re typing into a document.

Known as an 'em dash'.

Oh, I remember this one: https://news.ycombinator.com/item?id=10438363

The fact slack doesn't allow you to lock down name changes must be such a gaping security hole for big companies.

Change your name to the CEO, and profile image to match. Odds of people noticing the difference are extremely small until it's too late.

Changing to slackbot seems like small fry!

Bigger companies use SAML or other federation that makes it impossible to login without a corporate authentication.

Presumably with SAML/SSO you can still change your slack display name and profile picture?

The data only comes during the sign-in flow. If you want to change it dynamically outside of that, it's typically done via SCIM.

For anyone curious, we wrote a blog post all about this. https://workos.com/blog/the-developers-guide-to-directory-sy...

(I work at WorkOS.)

Not slack, we use teams at work and I have very limited ability to do anything, can't change my name and we have profile pics disabled.

Negative, that comes from Azure AD, or Cognito, or Keycloak, or whatever.

The users name, email, phone, location, avatar pic, department, etc all comes over in the SAML payload.

This is not correct in general. My job uses SSO and I can change my Slack name.

In our case we can not change the Slack display name, but we can change the @ handle. Pretty good compromise IMO.

It is correct, your company just messed up somewhere...

Eh, that’s a matter of opinion on policy. Technically (at least with Slack) it is possible to require SSO for users and control over which profile attributes they can change themselves, including display name. Although they may get clobbered at login as part of reading the SAML doc.

Just because you can, doesn’t mean you should - and in fact is a security hole if you do. We don’t allow security holes where I work so all attributes are copied over and nothing can be changed. No hidden employees. No unknown guests.

I’m pretty sure this is one reason why my firm recently removed people’s ability to change their name on our videoconferencing system.

Uh, it does allow that in the organization settings. Also the SAML/SSO comment below as well. If you can change names, IT admins are either non-existent or just being lazy.

My company allows name changes. It’s fun.

That means they're not using SAML/SSO which sounds absolutely crazy to me, unless you only have like a dozen users. The implication is that your IT team doesn't take security seriously. Not because you can change names, but because they aren't implementing identity policies.

Eh, a lot of startups even in the 100-200 employee range are still manually inviting Slack members. It's not really the end of the world as long as you're on top of things and have good communication between HR, IT, etc. Spreadsheets solve a lot of problems (in this case, having a good template offboarding/onboarding spreadsheet in Google drive that everyone can collaborate on to make sure stuff gets done quickly).

you can very much allow people to change display names while using saml/sso. My work setup allows this. We can change photo and description as well but nothing else.

Same here.

Or it’s just a more relaxed atmosphere? Not everything needs to be corporate no-fun serious business 24/7.

We’re on an enterprise Slack instance with >1000 members and SSO/SAML. Changing names and photos allows us to be fun and everyone trusts everyone else to not spoil the party.

Mine does too, to allow people to copy their pronouns from the boring “pronouns” field into the most conspicuous possible place (inside their actual name), for maximum virtue signaling.

Name changes can be locked; I'm in an Enterprise Grid org and our display names/usernames are synced against our employee profile. We're also required to SSO every single time we launch the desktop app so once you're terminated you're definitely not getting back in (they deactivate accounts very quickly too, so mobile is likely not a major concern).

Basically the only thing you can change without filing a ticket is your picture and some mostly-irrelevant freetext fields.

How does an enterprise chat tool not have the ability to invalidate all session tokens and all connected clients to disconnect?

Perverse incentives. People are paying them already without that feature, so why bother? They are incentivized to do and provide as little as possible.

https://api.slack.com/methods/admin.users.session.invalidate ?

At the same time the ability to change name is sich a godsend.

We're currently abusing it to have presence info straight in the display name (e.g. mike-2/12~16vac.) to let anyone contacting us what to expect for response times, or wether to ask for a task if it's a few days before a planned vacation.

Nobody seemed to look at the actual status property and it beats going to the calendars to check.

> mike-2/12~16vac

Looks like mike-2 is a robot powered by a doorbell transformer.

He'd probably be fine with that perception.

In MS Teams, your name is from AD and you almost certainly don't have permission to change that. Also, bots have hexagonal avatar frames while humans have circular ones. I'm not sure how many people notice, though.

This is a common issue with Discord as well, and is especially prevalent in the crypto space groups.

the screenshots of people replying to him who clearly know he's not slackbot, including calling him Tom, kind of contradict the headline here. he was clearly not "undetected".

we've got some former staff in our slack still. they check in and say hi every now and then, it's nice. if one of them started pretending to be a snarky slackbot one day, we'd probably have a laugh about it too.

“Undetected by management” is the meaning here, as the article makes clear. His friends knew he was there and were having a laugh.

Same here, slack is not our main communications channel but it was used for some external consultants. And sure enough people who had quit were never kicked out so they just continued planning lunches together.

One place I worked was slow to deactivate slack accounts, so when I left I made a private channel #daves_cave and invited friends my friends to it. I would leave a short story or pithy saying now and then; it was fun until management got wise and deactivated me.

I’ve got a private, paid Slack team ($10 a month?) and you can invite people from other paid Slack teams to chat in rooms on it. Nice thing about this is it’s “by design”, so less likely to get shut down, and also unlikely to fall foul of computer misuse laws.

I would have thought the answer to this at a corporation was Single Sign On?

I don't run IT these days, but when I did...we used to mark them as inactive in Azure Active Directory. They could no longer log in to any Office 365 service, Outlook Teams or whatever, and none of the third party services we had using MS SSO. Wouldn't you join Slack to it too?

If you have a competent/adequately resourced IT department, sure, of course. It’s also possible that a different department set up Slack without consulting IT.

Normally an organization would have this protected via SSO & thus the deactivation of the employee's account on Gizmodo's systems would have kicked them off of the company's slack. Just another reason why it's valuable to avoid non-SSO 3p cloud apps so that "who's an active user" has a single source of truth.

Slack has supported SSO via a variety of providers for quite a long time now. If G/O Media didn't bother setting up the integration, that's on them.

One thing that SSO isn't great at is deactivating live sessions. Often, you either solve this with short session times (annoying to users), making a note in the de-provisioning steps document (not foolproof), or using a third party vendor (costly).

Sure it is, this problem has been solved for a long time: SCIM. Any modern idp should support SCIM and if the app doesn’t I’d question using it at all.

SCIM adoption isn't near where it needs to be. I guess yeah, this is the correct answer. We live in a world where SSO is considered an enterprise feature, I hope one day that it's considered default.

Shameless plug for my startup (hope that's ok!)

If you're building an app and need to add SCIM, check out WorkOS. My email is in my profile to chat.

More info -> https://workos.com/directory-sync

$125 per connection / month and then you wonder why companies don't offer SSO/SCIM by default in their free/cheap plans.

(I work for a competitor in the same space as grinich.)

Charging for scim is a convenient way to segment customers, the same way SLAs are. For companies that care deeply about controlling user access (or are forced to by law or regulator), that isn't much money.

Features like this subsidize the free/cheap version, which you can then offer to let folks learn about and love your software, and use. After all, you can replace scim with careful manual processes until you get to a certain size.

It's similar to the sso tax: https://sso.tax/

I'm not aware of a scim.tax site, but maybe there should be one? :)

> Charging for scim is a convenient way to segment customers

It’s also a convenient way to keep charging non-SCIM customers for unused licenses when they inevitably forget to manually nuke accounts belonging to leavers.

Agreed. And most apps have it locked to the most expensive level.

Slack, to their credit, offers this at the business+ tier: https://api.slack.com/admins/scim

Me: "We should use SCIM, our IDP and our App both support it" PM: "No that's too complicated, we'll roll our own provisioning and never worry about de-provisioning because they won't be able to log in due to SAML anyway!"

I can't tell you how many times I've had that conversation... but I'd need at least both hands and a foot.

This is why most SSO forces you to sign in again every day. So frustrating!

>...using a third party vendor (costly).

I promise we're not _that_ costly.

But yes, having built a slackbot/Slack OAuth myself and dealing with it at my $CURRENT_CO (stytch.com), Slack is a service you have to be very careful with. They offer a very powerful API and permissioning model, but it can be nerve wracking.

Admins not killing old accounts is a security hole that I'd say 50% of companies I worked with had/have.

I can still log into the google workspace, slack, check out confidential documents on drive (not because of transparency, but because they dont know how to share properly). I can check out what is happening in nearly any of their projects by peeking at the channel and if I want to know more, I just take a look at the documents, including their pitches. If I poked for a bit, I could probably also find API keys and DB credentials.

These people work for banks, insurances, national televisions, hotels, airlines and more.

If I was a bad actor, it would be incredibly easy to cause damage to both them and the clients or do insider trading based on the upcoming project data.

But it seems like half of these places just don't care about security - even when contacted, admins/responsible people just flat out ignored it.

And then we wonder how breaches happen.

One manager asked for my personal email so they could add me to all the relevant google groups and whatnot so day 1 I could hit the ground running and wouldn’t need to wait for my company email to be provisioned. Needless to say, 8 years and 2 jobs later it’s still in there.

The distinction between the registered username and display name in discord and elsewhere is a great innovation..

this is a reporter "reporting" on another reporter's self-reporting (on twitter) of what he did from when he quit/was fired/laid off (the "article" doesn't even say) from his job as a reporter. "reporting" is in quotes here because it's the thinnest possible veneer atop the original tweet. what possible value does this article have over the original tweet, aside from adding an additional, unnecessary needed layer of "reporting" for this non-story? it's difficult to see this as anything but a "journalism" circlejerk (redundant).

The author gave some context for readers not familiar with slack. And interviewed another former employee (albeit with minimal effort) to add another validation point.

it was a joke Verge

Perhaps sadly, it's the kind of joke you can get in mega-trouble for these days (see other comments about CFAA and flicking boogers on the carpet).

'Nothing signed "THE MGT." would ever be challenged; the Midget could always pass himself off as the Management.'

    NO SMOKING.  NO SPITTING.
    THE MGT.

catch-22

Reply on news.ycombinator.com