Malicious libraries and plugins

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 abondened
  • 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.

Are You Seeing This? Join a Threat Sharing Group!

Just a quick note today about threat sharing groups. 

I am talking to more and more companies and organizations that are putting together local, regional or vertical market threat sharing groups. These are often adhoc and usually driven by security practitioners, who are helping each other with cooperative defenses and sharing of new tactics and threat patterns (think TTPs (tactics, techniques & procedures)) or indicators of compromise (IOCs). Many times, these are informal email lists or RSS feeds that the technicians subscribe to and share what they are seeing in the trenches. 

A few folks have tried to commercialize them, but in most cases, these days, the sharing is simply free and open. 

If you get a chance to participate in one or more of these open source networks, you might want to check it out. Many of our clients are saying great things about the data they get via the networks and often they have helped contain incidents and breaches in a rapid fashion.

If you want to discuss your network, or if you have one that you’d like me to help promote, hit me up on Twitter (@lbhuston). If you are looking for one to join, check Twitter and I’ll share as folks allow, or I’ll make private connections as possible. 

As always, thanks for reading, and until next time, stay safe out there! 

Human-Based Infosec: Monitoring

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.

Office 365 – all your stuff belongs to…who?

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!

We’re all on….Krack?

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.

Where Does Trouble Come From?

One of the most common questions I get is, “Where does attack traffic come from?”. I want to present a quick and dirty answer, just to show you how diverse illicit traffic sources are. 

To give you a glimpse into that, here is a list of the top 20 ISPs, based on the number of unique malicious source IP addresses who touched one of my HoneyPoint deployments in a single 24 hour period.

The list:

9 korea telecom
7 hinet
6 dynamic distribution ip’s for broadband services ojsc rosteleom, regional branch “urals”
5 sl-reverse
5 sfr
5 rr
5 chinanet jiangsu province network china telecom no.31,jingrong street beijing 100032
5 china mobile communications corporation mobile communications network operator in china internet service provider in china
4 turknet-dsl
4 superonline
4 sbcglobal
4 chinanet jiangsu province network china telecom 260 zhongyang road,nanjing 210037
3 zenlayer inc
3 virginm
3 verizon
3 totbb
3 jsc rostelecom regional branch “siberia”
3 intercable
3 comcastbusiness
3 comcast
3 charter
3 broadband multiplay project, o/o dgm bb, noc bsnl bangalore
3 as13285

As you can see by the above, the list is pretty diverse. It covers sources in many countries and across both domestic and foreign ISPs. In my experience, the list is also pretty dynamic, at least in terms of the top 10-20 ISPs. They tend to spike and fall like waves throughout different time periods. One of these days, maybe I will get around to visualizing some of that data to get a better view of the entropy around it. But, for now, I hope this gives you an idea of the diversity in sources of attacks.

The diversity also makes it very difficult to baseline log activity and such. As such, there may be some effective risk reduction in blocking ISPs by netblock, if your organization can tolerate the risk associated with doing so. But, more on that in another post. Hit me up on Twitter (@lbhuston) and let me know what your firm’s experience with that type blocking has been; if you’ve tried it or are doing it today. I’d love to hear if it reduced log noise, made traffic modeling easier or led to any specific risk reductions.

Thanks for reading! 

The Golden Rule and Security Staffing: Treat others’ data as you would your own

Since I began working at MSI several years ago I have been able to study the behaviors of organizations of various sizes in terms of information security.

Sort of a forced march through  “infosec cyber-anthropology”.

One thing that has always surprised me is the number of comparatively large organizations – often ones with significant IT staffing in the form of networking, database and sysadmin staff – who do NOT have dedicated security staff.

This to me is a lot like expecting the postmen,  utility crews, trash workers, and all the rest of the specialist priesthood that keeps our immediate environment working, to also pick up the slack and do police work on the side.

As in all bureaucracies, IT staff can be very turf-conscious. In some cases the hiring of dedicated security staff is clearly actively resisted by existing groups. Threatened sysadmins will claim that they can handle any security issues – often as long as they have the right tools. And that plays into the “magical thinking” that security product vendors are quite willing to cultivate in the minds of management: “Don’t hire people – buy my stuff!  Burn enough money on my altar and the evil will be held at bay.”

I believe strongly this is the road to hell – or at least career death for executive management when the inevitable breach occurs.

Ask those Equifax execs.

