Paul reports on a bypass flaw found in Samsung Android browser, security flaws found in Sonos Internet connected speakers, and Google wanting to get rid of SMS authentication! Jason Wood of Paladin Security joins us for the expert commentary, and more on this episode of Hack Naked News!
- Critical “Same Origin Policy” Bypass Flaw Found in Samsung Android Browser – A critical vulnerability has been discovered in the browser app comes pre-installed on hundreds of millions of Samsung Android devices that could allow an attacker to steal data from browser tabs if the user visits an attacker-controlled site. This represents quite a few devices in the wild. I wonder how many will actually get updates?
- 15-Year-Old Apple macOS 0-Day Kernel Flaw Disclosed, Allows Root Access – A privilege escalation vulnerability has been discovered in Apple OS X, reportedly existing in the codebase for 15 years according to public reports. It does require that the user is logged out, or force a reboot, to be successful. The researcher has released the code, rather than report this flaw to Apple. This is a potentially controversial disclosure, however, it underscores the lack of a public bug bounty program for Apple’s OS X operating system.
- Automatic autofill of your username and password? Not a good idea
- Security Flaws Found in Sonos Internet Connected Speakers
- Code Used in Zero Day Huawei Router Attack Made Public
- Google wants you to bid farewell to SMS authentication
Malware Attribution Difficulties and Code Reuse
Today I thought I would do something a bit more technical in nature. I’ve been learning more about analyzing malware recently and a blog post by Marco Ramilli caught my attention. In this post, Marco goes through different stages of a malware attack and noticed some interesting changes in the tools as he did his analysis. First off, he picked up a sample of some malware from one of his email addresses. The malware was a Microsoft Word document with a macro embedded in it. (It still amazes me that macro malware works.) The macro used four rounds of character substitutions and UTF-8 encodings to get it back to the infection command. The resulting Powershell command pulled down an exe from the internet and then executed it. Stage 1 complete.
The exe is stage 2 for this attack. The binary was a .NET executable and Marco was able to disassemble that back to the source code and analyze that. This gave him a feel for the coding style of the original developer. What I think Marco means by coding style is just how someone goes about formatting and commenting their code. If you’ve spent any time looking through source code by different developers, I’m sure you know what I mean. He also noticed that the comments were written in Japanese characters. So perhaps we have a Japanese attacker behind this? Well, let’s wait and see what the full results are. The exe actually attempts to appear to be written by the Coca-Cola company. So there’s an odd attempt at appearing reputable. What the exe primarily does though, is extract yet another exe from itself and execute that. Stage 2 complete and on to stage 3!
The last exe is stage 3 and it is yet another .NET executable. Marco went through the same drill of disassembling it back to it’s source code and analyzing that. What he noticed was that the style of coding was very different than the exe in stage 2. How the attacker went about writing and implementing his attack was a noticeable departure from the previous sample. The comments were also in English now. So we appear to have a new developer for this file. Overall the malware attempted to fingerprint the system it infected, look for other computers and check in with a web based C2 server.
What is interesting about this is that attribution would be difficult in this situation. It appears to be a reasonable theory that we have an attacker who has pulled together different executables by different authors and strung them together in a single attack. Or perhaps they have written one of the three stages and then re-used other tools to add on to their attack. There’s no clear path (at least on one sample) to figure out what area of the world the attacker may be in. It’s also interesting to see that they are using several different tools that they were not the authors of. It’s not a shocker that attackers using malware would use code reuse in their activities. We do it in development, systems administration and security testing. I’m sure they do it for the same reasons we do. They have limited time, resources and perhaps just don’t want to make the effort to write a new tool to do what one already does.
If you are interested in malware analysis, then you might be interested in checking out the blog post. You can get the link off the show notes for this episode.