All posts by Michael Buckbee

5 Last Minute Halloween Costume Ideas for IT

5 Last Minute Halloween Costume Ideas for IT

We’ve all been there. Late night. Cold as a witch’s tomb. Deep within the catacombs of the Datacenter. You hear a loud noise and are relieved when it turns out to be a demonic entity from an alternate plane of existence forcing itself into our world and not something genuinely frightening like a RAID enclosure seizing up or a rack toppling over.

But this can only mean one thing: it’s Halloween and here you are without a costume. Varonis is here to help with some last minute costume ideas for the IT professional.

1. Locky Ransomware

Great art comes from a place deep within, just like when in the cinematic tour de force “Suicide Squad”, Jared Leto brought the crazy energy of the Joker to life by leaving dead rats around the set and plotting future visits to Hot Topic to flesh out his character.

Costume Items

  • Combination Locks
  • Bike Chains
  • Mirror (to practice saying: “Yeah! Yeah! Super Weird! Who Would Do Such A Thing!” without flop sweating in).

Directions

Method act your way into being the Locky Ransomware Virus by chaining shut file cabinets, the office fridge and the “good” office bathroom (You know the one? One floor down on the level where sales used to be?).

Be sure to leave a Post It at each location stating that you’ll remove the locks once .2 BTC is deposited in your wallet.

2. Blad the Crimper

Cruelly overlooked by history and eclipsed by his more famous cousin (Vlad the Impaler). Blad is fighting against a society that won’t let him create cables the length that he wants and he’ll stop at nothing to make that happen.

Costume Items:

  • Crimping Tool
  • Dictionary to prove to people that you didn’t just make up the word “crimping”

3. Help Desk Ticket

If it’s one thing that endears you to your co-workers, it’s your insistence on having a help desk ticket for every: “I’ve just got a quick question? Ever since I installed this Free Online Poker website my ‘e’ key doesn’t work. Can you look at why Word won’t print right since the last time you helped me?” that they corner you with.

Costume Items:

  • Posterboard
  • Markers
  • Stapler

Directions:

Bend the poster board around until it makes a cylinder and staple it in place. Use the markers to draw a happy face on it. Place over your head and contemplate why you didn’t go into a less stressful profession like heart surgeon or something.

4. Data Retention Policy

Halloween is a fun time, but it’s also an opportunity to help educate your co-workers on your Data Retention Policy and basic digital security measures.

Costume Items:

  • A paper shredder
  • The longest extension cord you can find.

Directions:

Wander around the office (shredder in tow) removing papers from people’s desks and and turning them into meaningless scraps. Be sure to hit the bulletin board in the lunchroom that’s still cluttered with take out menus from 3 years ago.

If anyone asks why you’re doing this, tell them that they’re part of the problem and if they’d just manage their own files, this wouldn’t be necessary.

5. GDPR: General Data Protection Regulation

Everyone loves a good scare and what’s more frightening than a shadowy group of faceless EU bureaucrats taking 4% of your company’s global revenue because you neglected to purge a server of some old files.

Costume Items:

  • Hans Gruber’s Accent from Die Hard
  • Any countdown app for your smartphone

Directions:

Set the app to countdown to 25 May 2018
Hold it on your forehead “Heads Up” style.
Walk around the Halloween party asking people to divulge everything they know about you under penalty of law.

Krack Attack: What You Need to Know

Krack Attack: What You Need to Know

For the last decade, philosophers have been in agreement that there is another, deeper level within Maslow’s Hierarchy of Human Needs: WiFi Access.

We’re now at the point where even the most mundane devices in your house are likely to be WiFi enabled.

Today we learned that every single one of those devices–every single smartphone, wireless access point, and WiFi-enabled laptop–is vulnerable due to a fundamental flaw with WPA2(Wireless Protected Access v2).

It turns out that the WPA2 (Wireless Protected Access v2) protocol can be manipulated into reusing encryption keys in what’s being called the Krack Attack

The result?

Attackers can view and compromise your encrypted traffic, inject ransomware code, hijack your credentials, and steal sensitive information like credit card numbers, passwords, emails, photos, and more.

Who Is Affected?

Because of how it works, this attack threatens all WiFi networks – and WiFi-enabled devices.

While the flaw is in the WPA2 protocol itself, how that protocol is implemented differs across device and software vendors. Apple’s iOS devices and Windows machines are mostly (as of now) unaffected since they don’t strictly implement the WPA2 protocol and key reinstallation.

The largest group affected are Android users and those other client devices that implemented the WPA2 protocol very strictly.

How the Attack Works

