There's no shortage of speculation on what the Badlock vulnerability will hold in store for organizations when the patch is released this Tuesday. The vulnerability's discoverer posted on Twitter that the vulnerability will give administrator to anyone on the network (though the tweet was subsequently deleted).
What does this mean? Does the vulnerability require authentication or can an anonymous user exploit it? This answer alone will help drive how dangerous the vulnerability is. Also, does remote code execution occur or is this simply a privilege escalation vulnerability? Privilege escalation would be bad, but remote core execution would mean that with anonymous access, Badlock could be wormable. Bad stuff for sure.
What will Badlock impact?
Badlock will impact both Windows and Samba both of which use the SMB protocol.
How long will it to develop an exploit after the patch is released?
This is unknown, but the developers imply that an exploit will be developed 'soon' after details are made public. You should assume the worst and spend some time on Monday getting ready (if you haven't already).
What can I do today?
Rendition Infosec has created a five step checklist for getting ready for Badlock before it hits next Tuesday. We are referring to this as our "quick win" action items.
1. Verify that SMB cannot leave your network. If the exploit is wormable you don't want to be part of the problem. SMB leaving the network is problematic for other reasons even if a Badlock worm doesn't emerge. On any Linux or OSX host, check to see if you can reach TCP ports 139 and 445 on smbcheck.rsec.us. If you get a banner, your network allows SMB outbound (no news is good news). Talk to your firewall admin and get this fixed at your border firewall.
Not sure if your border firewall allows TCP 139/445 outbound? Rendition Infosec has set up a server so you can check. Try these commands from any Linux server in your environment (or download a copy of netcat for Windows if you are so inclined):
nc smbcheck.rsec.us 139
nc smbcheck.rsec.us 445
If you get no output, you're good to go. If you see what I have displayed below, you've got problems:
jake$ nc smbcheck.rsec.us 139
DANGER! Your network allows TCP port 139 outbound. You should block this!
jake$ nc smbcheck.rsec.us 445
DANGER! Your network allows TCP port 445 outbound. You should block this!
2. Scan your network for devices listening on SMB. Make sure you get authorization before doing this, but now is an excellent time to review your network inventories. Know which devices you need to patch.
3. Some of your network devices you never even think about will almost certainly be running SMB servers. These devices need to be patched, but patches for these will not be available next Tuesday and likely will take months to distribute. For those devices that you can disable SMB servers without breaking business functionality, do so.
For those devices that require SMB to be running, they probably only require access from a limited numbers of devices. Restrict these device communications using IP access control lists at your routers and layer 3 switches to limit exposure.
Finally, note that some devices may never receive updates. Samba 4.1 and below are out of patch maintenance, even for security fixes such as this.
4. Consider partitioning your network by using layer 3 ACLs to block TCP port 139 and 445 inbound to your client network segments. Private VLANs can be used to restrict client to client connections. Windows firewalls can be enabled to prevent the use of TCP 139 and 445 on client segments as well.
Many administrators hate to restrict their activities because of firewall use, but in this case it might be worth the pain. Firewall configurations can be updated via group policy, so manual intervention won't be required to remove these rules.
5. Identify points where network segments can be isolated in order to contain an outbreak. Determine who has the appropriate device permissions to isolate a portion of the network. Ensure that the appropriate personnel are available to act. Also determine in advance who has the authority to isolate portions of the network. You don't want to have a plan and then suffer from decision paralysis.
Isolating the network will almost certainly have adverse effects on business operations (how could it not), but these might be worth it to contain an outbreak of a worm. Discuss with business leaders under what conditions you would isolate network segments so the actions can be taken with minimal discussion while under fire. An alternative to isolating the network segment completely is to just block SMB from entering or leaving an infected segment. While this would stop a Badlock based worm from spreading, it is far from foolproof. Malware already present on these machines could continue to present a risk in your network as a whole.
Some of this might seem unnecessary, but if Badlock turns out to be wormable, then an ounce of prevention on Monday will be worth a pound of cure on Tuesday and beyond. As always, if you need additional help or assistance in securing your network, contact Rendition Infosec (or email inquiry at renditioninfosec dot com) for help.
What does this mean? Does the vulnerability require authentication or can an anonymous user exploit it? This answer alone will help drive how dangerous the vulnerability is. Also, does remote code execution occur or is this simply a privilege escalation vulnerability? Privilege escalation would be bad, but remote core execution would mean that with anonymous access, Badlock could be wormable. Bad stuff for sure.
What will Badlock impact?
Badlock will impact both Windows and Samba both of which use the SMB protocol.
How long will it to develop an exploit after the patch is released?
This is unknown, but the developers imply that an exploit will be developed 'soon' after details are made public. You should assume the worst and spend some time on Monday getting ready (if you haven't already).
What can I do today?
Rendition Infosec has created a five step checklist for getting ready for Badlock before it hits next Tuesday. We are referring to this as our "quick win" action items.
1. Verify that SMB cannot leave your network. If the exploit is wormable you don't want to be part of the problem. SMB leaving the network is problematic for other reasons even if a Badlock worm doesn't emerge. On any Linux or OSX host, check to see if you can reach TCP ports 139 and 445 on smbcheck.rsec.us. If you get a banner, your network allows SMB outbound (no news is good news). Talk to your firewall admin and get this fixed at your border firewall.
Not sure if your border firewall allows TCP 139/445 outbound? Rendition Infosec has set up a server so you can check. Try these commands from any Linux server in your environment (or download a copy of netcat for Windows if you are so inclined):
nc smbcheck.rsec.us 139
nc smbcheck.rsec.us 445
If you get no output, you're good to go. If you see what I have displayed below, you've got problems:
jake$ nc smbcheck.rsec.us 139
DANGER! Your network allows TCP port 139 outbound. You should block this!
jake$ nc smbcheck.rsec.us 445
DANGER! Your network allows TCP port 445 outbound. You should block this!
3. Some of your network devices you never even think about will almost certainly be running SMB servers. These devices need to be patched, but patches for these will not be available next Tuesday and likely will take months to distribute. For those devices that you can disable SMB servers without breaking business functionality, do so.
For those devices that require SMB to be running, they probably only require access from a limited numbers of devices. Restrict these device communications using IP access control lists at your routers and layer 3 switches to limit exposure.
Finally, note that some devices may never receive updates. Samba 4.1 and below are out of patch maintenance, even for security fixes such as this.
4. Consider partitioning your network by using layer 3 ACLs to block TCP port 139 and 445 inbound to your client network segments. Private VLANs can be used to restrict client to client connections. Windows firewalls can be enabled to prevent the use of TCP 139 and 445 on client segments as well.
Many administrators hate to restrict their activities because of firewall use, but in this case it might be worth the pain. Firewall configurations can be updated via group policy, so manual intervention won't be required to remove these rules.
5. Identify points where network segments can be isolated in order to contain an outbreak. Determine who has the appropriate device permissions to isolate a portion of the network. Ensure that the appropriate personnel are available to act. Also determine in advance who has the authority to isolate portions of the network. You don't want to have a plan and then suffer from decision paralysis.
Isolating the network will almost certainly have adverse effects on business operations (how could it not), but these might be worth it to contain an outbreak of a worm. Discuss with business leaders under what conditions you would isolate network segments so the actions can be taken with minimal discussion while under fire. An alternative to isolating the network segment completely is to just block SMB from entering or leaving an infected segment. While this would stop a Badlock based worm from spreading, it is far from foolproof. Malware already present on these machines could continue to present a risk in your network as a whole.
Some of this might seem unnecessary, but if Badlock turns out to be wormable, then an ounce of prevention on Monday will be worth a pound of cure on Tuesday and beyond. As always, if you need additional help or assistance in securing your network, contact Rendition Infosec (or email inquiry at renditioninfosec dot com) for help.
Thank you Jake
ReplyDeleteSome ISPs block outbound NETBIOS so users of Comcast, Verizon might get a false sense of security.
ReplyDeleteI'm certainly not implying that just because you can't talk outbound on SMB that you're okay. But the ISPs are just taking on the responsibility for keeping others safe.
DeleteThis comment has been removed by a blog administrator.
ReplyDelete