News about Excubits and IT-Security
Keep being updated and subscribe to our newsletter.
2018/06/03 by F. Rienhardt
Sometimes news wouldn't be news if you had used our drivers. CVE-2018-8174 is such an example. Referring to Kaspersky Lab's analysis, in April 2018 someone uploaded an infected RTF document onto VirusTotal. The document triggered several vulnerabilites to finally infect a victim's PC (MS Word under Windows). A very interesting point was, that the attackers utilized Windows' default content-type handlers to execute an OLE server, here mshtml.dll. Normally mshtml.dll would have been loaded with safemode flag enabled. Due to a bug this did not happen, hence Internet Explorer's engine is used ignoring the default browser settings. So no matter if you use Firefox or Chrome, the html engine from IE was used, and as if it wasn't bad enough, without safemode protection. Attackers were able to trigger an Use-After-Free vulnerability and herein could attack the machine.
Using behavior detection or your AV's latest signature database can mitigate. But it's just patchwork, the underlying problem is, that MS Word could trigger a document handler. The question is: Why does MS Word (we) need to run any monkier library under normal circumstances? We think that Parentchecking is a very powerful tool to mitigate against this and similar attacks. So we encourage you to make use of this powerful option shipping with Bouncer and our other drivers. Parentchecking, some call it conditional, transitive, call-graph, or dependency checking, is a very smart way to mitigate against many attack vectors. Our drivers support conditional rules for parent processes in the white- and blacklist. We call the originating/main program the parent process, the subprograms child processes. The fact that a parent processes triggers/requests sub-components like modules, executables or files is necessary. But hackers use this technique, too; to execute their evil stuff through media players, browsers or office applications. With parentchecking you can mitigate against such attacks.
Only allow your typical office applications to load and execute the modules that are really needed for daily operations, block all the others. Especially block executable code from temporary folders, you should also have a look onto our blacklist which contains applications and tools that are often misused for attacks. Even if you do not want to generally blacklist them, we recommend to use Parentchecking to stop your business applications executing them. This reduces the attack surface dramatically.
As a starting point block
beeing launched as childs of the parents
You go one step further if you block executables from temporary folders for the parent processes mentioned above.
2018/05/10 by F. Rienhardt
We are updating our policy like many other companies do these days, because on May 25th a new European privacy law called the General Data Protection Regulation (or GDPR) is going to be obligatory. Excubits is updating its policies which now provide even more detail about the information we collect, how we use it, and how we comply with GDPR. What is not changing is the already strong level of privacy.
We have always kept our users’ data personal and private. We never collected any telemetry data in our software products and do not plan to do so in the future. And we have never been in the business of selling any personal information to serve ads or other obscure online marketing stuff. We never used tracking pixels or tracking code on our website or software. We already had very strong data protection in place before the GDPR, so we do not fear the legal code and its requirements. We ensure that the new GDPR is valid for all users across the globe, no matter where you coming from, no matter if you live in the EU or not.
Thank you for being part of our community.
CEO Excubits UG (haftungsbeschränkt)
2018/04/18 by F. Rienhardt
Well, we have been busy in last couple of weeks and fixed some more performance issues in the new version of MZWriteScanner. We also did some minor face lifting and code cleaning in the upcoming Türsteher/Bouncer driver. We turned a lot of rounds in reviewing and still found parts to optimize and clean. This shows again that it is not all about features, features, and features. It is all about constancy and quality. We want our code to be secure, robust, and fast. With the EU General Data Protection Regulation 2016/679 in mind we confirm that all of our products (also the initial releases from back 2014) comply to it. Our software never did and does not collect any telemetry data. We really live data protection, not just talk about it.
We also had some time to tweak the Tray Application for Bouncer/Türsteher. We are happy to announce that the Tray Application can now be localized. Again we took our communities’ feedback and implemented a long wished feature. What is it all about? We have customers from all over the world. We understand that people do not always want the UI in English or German. For example what about French, Spanish, Russian, Mandarin, Arabic, Hebrew, Dutch, Portuguese, and even Bavarian, or Swabian ;-) No matter what language you speak, you can let Bouncer speak it, too. Just set the bouncer.locales or tuersteher.locales files for your language. We hope you enjoy this feature, especially with regards to our customers from the Arabic and Asian regions, which requested this feature.
We have updated the Beta Versions right now and will soon push them to the stable strand. Feedback is appreciated.
2018/04/08 by C. Lopez
We have released new versions of our demo drivers. On 01/04/2018 the beta version reached their hard-coded validity, so we updated the binaries for another year. The first release for Bouncer and Türsteher have been replaced today as they had an issue with the installer.
We have also updated the beta binaries of MZWriteScanner and Bouncer/Türsteher.
We have fixed some minor issues in MZWriteScanner which caused errors on network drives. We were also able to tweak hashing a little bit, so it is a bit faster. We still perform some internal tests but are looking forward to make an official release soon.
In Bouncer/Türsteher we fixed an issue with NULL parents. NULL parents are calls from the kernel. As there is no process - it is just the kernel - we can only log NULL. You need to specify (NULL) as parent for rules in the black- or whitelist. Also note, that blocking drivers from loading can lead to some confusion, if the driver was already loaded before. Windows caches previously loaded drivers in the kernel, so if a driver was loaded, stopped and then loaded again, no process creation is going to be triggered. To trigger it with Bouncer you shall restart the PC.
We are currently also hacking on the TrayApp for Bouncer/Türsteher and added a new icon color (blue), if the driver is in [#LETHAL] mode. We received feedback of users which forgot that they have turned Bouncer into non-lethal mode. So we hope, the blue icon will help to reduce the risk of running the driver too long in non-lethal mode. We have also optimized the color changing mechanism of the tray icon. The icon will no longer flicker between different colors on state-change. We do some internal tests and will then soon release a new package of Bouncer/Türsteher.
2018/03/12 by F. Rienhardt
We have changed the architecture in MZWriteScanner to optimize network drive access and again optimized hash calculation. For forensic investigation we have also added a "hidden feature" to track all touched files. This enables (security) researchers to track modified files while running the system. This feature can help to analyze malware's behavior, but can also help to spot other weird stuff on your machine. If you would like to test this feature, contact us for more details.
The new beta of MZWriteScanner can be downloaded here.
2018/03/08 by F. Rienhardt
We have received some questions about how our drivers (Bouncer, CommandLineScanner and MZWriteScanner) block kernel drivers. Some users noted that our drivers do not block .sys files, but that is not the case.
What might confuse some of you is the fact that Windows automatically caches previously loaded and executed drivers. For example (this was asked by an user): if you start VeraCrypt, its driver is going to be loaded into the kernel by the application. If you quit the VeraCrypt application, the driver still remains in the kernel for the next startup of VeraCrypt. This is done for system performance optimization. To top it all off, modern versions of Microsoft Windows also support hibernation shutdown: Windows actually is not really shutting down and quitting all applications on shutdown. Often used application services and especially parts of the Windows kernel are just hibernated and reallocated on next bootup. So previously loaded drivers are also back up on next startup without triggering any executable loading mechanisms. This helps the operating system to boot up in less then 8 seconds, but one downside is, that the operating system is not fully reflushed and cleaned up.
Bouncer, CommandLineScanner and MZWriteScanner are able to block drivers as long as they were not loaded into the kernel before. Is this a security issue? Well, we do not think so. If you (or an application) has loaded a driver, you must have allowed to load it using high privileges beforehand. You have already made a critical decision in terms of your system's security. If you decide to block a driver you need to blacklist it, and restart Windows. Then the kernel is “flushed” and reloaded from scratch on next reboot. This should solve the issue. But again: If you or an application has loaded a kernel driver, you or the application needed high privileges. Once again, this was already a critical security decision.
If you have a proper configuration to block executables/drivers from user folders, any new executable or driver should be blocked and there is still no security risk.
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.