Gardens need gardeners. Your information security environment will be an illusion if there are not people who truly care about it and feel a moral obligation to protect your organization and the information that customers entrust to you. That obligation includes questioning things as they supposedly are and not believing that what your SIEM says is necessarily the truth.

No “managed security services provider” is going to do this for you. Only loyal, engaged and actively concerned staff who have a clear sense of local mission can provide such care.

It is a level of care you would want for yourself and for your family.

Provide it to your customers.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Risk Assessment Techniques for Everyone

Risk assessment and treatment is something we all do, consciously or unconsciously, every day. For example, when you look out the window in the morning before you leave for work, see the sky is gray and decide to take your umbrella with you, you have just assessed and treated the risk of getting wet in the rain. In effect, you have identified a threat (rain) and a vulnerability (you are subject to getting wet), you have analyzed the possibility of occurrence (likely) and the impact of threat realization (having to sit soggy at your desk), and you have decided to treat that risk (taking your umbrella) – risk assessment & treatment.

However, this kind of risk assessment is what is called “ad hoc”. All of the analysis and decision making you just made was informal and done on the fly. Pertinent information wasn’t gathered and factored in, other consequences such as the bother of carrying the umbrella around wasn’t properly considered, other treatment options weren’t considered, etc. What business concerns and government agencies have learned from long experience is that if you investigate, write down and consider such factors rationally and holistically, you end up with a more realistic idea of what you are really letting yourself in for, and therefore you are making better risk decisions – formal risk assessment.

So why not apply this more formal risk assessment technique to important matters in your own life such as securing your home? It’s not really difficult, but you do have to know how to go about it. Here are the steps:

  1. System characterization: For home security, the system you are considering is your house, its contents, the people who live there, the activities that take place there, etc. Although, you know these things intimately it never hurts to write them down. Something about viewing information on the written page helps clarify it in our minds.
  2. Threat identification: In this step you imagine all the things that could threaten the security of your home and family. These would be such things as fire, bad weather, intruders, broken pipes, etc. For this (and other steps in the process), you can go beyond your own experience and see what threats other people have identified (i.e. google inquiries, insurance publications).
  3. Vulnerability identification: This is where you pair up the threats you have just identified with weaknesses in your home and its use. For example, perhaps your house is located on low ground that is subject to flooding, or you live in a neighborhood where burglaries may occur, or you have old ungrounded electrical wiring that may short and cause a fire. These are all vulnerabilities.
  4. Controls analysis: Controls analysis is simply listing the security mechanisms you already have in place. For example, security controls used around your home would be such things as locks on the doors and windows, alarm systems, motion-detecting lighting, etc.
  5. Likelihood determination: In this step you decide how likely it is that the threat/vulnerability will actually occur. There are really two ways you can make this determination. One is to make your best guess based on knowledge and experience (qualitative judgement). The second is to do some research and calculation and try to come up with actual percentage numbers (quantitative judgement). For home purposes I definitely recommend qualitative judgement. You can simply rate the likelihood of occurrence as high, medium or low risk.
  6. Impact analysis: In this step you decide what the consequences of threat/vulnerability realization will be. As with likelihood determination, this can be judged quantitatively or qualitatively, but for home purposes I recommend looking at worst-case scenarios. For example, if someone broke into your home, it could result in something as low impact as minor theft or vandalism, or it could result in very high impact such as serious injury or death. You should keep these more dire extremes in mind when you decide how you are going to treat the risks you find.
  7. Risk determination: Risk is determined by factoring in how likely threat/vulnerability realizations is with the magnitude of the impact that could occur and the effectiveness of the controls you already have in place. For example you could rate the possibility of home invasion occurring as low, and the impact of the occurrence as high. This would make your initial risk rating a medium. Then you factor in the fact that you have an alarm system and un-pickable door locks in place, which would lower your final risk rating to low. That final rating is known as residual risk.
  8. Risk treatment: That’s it! Once you have determined the level of residual risk, it is time to decide how to proceed from there. Is the risk of home invasion low enough that you think you don’t need to apply any other controls? That is called accepting risk. Is the risk high enough that you feel you need to add more security controls to bring it down? That is called risk limitation or remediation. Do you think that the overall risk of home invasion is just so great that you have to move away? That is called risk avoidance. Do you not want to treat the risk yourself at all, and so you get extra insurance and hire a security company? That is called risk transference.

So, next time you have to make a serious decision in your life such as changing jobs or buying a new house, why not apply the risk assessment process? It will allow you to make a more rational and informed decision, and you will have the comfort of knowing you did your best in making the decision.

