You’ll need the latest version of Nmap v7.40 which you’ll be able to find on Linux (Ubuntu, CentOS, etc) or on Windows thanks to the available binaries for both platforms. I didn’t have any success using Nmap v6.40 which was available via YuM on CentOS 7. So I had to remove Nmap 6.40 (sudo yum erase nmap) and then install the latest RPM version of Nmap which can be found on the downloads page.

I was using CentOS 7 x64 so I issued the following commands;

[mcnamaram1@centos ~]# sudo yum erase nmap
[mcnamaram1@centos ~]# wget https://nmap.org/dist/nmap-7.40-1.x86_64.rpm
[mcnamaram1@centos ~]# sudo rpm -ivh nmap-7.40-1.x86_64.rpm

Paulino Calderon released a NSE (Nmap Scripting Engine) script on Github that can be easily used with Nmap to detect vulnerable machines. You’ll need to download that script as well.

[mcnamaram1@centos ~]# wget https://raw.githubusercontent.com/cldrn/nmap-nse-scripts/master/scripts/smb-vuln-ms17-010.nse

I used the following command line arguments to run the actual scan and found an old Windows XP machine in my home that was vulnerable.

[mcnamaram1@centos ~]# sudo nmap -p445 --script smb-vuln-ms17-010.nse 192.168.1.0/24
Starting Nmap 7.40 ( https://nmap.org ) at 2017-05-15 21:29 EDT
Nmap scan report for 192.168.1.0

Nmap scan report for PLUTO.home (192.168.1.79)
Host is up (0.058s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: 00:21:91:81:A7:1D (D-Link)

Host script results:
| smb-vuln-ms17-010:
|   VULNERABLE:
|   Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)
|     State: VULNERABLE
|     IDs:  CVE:CVE-2017-0143
|     Risk factor: HIGH
|       A critical remote code execution vulnerability exists in Microsoft SMBv1
|        servers (ms17-010).
|
|     Disclosure date: 2017-03-14
|     References:
|       https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143
|_      https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

If you’re not a Linux guy or gal you can also use the Windows version of Nmap. The installation was pretty straight forward, I had to download the script to the Windows desktop, create a profile, add the script and select a target. In this case I decided to scan my entire home network IP subnet of 192.168.1.0/24 and the Windows version found the same vulnerable Windows XP desktop;

You’d be surprised what you might find connected to the network.

Good Luck!

::ffff:89.248.172.6 - - [26/Dec/2015:18:53:22 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:22 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:22 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:22 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:22 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:24 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:25 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:25 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"
::ffff:89.248.172.6 - - [26/Dec/2015:18:53:25 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"

I was naturally curious and started digging through my logs, I found 427,358 requests from that IP network over the past two weeks. Using whois I was able to identify the network and hosting provider where the requests were originating from.

[root@moon logs]# whois 89.248.172.6
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '89.248.172.0 - 89.248.172.57'

% Abuse contact for '89.248.172.0 - 89.248.172.57' is 'abuse@ecatel.net'

inetnum:        89.248.172.0 - 89.248.172.57
netname:        SC-QUASI40
descr:          QUASI
country:        SC
admin-c:        QNL1-RIPE
tech-c:         QNL1-RIPE
status:         ASSIGNED PA
mnt-by:         QUASINETWORKS-MNT
mnt-lower:      QUASINETWORKS-MNT
mnt-routes:     QUASINETWORKS-MNT
created:        2008-06-21T17:49:26Z
last-modified:  2015-11-09T13:20:10Z
source:         RIPE # Filtered

role:           Quasi Networks LTD
address:        Suite 1, Second Floor
address:        Sound & Vision House, Francis Rachel Street
address:        Victoria, Mahe, SEYCHELLES
remarks:        *****************************************************************************
remarks:        IMPORTANT INFORMATION
remarks:        *****************************************************************************
remarks:        We are a high bandwidth network provider offering bandwidth solutions.
remarks:        Government agencies can sent their requests to gov.request@quasinetworks.com
remarks:        Please only use abuse@quasinetworks.com for abuse reports.
remarks:        For all other requests, please see the details on our website.
remarks:        *****************************************************************************
abuse-mailbox:  abuse@quasinetworks.com
nic-hdl:        QNL1-RIPE
mnt-by:         QUASINETWORKS-MNT
created:        2015-11-07T22:43:04Z
last-modified:  2015-11-07T23:04:49Z
source:         RIPE # Filtered

% Information related to '89.248.172.0/23as29073'

route:          89.248.172.0/23
descr:          Quasi Networks LTD (IBC)
origin:         as29073
mnt-by:         QUASINETWORKS-MNT
created:        2007-11-19T14:34:49Z
last-modified:  2015-11-09T13:24:19Z
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.83.1 (DB-1)

I had never heard of Seychelles before, but Google pointed out that it’s a collection of islands off the east coast of Africa. I would personally think that bandwidth would be expensive there but I’m guessing the miscreants don’t mind paying for it.

It was pretty clear from the logs that this IP address was trying infiltrate the XMLRPC service in WordPress while hoping to avoid detection by using the Googlebot agent string. If anything using the Googlebot agent string actually draws attention to the request.

While not a foolproof solution, I’ve added another IP network into my server firewall tables.

I did a quick scan of the logs and found 38 distinct IP addresses had tried to login to my WordPress blog a total of 359 times since midnight. A number of IP addresses were from proxy and VPN providers of which the majority were based in the continental United States. There were 104 attempts from 104.193.120.218 which belongs to a service provider in Farmington Hills, MI and resolves to solutionslick.net which is a front to adult porn sites.

I’d love to spend more time pouring over my log files but I just don’t have the time or energy.

Cheers!

I’ve seen more than my fair share of duplicate IP address issues over the years and I’m wondering how Apple is going to implement this feature to prevent duplicate MAC addresses? And in that same thought how is this change going to impact other systems. It’s obviously going to impact those solutions that promise to track customers through retail spaces. Although the proposed change by Apple only covers the WiFi SSID scanning, once you connect to a guest/public hotspot iOS 8 will use the real WiFi MAC address which can then be tracked. How will this impact an Access Point or Wireless LAN Controller? What if a wireless network utilizes band steering and probe response spoofing?

Anyone have any technical details regarding how they will actually randomize the MAC address?

Cheers!

At the beginning of the presentation I asked the audience the following questions, trying to make the presentation interactive;

1. Who in the audience has ever been a victim of credit card fraud?
2. Who in the audience has ever been a victim of identity theft?
3. Who in the audience has ever been a victim of medical identity theft?

There were a surprising number of hands raised for each question which seemed to shock some of the audience members.

 Information Security

• Confidentiality
• Integrity
• Availability

We’re the problem?

• No security solution is ultimately stronger than its weakest link.
  – Weakest Link in Information System Security by C.W. Flink 2002

• Humans are considered to be the weakest link in the information security chain.
  – Global Information Assurance Certification Paper by Chan D Lieu 2002

Facts and Statistics

• In 2012, there were 447 documented breaches in the United States, exposing 17,317,184 records. In the first half of 2013, there have so far been 255 incidents, exposing 6,207,297 records.
  – ITRC Breach Report, Identity Theft Resource Center, May 2013

• The street cost for stolen medical information is $50, versus $1 for a stolen Social Security number.
  – RSA Report on Cybercrime and the Healthcare Industry, 2013

• The World Privacy Forum has reported that the street cost for stolen medical information is $50, versus $1 for a stolen Social Security number.
  – RSA Report on Cybercrime and the Healthcare Industry, 2013

• 94% of healthcare organizations surveyed experienced at least one data breach in the past two years
  – Third Annual Benchmark Study on Patient Privacy & Data Security, Ponemon 2012

• The average cost per record of a healthcare data breach in 2011 was $240, which is 24 percent higher than average. Healthcare data breaches are the fourth highest by industry, behind the financial, pharmaceutical and communications sectors.
  – 2011 Cost of a Data Breach: United States, Ponemon Institute and Symantec, March 2012

• Thus far in 2013, 48 percent of reported data breaches in the United States have been in the medical/healthcare industry. In 2012, there were 154 breaches in the medical and healthcare sector, accounting for 34.5 percent of all breaches in 2012, and 2,237,873 total records lost.
  – ITRC Breach Report, Identity Theft Resource Center, May 2013

• 1.42 million Americans were victims of medical identity theft in 2010, 1.49 million in 2011, 1.85 million in 2012
  – Third Annual Survey on Medical Identity Theft by Ponemon Institute 2012

• The average payout for a medical identity theft is $20,000, compared to $2,000 for a regular identity theft.
  – RSA Report on Cybercrime and the Healthcare Industry, 2013

Data Loss Prevention

• Data Loss Prevention includes People, Processes and Technology.It’s not a problem that technology can solve by itself instead it requires governance, policies, procedures, access controls, incident response, endpoint security, and training along with auditing and monitoring.

• Data at Rest – Where is my confidential data stored?
• Data at Motion – Where is my confidential data going?

Why?

• Reduce Risk – prevent breaches, prevent loss of PHI and IP
• Comply with Regulatory Requirements – HIPAA/HiTech

Questions, Comments, Thoughts?

There was a surprising number of questions and comments at the end of the presentations. I had thought people were starting to look glossed over half-way through, perhaps because I had too many statistics and facts but I was trying to make sure they understood the gravity of the problem. Now the real work begins as we try and implement a data loss prevention policy.

Cheers!

I received the following notification this week that informs Verizon customers that Verizon’s Email servers are now supporting SSL when utilizing POP3 and SMTP to send and receive email from a traditional email client such as Mozilla’s Thunderbird,  Microsoft’s Outlook or your Android or Apple Smartphone.

This is very exciting news because you hopefully already know that your username and password are sent in the clear when utilizing POP3 and SMTP (with authentication) when not utilizing SSL. So the answer to the ages old question of does Verizon support SSL encryption has changed? They now support SSL encryption on both the POP3 (receiving) and SMTP (sending) for traditional email clients.

I made the changed to my Microsoft Outlook client and it works perfectly.

You’ll need to dig deep into the settings to modify the port numbers that are utilized for both POP3 and SMTP, they can be found under “More Settings…”

You can find additional configuration information on Verizon’s website at this link.

I also recently noticed that Verizon now redirects any attempts to connect to http://webmail.verizon.net to the SSL secured site at https://webmail.verizon.net which again is very exciting from a security perspective.

Now you can safely utilize that public hotspot or guest network without worrying if someone is going to steal your username and password when you try and check your inbox. This change is long overdue and very welcome in my opinion.

Cheers!

Update: March 20, 2013

I just noticed that Verizon is only encrypting the actual login (passing the user credentials). They are not encrypting the entire session which includes the actual contents of the message or any attachments. This approach was helpful 5 years ago but not today, I’m not sure if Verizon is using secure COOKIES or not but this approach is usually susceptible to session hijacking.

Well if it is you had better start doing your some engineering before you end up with potential bandwidth and power problems.

Video surveillance is becoming more and more common place in large enterprises and there’s no doubt that IP based surveillance systems and digital video recorders (DVRs) have revolutionized the security industry. Their introduction onto enterprise networks though is starting to raise some eyebrows as the shear number of IP cameras balloons and the bandwidth and power hungry devices start putting a serious pinch on existing network infrastructures.

There are obviously a lot of factors that affect how much bandwidth and power a specific IP camera will consume. The bandwidth consumption can be relative to the resolution (QVGA/HD), the frame rate, compression, video codec (H.264), type of camera (fixed or PTZ) and the complexity of the actual picture. I typically see bandwidth utilization of 1.5Mbps – 5Mbps per camera depending on the conditions outlined above. The power consumption will usually depend on the camera make and model but 720P fixed cameras will generally consume 11W (802.3af) while higher end point to zoom cameras can consume a full 30W (802.3at).

Last year we installed around 139 security cameras into a new parking garage at one of our facilities. Each of those IP cameras is streaming to a digital video recorder (DVR) located in the local security office. You can only image how many DVRs there are in the security office. As you can guess the bandwidth utilization across the uplinks to the edge/closet switch that feeds the security office is significant. The yearly average for each of the uplinks is around ~ 75Mbps, totaling 150Mbps in all. That’s a pretty significant bit stream even compared to traditional bandwidth hungry applications such as PACS (Picture Archival and Communications Systems).

Like the rest of the enterprise the same security office utilizes IP phones for voice communications so engineers and architects need to be mindful of the role that QoS (Quality of Service) plays in guaranteeing available bandwidth and buffers for critical real-time application traffic flows.

I know a number of organizations that have decided to build a completely separate network just for their video surveillance and access control systems. The intention being to reduce any impact on the production network and to maintain those critical security systems if the production network should ever fail. There are obvious pros and cons to this approach, the most obvious being you now have 2 networks to support and maintain 24×7.

My Thoughts

I usually advocate utilizing a single network with adequate capacity and redundancy to meet the design requirements of all the application traffic the network will be supporting. If you’re going to be supporting video surveillance traffic make sure you allow adequate bandwidth and if possible that you locate the DVRs as close to your core as possible. Some video surveillance solutions support Multicast to help reduce the amount of traffic so if you are streaming to multiple devices such as a viewing station and DVR simultaneously you might want to look into whether the manufacturer supports Multicast. Just don’t be surprised when you install 100+ security cameras and find that’s your top traffic generator.

Cheers!

We recently received a warning from SecureLink regarding the recent release of Java 6 Update 26;

There is a compatibility issue with the upgrade process from any previous version to Java 6 update 26 because of changes to some Java system files. Symptoms include connection errors, disappearing java applet window, session disconnects and java system errors. This issue occurs for both SecureLink Users and SecureLink Enterprise Vendor Representatives. SecureLink Users and SecureLink Enterprise Vendors can work around this problem by uninstalling and then manually re-installing Java or by rejecting Java 6 update 26.

Uninstall instructions http://www.java.com/en/download/uninstall.jsp

Manual Install Instructions http://www.java.com/en/download/help/windows_manual_download.xml

Cheers!

On Tuesday July 10, 2008 a number of vendors including Microsoft, Cisco, Juniper and RedHat released patches and/or acknowledged the flaw existed. The Internet Software Consortium, the group responsible for development of the popular Berkeley Internet Domain Named (BIND) server from which nearly all DNS offshoots are based, also acknowledged the flaw and released a patch.

I personally spent about 90 minutes on last Wednesday updating several internal and external systems including numerous CentOS v5.2 servers and Windows 2003 Service Pack 2 servers. I was unable to find any mention of the DNS flaw on the Alcatel-Lucent website so I’ll probably need to place a call concerning Alcaltel-Lucent’s VitalQIP product.

I used yum to patch the CentOS Linux servers [“yum update”] and then just restarted the named process [“service named restart”]. On the Windows 2003 Service Pack 2 servers I used Windows Update to download and install KB941672 after which I rebooted the servers.

Here are some references:

http://www.theregister.co.uk/2008/07/09/dns_fix_alliance/
http://www.networkworld.com/news/2008/071008-patch-domain-name-servers-now.html
http://www.networkworld.com/news/2008/070808-dns-flaw-disrupts-internet.html

http://www.networkworld.com/podcasts/newsmaker/2008/071108nmw-dns.html

http://www.us-cert.gov/cas/techalerts/TA08-190B.html
http://www.microsoft.com/technet/security/bulletin/MS07-062.mspx

I would strongly suggest that all network administrators start looking into patching their DNS servers as soon as possible.

Cheers!

UPDATE: July 14, 2008

Here’s an update from RedHat concerning the configuration (named.conf) of BIND;

We have updated the Enterprise Linux 5 packages in this advisory. The default and sample caching-nameserver configuration files have been updated so that they do not specify a fixed query-source port. Administrators wishing to take advantage of randomized UDP source ports should check their configuration file to ensure they have not specified fixed query-source ports.

It seems that a check of the configuration file would be in order. Let me throw in a quick warning though if your DNS server is sitting behind a firewall you may need to check with the firewall administrator to understand how the firewall will behave if you randomize your source ports. I believe there are quite a few firewalls out there that only expect to see DNS traffic sourced from a DNS server on UDP/53.

Good Luck!