So you may have gotten a Slack password reset prompt. Something like half a percent of Slack’s userbase had their password hash potentially exposed due to an odd bug. When sending shared invitation links, the password hash was sent to other members of the workspace. It’s a bit hard to work out how this exact problem happened, as password hashes shouldn’t ever be sent to users like this. My guess is that other users got a state update packet when the link was created, and a logic error in the code resulted in too much state information being sent.
The evidence suggests that the first person to catch the bug was a researcher who disclosed the problem mid-July. Slack seems to use a sane password policy, only storing hashed, salted passwords. That may sound like a breakfast recipe, but just means that when you type your password in to log in to slack, the password goes through a one-way cryptographic hash, and the results of the hash are stored. Salting is the addition of extra data, to make a precomputation attack impractical. Slack stated that even if this bug was used to capture these hashes, they cannot be used to directly authenticate as an affected user. The normal advice about turning on 2-factor authentication still applies, as an extra guard against misuse of leaked information.
Et Tu Twilio
Not to be outdone, Twilio just disclosed an ongoing problem, but this one was an active social engineering attack. It started as a targeted phishing campaign against Twilio employees, and as employees fell for the fake login page, the attackers used the captured credentials to access internal tools and access end-user data. Of particular note is that these phishing attempts were successful because they were targeted at known Twilio employees, using the correct phone numbers, and included names or usernames. It’s reported that other companies, namely Cloudflare and Cicso, are experiencing similar attacks. It’s possible there was a breach in a shared provider, that enabled the targeted fishing.
More From The CPU Vulnerability Nightmares Front
Leading the charge is Intel’s ÆPIC Leak, a new sort of processor bug. This isn’t a speculative execution bug — we’re not tricking the CPU into acting on memory that will be rolled back. This is more like reading from uninitialized memory, and finding another process’s secrets there. That’s actually the exact sort of bug the researchers were looking for, as they intentionally filled buffers and caches with a known pattern, and then attempted to read from nonsensical memory locations looking for those patterns. If a memory read returned their canary data, then something interesting was afoot.
This was exactly what happened when reading from I/O addresses assigned to the Advanced Programmable Interrupt Controller (APIC). Certain bytes inside the APIC range are reserved, and trying to read them invokes undefined behavior. On many CPU models, this means a system hang and/or full CPU crash. On some processors, the read worked, but because the APIC doesn’t actually send data on these addresses, stale cache contents are returned. This is a very interesting result, but note that actually pulling off the attack requires root-level access to the system. That makes it basically meaningless, as the kernel can already read arbitrary memory, right?
There is an important exception to the rule of Kernel-sees-all. Intel’s SGX enclave technology is specifically designed to protect regions of memory from even the kernel. In practice this means DRM keys and SGX protected virtual machines. DRM key leakage is not a threat *to* the end user, so isn’t something to worry about. And the collection of people that run SGX protected VMs is likely quite small.
SQUIP
AMD isn’t missing out on the fun, making SQUIP public this week (whitepaper). It’s a new side-channel that derives process state from the scheduler queue. Simultaneous MultiThreading (SMT) is the technique used by modern processors to feed two threads of instructions into a single processing core. Because different instructions use different components of the CPU, SMT results in higher throughput than traditional one-thread-per-core arrangements. One downside is that the activity of one thread can have an impact on the performance of the other. For instance, for doing live audio processing, one of the recommendation was to disable SMT to avoid data underruns. For the security minded, there’s an obvious side-effect, that one process can learn a bit of information about what its sibling thread is doing on the CPU core. There have been a handful of methods to detect and take advantage of this effect, and what SQUIP brings is a new method to spy on the sibling thread.
In AMD Zen processors, there are multiple Arithmetic Logic Units (ALUs) per CPU core, but only one of those units can do multiplication, division, and Cyclic Redundancy Check (CRC) operations. SQUIP queues up many multiplication operations requests in a row, and then issues an rdpru instruction, Read Processor Register. It’s specifically looking for the value of the Actual Performance Frequency Clock Counter (APERF). There’s a quirky behavior here that is the key to the attack. There are separate queues for each of the ALUs, as well as the master queue for the core. The master queue pushes instructions into the individual sub-queues, but if the next target queue is full, the master queue stalls until the next instruction can be sent to the correct component. In effect, if the ALU1 queue is full+1, the rdpru call is delayed. Once that instruction makes it to the end of the primary CPU queue, it can immediately execute on one of the other ALUs. This, in essence, allows an underpriviledged process to spy on how many multiplication instructions are being performed by its sibling process, even if that sibling happens to be in a different VM, for instance.
So we can determine multiplication instructions. What exactly does that get us? The example the researchers reached for was RSA’s square-and-multiply, where each bit of the secret key will trigger either two or three multiplications, depending on the value of that given bit. By using the SQUIP technique over many runs (more than 50,000), it’s possible to infer the value of the secret key. It’s a brilliant bit of work, but probably of limited real-world use. This is AMD’s take, at least, as their guidance is to use best-practice coding techniques to mitigate this issue.
Microsoft Office and Symbols
It’s another of those “hath hell frozen over?” moments, as Microsoft announces the release of debugging symbols for Microsoft Office. What exactly are debugging symbols you ask? Maybe think of them as a roadmap to what’s in a binary file. When a program crashes, debugging symbols tell you what function was being executed when the crash happened, and maybe even the name of the variable that was the culprit. Now while this isn’t as much information as a full source release, it really does bring a lot of transparency to what is happening inside a given program. Imagine what a Ghidra decompile of Office might turn up. And that’s sort of the point. Microsoft wants researchers to find exploitable bugs and report them. On top of that, third-parties make plugins and integrations for Office, and better debugging makes both jobs easier.
VMWare
[Steven Seeley] of Source Incite found a collection of VMWare vulnerabilties back in May, and when they are put together, they make for an impressive RCE to root vulnerability chain. First off is a quirk that’s probably a feature. When an admin creates a dashboard link in the vRealize Manager application, a token embedded in that link allows anyone to access the dashboard without a valid account. While it’s essentially read-only access, there’s a second issue, where an API call to create a new user bypasses the normal authentication checks.
That next problem happens to be sensitive information that winds up in the logs, and that the system allows log access to an underprivileged user, or no user at all, in this case! The log line in question contains a Basic authorization string. Basic auth is just Password and ID run through a Base64 encoding. As demonstrated in this attack chain, it’s really not a good idea to use. Regardless, this allows a password reset for the admin user, getting an attacker admin access to the system. admin can go enable the SSH port, and log in. So an attacker has admin and SSH, but that’s still not root.
Up next is a sudo rule that allows any user to run a specific Python script with sudo — meaning that script runs as root. That script looks to an environment variable to find its binaries, and that variable is trivial to set. Set the variable so the script running as root will run a script you wrote, and you can do anything, like giving your account full sudo rights. The full exploit chain is called DashOverride, and patches are available for the three vulnerabilities in play. Well done [Steven] for the find.
SELinux
If you play in RedHat land, you’re probably familiar with SELinux, if only as the pesky thing that you turn off to make software work. Many of us sysadmins that work on RHEL and its clones are used to temporarily disabling it as a first troubleshooting step. Well, [esp0x31] would like you to reconsider that habit, making the case that SELinux can be a useful tool for system hardening. The post describes how you can set up a file context for a given program, and then strictly limit its access to only files with that context. Should this application be able to talk over UDP? If not, add a rule that prevents any UDP socket creation. A killer tip is the newrole command, which puts you into the SELinux domain you just defined — perfect for bashing on your new rules looking for a loophole.
Bits and Bytes
The Point-to-Point Protocol in Windows has a flaw, CVE-2022-30133, where sending traffic to port 1723 can result in arbitrary code execution. The scary bit about this one is that it’s potentially wormable, and that the port might be intentionally exposed to the internet, as this was an early VPN solution in Windows. Yoiks.
X-as-a-Service is one of the hottest ways to monetize, and the criminal element has jumped onboard. We’ve had ransomware-as-a-service, and now there’s command&control-as-a-Service. Is directing the hoard of machines in your botnet just too much trouble? For a low monthly fee, these guys will do it for you, and it comes with a slick looking dashboard and everything. We truly live in modern times.
Rsync has a flaw, where a malicious server can write arbitrary files on a connecting client. This could also be leveraged in the form of a man-in-the-middle attack. Look for a release of 3.2.5 in the coming days, which will contain the fix.
5.4 million Twitter accounts had their private data scraped and sold, thanks to a zero-day in Twitter’s web code. The sensitive bit was the email or phone number used to verify the account. For most of us it would just be an annoyance for that to escape. Just another make it another couple spammers’ lists. There are a handful of Twitter accounts that are run anonymously for good reason, and this sort of leak could be quite a problem, if it allowed bad actors to connect the dots. Thanks to [app-le-bees] for pointing this one out in our Discord!
When the AI models start learning how to find hardware vulnerabilities we are all gonna be buying new computers on a regular basis. The engineers at Intel and AMD are clearly the keystone cops of computer security and they will be unable to keep up. The machines we have now will soon be considered hopelessly insecure and good only for recycling.
I doubt that, as even if the AI does get really good at finding bugs, even designing systems without any bugs in them its not a quick process to create the new stuff, so its several years later as faster, more efficient, hopefully more secure processors start to arrive same as it is now – so the current stuff will get used and the flaws worked around until it ages out…
And I doubt the AI will ever* be good at catching vulnerablities really – no doubt a great tool to find aberrant behavior and hammer at the know failure methods but the cunning twists of logic that find whole new risk vectors and ways to use them I doubt.
*ever being any time soon at any rate. Eventually maybe AI will really be capable and at least have the potential for free thought and lateral thinking, right now they are very much more abacus than that.
Not to mention that most safety issues are found by fine combing the available documentation, finding potential open doors, then getting actual hardware, make applicable software, test it. Likely fail, since very few things of this sort is actually going to work at all.
Secondly, one has to know what to expect, where and when. Even if some security issues are a bit more random than that.
So AI that currently is a tool that more or less has to be trained for a specific task isn’t really going to adapt well to this frankly arbitrary field where one don’t know what to expect until one finds it, and when it is found it is found.
So yes, AI isn’t going to do this work for the foreseeable future, perhaps 20 years from now. But probably not.
AI is already doing stuff that we don’t understand. It can pick details out of X rays that are way past the capabilities of any human and we have no idea how it is doing it. I think it is fair to say that it will have our puny brains figured out any day now. Once they know how we think, they will be able to defeat anything that we can think of because they will be able to predict what we do.
Most of the things that we used to consider to be ‘secure’ have been proven to be full of holes. It is sheer folly to think that somehow we have gotten smarter and we don’t make those mistakes any more.
It only takes one tiny vulnerability to destroy the security measures that take decades to develop into commercial products. The theoretical math behind the stuff you are seeing in our new processors has been in development since before Y2K was a thing. If their initial assumptions are proven bad, they will have to start over again from scratch.
The industry s moving a lot slower than you think. We are all still running processors that are slavish clones of DEC VAX designs, there has been almost no progress in 40 years. How can you expect change when there is no history to suggest that change will even happen.
AI isn’t doing anything we don’t understand, yet anyway, just with very precise and accurate training data and feedback its very good at spotting the conditions its trained to spot – its noticing and correlating minor details the humans wouldn’t in things like medical scans – but that also means adversarial images, like say a picture that is clearly a tortoise can be identified as an AK47! As it has no idea what its doing, so with anything out of its training dataset it can easily be lead astray – even without any malicious intent as it doesn’t know it doesn’t know, and won’t know it got it wrong unless we tell it. But if you have a very specific task in the right conditions it works well enough now that the occasionally an ‘AI’ system is actually right often enough to be useful, in those conditions and for that task BUT for absolutely nothing else is it reliable.
I’d argue nothing we have ever thought of as ‘secure’ has been proven bad – there have been shoddy implementations it is true, but the core methods have always had to balance with practical functionality on the hardware of the day. So it has never been thought to be anything but ‘secure enough’ by anybody in the know.
Really all you are ever doing is making cracking the method used take (on average) too much compute time to be worth the effort. Which is why the coming of quantum computers has created such alot of noise – it changes the playing field, but not in a way that wasn’t entirely predictable – everyone knew systems secure enough for conventional processes can be done faster by other methods, at least in theory.
Same thing with speculative executions and the like, even once some proof of concept attacks have been carried out its still safe enough really – and the risks such methods could pose was never hidden, it just wasn’t easy to see a way to make it exploitable, all while providing really quite substantial performance increases.
Same thing with the Intel Management engine, hate it all you like as a security hole, but it provides a pile of vital services (at least for the world of mass deployed business computers and the like – not likely to find much use for its intended features at home), but everyone interested knows oneday it will be exploitable, the only question is will anybody still be using that variety of it by the time it is.
Alas as ultimately social engineering aspects are overall the weakest link in security – people are far more fallible than the software/hardware made honestly – there is only so much point in worrying about it anyway…
First of we have AI, or more specifically neural networks.
“AI is already doing stuff that we don’t understand. It can pick details out of X rays that are way past the capabilities of any human and we have no idea how it is doing it.”
No, it is fairly logical how it works, and why it achieves the results as well as it does.
Neural networks are from a simplified point of view just a small system trained to do one specific task. As long as the task is sufficiently contextually simple it won’t often need all too much resources to work effectively.
The more contextually complex a task gets, the harder it is to train an AI for the task.
Face recognition is a typical example of this. Make an AI with 1000 neurons and it can identify 1 person with fairly good accuracy. Train it to recognize 10 people and its accuracy goes down dramatically. Give it 10 000 neurons and we can train it to about the same accuracy again.
The same thing goes for training a neural network for any other task. The more outputs we desire, and the more accurate we desire them to be, the more resources we will tend to require. Exact amounts depends on the application.
But as we add neurons, training times often increases exponentially, not linerally. Often the solution here is to split the network into multiple smaller networks handling their own sub tasks.
Then there is history.
“Most of the things that we used to consider to be ‘secure’ have been proven to be full of holes. It is sheer folly to think that somehow we have gotten smarter and we don’t make those mistakes any more.”
A lot of older computer systems simply didn’t have the resources to spend on anything other than getting the code to run and store enough data for it. Security on the hardware level were also not critical, if someone “hacked” the computer, so what… Worst case if tampering/sabotaging it so that it seems to work fine, but actually gives incorrect answers. Something a few confidence tests at the time can find, since the machines weren’t all that complex.
I won’t disagree that a lot of X86, and even ARM is largely built on an antiquated foundation.
But in practice, there is a lot less security holes than one might expect. And to be fair, most hardware security flaws found in the last decade haven’t been that bad.
Most security flaws aren’t trivial to pull off.
Specter makes a rather noisy show for a slow easily spotted attack.
Port smash can be circumnavigated by always doing the same work regardless of what the actually chosen path were, most relevant to encryption algorithms and even then a game of chance to have the attacker and target on the same core and running at the same time.
Row Hammer is another cookie to entice hackers with. But cache alone already slows this down (threads generally shouldn’t control caching, or rather it should be a privilege). Let alone the simplicity of address line shuffling making the attack a guessing game as well, not that it weren’t already a lottery to start with since memory allocations are decided by the Kernel at runtime, so the target can be anywhere.
There is also the PCI/USB Direct Memory Access address space overlapping with Kernel space. And this is somewhat trivial to fix by just disallowing this DMA to a given portion of the address space. This were short lived… I think most CPUs just fixed it in firmware. (Honestly a better solution would be to shift the DMA space elsewhere in memory, but software compatibility is a nightmare.)
However, finding security flaws isn’t as much about randomly prodding the CPU with instructions and hoping for the best. That most often just crashes the thread in short order. Or potentially confuse other software and getting something else to crash as well. (here we can tangent into software security, but I won’t.)
So randomly chucking instructions at the wall doesn’t give one much information, since what do we expect? CPU’s don’t just give one a “Congratulations, You just hacked the Kernel!” message, so knowing that one even got relevant data or even did something at all is in itself part of the challenge.
In effect, reading documentation, looking at how the hardware supposedly is implemented. Prodding at it to carefully observe if it behaves as expected to give more hints about its underlying structure, and from there we can work out a potential strategy to finding a security flaw. Most of the time, one won’t find one.
Directly attacking memory and cache is a category of attacks that are well secured. As well as most other direct attacks at other single points of failure. But sometimes there is a lapse in focus and a new feature is a wide open door for a hardware generation, or a few firmware versions.
Currently (last decade or so) the CPU designing industry is just facing a new group of security flaws called timing attacks. And haven’t yet found the inherently secure method of just waiting a fixed amount of time (from the point the call were made (from the caller’s perspective)) before delivering the bad news to the thread that it doesn’t have permission to read what it asked for (also good practice for database servers, etc). And always return the same monotone answer of all 0 (or 1 if one likes that better) if one has to return a value. Delivering a “no you can’t read that” flag as quickly as possible leaks information about cache state and therefore thread state. (some designers argue that postponing delivery of the flag can lead to future bus congestion and a drop in overall performance, not to mention that the thread waiting for an answer is literally stalling at this point. While I say an honest thread rarely if ever calls data it shouldn’t have access to so the drop in performance is only excepted if someone is dishonest or made a clumsy mistake.)
Now, I have only studied computer architecture design for about 15 years, so this is just my hot take.
But in the end.
Finding security flaws requires patience and lots of consideration of the inner workings of whatever system one is dealing with. This is a lot of complexities that frankly is more about asking the same two questions:
a. Is there a way to directly access what we shouldn’t? (direct attack. These are common when feature creep has gone too far and one starts to loose track of the project… Or have too many design teams working on their own things with too little communication between teams.)
b. Can we derive out any information from observations? (side channel) (Fixed response is the trivial solution but not always applicable, and when it isn’t then it is “fun”. System performance bottlenecks and even response times on valid calls already leaks data about the rest of the system, but have sufficiently many things running concurrently and it all blends into noise. (Also, threads do not generate white noise so filtering isn’t an option. It is just analysis the whole way down to try to untangle the mess.))
Ensure that both questions have an honest no and it is secure from the software side. (Hardware level attacks is another can of worms.)
So can neural networks answer those questions for us?
Neural networks are good at learning vital patterns to follow a set of rules to get desired results. They mimic the dataset they were trained on and smooth out the gaps in-between.
What dataset would one use to train a neural network to find new security flaws? (I don’t know.)
The only guarantee in computer security is:
The statement “this system is secure” will Always be proven wrong.
I am willing to bet money that a major nasty apache bug will be found this year. It is an easy bet because it happens every year like clockwork. All the static analysis and all the best practices and all the mitigation patches will fail to keep Humpty Dumpty from falling down, and some business out there is gonna suffer a major loss. It’s also going to happen to samba and the Linux kernel. We can also add outlook and excel and active directory and sql server to the list. They’re all gonna get hacked. It’s as inevitable as tomorrow’s sunrise. To think otherwise is pure wishful fantasy. If you have these programs installed and you are not watching things closely you might as well just quit now because you are certainly going to be throwing in the towel soon enough.
Missed a good one.
https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html
You misspelled Cisco as Cicso.