HoneyPoint Security Server Console 4.1 Released

MSI is proud to announce the immediate availability of the HoneyPoint Console version 4.1!

The new version of the Console for HPSS is now available for Windows, Linux and Mac OS X.

The new Console includes the ability to bypass local event logging and instead send the events directly to syslog or to be processed by the plugins. This allows the Console to work with a SIEM, other monitoring tools, or any centralized log management system without worrying about managing the local event database. Several improvements in the GUI console have been made, the ability to test email servers has been added, and multiple bugs have been addressed.

To obtain the new Console files or installer, refer to your QuickStart Guide on how to access the HoneyPoint Security Server distribution site. No changes to the database or license key are required, however, you must have a current license to qualify for the upgrade. An in place upgrade can be performed or the installer can handle the upgrade on Windows. As always, we recommend backing up the database and any plugins and logs before upgrading.

Thanks, as always, for choosing HoneyPoint Security Server and MSI. We value your partnership and trust.

Have ISP-provided WiFi but don’t think you use it? You could be wrong – and on the open Internet

As with many home networks, you may have an all-in-one cable modem/router/wireless access point provided by the ISP, as well as your own personal router/wireless access point. To prevent a double NAT issue, the ISP router is bridged and the personal router is performing NAT and firewall functions. This setup for a friend’s home network is diagrammed as below:

All wireless devices connect to the Personal-WIFi SSID, with the wireless key saved for automatic reconnection to this access point, and behind the router’s firewall. The ISP-Modem-WiFi SSID was not disabled for the occasional connectivity and bandwidth test. However, whenever he switches to the ISP-Modem-WiFi SSID, he manually enters the wireless key and none of his wireless devices has this wireless key saved. Or so he thought.

About a month ago, he had set his laptop down close to the ISP’s modem in the basement. The laptop was on but was not being used. Later that day, he got on the laptop and noticed he couldn’t connect to any internal sources in his home network but there was internet connectivity. He moved the laptop to the den, and was then able to connect to his media server and file shares. He didn’t think anything of it.

The next day, he discovered for several hours in the previous day, the laptop had had many connection attempts from the internet, several over ftp, telnet, mssql ports. This was alarming because the attempts were coming from the public internet – how were these attempts going through the firewall?

On the laptop runs a HoneyPoint agent – MicroSolved’s proprietary honey pot application – that listens for and responds to connection attempts to specific ports. The agent will then send an alert to the HoneyPoint console for report, alerts or analyses. The laptop HoneyPoint agent had detected these connection attempts. No real service connections were established; no actual breaches occurred. The HoneyPoint agent records the source IP, port being probed, and what data was sent. The attacks indicated discovery probing with a vector towards IoT devices.

But the lingering question was, how could the connection attempts go past the firewall?

It was only serendipitous that he stumbled on the answer. About a week ago, he couldn’t RDP to a Windows box in his internal network, but still had internet. Turns out, the home wifi (Personal-WIFi SSID) was having a hiccup but the laptop had automatically switched to the ISP-Modem-WiFi SSID – outside the firewall. He had inadvertently saved the wireless key to this SSID and was not aware of it. The laptop was now bridged and getting an IP from the ISP, with no firewall or router in between. Also, almost immediately, he noticed the HoneyPoint alerts – connection attempts on the same ftp, telnet, mssql ports were coming in from the public internet.

Lesson learned = if you’re going to keep your wireless access point enabled without a firewall – as in the bridged ISP modem/router – then DO NOT save the wireless key for it on any of your devices (either intentionally or accidentally) or you may be connecting to it without being aware. Best is to disable the wireless, but if you need it, set a strong WPA2 password and do not save the key on any device.

Another lesson learned = In the ensuing troubleshoots, he discovered the router’s uPnP setting had been left enabled, its default setting. That was immediately disabled. Additionally, HoneyPoint agent is a light-on-resources, quick-alerting IDS that does its intended job.

Note of explanation: One could argue the point to bridge the personal router instead of the ISP modem/router, and you would not have this issue. However, if you have many DHCP reservations in your internal network and have ever changed ISP’s, you understand the pain of re-entering those client reservations on a new modem/router. With this setup, you can easily switch ISP’s, slide in a new modem/router and bridge it, and all internal network resources are not interrupted.

Resources: Is UPnP a Security Risk?; Disable This Buggy Feature…