Re: Teams is fine
"Tha's all I got for ye. Go away now."
137 publicly visible posts • joined 7 Jul 2020
I have always maintained that at the individual level, the barrier between APT "Bears" and financially motivated "Spiders" is far more porous than many give credit for.
So if you are not locked up in a warm hut in Siberia with all the hardware and bandwidth you can eat (as opposed to being thrown into some brutal tuberculosis-raddled hell-hole) then there is nothing to stop you from engaging in some "private enterprise" in whatever free time you are granted. And if you are in the game, you know where the commercial players are advertising and that they pay well.
Naturally we see tactics and methods transferred between the two groups.
No, the resolution of the conflict between privacy and employer interest is well established. The automatics do the checking for you, and if they say there is something wrong then you have due cause to go checking for yourself. If you can see that there is definitely something bad, that gets referred to management / HR.
I'm on my fifth proxy technology and have never been asked to exempt any tier of management from the governance applied to other staff. Some might have more access rights, but the logging is the same. On average, we spend more time worrying about senior management and sysadmins because there is scope for worse trouble if they are breached or go rogue.
Is it not a very strange and inexplicable coincidence that a waterspout should turn up just as there were sinister plots afoot to sink the boat ?
I'm assuming that we have incontrovertible evidence that there was a waterspout, and that beyond a little cloud seeding weather control remains firmly in the field of science fiction.
ITYM https://www.theregister.com/2015/02/19/superfish_lenovo_spyware/
That was for teh adz. Lenovo customers worried about the PLA one day deciding to weaponize their interest in Lenovo should consider whether they really want Lenovo Vantage installing updates direct from Lenovo when and how it pleases.
And yes, that bloatware finds its way into commercial builds too.
It prevents any number of Onanists from registering it as a spurious public top-level domain with a compliant ICANN in order to extort money from those who already use it.
I assume that the usual suspects tried it on but ended up on an oompa-loompa hit squad. "It's not chocolate in that glass pipe!"
Also consider that after 2 years we have only arrived at the "You can start to argue the fine down" stage. By the time any penalty finally hits the Advanced books, the original directors / managers responsible for the operational state of affairs there will have moved on.
"A murderer was captured this morning and tried today. Tune in for the execution at six tonight. All net, all channels. Would you like to know more?"
I hate to break it to you, but "thievocracy" is a mash of Old English "theof" and Greek "kratos", the root words having drifted somewhat for modern usage. Either go with "government of thieves" or kleptocracy, which is perfectly well understood even by those who only know a few Greek loan words.
"Thievocracy" sounds like the product of a rather dim and guilt-ridden academic. It jars.
That's a non sequitur. You invite discussion of acceptable content, but this scandal involved an egregious failure of message authentication.
Proof: if plain text was the only acceptable medium then organizations would communicate in that format (anyone remember telex?). These spoofs would still appear perfect in that format, and any client code that added a security preamble to the message would show that it had passed authentication checks. Transfer the funds, Ms Heisselippen!
Text-based attempts to commence BEC are still very commonplace. The plainer ones stand out because a colossal quantity of dross is accepted and even expected in messages, but level the field and they would remain perfectly effective.
I must admit that I had noticed this flow, deduced that the senders were M365 tenants and had assumed simple account breaches. For many, I doubt that the actual cause makes much difference.
No, that plays to the Microsoft canard of blaming an open market for security software for the catastrophe. That is in turn a not-so-subtle return the position where MS grant themselves monopoly privileges when writing new software (because only they have complete access to the system APIs). We were arguing that one in the mid-90s.
I would point out that no Crowdstrike customer was deceived into installing the software, and I would expect that all of them fully accepted that they were granting significant system trust to Falcon. What no-one expected was the shocking lack of software quality that allowed a poorly written _data_ update to crash the software and the machines it ran on. Blaming an automatic content validation tool is no excuse; that approach would not prevent an attack by poisoning the data files after validation.
Crowdstrike need to fix that flaw before I would trust Falcon on my kit.
Been there. Did that. Have the vendor T-shirt.
Strangely enough, they now have an arrangement whereby the clueful can designate a test group and release the software to that before deciding to release it to the entire estate.
Others say "we only deploy $newstuff to 10% of your estate" (so only 10% is fscked, and hopefully that does not include both of your solitary pair of DCs). Scream loudly enough and the other 90% shall be saved.
It's Heaving Packhorse - have a look at the logo on your wireless access points and in your patch cabinets. If you see the word "Aruba", start asking questions.
Original item here for those hitting dud links elsewhere:
https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04640en_us&docLocale=en_US
Which is little more than the TXT for ARUBA-PSA-2024-004 but slightly easier reading.
Take-downs put a temporary stop on fraud, but unless the right people are arrested, remanded and face a sufficient increase in sentencing unless they give up their backups the take-down will only last until a new host is found and a new name established. As LabHost is suspected of being a clone of a previous souk, it is possible that these sites are being run in series.
The news articles are all either light on technical information because of their natures or are coy about answering my question - exactly who is hosting this sort of thing? The US DoJ article is a little more forthcoming:
https://www.justice.gov/usao-wdpa/pr/justice-department-seizes-four-web-domains-used-create-over-40000-spoofed-websites-and
The only real answer is to shift part of the liability back to these hosts and registrars, something they would be resolutely against even when investigation shows a complete lack of diligence by them when accepting the business. For a more spiritually uplifting tale for a Friday, read this crimp in Freenom activity:
https://www.spamhaus.com/resource-center/troubles-in-tokelau-malfeasance-in-mali-whats-happening-with-freenom/ (2023)
I never, ever thought I would cheer on Facebook, but go Zuck!
That might have been wiser to exclude, though we also use the existence of a working proof-of-concept in assessing how immediate a threat is. If you are going to trust a security vendor, you may as well trust their assertion "We have seen and tested a POC but are not publishing it in order to prevent exploitation".
Rapid7's responsibility is to its customers to inform them of vulnerabilities. Everyone else can be thankful that the information is at least partly available publicly rather than behind a paywall. As a member of the public, assume that you will be the last one informed - the tester of varied hat colour who found the vulnerability knows about it, the agency he sold it to knows about it, the original publisher who may or may not have paid a bug bounty knows about it, and other testers may have found it. There are many chances for a vulnerability to escape before it goes public, and those risks cannot be negated.
Even if Rapid7 had quietly added the vulnerability to their database just for their customers, that would have widened the chances of escape via an attentive customer. Disclosure is the only way.
In that context, trying to quietly plaster over a vulnerability is really not on.
Yes, a lot of internet protocols are horribly open. Read any account of the early days and you will soon appreciate that the internet is a far bigger thing than they expected.
The real question is why nothing effective has been done since then to address the problem for the vast majority of users. It's been over 30 years since Eternal September started - that's longer than the time between the birth of the internet and that catastrophic date. Why not? Because those who opened that dreadful door have always resisted taking any liability for their actions, and continue to lobby so to this day.
That is offensive security - you will master a number of techniques, but unless you study how to run a methodical pen test you will not know about security.
Defensive security involves knowing the complete map of vulnerabilities and how you can intercept or interfere with attacks en masse at every step of the chain.
The horrifying thing here is how a compromise of a non-product test tenant account can turn into access to "senior leadership" accounts in Microsoft's own tenancy. The best case (which is still fairly damning) is that this "test tenant" was testing some sort of internal super-partner access for licence auditing or something similar. Unforgivable that it was not on MFA and left open after it was no longer needed.
There seems to be some confusion between SharePoint Server and SharePoint Online here. Whilst they do not appear in lockstep, I see vulnerabilities announced for SharePoint Server almost as frequently as Exchange Server. Neither should be exposed directly to the internet. SharePoint Online is only available on the internet. The problem there is exposing your SharePoint Online users to the internet...
So if "Snow" had chosen to redirect a whole collection of announcements for high-traffic Orange networks on to one specific customer, the effect would have been trivial?
Considering previous BGP whoopsies, I think not. In fact, is there a correlation between the MFA implementation date for ARIN and an apparently inadvertent attempt to route a large part of the US eastern seaboard through an obscure southern US steelworks or lumber yard?
Even the pointy-haired ones can see that's a silly idea that is still exploitable.
1) text based bogus writ threats will still get through
2) socially engineer the recipient to reassemble the link - which is a variation of these password-protected droppers that are making a comeback.
Some commentators appear to have missed one of the points - the Singaporean paper is saying that the banks do not pick up liability if they have not practiced fsckwittery.
That rather limits their scope for communication, since many of the available media are inherently fsckwitted for financial communication. A PSTN that is open to spoofing? SIMs that can be 'jacked by spinning a tale at the local carrier retail outlet? Active collusion by corrupt staff at any point in the over-extended outsourcing chain? Secret Q&A in an era of criminal e-pending? FFS, that's worse that a moderately weak password.
There are secure means of consumer communication. The banks know them and many of us know them. We simply need an ombudsman that knows them, but that might be too big an ask.