from Hacker News

Segment Security Incident

by sandis on 9/5/19, 2:18 PM with 58 comments

  • by erichurkman on 9/5/19, 4:41 PM

    > For a small subset of customers (13), the unauthorized party was able to gain read-only access to their workspaces and click around in their accounts for up to a few minutes. These customers have been notified.

    That implies that Segment employees, or a subset, have unfettered access to view their customers' accounts? That it didn't require positive customer assent to gain access?

    I like Box's model for this: https://community.box.com/t5/Working-with-Box-Support/Box-Pr...

  • by zaroth on 9/5/19, 3:49 PM

    In all the SaaS type applications I’ve ever developed, the privileged “Admin Panel” functionality is always on a private network accessible only via VPN access, which is authenticated via a password + private key. Then the Admin Panel itself has its own separate login, which is username + password.

    Ideally the private key for the VPN is a hardware token, but I will admit in most cases it’s simply a file on the drive.

    The Admin Panel has zero third party JavaScript nor client-side analytics.

    I’m not sure this buys quite as much security as it might appear, because there’s probably any number of ways to piggyback on a valid session.

    For example, there was a bug bounty Tesla paid out when a researcher was able to establish XSS by mangling their car name, which was read via the API and showed up in an internal dashboard as unescaped HTML.

    So I think the biggest attack surface for Admin Panels remains a hostile client seeding XSS into unescaped fields, and CSP helps a great deal with this, but at the very least I don’t see any reason why these panels should be on a public URL.

    You can say, well, they should have MFA on the panel, but I can’t shake the feeling that these simple measures avoid a huge number of attackers looking for low-hanging fruit.

    It’s like putting SSH on a non-standard port. It’s theoretically meaningless but practically it’s a huge improvement, if only because it helps attack signals stand out against the script kiddie noise.

  • by nrmitchi on 9/5/19, 3:30 PM

    Between this and CircleCI, this sounds like a targeted credential-stuffing attack against accounts on Segment. If this is the case, it sounds like the only two cases that have been detected are Segment (detected on August 31st through unknown means), and CircleCI (detected on August 31st through an automated email).

    Has the risk of of other Segment accounts having been compromised through the same channel (but have yet to be detected) been investigated?

  • by teamspirit on 9/5/19, 3:41 PM

    > Removed privileged access controls internally, adding accounts on an as-needed basis

    I believe this is critical. Access controls really should be set as needed, per user, and fine grain. While it can be time consuming and may not even make sense at the beginning of a project, doing everything this way from the start should help to keep an organization better secured in the long run.

  • by eranation on 9/5/19, 4:26 PM

    "Enforced mandatory Multi-Factor Authentication (MFA) for all employees when accessing Segment-owned workspaces and performing administrative actions in the Segment app."

    This should always be step #1, don't wait for an incident.

  • by superzadeh on 9/5/19, 2:32 PM

    It is a bit strange, they mention that write keys have been accessed, but they don't seem to have invalidated them, or even recommend to update them?

      Information about how Segment customers interact with different aspects of our product, 
  *including customer write keys for Segment*, integration names, workspace names, 
  and how customers interact with our user interface.

  • by sunaden on 9/5/19, 2:34 PM

    I'm just awaiting the conspiracy theories including both CircleCI and Segment

  • by umvi on 9/5/19, 3:15 PM

    > we took immediate action, disabling and deleting the account that was compromised

    Since this was a privileged account, how can they be sure the attacker didn't use said account to setup more ways to get back in? That's the first thing Kevin Mitnick always did when he pwned a box: setup alternative routes to get in, in case his original door got closed.

  • by dmix on 9/5/19, 3:21 PM

    > This data is used by our product, marketing, and customer success teams

    It always seems to be the marketing analytics data that's wide open for 'hackers'.

    You could spend all day building a secure DB and application architecture then have the marketing team upload analytics for everything onto some random insecure service.

    Maybe the marketing/data teams need to get some security lessons as part of their training the way programmers learn?

  • by Nextgrid on 9/5/19, 3:25 PM

    This is why I’m against third-party analytics in any app/service. Someone compromising the analytics provider can get a lot of data from app end-users even across different apps that use the same analytics service.

  • by zer0faith on 9/5/19, 3:12 PM

    This is why you NEVER expose elevated access to the open internet.

    Why all the down votes... this is a legitimate security issue.

  • by wildtomato on 9/5/19, 2:41 PM

    Looks like the whole site is down. Anyone save a copy?

  • by mindfulplay on 9/5/19, 3:24 PM

    Seeing way too many "incidents" these days ....

    I would like at least one company to post an "incident" reveal in a more honest way:

    " Due to our carelessness and relatively insecure practices, we had improperly disclosed user accounts to a moderately savvy hacker. We realize this is our fault.

    If you'd like to help and given that we have your attention now, it would be valuable if you can help pentest our servers: the attacker used a simple SQL attack based on an unpatched server via CVE-3245. Are we missing anything else? Please let us know.

    Thank you."