The attack works against WiFi clients and depends upon being within WiFi range of the target device. Attackers can use a special WiFi card that retransmits a previously used session key which forces a reinstallation of that key on the client device.

By doing so (and depending on exactly how WPA2 is implemented on the client device), the attacker can then send forged data to the client. For example, an attacker could silently manipulate the text and links on a web page.

How Practical Is the Attack?

An interesting twist to this attack is that it depends much more upon physical proximity in order to compromise a client since you need to be in WiFi range. An attacker also needs a somewhat specialized networking device and to be able to code up the exploit manually – since no software has yet been released for this attack.

What You Can Do To Protect Yourself Today

The more encryption you run at different layers of the communications stack the better. If you’re in charge of a website, this is just one more in a vast list of reasons you should be forcing SSL/TLS on your site.

VPNs are also a strong (additional) option: they’re inexpensive, easily configured, and can make Krack much less of an issue. An attacker can view/capture the encrypted data but won’t be able to do anything with it.

What You Can Do In The Coming Weeks

Update your devices – and be mindful of where and on what devices you’re using WiFi.

Every vendor is likely going to release a patch addressing this vulnerability: install the next product update that gets pushed to you – and encourage those around you to install security updates.

Neglected security updates are actually a large and persistent vulnerability: they’re there for a reason – install them! Greater adoption helps everyone. If you need more convincing, check out Lesson 4 of Troy Hunt’s Internet Security Basics.

What You Can Do Long Term

This may spark more (and long-needed) research into the areas of WiFi vulnerabilities.

While you can’t entirely prepare for the unknown, you can set yourself up to respond quickly by establishing good procedures for emergency patch management, implementing defense in depth by layering multiple different security systems and keeping all of your systems as up to date as possible.

This attack highlights that it’s important not to rely solely on any single layer of defense. For many home networks, this is, unfortunately, their only security layer. Always consider what happens when a layer of defense fails.

[Podcast] The Anatomy of a Cybercriminal Startup

[Podcast] The Anatomy of a Cybercriminal Startup

Leave a review for our podcast & we'll send you a pack of infosec cards.


Outlined in the National Cyber Security Centre’s “Cyber crime: understanding the online business model,” the structure of a cybercrime organization is in many ways a lot like a regular tech startup. There’s a CEO, developer, and if there are enough funds, an IT department.

However, one role outlined on an infographic on page nine of the report that was a surprise and does not exist in legitimate businesses. This role is known as a “money mule.” Vulnerable individuals are often lured into these roles with titles such as “payment processing agents” or “money transfer agents.”

But when “money mules” apply for the job and even after they get the job, they’re not aware that they are being used to commit fraud. Therefore if cybercriminals get caught, “money mules” might also get in trouble with law enforcement. The “money mule” can expect a freeze on his bank account, face possible prosecution, and might be responsible for repaying for the losses. It might even be on your permanent record.

Other articles and threads discussed:

Tool of the week: SPF Translator

Panelists: Mike Buckbee, Kilian Englert, Mike Thompson

[Podcast] How Weightless Data Impacts Data Security

[Podcast] How Weightless Data Impacts Data Security

Leave a review for our podcast & we'll send you a pack of infosec cards.


By now, we’re all aware that many of the platforms and services we use collect and store information about our data usage. Afterall, they want to provide us with the most personalized experience.

So when I read that an EU Tinder user requested information about her data and was sent 800 pages, I was very intrigued with the comment from Luke Stark, a digital technology sociologist at Dartmouth University, “Apps such as Tinder are taking advantage of a simple emotional phenomenon; we can’t feel data. This is why seeing everything printed strikes you. We are physical creatures. We need materiality.”

He is on to something. We don’t usually consider archiving stale data until we’re out of space. It is often through printing photos, docs, spreadsheets, and pdfs that we would feel the weight and space consuming nature of the data we own.

Stark’s description of data’s intangible quality led me to wonder how weightless data impacts how we think about data security.

For instance, when there’s a power outage, some IT departments aren’t deemed important enough to be on a generator. Or when Infosec is often seen as a compliance requirement, not as security. Another roadblock security pros often face is when they report a security vulnerability – it’s not usually well received.

Podcast panelists: Mike Buckbee, Kilian Englert, Mike Thompson

[Podcast] When Hackers Behave Like Ghosts

[Podcast] When Hackers Behave Like Ghosts

Leave a review for our podcast & we'll send you a pack of infosec cards.


We’re a month away from Halloween, but when a police detective aptly described a hotel hacker as a ghost, I thought it was a really clever analogy! It’s hard to recreate and retrace an attacker’s steps when there are no fingerprints or evidence of forced entry.

