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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Perverse incentives. People are paying them already without that feature, so why bother? They are incentivized to do and provide as little as possible.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
(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.
> 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.
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.
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.
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.
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.