A friend on a road-trip recently had an experience using hotel wifi that was a little surprising.  For several hours, while on the hotel’s wifi, her machine was effectively on the open Internet with no intervening firewall,

Her laptop was instrumented with one of MSI’s “honeypoints“, a lightweight honeypot that emulates various services and reports back to a central console when these “fake” services are interacted with, possibly by an attacker.

Over the several hour period while on wifi, the following Internet probes (and in some cases clear attacks) were seen.

The attacker IP and the port probed are in bold below:

• Jan 15 18:03:43 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.20.87.98 on port 443 at 2018-01-15 18:03:42 Alert Data: Connection Received  ==> https probe
• Jan 15 18:03:49 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.20.87.98 on port 443 at 2018-01-15 18:03:48 Alert Data: GET / HTTP/1.1#015#012Host: 63.140.158.108#015#012#015
• Jan 15 18:03:49 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.20.87.98 on port 443 at 2018-01-15 18:03:48 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2215.txt
• Jan 15 18:23:02 HPSS012 HPSS Agent: Tarsus.local received an alert from: 181.214.87.7 on port 3389 at 2018-01-15 18:23:02 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2216.txt  ==> Terminal services probe from Sweden
• Jan 15 20:06:21 HPSS012 HPSS Agent: Tarsus.local received an alert from: 209.126.136.7 on port 443 at 2018-01-15 20:06:20 Alert Data: Connection Received
• Jan 15 20:06:29 HPSS012 HPSS Agent: Tarsus.local received an alert from: 209.126.136.7 on port 443 at 2018-01-15 20:06:28 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2217.txt
• Jan 15 20:20:36 HPSS012 HPSS Agent: Tarsus.local received an alert from: 189.219.71.36 on port 23 at 2018-01-15 20:20:35 Alert Data: cat /proc/mounts; (/bin/busybox BBFMC || )  ==> Port 23 (telnet) IOT attack from Mexico. Likely from a Mirai botnet variant.
  
• Jan 15 20:26:22 HPSS012 HPSS Agent: Tarsus.local received an alert from: 8.3.123.42 on port 1433 at 2018-01-15 20:26:21 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2218.txt  ==> Microsoft SQL Server probe from Guam
• Jan 15 20:26:22 HPSS012 HPSS Agent: Tarsus.local received an alert from: 8.3.123.42 on port 1433 at 2018-01-15 20:26:22 Alert Data: Connection Received
• Jan 15 20:26:33 HPSS012 HPSS Agent: Tarsus.local received an alert from: 8.3.123.42 on port 1433 at 2018-01-15 20:26:32 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2219.txt
• Jan 15 22:03:44 HPSS012 HPSS Agent: Tarsus.local received an alert from: 198.199.113.84 on port 1433 at 2018-01-15 22:03:43 Alert Data: Non-ASCII Data Detected in Received Data.#012 File saved as Alert2220.txt  ==> SQL Server probe from U.S. 

These alerts were being reported to the console from the IP address assigned by the hotel to my friend’s laptop: 63.140.158.108

That IP is registered to:

NetRange: 63.140.128.0 – 63.140.255.255
CIDR: 63.140.128.0/17
NetName: WAYPORT-63-140-182-NET

Wayport is an ATT wifi service providing “hotspots” to various large companies.

These are the types of probes and attacks a box on the open Internet can expect to get. It’s become like cosmic radiation – pervasive. I discussed a previous related event here:  https://stateofsecurity.com/?p=4126

What is interesting in this case is the fact they happened at all.

The hotel was part of a major chain.  The common assumption is they are watching out for their guests to ensure a “safe” wifi environment…and in general they are.

But – there maybe some fine print.

Some hotel wifi agreements apparently specifically allow you to request “advanced” connectivity options, in some cases as a result of wanting to do VPN from your laptop.  The result of those decisions may lead to a public Internet address and full Internet exposure of your device .

So – no Internet firewall but the one you bring with you.

Bottom Line:

