When Google released Chrome 56 at the end of January, it touted a major improvement by flagging non HTTPS compliant sites. Which means that you’ll know when you’re going to a potentially unsafe site. That’s a good thing. However it also slipped in something else. Chrome now lets websites ask about users’ Bluetooth devices and harvest information from them through the browser. Now, you have to grant a website access to your Bluetooth gadgets before anything happens.But if you do, it can see everything from your mouse, to your fridge, to anything else that might be connected to your computer via Bluetooth.
Here’s why I have a problem about this.
We’ve now gone beyond having websites scan for what browser or OS you’re running. Now someone, be it a marketing type or a hacker, can find out if you’re have a smart fridge, or Bluetooth trackers, or smart lights in your home. At the very least, these are new avenues for you to be the recipient of targeted marketing. At worst, this opens the doors to hackers who could cause all sorts of chaos. This is an absolutely horrific idea that I hope get binned and quickly.
In the meantime if you get a request to let a website access Bluetooth, your best course of action is to say no. At least until a way to disable this in the browser is found. Your other course of action is to switch browsers, but I suspect that it may not be long before a similar “feature” starts to show up in other browsers.
Windows Exploit Now In The Wild…. Sysadmins Should Worry
Posted in Commentary with tags Microsoft on February 6, 2017 by itnerdThere’s a new Windows exploit that is now in the wild. What’s scary about it is that Microsoft has not fixed this exploit and there is a proof of concept attack that is now available for it. Here is what CERT had to say:
Microsoft Windows fails to properly handle traffic from a malicious server. In particular, Windows fails to properly handle a specially-crafted server response that contains too many bytes following the structure defined in the SMB2 TREE_CONNECT Response structure. By connecting to a malicious SMB server, a vulnerable Windows client system may crash (BSOD) in mrxsmb20.sys. We have confirmed the crash with fully-patched Windows 10 and Windows 8.1 client systems, as well as the server equivalents of these platforms, Windows Server 2016 and Windows Server 2012 R2.
Note that there are a number of techniques that can be used to trigger a Windows system to connect to an SMB share. Some may require little to no user interaction.
Exploit code for this vulnerability is publicly available.
Let me translate for you. If you have a Windows Server in your environment that serves stuff up to Windows clients (or anything else for that matter such as Macs), it is using the SMB protocol. There’s a bug in the SMB protocol that allows someone with the right skills to perform a denial of service attack on the server by crashing it. Now this is only an issue if you let SMB traffic go from the server or servers in question to the broader Internet. While that’s something that I do not recommend, a lot of companies and individuals with home Network Attached Storage boxes do that. Seeing as there’s no patch at present, blocking outbound SMB traffic is the best way to protect yourself.
Now Microsoft was apparently told about this issue three months ago by security researcher Laurent Gaffie. But they didn’t come up with a fix, thus he went the route of releasing POC attack code on Github. Thus now that it’s in the wild, it will be interesting how fast the folks in Redmond come up with a fix.
1 Comment »