They have had several remote code execution vulnerabilities lately (summer 2018). While they were very quick to patch them they did not notify their customers in any way. There was nothing on their website that said anything about the urgency.
Instead of reusing functionality that exists in the router already (ssh?), the authentication for winbox is something they built themselves. It was in the winbox auth that the main security flaw was. It just looked really bad to me.
The winbox client also downloads and runs any DLL that is sent by the winbox server. The winbox client has a windows certificate so all it's code is trusted. So own the router and you get the admins workstation too.
It just feels like maybe they hired some random guy without much appreciation for security for doing winbox.
The SMB server also had a rce a while ago.
That said, I guess that if you disable winbox and stuff that should not face the internet, you are probably safe?
This is a good example of the antiquated security model we need to put firmly in the past. If you’re depending on Linux’s privileged port mechanism to protect your Windows boxes, many things have already failed:
1. Your network should be segmented and authenticated: a Linux box listening on port 445 shouldn’t matter because it’s not in a network group which receives that.
2. Your Windows boxes should have their firewalls enabled since they shouldn’t normally be making SMB connections to your Linux servers.
3. Your Linux boxes should have their firewalls configured.
4. Your Windows boxes shouldn’t be accepting requests from strangers to connect over SMB.
Another way to think about it: if there’s a major Windows vulnerability, is it more likely that it’ll be attacked by a Linux box or someone in accounting clicking on the wrong PDF? Ultimately you just can’t trust the client - the percentage of times where someone can run code on your Linux box but can’t get root or attack something on a different port is just not enough to rely on for anything. Since you already know you need to protect against those other things, just focus on doing that.
"Regarding Samba/SMB (...) 79% (1424) has weak or no authentication, which means that anyone could access the files in these servers without any username or password, e.g., critical business information or private financial records."
Companies still miss the basic security configurations, and then they are surprised they were "hacked".
That's a good point, because in the example we can clearly see how to check if a system is or not patched and that, using this attack, we can crash a Windows Server.
The remote execution part is completely missing (fortunately), but I was wondering if this gives the admin rights on machine (I have absolutely no experience on Windows Server machines, so I don't know how it works in terms of services, permissions and roles).
What's the reason to use these boxes? "Nobody ever got fired for buying IBM"? It seems that vulnerabilities are much more common than in the platform VPN (ipsec/ssh/openvpn etc) implementations shipping in server operating systems, why not just just terminate at a server box?
The irony of this is SMB servers are often setup with insecure configs exactly because it's so rarely used over public networks. Too many people assume public networks will be their Maginot Line against SMB attacks.
It doesn't sound like it. Even our production servers hosted by a "rackspace" company have outgoing ports closed by default, we earn a tiny amount compared to RSA.
I know there will be reasons but honestly, the server should have been air-gapped or something. I can't imagine they need changing very often so why not copy it across the gap on a USB stick when you need it and leave it non-networked otherwise?
Of course, I know nothing about this organisation, it just sounds weird that a system that was so crucial was so vulnerable.
Because it's a disposable server running in an isolated VM that I need for one reason only and even if someone does break in(impossible with these random logins, and I assume RDP doesn't have any currently known security faults) then it wouldn't be the end of the world - I have a notification on successful login so I'd be told if it ever happened and I would just kill the VM instantly. Right now it's exposed to the internet for simplicity sake.
Indeed. But the view of the NetSec team is that you server is not trusted to secure itself.
If every service in your ecosystem implemented ipfw rules (or equivalent) then that's great. But if your box got popped, then can I be sure that it won't be used as an attack vector for other machines? I will turn off the ipfw ruleset locally, and start connecting out to other systems. If there was a firewall sitting there between me and other systems, this would hit rules that should never be hit, resulting in the NetSec team getting some alerts.
Now I believe, like most sane people, that if you've popped an appserver, it's already likely to be game over, and this is a moot point.
For most applications, the app server doesn't live in its own little DMZ, and usually does have privileged access to the DB, often shares the same authentication domain as other services which is not properly secured (e.g. your [backup|log|monitoring|deployment] server connects to every machine with a service account, not SSH protected, and now I have the service account for all machines).
You wouldn't be foolish enough to have mixed admin functions (content management?), and user functions on the same app server... right? Right? Oh... wait... almost everyone does that.
Thats true and it goes for dedicated servers and colo'd servers as well in some cases. The issue here isnt outrage about a host having access to your box, which almost all of them do anyways(IPMI, Root Disks, etc..) - but that they used his password to do it and without asking him.
He means that SMB is not a secure protocol and can't be run securely over an untrusted network at all. Vulnerabilities within a private network are a different class of problem. Obviously you should upgrade/patch and pull the fix. But if (say) the operation of your 20-person company depends on a live Samba instance, you might logically make the decision to leave it unpatched on your internal network for a day or so until you have time to test the upgrade.
And the company doesn't even have to be actively hostile for remote to be risky.
The company could go out of business and shut down their servers. Or shut down the servers because they're no longer selling the product.
Sometimes incompetence is as bad or worse than malice. The company could break an API accidentally. Or the API only works intermittently. Or they could add poorly-implemented rate limiting that unintentionally affects multiple users when they share an IP via NAT.
How underwhelming was this announcement? If you have internet-facing or dmz'd smbd servers you deserve badlock and have no doubt been facing far greater security risks since the time when you initially put your server there. This announcement isn't scary at all for those whom considered or valued literally any sense of security when setting up their Samba server.
Assuming your software is fairly up to date and/or you haven't badly misconfigured it, they're not gonna do anything. There are a ton of routers and IoT devices that are a much easier catch than a machine run by someone that actually gave a thought or two about securing their server.
Yeah, the hard part is when you do not control the server, so you need to tell your customer to contact their costing and fix the issue, sometimes we got the id of the security rule that triggered the issue but not all the time.
A lot of stuff is hosted on compromised sites or devices - which are often running some insecure admin interface on an odd port. Very rare in my experience that someone would spin up a new web server on a box they’ve popped.
A colleague noticed about 2 weeks ago that instead of 10 or so hosts in his list on the teamviewer website had suddenly grown to 600+ hosts - I witnessed this, and told him he should contact teamviewer. Shortly after this someone tried to take control of his brother's machine.
We use teamviewer host and haven't seen anyone trying to log in, but I'd rather not take the chance and have removed the software from all our machines. If we need to remote assist someone, they can run the software manually.
Having the ability to remote connect and repair problems is great, but when there is the remotest (pun intended) chance that it can be used nefariously then I'd rather limit the threat.
Instead of reusing functionality that exists in the router already (ssh?), the authentication for winbox is something they built themselves. It was in the winbox auth that the main security flaw was. It just looked really bad to me.
The winbox client also downloads and runs any DLL that is sent by the winbox server. The winbox client has a windows certificate so all it's code is trusted. So own the router and you get the admins workstation too.
It just feels like maybe they hired some random guy without much appreciation for security for doing winbox.
The SMB server also had a rce a while ago.
That said, I guess that if you disable winbox and stuff that should not face the internet, you are probably safe?
Too much for me though. I would not feel safe.
reply