• Regardless of the cause, you should expect the worst from “free” wifi.
• Assume full Internet exposure and have a software firewall enabled that blocks unsolicited inbound traffic.

See:

• https://conetrix.com/blog/public-ip-addresses-and-hotels
• https://superuser.com/questions/1063910/public-ip-given-at-a-hilton-hotel
• http://www.corecom.com/ccftp/Testing_Hotspot_Security.pdf

Quote from that last:

“Most private LANs use network firewalls to defend trusted insiders against Internet-borne attacks.This is not necessarily true in hotel broadband LANs, where topologies and security practices vary widely.For example, some use private IP addressing, while others assign each user their own public IP address to facilitate VPN tunneling. Users may assume they are insulated from outsiders, but really have no idea whether any firewall lies between
their notebook and the Internet. Notebooks that do not firewall themselves or that use certain applications that open holes in firewalls could thus be exposed to intrusions from the far side of the Internet.”

The General Data Protection Regulation (GDPR) was passed in May of 2016 and comes into force exactly five months from Christmas Day on May 25, 2018. The aim of this regulation is to strengthen and unify personal data protection for all citizens (and residents) in the European Union, and to allow them to control their personal information (data). This personal data must be protected according to a number of articles in the regulation, and also applies to non-European organizations that process the personal data of EU citizens.

According to the European Commission, personal data is “any information relating to an individual, whether it relates to his or her private, professional or public life. It can be anything from a name, a home address, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer’s IP address.” As can be seen, this list covers just about everything!

One of the big requirements that is going to affect US organizations that do business with EU persons is their “right to be forgotten.” This means that EU citizens and residents can request that their personal data be removed from corporate databases in a timely manner. If this cannot be done, they have the right to know exactly why not.

Unlike HIPAA/HITECH, non-compliance with the GDPR can lead to some major league fines: in some cases, up to 20,000,000 Euros or 4% of the annual worldwide turnover of the preceding financial year of the organization (whichever is greater). I think that fines on this level show just how seriously personal privacy is being taken in the EU.

This new regulation just illustrates the pressing need for organizations to know how data flows across and is stored on computer networks. If you know exactly where personal data is and how it flows, you can deal with it. If you don’t, better get ready for some trouble ahead!

He knows what “normal” is. Source: Wikimedia Commons

I have repeatedly had the experience of performing external vulnerability assessments and discovering significant issues that were not being called out as such by the regular commercial assessment services employed by the client organization.

I recently discovered a case where active web server logs were freely available on the open Internet .  The usual information – source IP address, target resource, and status codes –  were all available.

Example:

64.39.99.99 – – [02/Aug/2017:10:09:07 -0400] “GET /client/chat.php?id=1%22%20%3E%3C/script%3E%3Cscript%3Ealert%28%27QualysXSSTestPart2%27%29%3C/script%3E&xhash=1 HTTP/1.1” 302 433 “-” “-“
64.39.99.99 – – [02/Aug/2017:10:09:08 -0400] “GET /index.do HTTP/1.1” 302 301 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:10 -0400] “GET /userui/welcome.php HTTP/1.1” 302 311 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:12 -0400] “GET /struts2-rest-showcase/orders HTTP/1.1” 302 321 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:08:58 -0400] “POST /rest/json/login HTTP/1.1” 302 308 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:14 -0400] “GET /node.xml HTTP/1.1” 302 301 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:14 -0400] “GET /user/login HTTP/1.1” 302 303 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:15 -0400] “GET / HTTP/1.1” 302 293 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:16 -0400] “GET /admin.php HTTP/1.1” 302 302 “-” “-”
64.39.99.99 – – [02/Aug/2017:10:09:16 -0400] “GET /console/login/LoginForm.jsp HTTP/1.1” 302 320 “-” “-”

The highlighted entry is a “cross site scripting” (XSS) test being run over the Internet by the vulnerability management service “Qualys“.

From “whois 64.39.99.99”

NetRange: 64.39.96.0 – 64.39.111.255
CIDR: 64.39.96.0/20
NetName: QUALYS