Let’s start with your boarding pass. Before you toss it, make sure you shred it, especially the barcode. It can reveal your frequent flyer number, your name, and other PII. You can even submit the passenger’s information on the airline’s website and learn about any future flights. Anyone with access to your printed boarding pass could do harm and you would never know who your perpetrator would be.

Next, let’s assume you arrive at your destination and the hotel is using a hotel key with a vulnerability. In the past, when hackers reveal a vulnerability, companies step up to fix it. But now, when systems need a fix and a software patch won’t do, how do we scale the fix for millions of hotel keys when it comes to hardware?

Other articles discussed:

Tool of the week: Gost: Build a local copy of Security Tracker. 

Panelists: Kilian Englert, Forrest Temple, Mike Buckbee

What You Can Learn About How to Secure an API from the FCC

What You Can Learn About How to Secure an API from the FCC

Every day thousands of phishing emails are sent to unsuspecting people who are tricked into handing over their credentials for online services or directly bilked out of their money. Phishers go to great lengths to lean on the credibility of the organizations they’re impersonating. So what could be better than the ability to post a document onto an actual official website?

Recently, it came to light that as part of the FCC’s public commenting system that malicious individuals could upload their own PDFs and image files to the FCC’s site. These files are indistinguishable from official communications that the agency might post – and the potential to abuse that vulnerability is incredibly high.

Just think of the implications of this capability: Phishers could use hosted PDFs to level fake fines on people. Stock market manipulators could post fake FCC sanctions for public companies. Not surprisingly, trolls and mischief makers are already generating fake FCC memos mocking the agency.

Service Oriented Security Issues

It’s since been fixed, but when reported, the FCC’s commenting application was utilizing an internal app API they had built. For large or complex applications, this style of building a single user facing application out of smaller component apps is becoming more common. This type of Service Oriented Architecture (SOA) can let you build powerful applications more simply (you could imagine that there are many applications the FCC might built that would require the ability to attach files), but greatly increases the potential surface area for attacks.

What’s an API Key Really?

To utilize their own FCC File Upload App, they issued themselves an API key to the application. While the term ‘key’ brings up associations of Public Key Cryptography and and the Public and Private keys used for SSH, an API key is really better considered to be just a password.

Typically they’re long randomly generated sets of characters, like: ‘20yhy3093-3asdfewer34093049-2394xcv02” but there’s no reason an API key couldn’t be something like “this-is-my-super-secret-password-api-key”.

In many ways it’s just as insecure if you were able to log into an application using only a password (With no username).

API Exposure

The FCC’s original commenting application pre-assigned a URL for uploading from their file handling application. In the process of this they also exposed the API key that they’d assigned to the larger commenting app.

Hackers and mischief makers were then able to reuse that same API key (essentially impersonating the legitimate FCC app) to make calls placing extremely questionable files on the FCC server among other actions.

API Issuance

Separate from the above leak of their own API key, it was also found that the FCC was issuing official API keys to anyone who asked. While the intent and possibilities here were great: developers could find interesting aspects about FCC data, or build their own clients to interact with FCC servers, they didn’t take into consideration all the different ways that the system could be abused.

What Are the Lessons?

The internet has identified a huge vulnerability in the FCC’s site – leaving them open to a whole mess of abuse.

Properly authorizing API access is notoriously tricky and there are a few key areas that are paramount to maintaining a secure state:

Keep your own public API key private. Use a secrets management store, or at least don’t check them into source control and call them from environment variables.
Monitor API keys and manage who has access to them in the first place (pro-tip: most people shouldn’t have access)
Separate the publicly modifiable aspects of your service from official communications.

Beyond API Keys

API key issuance as a means of authentication and authorization is in many ways on the way out. It’s too brittle. There isn’t an efficient means to indicate what modules of a larger system an API key should have access to (scoping) and often times there isn’t a great way to revoke privileges once given.

The general solution to all of these challenges is use OAuth. We’d recommend checking out our: Introduction to OAuth post to start learning more.

Wrapping Up

The intersection between an organization’s own services and the public is a highly valuable area that needs to be secured. A century ago it was faked telegraphs and memos sent on stolen letterhead. A decade ago it was common for email servers (or even just HTML forms connected to services that send emails) to be coerced into sending messages from a phisher that look as if they originate from the legitimate organization.

Today it’s API abuse. Just the latest method that horrible people on the Internet are using to defraud people. As you build and secure systems, focus on protecting your data, your users and your organization’s credibility.

Dedham Savings Uses Varonis to Build Trust with Their Customers and Stop Su...

Dedham Savings

Dedham Savings Case Study

