wrote:
I've only heard it can infect Windows XP and newer versions of Windows.
What about Win98, or Win95, WinME, or Windows 2000?
Anyone know?
There's the bulletin, but it's not going to
care about older OSes. Notice that Microsoft has patched
WinXP, but it doesn't get an entry here (because WinXP is
out of support). I don't know whether WePOS would be documented
in one of these or not.
https://technet.microsoft.com/en-us/.../ms17-010.aspx
*******
https://www.reddit.com/r/sysadmin/co...ut_that_scans/
Of which one tool is listed as:
https://github.com/topranks/MS17-010_SUBNET
You can then open the Python source for a look. This is
so you can review how they're testing.
https://github.com/topranks/MS17-010...mb_ms17_010.py
Note the mis-spellings in the source. And we all know
what that means. Needs a spell checker :-)
The source appears to be crafting a DoublePulsar exploit of
sorts and looking for a characteristic response. So my
presumption is, that test does *more* than just check
for an open port 445, it actually attempts to use the
vulnerability in some way. Which in theory could tell
you if a Win98 box was vulnerable.
The hardest part of using Python, is sorting out the
versions. I'm not a Python jockey and cannot guess
whether that'll run on some other version of Python
you happen to have.
So that program would appear to be tickling each system
in the appropriate spot, rather than just checking
whether port 445 is open.
You can also try "DoublePulsar smbv1" in a Google search,
but be careful with what turns up. Using a scanning tool
that scans from the *WAN* side of your LAN, doesn't tell
much of a story (can't punch through your stateful IPv4
NAT router). You want to scan the LAN side. Like use
one of your LAN machines, to check the rest of them. Perhaps
you can scan the scanning machine itself using 127.0.0.1
as the IP address ? That's if you don't want to have to
set up Python on a second machine.
*******
OK, I did the best I could to test it.
+-------------------+ +---------------------------------------
| WinXP Host | --- | LinuxMint 18.1 scanning machine
| 192.168.2.100 | | python2 smb_ms17_010.py 127.0.0.1
| | python2 smb_ms17_010.py 192.168.2.100
| +--------------+ | python2 smb_ms17_010.py 192.168.2.110
| | VPC2007
| | Win98SE
| | Guest
| | 192.168.2.110
This is the result:
https://s3.postimg.org/v6jnzsj9f/scan.gif
127.0.0.1 Errno 111 Connection refused (Linux scans itself, Samba server
not running on default LiveCD bootup
so port 445 is not open.)
192.168.2.100 VULNERABLE (Windows 5.1) (An unpatched WinXP SP3 machine)
192.168.2.110 Errno 111 Connection refused (The Win98SE virtual machine)
I tested the Win98SE VM twice. The first call was
before the Linux box *mounted* the Win98SE share.
The second call was after the Win98SE share
was successfully mounted (presumably by SMBv1
protocol). So while SMB seemed to be working
from the Linux test machine to the Win98SE serving
side, the DoublePulsar test didn't trip off.
That's not a definitive test (because the Win98SE
was inside a VM, and you could argue "it's not the same"),
but I was able to mount the share the Win98SE machine
provides to the world. That share is completely
insecure by the way. The MINT machine doesn't even
present a password box when it touches that. If the
MINT (test) machine tries for a share on WinXP,
the usual boring password box appears, and I have
to log in.
For the exploit to work, the password doesn't matter.
WinXP SP3 could be tipped over, with the right payload
sent. That's what VULNERABLE means. If WannaCrypt gets
loose in my LAN, the WinXP SP3 machine could get "wormed".
I removed the WinXP patch on purpose (4012598). For the
Win98SE machine to get tipped over, some better
code would be needed at a guess. You can never really
be sure how many vulnerabilities are out there, and
this one test doesn't prove Win98 is "bulletproof",
merely "inconvenient to attack". So maybe we can
rate Win98 as "security by obscurity". Only Microsoft
knows the true situation, and they don't really have
an incentive to even speak the word "Win98" any more.
Paul