Anyone on the Internet was able to view these logs and learn of the organization’s use of Qualys and something of the types of tests being performed and what the outcome of those tests were.

All highly useful information to any potential attacker.

Note that the problem here is NOT with Qualys.

The site that allowed these logs to be revealed had no “technical” security problem. Any internal user who was basing their understanding of the external security status of the organization strictly on the scanning service reports would likely have no reason to believe anything was wrong.

Your organization needs at least one knowledgeable and caring staff member whose job it is to know what your organization looks like from the Internet and can see when something is clearly wrong in the same way a neighborhood patrol officer can notice a strange car or a gate open that is normally locked.

You need your own “cop on the beat”.

How closely do you inspect what 3rd party plugins and libraries you use with software and development? We kind of tend to take for granted that once we vet a library or plugin and add that into our usage, then it’s likely to never be a threat in the future. However, over the last few years attackers have started increasing abuse of this trust. A type of watering hole attack that reaches a larger amount of people than a typical focused attack.

There’s 3 main ways this has happened:

• Attackers buy the plugin/library from the original author or assume control of one that is abandoned
• Development system or other system in chain is compromised by attacker
• Attackers create releases that mimic popular and established libraries/plugins in name and function

This has affected a wide range of software, from web applications to web browsers to text editors/IDE’s. Let’s take a brief look at a few instances.

WordPress Display-Widgets plugin. This plugin was sold by the original developer, and at that time had several hundred thousand active installations. The new developers then added code to it that downloaded and installed a plugin that added spam the site.

The Node.js package repository was found to have malicious packages that looked like real packages, differing slightly in the name in an attempt to fool anyone trying to find specific packages. The malicious packages generally tried to send sensitive environment data back to a server.

Python also experienced something very similar. Package uploaded in an attempt to fool anyone not paying close enough attention. Not relying on just misspelling the name, but with names that look legitimate, such as “bzip” for the real package “bzip2file”.

Those are just a few examples, Chrome and Firefox have both had similar issues multiple times as well. So how do we protect against this? Partly some of this has to be on the software that allows the plugins to run. There are some bad policies and practices here, such as WordPress letting anyone claim “abandoned” plugins.

Some things you can do yourself are to install any libraries/plugins (for python, ruby etc) with your systems package manager. If you use pip, gem or the like, make sure you are using the correct plugins, avoid misspellings or “close enough” names. Check the reputations of plugins via Twitter or search for reviews and info on plugins, by name, in your search engine. If you find any  anomalies report them on social media and forums associated with your language. Try not to use plugins that have been abandoned and recovered by another developer with no reputation.

For this third installment in my series on human-based information security I will be discussing the idea that human analysis and interaction must be at the core of any truly effective monitoring program. To reiterate the basic point of this series, it is axiomatic that information security is a human problem, not a technological problem. It is my contention that our failure to embrace this truth is demonstrated in the fact that not only are more data breaches and other security failures still occurring, they are actually becoming more prevalent over time.

Largely because of this increase in data breaches, and the public outcry about them, incident response has become an increasingly important part of the information security effort over recent years. And as anyone who has actually participated in the effort knows, the most difficult part of incident response is detection. Most network compromises go unnoticed for days, weeks, months, even years! And the only way that l know of to address this problem is through verbose system logging and effective monitoring processes.

System logging and monitoring has always been a thorn in the side of every CISO and network security admin. It seems like such an overwhelming task that most of them automatically give up and either hardly log and monitor at all, or turn the effort over to a third-party service provider that will never be as invested in the task as they would be in their own company’s security monitoring. We always go that extra mile to protect our own, don’t you think?

However, this task isn’t nearly as daunting as it seems. With the help of proper parsing and aggregating tools and a handful of command line tools, the task can be reduced to the human scale. Personnel can pull just that information they need from these mounds of data, and are much better at recognizing anomalies and danger signs than any program, especially over time. It is also a happy fact that the more you perform log searching and monitoring, the easier it is and the better you get at it. One particularly good log monitoring engineer I know even gleans valuable information by simply scrolling through the raw log data at high speed; he is able to see areas of concern in the data through pattern recognition alone.

