The M.T.A. Is Breached by Hackers as Cyberattacks Surge
nytimes.com
nytimes.com
This one happened over a month ago, its obvious this is a trending headline likely not organically, so make sure to separate the dates before thinking we are under a coordinated attack all at once right now
FTFY
People are far too trusting of these claims of where these attacks originated. Very few people in the world, including journalists, know how IP networks work.
Sure, but as a result that statement could also be full or complete bullshit and anyone not related would be unable to distinguish the difference. The times you've made that statement may have had substantial evidence behind them, but (presumably) you know just as much as me about what's being used to make this statement.
> One past example of a "hacking group believed to have links to the Chinese government" was someone they suspected as a hacker taking an rideshare to a large office building that rented space to a government organization.
Did they say it was the only evidence they had to tie the incident to China linked hackers, or was that one thing they were willing to share?
I have proof that they have not printed any evidence for their statement in this article. It's your decision whether you believe they should be trusted without evidence, I personally don't think so.
>Did they say it was the only evidence they had to tie the incident to China linked hackers, or was that one thing they were willing to share?
They also found a supposed job listing with tenuous links as well, I linked it elsewhere. I have no clue if they have better evidence.
Well, no, because obviously the Chinese government's teams don't want to get tracked and attributed, and obviously the people trying to catch them don't want to reveal the techniques they use to track and attribute their alleged activity.
Of course, their saying "just take my word for it" doesn't mean you should trust them or their findings, but it doesn't mean you should necessarily distrust them just because they don't reveal their methods.
>One past example of a "hacking group believed to have links to the Chinese government" was someone they suspected as a hacker taking an rideshare to a large office building that rented space to a government organization.
What's the source on this one? Sounds like an interesting story.
Most of these methods are already public knowledge, usually advanced versions of "don't reuse email addresses."
>Of course, their saying "just take my word for it" doesn't mean you should trust them or their findings, but it doesn't mean you should necessarily distrust them just because they don't reveal their methods.
I should assume their statement is false until evidence is provided. That's a fairly universal concept.
>What's the source on this one? Sounds like an interesting story.
Yes, a decent chunk of it comes down to that general idea, but in practice you're dealing with a ton of permutations of that idea. You don't want the adversary to know the specific data types or values you were pivoting off of and correlating against.
So it's not about the general methodology but the specific applications and indicators. Plus there are many other attribution methods beyond just that.
>I should assume their statement is false until evidence is provided. That's a fairly universal concept.
I don't think that's how that works. You just have no evidence or reason to believe their statement is true. That's different from assuming their statement is false. "Failing to reject the null hypothesis" isn't the same thing as "confirming the null hypothesis".
>https://www.crowdstrike.com/blog/two-birds-one-stone-panda/
>One past example of a "hacking group believed to have links to the Chinese government" was someone they suspected as a hacker taking an rideshare to a large office building that rented space to a government organization.
That seems like a major misrepresentation. Here're the two posts that that CrowdStrike post is based on:
https://intrusiontruth.wordpress.com/2018/08/02/who-is-mr-ga...
https://intrusiontruth.wordpress.com/2018/08/15/apt10-was-ma...
I'm not going to summarize everything IntrusionTruth and CrowdStrike reported, but it definitely wasn't just "someone they suspected as a hacker taking a rideshare to a large office building that rented space to a government organization". It was someone whose name and other personal information they already had likely associated with APT10 - through several different means - allegedly also appearing on multiple Uber ride receipts with a destination of the regional headquarters of the Ministry of State Security, which is in the city he appears to work and live in. (Among several other indicators pointing to his likely involvement, including potential associations between local companies he was affiliated with and the Ministry of State Security Tianjin Bureau + APT campaigns.)
What are you basing this "rented space to a government organization" on? Could you imagine the NSA putting a regional headquarters in some rented office space, for example?
In my opinion, the totality of the combined analyses makes a pretty good case that Gao was part of APT10, and a moderate case that he may have worked for or with the Ministry of State Security Tianjin Bureau. Combined with other reports published by both parties, the case for associations between APT10 and MSS Tianjin Bureau is additionally strengthened.
Then a few months later, the Justice Department announced this indictment: https://www.justice.gov/opa/pr/two-chinese-hackers-associate...
>Two Chinese Hackers Associated With the Ministry of State Security Charged with Global Computer Intrusion Campaigns Targeting Intellectual Property and Confidential Business Information
>Defendants Were Members of the APT 10 Hacking Group Who Acted in Association with the Tianjin State Security Bureau and Engaged in Global Computer Intrusions for More Than a Decade, Continuing into 2018, Including Thefts from Managed Service Providers and More Than 45 Technology Companies
I have no evidence to believe the statement "meowface is a Chinese hacker" is true, but I shouldn't assume it is false? Accusations need evidence. This isn't science, it's criminal justice.
As for the rest, all of the evidence they provided was pretty unsubstantiated in my opinion, but I had combined "an uber receipt they can't verify saying an alleged hacker went to an MSS building" and "a supposed recruiting message gave the same address as CNITSEC." I had not read the details in several years, that was my mistake. That was the grand total of the evidence provided though, and the indictment does not provide anymore.
Yes, you shouldn't assume it's false. People should simultaneously assume I'm not guilty of any accusation until conclusive evidence is produced, and also not prima facie assume any such claim is false. Purely as a standalone statement, you can't assume it's either true or false. You shouldn't assume it to be true, but that doesn't mean you should assume it to be false.
To use an extreme example, let's say someone you know tells you they were assaulted by some individual, and at that moment you have no other information besides that. Should your immediate reaction be to assume the statement is false?
This is why one should simultaneously give both accusers and accused the benefit of the doubt. You should simultaneously grant victims the presumption of not lying and grant the alleged perpetrators the presumption of non-guilt. A victim makes an accusation, and the accused says they didn't do it, and you have no other information besides that. Do you simultaneously assume both statements from both people are false? No. You assume both are indeterminate at the present time, given you have no other information.
The burden of proof is always on the accuser, but there's still a difference between "not assuming something to be true" and "assuming something to be false". This is also why courts never find someone innocent; they just find you to be guilty or not guilty. Not guilty means the prosecutor/plaintiff failed to conclusively demonstrate guilt. Innocence would be a positive claim rather than a mere failure to accept a claim.
There's an exception if a claim is particularly extraordinary. If you have an extremely low prior, it's fine to assume the claim is false. "This person talking about security stuff online is a Chinese hacker" is a big claim, but not an extraordinary claim like "telekinesis is real".
Also, in this case with the MTA, it's not (yet) criminal justice. It's some private firms saying they believe they have evidence that indicates the perpetrators are likely affiliated with the Chinese government. If they were standing trial instead of just having some company making some claims about them, of course the standard of evidence would be much, much higher.
No, they have provided evidence, their statement they were assaulted by x. Whether that evidence is reliable is a different matter. Not making your mind up but proceeding as if they are telling the truth is a logical action.
A comparable event would be a stranger coming to you, saying person y was assaulted, and there is evidence x was responsible. You have no way of knowing how strong the evidence is, or if it even exists. And their motive for telling you this is unclear. The burden is on them to provide some kind of evidence before that statement should even be considered undetermined.
In this case, I don't doubt the ransomware attack happened, and I assume they have some idea of who is responsible as ransomware requires communication with the hackers. The claim that they have links to the Chinese government is extraordinary enough that evidence is required.
I agree. I just think this is a language debate. "Assuming [X] is false" is just different from "not assuming [X]" / "not assuming [X] is true" / "not believing [X]". It's fine to not believe it without evidence (I wouldn't, either), but to assume it's false is to make a positive statement rather than a rejection of another positive statement.
People are funny.
edit: And what's with the "hacks" scare quotes? We know exactly how the attack happened, step by step... in what way was it not a very straightforward hack?
This hack wasnt special in this respect though. Hack attribution is usually based on pathetically thin evidence.
For a high profile hack attack it really isn't feasible politically to say that you aren't sure who the attacker is, though. It makes you look weak and powerless.
Not being sure who the enemy is or being utterly sure and wrong for long periods of time is a weird feature of cyberwarfare that I'm not sure any country is capable of adapting to yet.
Once again, we have:
* Shared infrastructure
* Shared TTPs
* Clues like language
* No evidence to the contrary
And that's just what's public. I assure you that quite a lot stays between people. I know many people in the field who can't share public details about breaches due to pending legal issues - Dropboxers couldn't talk about aspects of the 2012 breach until just this last year.
Or, you could just hit us with the oft repeated 2003 weapons of mass destruction talking point of "the evidence is there it's probably just classified" if you want to make me reminiscent for the good old days.
I'm not really interested in doing research for you.
I asked in case I missed or misinterpreted some specific piece of evidence that was particularly compelling.
a) would help the ransomware & hacking crisis, and, b) is practically enforcable at scale?
it comes down to training and cost cutting. If the penalty for failing miserably is 0 you won’t see any change. I would hold the companies responsible for things like this liable to the point they would be put out of business after an event like this. If the cost of being sloppy is that you no longer have a business people will start paying attention really quickly.
99% of these standards are completely useless and exist only to reduce legal liability. The other 1% are only incidentally slightly useful.
You will never ever create a secure company by following some stupid checklist, unless the checklist is so extreme as to be useless to most orgs. “Step 1: only run OpenBSD…”
you cannot just say: oh this is so complicated that we cannot possibly have a system for it and we have to rely on the people to do the “right thing”
Not one of those but since they are [apparently] inadequate anyway...
I read an analogy that pinning this on "cyber security" is like accusing a mugging victim of having a lack of personal security guards. That's just not how civil society works.
Minimum safety standards: laws and ability to enforce them.
This is a short-term win for the bad actors. Just wait until the next "great firewall." Well gain safety, but we'll lose access to those low cost eastern European dev talent. That's more likely than every single US business being forced to hire private security just to operate.
This is a cope and also irrelevant.
Civil society works a certain way because of its social interaction dynamics. The internet works much differently (namely, retribution is much harder, which rules out most tit-for-tat transgression management strategies, and the scale is much larger than is possible with human interaction).
Civil society does punish businesses when bad things happen due to negligence. Especially when the result of the negligence negatively effects someone else.
The parent comment:
> Minimum safety standards: laws and ability to enforce them.
So it's not just the law but also the potential for repercussions, of which there are currently zero.
It’s also possible to eliminate these attacks entirely, but it probably requires corporate tech infra that looks totally different from what most orgs now. If it were my job to set up some sort of hardened corporate setup, my first step would probably be to restrict most employees to iPads. There’s not really any reason a shift manager at a meat packing plant or whatever needs or benefits from a Windows box.
The Pulse VPN has a history of security issues (see e.g. https://arstechnica.com/information-technology/2020/01/unpat...) - so much so that the second and third Google autocomplete results are "pulse vpn vulnerability" and "pulse vpn hack". One practically enforceable at scale rule is to pay attention to whether your vendors have a bad security track record and also be meaningfully prepared to switch (switching VPNs is no fun, but it's doable).
Another one is to ask your vendors what they're doing about their security track record and whether they are taking systematic measures to make zero days less frequent and not just fixing individual bugs. "Stop using memory-unsafe languages" is one of my favorite answers to that, but there are a lot of others: "use sanitizers," "test your code with fuzzers," "use open-source components for the privileged portions," "get frequent third-party audits," etc. are all potential answers too. Some work better than others; any of them is better than not having an answer.
> “The M.T.A.’s existing multilayered security systems worked as designed, preventing spread of the attack,” said Rafail Portnoy, the M.T.A.’s chief technology officer. [...] there was “no employee or customer information breached, no data loss and no changes to our vital systems.”
The other really good answer here is to not have an all-or-nothing architecture for your network, and it sounds like the MTA is doing that already. Don't wire the train-switching network to the email-checking network just because you can. This is much harder to practically enforce at scale in an environment that wasn't designed for it, but it's a great rule to enforce in new systems. Any time you build something that would be worse to get taken over by hackers/ransomware/whatever than the rest of your company's computerized systems, build it separately and make limited interfaces for people to interact with it.
The move to put everything in the cloud really ought to make this easier: you can make a new cloud account for new systems and use bastion hosts etc. for developer access to them, instead of throwing it in your existing account.
I've worked a bunch of places that have passed various audits and certifications, you know, PCI, SOC, and unfortunately the audits of infrastructure isn't as deep as the average Joe would expect. They place heavier weight on processes over technical safeguards. It's like what they say about the CISSP exam, a mile wide and an inch deep.
Hold product managers and non-tech execs accountable for security breaches. Stop treating IT/ops like the suckers. Since that's never going to happen, buy some Monero to increase your bargaining leverage on the ransom price.
The bar is not very high, it's bike theft economics. Your stuff only needs to be less vulnerable than the next guys, unless you are a political target. If you are a political target, please forget my name.
Sadly I have to report what you state is possible, but not plausible in today's modern heterogenous enterprise.
If I had a static environment with no new software or business processes, then NO PROBLEM. I can lock it down in every kinda way and it stays locked down to a known baseline.
Add to that new biz processes and now I have interconnection internally and externally which make detection and prevention difficult. Things are much more difficult now.
Add to that new software, ever changing dev env, OS updates, firmware updates, software version updates, dev env dependency updates, now you're talking near impossible to keep up.
And that's the state we're in today. There are some generic mostly effective controls that if implemented correctly can stop most advanced attackers (the so called "20 security controls") https://www.yumpu.com/en/document/read/6582321/20-critical-s...
But even in spite of that, any major nation state had an arsenal of "capabilities" that allow them to dominate most cyber warfare area of operations in the civilian sector. US can do it, UK, Israel, China, Russia, probably even India and others!
Against nation states, there is no stopping nation states in the civ sector, despite what every F500 company's CSO wants you to believe.....sad but true.
These ransomware attacks are so devastating in no small part due to decisions Microsoft made many years ago. Combining authentication, remote administration, file sharing, printing, event monitoring, security policy updates, and the kitchen sink into Windows Networking. An attacker compromises a single Windows machine and has leeway to attack critical servers across the network. If real segmentation of services were reasonably possible in a Windows environment a single credential couldn't be used to hop between systems and encrypt file services everywhere. Not to say some segmentation isn't possible in these environments but the skills and hours needed to accomplish it are far beyond what most companies have available.
And that doesn't even begin to cover the Exchange/Outlook dominance and poor security choices that lead to the higher rate of success for phishing attacks.
This is true for almost all types of malware these days, especially when it comes to privilege separation/escalation attacks. All of your observations about segmentation/AD are true here.
As for ransomware specifically, a lot can be done to stop most ransomware, especially small-time stuff. Unlike most malware ransomware is intentionally loud, and performs the same generic actions of enumerating and encrypting files, which makes detecting and stopping most samples with heuristics much more effective than a lot of people would admit: https://www.youtube.com/watch?v=3pH13DxClag
A lot has happened with ransomware in the past five years, but a lot really hasn't - this stuff still works, and would have an effect against the big RaaS strains that people are talking about today.
Realistically, the only way for an organization to actually be secure is if it's part of the culture from the start.
For a long time, people like insurance companies had an "enforceable standard" for 60/90 day password rotation. And in every single business I looked at, they "had a password rotation policy", but then three key executives didn't like it so "do not expire password" got ticked on their accounts as some "accepted exemption". This sort of thing always passed audits, and marketing always wrote information about how the business had a strict password expiry policy. And those executives were the most likely to be compromised.
I think if you go too far down a "minimum standard" path, that's the sort of thing you're going to see.
There's obviously way more to it than that, but a huge problem today is that once an attacker gets into a network they can hop around as they please due to implicit trust. Removing that implicit trust and checkpointing access via u2f are huge barriers.
It's also not super hard imo to gradually move to.
Isn't this because the systems that control train cars & rider safety on the MTA are all manual/electromechanical, with some dating back to the LaGuardia administration? Hard to hack those without being local to the tracks, and handy with a soldering gun....
That's quite the choice of adjective given the month.