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.

HPSS and Splunk

We’ve had a few users ask how to feed alerts from the HPSS Console into a SIEM. In these cases it was Splunk, so I will show how to quickly get a feed going into Splunk and some basic visualizations. I chose Splunk since that’s what I helped the users with, but any SIEM that will take syslog will work.

The first step is to get the HPSS Console set up to externally log events. This can be enabled by checking the “Enable System Logging” in the preferences window. What happens with the output depends on your OS. On Windows the events are written to Event Log, and on Linux/MacOS they are handled by the syslog daemon. Alternatively you can use the Console plugins system if syslog/eventlog is not flexible enough.

HPSS Preferences Window

Before we go further, we’ll need to configure Splunk to read in the data, or even set up Splunk if you don’t have an existing system. For this blog post, I used the Splunk Docker image to get it up and running a couple minutes in a container.

In Splunk we’ll need to create a “source type”, an “index” and a “data input” to move the data into the index. To create the source type, I put the following definitions in the local props.conf file located in $SPLUNK_HOME/etc/system/local (you may need to create the props.conf file)

[hpss]
EXTRACT-HPSSAgent = Agent: (?P<Honeypoint_Agent>[^ ]+)
EXTRACT-Attacker_IP = from: (?P<Attacker_IP>[^ ]+)
EXTRACT-Port = on port (?P<Port>[^ ]+)
EXTRACT-Alert_Data = Alert Data: (?P<Alert_Data>.+)
TIME_PREFIX = at\s
MAX_TIMESTAMP_LOOKAHEAD = 200
TIME_FORMAT = %Y-%m-%d %H:%M:%S

This tells Splunk how to extract the data from the event. You can also define this in the Splunk web interface by going to Settings -> Source Types and creating a new source type.

Source Type definition

Next create the Index under Settings -> Indexes. Just giving the index a name and leaving everything default will work fine to get started. 

To create a Data Input, go to Settings -> Data Inputs.  I’m going to set it up to directly ingest the data through a TCP socket, but if you already have a setup to read files from a centralized logging system, then feel free to use that instead.

 Set the port and protocol to whatever you would like.

For the source type, manually typing in “hpss” (or whatever you named it) should bring up the already defined source type. Select that, and everything else can remain as is. Then go to review and finish. It’s now ready for you to ship the events to it.

Lastly, we need to get the logs from the Console system to Splunk. Again, this will differ depending on your OS. I will show one way to do this on Windows and one for Linux. However, there are numerous ways to do it. In both cases, replace the IP and Port of your Splunk instance.

On Windows you can use NXLog or another type of eventlog to syslog shipper. After installing NXLog, edit the following into the configuration file.

define ROOT C:\Program Files\nxlog
#define ROOT C:\Program Files (x86)\nxlog

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log

<Input in>
Module im_msvistalog
Query <QueryList>\
<Query Id="0">\
<Select Path="HPConsole">*</Select>\
</Query>\
</QueryList>
SavePos TRUE

</Input>

<Output out>
Module om_udp
Host 192.168.232.6
Port 1514
</Output>

<Route 1>
Path in => out
</Route>

On Linux with rsyslog, create a conf file with the following

:msg,contains,"HPSS Agent" @@192.168.232.6:1514

Now Splunk should be receiving any HPSS events sent to it and storing them in the defined index, and extracting the fields during search queries.

In the future we can look at creating some graphs and analyze the events received. If there is any interest, I can look at creating a Splunk app to configure all of this for you.