The caveat of all this is that you need to allocate dedicated personnel to perform these tasks, and these personnel need to be very well trained and knowledgeable about the full capabilities of the tools they use to parse, aggregate and monitor the log data generated by the system. This means proper support and funds allocation at the management level. Our job as information security professionals is to ensure that these folks understand the reality and importance of logging and monitoring to the overall information security effort.

We’ve had a surprising number of incident response engagements involving Office 365 lately, and I’d like to discuss some best practices to keep you from an incident. There are also some actions that should be taken to allow effective investigation if you should suspect a user or resource is compromised.

The single most important thing that would have kept most of these incidents from occurring? Enable multi-factor authentication. Period.

Yes, I know. But our users complain! It’s a hassle! It’s an extra step!

Let’s consider carefully. Look at each user in the organization. Consider what they have access to, if their credentials are compromised. Look at these resources in your organization:

• Exchange
• All Office 365 documents
• Sharepoint

Weigh out the user inconvenience vs. the loss of any and all data that they have access to….and discuss with your risk and compliance staff.

Still with me? Here’s how to enable multifactor authentication in Office 365.

If you are on a hosted Office 365 infrastructure, your service provider should be ready and willing to help with this if you do not have access in place to enable the option.

Next, let’s talk about investigating an actual compromise. Microsoft has some fairly robust mailbox audit capability for user access, etc. And…it’s not turned on by default.

Crazy, you say? Just a bit!

First, you need to turn the options on – instructions to do that are here.

Then you need to enable it for mailboxes. Instructions to do that are here.

Please note that this second step requires Powershell access – so if you are in a managed Office 365 environment, your service provider will likely need to assist. (and don’t take no for an answer!)

There are a number of other options that are useful for fine-tuning the spam and malware settings, enabling DLP, and other useful things that are not on by default – or not configured for the most optimal settings.

Would you like an audit of your Office 365 environment? Our engineers can help you fine tune your settings to optimize the available options. Reach out, we’d love to help.

Questions, comments? Twitter – @TheTokenFemale, or lwallace@microsolved.com. I’d love to hear from you!

Yesterday, the media exploded with news of the new Krack attack against WPA2. What’s Krack? While it sounds like a new designer drug, it’s short for – Key Reinstallation Attacks.

What’s that mean in English? Due to a flaw in the WPA2 protocol, a determined attacker can target and break the 4-way handshake and compromise the unique session keys. They can force reuse of a key, and intercept (as well as potentially modify) unencrypted traffic. The full whitepaper is here.

The good news, such as it is:

• This is not a remote attack – the attacker needs to be in range of the affected Wifi connection
• At this point, there is no evidence of these attacks in the wild. Caveat, at this point.

There have been a couple of reports suggesting that WPA2 should be disabled in lieu of WPA or (ack) WEP. These are not better options, as a general rule. WEP in particular is vulnerable far beyond the WPA2 protocol issues.

What can we do, and what should our user base do?

• As soon as there’s a patch available, take advantage of it.
• Watch your vendors – who is patching quickly, and who is not? If your vendor is months behind the curve, why? It may be time to look at other options.
• Wired connections are immune. This should go without saying – this includes tethering directly to mobile devices, not tethering via WiFi.
• You’re already horribly suspicious of free public WiFi, right? Double that paranoia.
• If you must use a public WiFi, do not do so without using a VPN or other traffic encryption mechanism. Split tunnel VPN is not your friend here – configure a full tunnel VPN connection
• Bring your physical security staff into the conversation. They will be integral in observation of potential attackers in the sphere of your physical presence. (Have you checked how far your WiFi signal is traveling lately? Consider checking…)

CERT has a complete list of vendors and their known status here.

Questions, comments, things I haven’t thought about? Reach out, I’d love to hear from you. Twitter @TheTokenFemale at any time.