News about Excubits and IT-Security
Keep being updated and subscribe to our newsletter.
2018/02/07 by F. Rienhardt
We proudly present a new feature for MZWriteScanner: Block Executables From External Drives. We all know that external drives are often used to carry and share documents. There's always the risk of getting infected by malware with just one wrong double click onto a file from e.g. an USB-Stick. Disabling e.g. USB Storage is not practicable for the majority of users out there, although possible in Bouncer (just blacklist USBSTOR.SYS, or CDROM.SYS). While blocking executables with Bouncer or CommandLineScanner is made simple, there was room for improvement in MZWriteScanner. We decided to find a smart solution for this driver in the kernel, and only in the kernel.
Well, guess what?! We are happy to publish a new beta of MZWriteScanner containing the new [BLOCKFROMEXTERNAL] option. We are currently checking whether we can build a free driver just implementing the [BLOCKFROMEXTERNAL] feature for the community, to make the use of usb-sticks a little bit safer and make computers more robust. Just let us know what you think about it.
2018/02/07 by F. Rienhardt
You should not blindly trust in digital signatures, read this paper for more details. Hence allow by signature is not always a good idea when it comes to application whitelisting. For a good reason we decided very early not to support digital signatures in our whitelisting solutions, and we will keep on it.
2018/03/02 by F. Rienhardt
We have just updated our blacklist recently. We have added *wbemtest.exe to avoid attacks via WMI.
2018/01/30 von F. Rienhardt
We went through dozens of new driver variants in the last couple of weeks and are now ready to publish a new option for MZWriteScanner: [FASTHASH]. Fasthashing allows a massive speed up for MZWriteScanner.
Well, you might have noticed that copying or moving executables while MZWriteScanner is enabled can take its time. This is because performing SHA256 on large files is time consuming. We thought about this issue, did a lot of testing with different approaches and finally ended with measured upper limit hashing. In most cases an executable’s MZ/PE-Header contains highly variant information which differs from one executable to another (e.g. memory locations used, entry point, checksum, etc).
So the question was: why should we hash a file completely when the most variable part of the file is also in the first bunch of byte blocks? Well, yes. So we decided to add [FASTHASH] which only hashes the first 16 blocks (~512 bytes) of a newly written executable. This dramatically enhanced overall performance.
No effect without side effects. If we do not hash the complete file there is a risk. If you process executables which are large, compressed (SFX, self extracting zip, rar, 7z, etc. ) and do not differ much in their beginning, it is very likely to happen, that two different files share the same hash value. So if you are going to process many such files, [FASTHASH] is not an option for you. It can be a risk. That should be said here very openly, but we expect normal and legit executables differ much in their structure as their MZ/PE-headers will be different (different entry points, memory allocations and stack options, resources, imports, etc.).
So we invite you to test the current beta and share your thoughts and comments. Thanks.
2018/01/30 von F. Rienhardt
We can happily confirm that all of our drivers are still working fine after the Meltdown updates for the Windows Kernel. We have not encountered any issues and protection works as supposed.
2018/01/08 von F. Rienhardt
The year has just started and we are back with news. We learned from your feedback and suggestions and heavily hacked on a new version of MZWriteScanner which will support parent checking and a persistent cache for newly written executables. Both features were requested by many users, so it really was time to add this functionality. Upcoming MZWriteScanner will be able to track and block newly written executables after reboot. With parent checking you will be able to define more powerful rules which should fit our customers need.
Over the last couple of days, there has been a lot of discussion about security vulnerabilities named Spectre and Meltdown. The Spectre vulnerability allows an attacker to bypass software checks to read data from arbitrary locations in the current process' address space. The Meltdown vulnerability allows an attacker to read data from locations in the operating system’s protected kernel address space. Both vulnerabilites could be used to gather information like passwords or cryptographic keys. In VM-based cloud environments an attacker sitting in one VM could leverage data from other VMs running on the same server. So, if you are using or running VMs you should be aware of who is running what on your (VM) machine(s). The same is true for Citrix solutions and alike. While doing a security audit we have investigated that Citrix-Servers are often not very well protected and immoral users (or through an exploit) might start executables (DLLs) which then exploit Spectre and Meltdown to obtain information from the Citrix environment. Here strict SRPs/AppLocker rules or our drivers ☻ can help to mitigate against the risk, so take care of it.
Some users asked us whether MemProtect can mitigate against Meltdown or Spectre: No! MemProtect is a driver sitting in the Windows Kernel. Both vulnerabilities leak data via a hardware side-channel attack. A driver like MemProtect cannot mitigate against such. We were also asked if there is any risk, if kernel memory from our drivers is leveraged. Well, we do not think so. The configuration information could be read, but an attacker could also read the configuration from the .ini file, so there is no real benefit here. Of course our driver’s internal state variables could be leveraged, but we do not see much value and benefit for an attacker.
What about the upcoming Windows updates, patching Spectre and Meltdown? We are aware of the new updates for Windows which were already released for Windows 10 and will be released on the next patchday for Windows 7 and 8/8.1. Microsoft states that after patching for Spectre and Meltdown, some security software might fail to work. From what we currently know our drivers seem to work after the patches and should still protect you. But we continue to perform tests this week and keep you updated.
If you have any questions, please do not hesitate and contact us.
2017/12/27 von F. Rienhardt
This is going to be the last post for this year. We hope you all had great christmas holidays and wish you, your family and friends all the best for 2018. Thanks a lot for your support, ideas and open mind. We will continue to keep up the open approach and love to discuss with you in 2018.
We are happy to announce that we have 'hacked' on a first prototype of MZWriteScanner which supports parent checking. As soon as we feel comfortable with the driver, we will publish a first beta :-)
2017/12/23 von F. Rienhardt
After the last updates for Windows 7, in some constellations new EXE files were detected by MZWriteScanner, but not blocked. The reason for this was, that Windows 7 tried to load the executable into memory and after being blocked by MZWriteScanner, the Windows loader "decided" to load the binary with kernel privileges. Since our driver did not block calls within the kernel, it was finally possible to start an EXE file loaded. This is strange, because the operating system should stop loading and starting an executable if it fails because of a permission denied. Since this only happens under Windows 7 (we heard on some Windows 10, too), we assume that this is probably a bug in the operating system. We recommend to update MZWriteScanner to the new version. Shout outs and greetings to Mike for reporting the issue.
Some of our customers told us about slow access rates on external devices. We have enlarged the read buffers. If you have similar problems, you can choose from one of the following options:
to enlarge the read buffers. This could speed up things.