Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Microsoft Security

Windows Remains Vulnerable To Serious 18-Year-Old SMB Security Flaw 171

Posted by samzenpus from the protect-ya-neck dept.
Mark Wilson writes A serious security hole leaves millions of Windows users open to attack, making it possible to extract encrypted credentials from a target machine. Researchers at Cylance say the problem affects "any Windows PC, tablet or server" (including Windows 10) and is a slight progression of the Redirect to SMB attack discovered by Aaron Spangler way back in 1997. Redirect to SMB is essentially a man-in-the-middle attack which involves taking control of a network connection. As the name suggests, victims are then redirected to a malicious SMB server which can extract usernames, domains and passwords. Cylance also reports that software from companies such as Adobe, Oracle and Symantec — including security and antivirus tools — are affected.
This discussion has been archived. No new comments can be posted.

Windows Remains Vulnerable To Serious 18-Year-Old SMB Security Flaw More

Windows Remains Vulnerable To Serious 18-Year-Old SMB Security Flaw

Comments Filter:

  • apparently this is how sony got hacked

    • Re: (Score:2)

      by ShaunC ( 203807 )

      I hadn't heard that for all the North Korea rabble-rousing and misdirection. Were there ever any real postmortem details? I remember seeing plenty of speculation, but none mentioning this attack; if the official report from Mandiant ever came out, it didn't cross my radar.

    • Re: (Score:3)

      by PRMan ( 959735 )
      Does anyone have a link for this?

    • Re:used devastatingly already (Score:5, Interesting)

      by fuzzyf ( 1129635 ) on Monday April 13, 2015 @05:50PM (#49466073)
      Man in the middle using SMB share. That requires someone to be on the local network to begin with.
      Could be used after pivoting, but not as a first foothold attack.

      • yes, they probably had inside help

        • I think a lot of people have forgotten that Stuxnext required someone on the inside who had access to the Iranian centrifuge lab to kick off the party. Cultivating that inside asset was probably harder, and definitely more dangerous, than engineering the virus.

          • yeah the technical aspects of an exploit are always interesting

            but a real devastating hack is always 90% boring and mundane social aspects

        • Re: (Score:1)

          by fuzzyf ( 1129635 )
          I would love to see some details about this.
          One would think that basic credential traversal would be the preferred method once inside. MITM redirection of SMB traffic would probably set of a few IDS alerts.

    • So you are saying it wasn't north korea as the US government has been claiming and it was actually someone on their local lan? where did you find this information?

      • Re: (Score:2)

        by cjb658 ( 1235986 )

        They would just need a VPN login, easily obtainable through phishing.

      • i *think* they had inside help, that's my own personal opinion, no source

        i don't know all the details of the tool, maybe they didn't have inside help but just a little social engineering for a few hours one day. or maybe even the sony security was so rotten, they could set it all up from the outside

        here's the article that mentions the attack:

        http://www.securityweek.com/ha... [securityweek.com]

      • Re: (Score:2)

        by dbIII ( 701233 )
        The North Korea distraction was late in the game and idiotic, but it did have the benefit that the stupid lie could be used as an excuse to get extra funding due to "cyberwar" threats instead of the normal criminal activity it very clearly was.
        If you fell for it and are not a source of funding for IT security then you are "collatoral damage".
    • Citation needed

  • Grammar (Score:1)

    by Anonymous Coward

    "Software...are affected"? Has samzenpus ever heard of a mass noun?

  • Wow, this *IS* old... (Score:5, Insightful)

    by rickb928 ( 945187 ) on Monday April 13, 2015 @04:57PM (#49465779) Homepage Journal

    IIRC, we discussed this in MSE classes, the same ones where the instructor assured us we need not register a domain name for our internal network (!), and agreed that despite the lack of information from Microsoft, It was worth it to block SMB ports from the public networks. As well as others, such as SQL Server (1433/1434 at a minimum), AD (135,389,5722, and the list goes on), and other services we need not expose to nor listen on for external traffic, we rapidly got to the point where the reasonably responsible admin blocked by default, opened only what was necessary, and then directed these to the proper hosts inside the network.

    This is slightly older than the Y2K bug. And still not really fixed? Microsoft's choices here have always come back to haunt them. NetDDE, OLE, the HTML viewers, and this, all making Outlook once the premier distribution method for viruses and all form of malware,

    Interprocess friendliness has its cost. Ease of use goes both ways. The crooks are happy to take advantage of your features.

    • Re: (Score:3, Interesting)

      by mmell ( 832646 )
      Yeah, but . . .

      Are there any Windows Administrators out there with I.Q.'s > 90 that knowingly and intentionally leave ports 137, 138, 139 and/or 445 open to the Intartubes?

      • I'm sure there are Windows Administrators who would leave those ports open. Hopefully you have Network Administrators who know enough to block by default and require justification to open ports.

      • Re: (Score:2)

        by dAzED1 ( 33635 )
        they should be able to - if Windows was worth the security targets it has bought.

      • Yeah, but . . .

        Are there any Windows Administrators out there with I.Q.'s > 90 that knowingly and intentionally leave ports 137, 138, 139 and/or 445 open to the Intartubes?

        If your Windows Admins are managing your firewalls, then you are in trouble... Usually it's either the network engineers or firewall Admins.

        This has been a non-issue for the simple fact that no one opens these ports to the Internet...

        • Re: (Score:1)

          by Gob Gob ( 306857 )

          If your Windows Admins are managing your firewalls, then you are in trouble... Usually it's either the network engineers or firewall Admins.

          It always strikes me as odd that people assume businesses have the resources to deploy "best practices" ~ aka having one specialist team member for every IT position (Net, Admin, DBA, analyst, help desk, etc). Most businesses (ie small / medium ones) can only scrape together the means to employ one person (if any) and hope they have the skills to keep the business applications running ~ pretty much _everything_ else is secondary.

          Does this "best practice" mantra attempt to coach SME's to do the right thing

      • Re: (Score:2, Insightful)

        by holostarr ( 2709675 )
        Yes there are! I personally know one at my company who is as a matter of fact very good at what he does and incredibly knowledgeable. Your assumption that Microsoft products somehow attracts idiots more than other products is stupid.
        • Re-read and try again. Better still, make yourself feel better and just remove the word "Windows" from the S/A description. The statement still works both as written and as intended (because there are sysadmins out there with I.Q.'s below 90, and not all of them are Windows admins).

          Feel better?

      • Re: (Score:3)

        by XanC ( 644172 )

        Last year I signed up for a dedicated server, and discovered that the provider's VPN server and their control panel server had Windows file sharing and remote desktop ports open to the world! And they wouldn't give me a refund. Losses cut and lesson learned...

        • Re: (Score:2)

          by XanC ( 644172 )

          Oh I should also point out that they didn't use HTTPS for anything. Logging in to your account and everything was entirely HTTP. "Reliable Site" my ass...

          • I'm sure that the crackers who took over those machines found them to be very reliable.
          • I agree with the AC. When a webhost does this type of thing they need to be named and shamed so those of us currently in search of a good managed dedicated server for a client can mark these guys off our list. Also, how much money are you out? Did you pay for a whole year for a new host, or did you do the smarter route and only did month to month for the first year or two as you verified their security and stability?

            • Re: (Score:2)

              by XanC ( 644172 )

              It was ReliableSite.net. I tried to name them earlier but was too subtle. :-)

              I was only out a month's worth, fortunately.

          • Name and shame.

      • Re: (Score:3, Interesting)

        by Gumbercules!! ( 1158841 )
        Yeah sadly, there's heaps of them. People who connect their Windows machine to the internet by establishing the PPPoE session from the machine, for one. People who rent a VM from a cloud provider and just get a straight up Windows box with no firewall, for two. If you think there's not a lot of those, believe me, there are. We run a cloud computing company and we frequently (ok, by frequently I mean a few times a year, I suppose - but we're just one company) get requests for people to have a Windows box wit

        • Re: (Score:2)

          by Bert64 ( 520050 )

          Requiring a firewall is another poor design decision... You should be able to turn all these services off, but windows makes it extremely difficult to disable the default listening services and the recommendation is to hide them behind a firewall... If the system still runs with the services hidden so that noone can connect to them, then why exactly do they need to be listening at all?

        • Re: (Score:2)

          by mvdwege ( 243851 )

          As a service provider, I am not sure how to handle this because, technically, it's "their server".

          On the other hand 'their' server has to share a network with other servers. If they refuse to use best current security practices, their server will start interfering with other servers.

          So the answer is: don't sell them unsecured VMs. If they can't take the above argument and insist, at least charge them more based on the fact that you will have to clean up the mess eventually. And if you have many such custome

    • Re: (Score:2)

      by dbIII ( 701233 )

      and other services we need not expose to nor listen on

      That's *nix (or any other) firewalling 101. The instructor was probably not addressing any individual known threat but the general idea that you don't let the outside world touch ports for internal use just in case something can get in some day.

      • I shouldn't have left the impression that this instructor taught us to block but default. At that time MCSE didn't teach that. And he didn't either. We all discussed it over coffee among other things, like the stupidity of naming your intranet 'msft.net'. That was taught at one time.

        • Re: (Score:2)

          by dbIII ( 701233 )
          Fair enough. I've been known to block the ports listening to SMB stuff at various points in internal networks just to make sure that the wrong thing doesn't answer when called. Printing stuff out three buildings away on a different subnet is funny the first time but then gets a bit old.
          "If it's not expecting traffic on that port on that interface then block it" always seemed like a simple way to start to me.

          • That's a permissions problem. Users in one building shouldn't have permission to use printers in another.

            Groups are your friend.

            • Re: (Score:2)

              by dbIII ( 701233 )
              Yes I know that and I also had users that moved about the campus and logged on in machines sitting in other buildings. Limiting by location of machine is a better friend :)

    • Re: (Score:2)

      by Bert64 ( 520050 )

      The problem is poor design and inertia... It's not like a simple bug which can be fixed without changing how the software works, there are many design flaws in the protocol itself and fixing them would require incompatible changes. If you're going to drop current windows versions and go to an incompatible system, might as well go straight to linux.

    • Comment removed based on user account deletion

  • It requires a man in the middle attack on traffic that should never go across the internet outside a vpn. Yes it's a problem but not exactly a significant one for a well put together network.

    • My understanding is that this exploit simply requires you to have outbound SMB ports open.
       
      In my experience, most firewall setups (especially those in companies who don't have dedicated IT staff) allow unrestricted outbound communications.

      • Why on earth would any competent IT staff have SMB open outbound? If at all possible desktops should not be allowed to make direct connections to anything outside in a corp network.

        • Re: (Score:1)

          by Gr8Apes ( 679165 )
          The better question is why would any competent IT staff have any SMB services installed or allowed?
          • Perhaps because it's standard for both Windows and OSX workstations? In a multi-platform network SMB is often the best choice for filesharing. If it's setup properly (NTLMv2 only, SSL encrypted, SMB message signing turned on) it's actually pretty reasonable security wise.

            • Re: (Score:2)

              by Bert64 ( 520050 )

              The problem is that SMB is not just a filesharing protocol, it provides access to whole heaps of other functionality at least on windows. If all you want to do is file sharing then SMB is a terrible choice.

              • Well AFP is horrible and NFS isn't exactly fully supported cross platform, that doesn't leave a lot of options.

                • Re: (Score:1)

                  by Gr8Apes ( 679165 )

                  try scp or rsync sometime: fully supported by all operating systems that try to be secure. Oh, you meant "GUI" access, in that case, use a web based service [fromdev.com] that allows directory views and uploads. Or use some dropbox like enterprise solution [aerofs.com]. In any case SMB is a terrible terrible solution. None of my *nix based boxes run it.

                  Disclaimer: I use scp and rsync - I have not used any of the other solutions.

                  • SCP and rsync are file transfer protocols not file sharing protocols, they don't work nearly the same. Perhaps your solution works for a single developer's workstation or a small technology startup but it's not going to scale to a large business with many employees, most of whom do not work in IT.

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      Hence the reference to an enterprise solution, one that is targeted to windows even. Pretty much everything is better than the insecure disaster known as SMB.... and if you think those alternatives are "bad", then blame MS for foisting the horrors of insecure and crappy SMB on the masses.

                      I believe "Just because you can doesn't mean you should" applies to all facets of SMB like playing with frightened skunks (with similar results for those slow on the relationship)

              • Re: (Score:2)

                by jp10558 ( 748604 )

                I'd love to know the better solution for Mac, Windows and Linux access to network shares, and the network shares have to be performant, local (i.e no cloud sync), not require paid software, and support several tens of terabytes per shared filesystem. Oh, and use Active Directory permissions...

                • Re: (Score:1)

                  by Gr8Apes ( 679165 )

                  So there's your problem - you want this polished turd because it's all shiny, but it's still a turd. You never wondered why it's free? You will have to pay to get one of the secure ones if the host of other free solutions [slashdot.org] are not to your liking.

                  The real question with disk space being so damn cheap is why would you want a "performant, local" network share anyways with AD permissions to boot on 10s of TBs per FS? That sounds more like a content management system that you've co-opted SMB to do, and it is whol

                  • Re: (Score:2)

                    by jp10558 ( 748604 )

                    Honestly, I'm not sure if you're a troll, or just someone who strongly believes if you don't do it your way, you're wrong.

                    I'm working in a research institution. We have limited funding from grants. We are doing X-Ray research, with detectors that output data on the order of 30GB a run, and there can be more than one run a day. This data, once generated, needs to be accessible by compute nodes, without hitting the acquisition disk. There isn't reliable down time between acquisitions, so rsyncs are hard to sc

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      Honestly, I'm not sure if you're a troll, or just someone who strongly believes if you don't do it your way, you're wrong.

                      Fortunately, I'm neither. I will, however, point out when something's just "wrong". (I know, it's easy to be a critic)

                      I'm working in a research institution. We have limited funding from grants. We are doing X-Ray research, with detectors that output data on the order of 30GB a run, and there can be more than one run a day....

                      So you have bounded the binary data problem, 30GB data sets with multiple sets generated a day. You also state that the acquisition disks cannot be hit while it's running. You don't state whether you can use a SAN, which would be your best technical option, although does cost some money but allows for processing, redundancy, backups, and offloading. The next best option would be a NAS system

                    • Re: (Score:2)

                      by jp10558 ( 748604 )

                      Well, there's the experimental data, and then the administrative data. Those word docs need to be shared, backed up, etc. The various matlab and labview files need to be accessible from Sun Grid Engine nodes and local Windows, Scientific Linux and Mac OSX workstations.

                      We currently use a RedHat HA cluster that provides NFS and CIFS / SMB access to disk stored on iSCSI devices. So sort of a home build SAN I guess. We looked into better known commercial offerings, but basically they were 10x our budget. Unlike

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )
                      So your problem is really 2-fold:
                      • You are being asked to deliver diamond jewelry with a glass budget
                      • You cannot change anything about your users

                      I'd state the second is false, as you're forcing them into a windows environment, and, unless things have changed, many of those folks have used *nix flavors as well. Of course, you're stuck with the MS Office disease, which probably still has 10 years left before it clears up.

                      Given your constraints and situation and where you are, I don't believe any obviously

                    • Re: (Score:2)

                      by jp10558 ( 748604 )

                      Oh, I'm not forcing anyone into a Windows environment. I strongly push them towards Linux and tell them it's the preferred environment at the lab, and all our infrastructure is Linux based. We just wanted to set up a data download station, and suggested Linux, but were told the external users aren't familar with Linux (I don't know how they run the experiment, where lots of it is based on Linux, but hey, not something I get to change), and will need Windows there.

                      We have plenty of Labview stuff which I'm to

  • Windows file-sharing on home machines has pretty much always been terrible. It's like a bunch of monkeys put it together. I am guessing they tasked one or two guys to add it to home machines when the bulk of a group was working on corporate file sharing (which is at least a bit more reliable), and the result was just a really bad design and code that has been sitting around the kernel forever. Getting two machines to talk to each other over an Ethernet cable has always been much harder than in linux. (I

  • original paper here (Score:3, Informative)

    by Anonymous Coward on Monday April 13, 2015 @05:58PM (#49466121)

    original paper here: http://cdn2.hubspot.net/hubfs/270968/SPEAR/RedirectToSMB_public_whitepaper.pdf

    How hard is it to mandate any submission contain the source instead of some shill article?

  • Ceterum censeo (Score:4, Funny)

    by TeknoHog ( 164938 ) on Monday April 13, 2015 @06:05PM (#49466145) Homepage Journal
    I remain vulnerable to serious 18 year olds, if you catch my drift.

  • Wish this were new or news (Score:3)

    by WaffleMonster ( 969671 ) on Monday April 13, 2015 @06:23PM (#49466229)

    I don't know how or why it came to this. The world is hooked on insecure authentication protocols. NTLMv2, Kerberos, plaintext, plaintext over encrypted tunnel protected by group secrets (sigh..) or certificates and dull thud of every flawed permutation of a challenge handshake system imaginable.

    These things are employed virtually everywhere and the consequences are visible everywhere.

    Haha I tricked you or your computer into connecting to my file system or my fake bank or my fake web site and because of that I now have your credentials and your f*****d.

    Living with consequences has become so routine and institutionalized some find it difficult to see the problem at all ... instead resorting to blaming failure of a castle defense or operating in an unsafe environment rather than notice the root cause of the problem - broken authentication systems.

    When the most widely deployed use of a secure authentication protocol is protecting an online role playing game I have no interest in Microsoft's (And all other vendors) lame excuses for not fixing these problems decades ago.

  • Article one giant spew of hyperbole (Score:5, Informative)

    by laughingskeptic ( 1004414 ) on Monday April 13, 2015 @06:24PM (#49466237)
    The article states "the encryption method used was devised in 1998 and is weak by today’s standards ... Microsoft has yet to release a patch to fix the Redirect to SMB vulnerability" as if Microsoft must remove the feature in order for Cylance to consider this resolved. Instead a number of improvements have been made to SMB since 1998 include support for HMAC-SHA256 (v2.0) and AES-CMAC (v3.0) hashing. http://www.windowsecurity.com/... [windowsecurity.com]. You are going need a little more than "$3000 worth of GPUs" to forward brute force the AES-CMAC hashed passwords.

    • Re: (Score:1)

      by Tablizer ( 95088 )

      There may be a good reason MS left some of it in place. Anybody want to offer speculation?

    • The article states "the encryption method used was devised in 1998 and is weak by todayâ(TM)s standards ... Microsoft has yet to release a patch to fix the Redirect to SMB vulnerability" as if Microsoft must remove the feature in order for Cylance to consider this resolved. Instead a number of improvements have been made to SMB since 1998 include support for HMAC-SHA256 (v2.0) and AES-CMAC (v3.0) hashing.

      When faced with claims of security it is necessary to fully understand the underlying basis of trust without which security is a mirage.

      What is the mechanism by which one system or user authenticates the identity of another system or user and why is this process trustworthy?

      Without secure authentication and proper binding encryption by itself is useless.

      You are going need a little more than "$3000 worth of GPUs" to forward brute force the AES-CMAC hashed passwords.

      How are the key parameters to AES and HMACs derived? If an attacker can figure that out then a whopping $0 worth of GPUs will suffice.

      So how about it... w

    • Although SMB has been improved to now include AES-CMAC (on Win8/2012) the underlying hashing algorithm used for authentication is still based on LM, NTLMv1, or NTLMv2. Whilst the channel between a client and a server can be encrypted, if you can man-in-the-middle a HTTP connection and redirect it to SMB you are able to set the version of SMB and encryption level used and obtain the authentication details.

      • Although SMB has been improved to now include AES-CMAC (on Win8/2012) the underlying hashing algorithm used for authentication is still based on LM, NTLMv1, or NTLMv2.

        Only Windows Server 2003 and below will accept LM/NTLMv1 by default, which means as far as supported systems only 2003, and it is EOL July 14, 2015. You'd have to be desperate to still be running any 2003, and if you were you can disable LM/NTLMv1 via GPO. Vista/2008 and above will only accept NTLMv2 responses.

        • Only Windows Server 2003 and below will accept LM/NTLMv1 by default, which means as far as supported systems only 2003, and it is EOL July 14, 2015. You'd have to be desperate to still be running any 2003, and if you were you can disable LM/NTLMv1 via GPO. Vista/2008 and above will only accept NTLMv2 responses.

          NTLMv2 is broke too.

          • NTLMv2 is broke too.

            NTLMv2 isn't broken, but it definitely isn't as good (secure or featureful) as Kerberos, which is why Windows uses Kerberos by default. If you're in a domain, then Windows will only fall back to NTLMv2 for SMB if you do something that would prevent a Kerberos ticket from being verified (like access an SMB share by IP instead of name). It's really just a simpler fallback mechanism now. You could prevent that by requiring signing for all SMB connections, which I believe is only enabled by default on domain

            • NTLMv2 isn't broken, but it definitely isn't as good which is why Windows uses Kerberos by default.

              Both NTLMv2 and Kerberos are broken because an attacker is able to conduct offline brute force attacks against credentials simply by observing challenge/response communication between client and server.

              This constitutes an unacceptable risk because the vast majority of users do not use passwords with sufficient entropy to withstand an offline as attack conducted by modern, distributed and specialized hardware. In the end your looking at an easy >90% success rate against most targets vs guaranteed 100% ra

  • Forget those 0 day attacks you've heard so much about. the 6575 day attacks are the real problem!

  • ... on the Windows side. Too much stuff would break if you had to approve every server connection.

    The applications that are providing the attack vector might be fixable. It isn't really a good thing for a remote attacker to be able to get your machine to try to open a file, especially a remote one. The main problem, from the sounds of it, is the sheer number of applications affected.

    Reminiscent of DLL hijacking attacks, really.

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Close