Trust is important in all relationships, but even more so for a community bank like Dedham Savings. Charged with protecting the sensitive financial data of their customers, Dedham turned to Varonis.

During a Varonis risk assessment, they discovered a large amount of stale customer data on their network: data that they could immediately take off the network, reducing the potential severity of a data breach and instantly improving their security posture.

With default network tools, it’s hard for any IT team to deeply understand exactly what is happening on their network – and they don’t have insight into the behaviors of users on their network: what files they’re using, what they have access to but really shouldn’t and how their network access profile matches others in their department.

As Jim Hanlon, Senior Vice President & CTO of Dedham Savings Bank, says: “The more customer data that you have on your network, the more risk there is. You really do need [something] like Varonis managing these vast amounts of data and to protect your customer data” – see how Dedham Savings uses Varonis in this quick one minute video.

How to Better Structure AWS S3 Security

How to Better Structure AWS S3 Security

If the new IT intern suggests that you install a publicly accessible web server on your core file server – you might suggest that they be fired.

If they give up on that, but instead decide to dump the reports issuing from your highly sensitive data warehouse jobs to your webserver – they’d definitely be fired.

But things aren’t always so clear in the brave new world of the cloud – where services like Amazon’s Simple Storage Service (S3), which performs multiple, often overlapping roles in an application stack, is always one click away from exposing your sensitive files online.

Cloud storage services are now more than merely “a place to keep a file” – they often serve as both inputs and outputs to more elaborate chains of processes. The end result of all of this is the recent spate of high profile data breaches that have stemmed from S3 buckets.

An S3 Bucket Primer

S3 is one of the core services within AWS. Conceptually, it’s similar to an infinitely large file server at a remote site or a FTP server that you’re connecting to from across the Internet.

However, S3 differs in a few fundamental ways that are important to understand: failing to do so will trip you up and may result in insecure configurations.

S3 is organized around the concepts of Buckets and Objects, instead of servers with files.

Buckets are the top level organizational resource within S3 and are always assigned a DNS addressable name. Ex: http://MyCompanyBucket.s3.amazonaws.com

This might trick you into thinking of a bucket like a server, where you might create multiple hierarchies within a shared folder for each group that needs access within your organization.

Here’s the thing:

  • There’s no cost difference between creating 1 bucket and a dozen
  • By default you’re limited to a 100 buckets, but getting more is as simple as making a support request.
  • There is no performance difference between accessing a 100 files on one bucket or 1 file in a 100 different buckets.

With these facts in mind, we need to steal a concept from computer science class: the Single Responsibility Principle.

Within a network, a file server is a general resource typically used by lots of different departments for all kinds of work.

S3 allows you to devote a bucket to each individual application, group or even an individual user doing work. For security (and your sanity as a sysadmin) you want the usage of that bucket to be as narrowly aligned as possible and devoted to a single task.

A significant number of the unintentional data exposure incidents on S3 appear to have been caused by public facing S3 buckets (for websites) that were also (likely accidently) used for the storage of sensitive information.

Sidebar: A warning sign is often found in the bucket naming. Generic, general names like: ‘mycompany’ or ‘data-store’ are asking for trouble. Ideally you should establish a naming convention like: companyname-production/staging/development-applicationname

Bucket Policies

Policies are the top level permission structures for buckets. They define:

  • Who can access a bucket (what users/principals)
  • How they can access it (http only, using MFA)
  • Where they can access it from (a Virtual Private Cloud, specific IP)

Policies are defined in blocks of JSON that you can either write by hand or use AWS’s Policy Generator – https://awspolicygen.s3.amazonaws.com/policygen.html – to create.

Benefit #1 of organizing your buckets into narrowly defined roles: your bucket policies will be an order of magnitude simpler, since you won’t have to try to puzzle out conflicting policy statements or even just read through (up to 20kb!) of JSON to try and reason out the implications of a change.

Example Bucket Policy



{
  "Version": "2012-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::examplebucket/*",
      "Condition": {
         "IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
         "NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"} 
      } 
    } 
  ]
}

Narrow buckets mean simpler policies, which in turn mean less likelihood of accidentally over permissioning users – and unintentionally creating a data breach.

Think of Bucket Policies as how the data should be treated.

IAM Policies in S3

Identity and Access Management IAM policies, on the other hand, are all about what rights a user/group has to a resource in AWS (not just S3).

You can apply both IAM and Bucket policies simultaneously: access attempts will calculate the least privilege union of the two policies and take action accordingly.

Further Reading: IAM Policies and Bucket Policies and ACLs! Oh, My!

VPC Endpoints in S3

