If you're interested in reading more about the current Windows worm/ransomware, these two sites have brief articles explaining what's up.
http://blog.talosintelligence.com/2017/05/wannacry.html
https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-wide...
Note that they recommend blocking ports 139 and 445 to help prevent the spread of the worm infection. Amprgw has been blocking those ports for quite some time, but that doesn't prevent the infection from spreading within a group of computers or an organization. It is strongly suggested that people running Windows should be sure that all issued patches have been applied.
As usual, systems running non-Windows OS's (Linux, etc) are immune to this attack. - Brian
IM not sure that this is the right group but as i wrote before here we have top experts in it field so Ill try
I read the explain on the virus in the sites ...
The domain is well known .. someone pay for it
is it so problem to catch the person who paid for this domain ???
what about shutting out this domain and by that stop the spread of the software ?
________________________________
http://blog.talosintelligence.com/2017/05/wannacry.html [https://4.bp.blogspot.com/-nDcKns-tCMg/WRYv1PfUO_I/AAAAAAAAA_Q/ZWhZcAtqCYsx-...]http://blog.talosintelligence.com/2017/05/wannacry.html
Player 3 Has Entered the Game: Say Hello to 'WannaCry'http://blog.talosintelligence.com/2017/05/wannacry.html blog.talosintelligence.com A blog about the world class Intelligence Group, Talos, Cisco's Intelligence Group
https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-wide... WannaCry ransomware used in widespread attacks all over the world - Securelisthttps://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-widespread-attacks-all-over-the-world/ securelist.com Earlier today, our products detected and successfully blocked a large number of ransomware attacks around the world. In these attacks, data is encrypted with
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
It is not that easy unfortunately. You can hide your a** when you register a domain. Vpn/tor/ etc and use stolen credit cards to do so. Also, the virus is in the wild and self replicating and infecting others. Infection does not only come from the origin domain, but also from every other infected computer which will scan it's networks for other windows computers and try to exploit and infect those..
Ruben - ON3RVH
On 13 May 2017, at 06:53, R P ronenp@hotmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ IM not sure that this is the right group but as i wrote before here we have top experts in it field so Ill try
I read the explain on the virus in the sites ...
The domain is well known .. someone pay for it
is it so problem to catch the person who paid for this domain ???
what about shutting out this domain and by that stop the spread of the software ?
http://blog.talosintelligence.com/2017/05/wannacry.html [https://4.bp.blogspot.com/-nDcKns-tCMg/WRYv1PfUO_I/AAAAAAAAA_Q/ZWhZcAtqCYsx-...]http://blog.talosintelligence.com/2017/05/wannacry.html
Player 3 Has Entered the Game: Say Hello to 'WannaCry'http://blog.talosintelligence.com/2017/05/wannacry.html blog.talosintelligence.com A blog about the world class Intelligence Group, Talos, Cisco's Intelligence Group
https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-wide... WannaCry ransomware used in widespread attacks all over the world - Securelisthttps://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-widespread-attacks-all-over-the-world/ securelist.com Earlier today, our products detected and successfully blocked a large number of ransomware attacks around the world. In these attacks, data is encrypted with
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 13 May 2017, at 03:23, Brian Kantor Brian@UCSD.Edu wrote:
Note that they recommend blocking ports 139 and 445 to help prevent the spread of the worm infection. Amprgw has been blocking those ports for quite some time, but that doesn't prevent the infection from spreading within a group of computers or an organization. It is strongly suggested that people running Windows should be sure that all issued patches have been applied.
Blocking 139 and 445 would prevent the direct propagation between nodes with direct connection, not using NAT.
Almost all of the affected networks are behind NAT. It takes just one user to open an attachment, visit a web page included in a spam or, say, plugging a hostile memory stick to have one compromised computer attacking the internal network.
Local area networks are usually flat. Most network hardware doesn't have the capability to apply usable port filters, and even that is hard to manage.
And even if preventing p2p local traffic would have helped, guess what the affected organizations are using in their servers? Yes, the same OS.
This is actually pretty similar to the worm incidents in the early 2000s. At some point it took like 5 minutes for a freshly connected computer to get infected. But this time the crazy spread has happened within local networks.
There are several already known lessons. Unfortunately the measures are really complicated to deploy.
And the elephant in the room is: is it still reasonable for a software maker whose products are ubiquitous thanks t illegal monopoly actions to avert responsibility?
Patches are often applied late because it's not rare to experience serious disruption. Anyway the software being patched is poorly made in the first place. The problems caused by patches are actually another sign of very poor software design.
To make it worse, monoculture has always been a really bad idea. Diversity helps.
And of course I don't know what the idiots of the US government agencies have in mind. One of the three letter agencies has reportedly been hoarding serious security bugs with the hope of exploiting them. Maybe this has been useful to them, but they are severely hurting users in their own country and allied countries. Moreover, how do I know that Microsoft or Apple haven't been helping the US government in some way?
I am very wary of Chinese software (if only because it's really atrocious!) but the doomsday scenarios I imagined coming from products controlled by the Chinese government are actually coming from US companies.
Borja - EA2EKH
On 13 May 2017, at 03:23, Brian Kantor Brian@UCSD.Edu wrote:
As usual, systems running non-Windows OS's (Linux, etc) are immune to this attack.
Sorry, I forgot. This is going to be very interesting with IPv6 and the disappearance of NAT.
Borja.
Even with v6 it is still standard and recommended procedure to block inbound (and outbound) smb/cifs at the border routers
Ruben - ON3RVH
On 13 May 2017, at 13:10, "ea2ekh@gmail.com" ea2ekh@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 13 May 2017, at 03:23, Brian Kantor Brian@UCSD.Edu wrote:
As usual, systems running non-Windows OS's (Linux, etc) are immune to this attack.
Sorry, I forgot. This is going to be very interesting with IPv6 and the disappearance of NAT.
Borja.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
It seems to me that with the growing popularity of IPv6-connected hosts, it's even MORE important to block those ports, as those hosts no longer have even the small protection of NAT gateways. - Brian
On Sat, May 13, 2017 at 11:36:21AM +0000, Ruben ON3RVH wrote:
Even with v6 it is still standard and recommended procedure to block inbound (and outbound) smb/cifs at the border routers Ruben - ON3RVH
On 13 May 2017, at 13:36, Ruben ON3RVH on3rvh@on3rvh.be wrote:
(Please trim inclusions from previous messages) _______________________________________________ Even with v6 it is still standard and recommended procedure to block inbound (and outbound) smb/cifs at the border routers
Of course, but I'm talking abot the general case, not just blocking of certain, known-bad protocols.
A situation without NAT is vastly different. A misconfigued NAT shouldn't result in an exposed internal network. You need *positive action* in order to direct incoming connections to certain internal hosts. Actually the vast majority of installations of commercial firewalls just employ them as simple NAT routers, go figure!
With IPv6 you need *positive action* to restrict them. The failure mode is completely different (and indeed more dangerous). Not speaking just of our AS, but, how many hotel/airport/railway WiFi access will you expect to be properly configured, if any? What happens with a software bug making traffic bypass the filter?
With IPv4 and the lack of a biunivocal correspondence you have what I like to call "a priori" protection. With no NAT, however, you need "a posteriori" protection, that is, adding some protection measures.
Last month I gave a talk in our Esnog conference (our Spanish femto-NANOG) proposing that privacy enhanced SLAAC IPv6 addresses shouldn't listen on the IPv6 equivalent of INADDR_ANY by default. Otherwise it can have really bad consequences.
As I said, it's going to be very interesting.
Borja.
On 13/05/2017 9:09 PM, ea2ekh@gmail.com wrote:
Sorry, I forgot. This is going to be very interesting with IPv6 and the disappearance of NAT.
Actually, a lot of routers block all inbound traffic by default, so the situation shouldn't change too much. Scanning my IP will be too inefficient with IPv6 as well, because the address space is vast, and the majority of IPs in a given network are unused. Will be interesting to see how malware adapts.
On 13 May 2017, at 13:54, Tony Langdon vk3jed@vkradio.com wrote:
Actually, a lot of routers block all inbound traffic by default, so the situation shouldn't change too much. Scanning my IP will be too inefficient with IPv6 as well, because the address space is vast, and the majority of IPs in a given network are unused. Will be interesting to see how malware adapts.
Let me show you a practical example :)
Imagine that you are sitting behind a misconfigured IPv6 router which doesn't block incoming connection. A hotel hotspot for example. I guess it's going to be commonplace.
Now, you are visiting a website. Thanks to RFC4941 your computer has a temporary IPv6 address used for the purpose of originating outgoing connections. That address, moreover, doesn't have any identifying information.
So, you visit the website. The website uses an advertising system that of course wants to track you. You are using "private" settings in your browser so that it doesn't store cookies or website data. However, you happen to have your trusty ssh daemon listening. Which is not unusual. Who hasn't forgotten to disable it now and then?
Now, the advertiser tries to connect to your ssh daemon. Finding it with a scan wouldn's be feasible, of course, there are too many addresses to try. But you have revealed it by visiting the website and, hence, downloading an ad from the dodgy ad server. The dodgy ad server knows your IPv6 address and connects back. Your ssh server offers a public host key, which is indeed an identifiable data. They will know that you are the same user who visited yesterday from the airport in another city.
I like to compare IPv4 to land war (you are protected behind a strong defense) and IPv6 to maritime war. Finding you beyond the horizon can be really difficult unless you reveal yourself by turning on the radar (ie, visiting that website, joining a file sharing p2p network, sending an email through a provider that displays all the IP addresses in the mail headers, whatever).
There is a simple solution to this. Programs listening on INADDR_ANY shouldn't receive incoming connections by default, so daemons such as ssh or whatever you have there running shouldn't receive it unless specified by the programmer (it can be important in certain cases).
But for now your temporary addresses are treated like, well, IPv6 address by all the OSs I have tried. So your ssh is listening on all of them ;)
Borja.
On 13/05/2017 10:05 PM, Borja Marcos wrote:
Let me show you a practical example :)
Imagine that you are sitting behind a misconfigured IPv6 router which doesn't block incoming connection. A hotel hotspot for example. I guess it's going to be commonplace.
Yes, I can see your example. Fortunately, one thing I have seen so far is routers being supplied with all inbound connections stopped. Furthermore, mine doesn't allow you to totally disable the firewall, only for specific hosts (which I have done for some key Linux systems), or for specific ports on specific hosts (which I did on Windows for testing - I never leave Windows exposed to the net). Now with a router like mine, your scenario wouldn't work, because the temporary IP addresses would never be allowed to pass.
So, there are ways to build it into the router design to make it harder for people to shoot themselves in the foot. :)
On Sat, 13 May 2017, ea2ekh@gmail.com wrote:
On 13 May 2017, at 03:23, Brian Kantor Brian@UCSD.Edu wrote:
As usual, systems running non-Windows OS's (Linux, etc) are immune to this attack.
Sorry, I forgot. This is going to be very interesting with IPv6 and the disappearance of NAT.
Many current off-the-shelf residential routers are "IPv6 Ready". Ie. they support RFC 6204 which in turn recommends (S-1) implementation of "Simple Security" for IPv6 (RFC 6092). The problem is that not all these devices automatically enable Simple Security when IPv6 is enabled.
On Sat, 13 May 2017 11:09 UTC, ea2ekh@gmail.com said:
On 13 May 2017, at 03:23, Brian Kantor Brian@UCSD.Edu wrote:
As usual, systems running non-Windows OS's (Linux, etc) are immune to this attack.
Sorry, I forgot. This is going to be very interesting with IPv6 and the disappearance of NAT.
I'm not sure IPv6 will be implemented at the breakneck pace I feared: NAT has saved the net, as a whole, from having to implement IPv6 capacity on a short deadline. Although statisticians and advertisers are drooling at the thought of having a MAC address in every IPv6 packet, the enormous investments companies and ISP's have made in IPv4 equipment, plus caution regarding possible end-user pushback, has caused them to drag their feet for a while.
Sooner or later, though, we'll have to adapt: although "NAT", as a security mechanism, might go away, routers can be set to refuse uninvited incoming packets. There is also a very good chance that ISP's will offer IPv4 <> IPv6 transition services, which might keep IPv4 viable for several more years: the cable companies experience with supporting NTSC television transmissions long after the digital TV start has, I think, reminded ISP's that most consumers cling to their old electronics until everyone else they know has made the leap to the new stuff. Since I've always been a late adopter myself, I think any ISP that demands customers replace their "home" routers and PC's and Roku boxes and Gameboys en masse will lose a lot of income, very quickly, so I doubt they'll force anyone to use IPv6 until current IPv4 gear has aged out of consideration.
Thankfully, IPv6 won't require updates for a lot of the *NOS software and older Linux versions being used at gateways, because I think we can start to encapsulate IPv4 inside IPv6 packets, and use that mechanism to keep major parts of amprnet viable with IPv4. Let's talk about what and where that method could be used, and (of course) whether it should be implemented.
Bill, W4EWH
-
"" -
Bill Horne, W4EWH -
Borja Marcos -
Brian Kantor -
ea2ekh＠gmail.com
-
R P -
Ruben ON3RVH -
Tony Langdon