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."
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.
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.
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.
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
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.
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:)
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.
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.
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.
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.
> 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 “о.”
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.
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.
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.
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.
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)
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Readit News
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.
"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...
Deleted Comment
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 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.
(my college frisbee team is on slack)
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.
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/
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.
It's not exactly a common Muslim first name, but it's not unheard of.
I also worked with a guy whose last name was Null. His email was null@ for a period of time.
> 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.
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.
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.
(https://en.wiktionary.org/wiki/Chesterton%27s_fence)
Deleted Comment
The company can have the last laugh: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
For criminal charges, I believe you'd use the default 5 year statute of limitations for noncapitcal federal crimes (18 U.S.C. § 3282)
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 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.
I now use Markdown (and store notes on a private server) so commands can readily be replayed.
Very nice error :D
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!
Basically the only thing you can change without filing a ticket is your picture and some mostly-irrelevant freetext fields.
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.
Looks like mike-2 is a robot powered by a doorbell transformer.
Deleted Comment
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.