A very powerful, but often underutilized tool in securing AWS services is to divide applications into different logically separated application groups inside of a Virtual Private Cloud.

On a grander scale than simply designating a bucket for a particular purpose, a VPC is a logically separated set of Amazon Web Services (including S3) that can be cordoned off for greater security.

Most of the large databreaches that have surfaced regarding groups using S3 have NOT been website related. Organizations are using a variety of AWS’s tools like RedShift and Quicksite to do analysis of massive amounts of (potentially) sensitive data: analysis, reports and raw data that should not be placed on a public network.

The tool of choice to separate this is AWS’s Virtual Private Cloud. With VPC you can define a set of services that will be unable to connect to the general Internet, and only be accessible via a VPN (IPSEC) connection into the VPC.

Think of a VPN connected VPC as a separate section of your internal network – and resources like S3 within the VPC aren’t publicly addressable:

  • A bot scanning for open buckets won’t be able to see them.
  • Your new data scientist can’t accidently leave a bucket publicly accessible because they were trying to download a report.
  • Day to day users of the services don’t have to try and figure out if their actions will cause chaos and destruction.

Enable S3 Logging

By default, S3 doesn’t maintain access logs for objects (files) in a bucket. On a per bucket basis you can enable access logs to write to another S3 bucket.

http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html

Reviewing access periodically can give you great insight into if your data is being accessed from an unknown location, or in the case of a data breach, how and when exfiltration occurred.

S3 stores raw logs to the logging bucket where you can parse them with a number of different open source tools, like:



More recently, AWS Athena was launched. It’s a new service that lets you directly run SQL queries against structured data sources like JSON, CSV and log files stored in S3.

In Conclusion

AWS S3 is a powerful and extremely useful service that increases the capabilities of IT and application groups. Properly administered, it can be a safe and powerful tool for data storage and as the base of more complex applications.

Steps to keep your data secure on AWS S3:

  1. Review which of your S3 buckets are open to the public internet
  2. Split S3 Buckets to 1 per application or module
  3. Separate concerns with VPC S3 Endpoints
  4. Log everything

[Podcast] Blackhat Briefings That Will Add to Your Tool Belt

[Podcast] Blackhat Briefings That Will Add to Your Tool Belt

Leave a review for our podcast & we'll send you a pack of infosec cards.


We’re counting down to Blackhat USA to attend one of the world’s leading information security conference to learn about the latest research, development and trends.

We’ll also be at booth #965 handing out fabulous fidget spinners and showcasing all of our solutions that will help you protect your data from insider threats and cyberattacks.

In this podcast episode, we discussed not only sessions you should attend, but also questions to ask that will help you reduce risk. We even covered why it isn’t wise to only rely on important research methods like honeypots save you from insider threats or other attacks.

Tool of the Week: Virtual Private Cloud (VPC)

Panelists: Kris Keyser, Kilian Englert, Mike Buckbee

[Podcast] Cyber Threats Are Evolving and So Must Two-Factor

[Podcast] Cyber Threats Are Evolving and So Must Two-Factor

Leave a review for our podcast & we'll send you a pack of infosec cards.


Finally, after years of advocacy many popular web services have adopted two-factor authentication (2FA) as a default security measure. Unfortunately, as you might suspect attackers have figured out workarounds. For instance, attackers that intercept your PIN in a password reset man-in-the-middle attack.

So what should we do now? As the industry moves beyond 2FA, the good news is that three-factor authentication is not on the shortlist as a replacement. Google’s identity systems manager, Mark Risher said, “One of the truths we’ve found is that people won’t accept more security than they think they need.”

There have been talks about using biometrics as a promising form of authentication. In the meantime, know that using 2FA is more secure than using just a password.

Other Articles Discussed:

Panelists: Rob Sobers, Mike Buckbee, Kilian Englert

[Podcast] Budgets and Ethics

[Podcast] Budgets and Ethics

Leave a review for our podcast & we'll send you a pack of infosec cards.


Right now, many companies are planning 2018’s budget. As always, it is a challenge to secure enough funds to help with IT’s growing responsibilities. Whether you’re a nonprofit, small startup or a large enterprise, you’ll be asked to stretch every dollar. In this week’s podcast, we discussed the challenges a young sysadmin volunteer might face when tasked with setting up the IT infrastructure for a nonprofit.

And for a budget interlude, I asked the panelists about the growing suggestion for engineers to take philosophy classes to help with ethics related questions.

Other Articles Discussed:

Tool of the week: honeyλ, a simple, serverless application designed to create and monitor URL {honey}tokens, on top of AWS Lambda and Amazon API Gateway

Panelists: Kilian Englert, Mike Thompson, Mike Buckbee