Conference Gadget OpSec

I’m getting ready for PuppetConf shortly and that got me thinking about how to survive conferences with your gadgets operations security (opsec) intact. Here are a few things I’ve learned over the last few years, in no particular order:

  • Charge your devices every night. Check them in the morning to see they actually charged; if not, make sure they’re plugged in while you’re taking a shower and getting breakfast so they can survive the long day. Nothing like sitting down in the keynote and realizing your phone is at 20% and it hasn’t even started. Don’t forget to charge any battery packs you brought.
  • Reduce brightness settings on anything with a screen. Your lapaptop, tablet, phone, watch, etc. It should be very low, somewhere between “no-one else can read this” and “I can’t read this.” This serves two purposes:
    • Prevent others from reading your screen. The person behind you probably doesn’t need to read your email, and definitely not your KeePass/LastPass/etc. Nor do they need to be blinded by it during a presentation where the lights are dimmed.
    • Save battery life. You won’t miss as much of the conference and you save yourself from another risky event…
  • Bring your own charging cables/adapters and battery packs. Do not borrow them or use USB charging stations. (If you really must borrow a charge, make sure you trust that person with your digital life.) Most devices use a USB cable of some sort, and in case you haven’t heard, USB security is pretty horrible and opens you up to being rooted and data exfiltration (see BadUSB, Mactans, USB keystroke loggers and plenty of others). It’s just not worth it.
  • Determine if you want to bring your gadgets at all. This is especially true at security-oriented conferences. Hacks abound at these things, including hacking the cell service. If you must bring a device, it might be best to acquire something for use only at that conference and destroy it afterward. That seems harsh, but flashing the device may not remove some infections. Are you willing to risk it?
  • Use a VPN or at least prefer cell service over wifi. Make sure that any data you transmit is protected from malicious and inadvertent snooping. Most of us are not at security conferences where the cell service is hacked, so if you don’t have a VPN it’s probably pretty secure in comparison to wifi, but not always (know the atmostphere). Adding the VPN on top is the best, though. If your company doesn’t provide one, find a trustworthy service or set one up at home.
  • Ensure you have good password hygiene. At a minimum, make sure they’re of reasonable quality and aren’t shared between services. Jessy Irwin talks about this on a Digital Underground PodCast.
  • Don’t log into anything you don’t have to. For persistent-access services, like email or file sync, log in at home so you have a working token and do not need to enter the password again. For anything you need to authenticate to every time, it’s probably not a good idea. Every use of credentials potentially exposes them to onlookers. Pay your mortgage before you leave or after you get back, not from the hotel wifi.
  • Have a Two Factor Authentication (TFA) backup plan. TFA is much more secure than Two Step Authentication (TSA), but often has some limitations for certain use cases that you need to understand. TSA codes can usually be sent to a new device, whereas adding a new device to your TFA device list may require the existing TFA device. If the original is lost or hacked, you may have no way to recover your account, or it may take significant effort above your “worth my time” threshold. Understand what services would be affected and make sure you have another way to recover access. This might include disabling TFA for the duration – if so, ask yourself again if you really want to bring that gadget. This is best thought through before converting a service to TFA, but now is the time to double check.
  • Keep your devices with you, or in something more secure than the hotel safe. Those safes are often easily broken, as shown here and here. Especially at those security conferences. Definitely don’t leave your laptop unlocked and unattended at the bloggers table. Same thing with your charging and battery equipment.
  • If you don’t need a particular gadget, leave it at home. This is so important, I’m mentioning it twice. Earlier I talked about devices being hacked, but you also cannot lose something if it’s in the dresser at home. Maybe you need your phone, but the FitBit can stay.
  • Bring non-gadget backups. This is especially true for payments. If your phone is hacked, lost, or falls in the toilet, make sure you have at least one physical credit card with you.
  • Maintain a list of devices, services, payment methods you travel with. When something bad does happen, it’s really helpful to have a list of what’s affected. Keep a list at home in case you lose it all, as well as taking a (modified?) copy with you. The list should help you determine what you need to recover, but not have information that someone else could use to steal your identity. In other words, “Bank account check card, $phone” is fine, “Bank Of Bad Opsec, $phone, $card_number, $expiration, $ccv” is way too much. If something happens, start making phone calls. If the list was lost as well, that’s why you have a list at home. Make the calls now, do not wait till you get home and find $20k in charges to dispute or that your enter cloud drive was emptied.
  • Be paranoid. It may not come naturally to all of us, but it is key to good OpSec. If you think something might expose you unnecessarily, don’t do it. It is better to be safe than sorry.

I also have one non-opsec tip for conferences: always call your vendor reps and ask what they have going on at the conference. You can usually arrange some one on one time with their engineering team or attend their event where you can meet others using the same products and compare notes.

If you have your own tips, drop them in the comments or send them to me on twitter!

What is a backdoor?

Last month, a significant finding in Fortinet devices was discovered and published. When I say significant, I mean, it’s huge – Multiple Products SSH Undocumented Login Vulnerability. In other words, there’s a username/password combination that works on all devices running the affected firmware versions. If you are still running an affected version, you NEED to upgrade now! This is bad in so many ways, especially following similar issues with Juniper and everything we’ve seen from Snowden’s data dumps. Fortinet responded by saying ‘This was not a “backdoor” vulnerability issue but rather a management authentication issue.’

Is that right? What is a “backdoor” and what is “management authentication”? Is there an actual difference between the two, or is just a vendor trying to save their butt? I got into a discussion about that on twitter:


Ethan challenged me to think about the terminology and I think I’ve come around a bit. Here’s what I now believe the two terms mean.

Continue reading

Deploying MySQL with Puppet, without disabling SELinux

I’ve been vocal in the past about the need to not disable SELinux. Very vocal. However, SELinux can be difficult to work with. I was reminded of how difficult while deploying MySQL recently. Let’s take a look at how to iron out the SELinux configuration for MySQL, and how to deploy it with Puppet I will be using CentOS 6.6 in this article. The package names and SELinux information may vary if you use another distribution.

MySQL Design

Let’s review the design of the MySQL installation before continuing. For the most part, it’s a standard install, we’re not doing any elaborate tuning or anything. All the passwords will be ‘password’ (clearly you should change this in production!). All the anonymous users (@localhost, root@localhost, etc.) will have a password set. An additional ‘replication’ user is created so multiple databases can be replicated and example replication settings are included. The test databases are removed and a single user/database pair of wikiuser/wikidb will be created. We won’t do anything with the database, it’s just an example that can be duplicated as needed.

Continue reading

Fortigate user permissions peculiarities

While working with a customer on their Fortigate firewalls, I was introduced to a peculiarity of how FortiOS interprets user’s diag commands. I suspect this affects multiple versions, but I don’t have the ability to test this.

  • FortiOS: 4.2.x
  • User: wild-card (TACACS)
  • Profile: super_admin_readonly

TACACS users whose permissions elevate them to the super_admin profile are unaffected. They can run diag commands unrestricted as they have full access.

TACACS users whose permissions remain at super_admin_readonly were finding that they could not run diag commands that accessed an interface, such as diag sniff packet any “icmp”. Upon further investigation, the issue was related to the IP the user connected to and the interface (“any” in the example) used in the command. As a readonly user, the any interface is off-limits. The interfaces configured for the VDOM that the user connected to are available to the readonly users.

In other words, if a firewall had two VDOMs, Common and DMZ, and the user connected to any interface connected to the Common interface, only those interfaces would be useable. For instance, diag sniff packet common-outside “icmp” would work, as well as common-inside. Interfaces connected to other VDOMs are off-limits, so diag sniff packet dmz-outside “icmp would fail. By providing the end user a list of the IP addresses and interface names, and the VDOM they belonged to, the user was able to perform all required diagnostic commands.

I hope this is fixed in more recent versions, but at least there’s a workaround that makes some logical sense.

Improving the InfoSec Social Media Community

While attending CPX 2014, I had a mini-epiphany. This twitter thread got me thinking, “Why is CPX so much different than VMworld?” There’s an obvious size difference – 1600 attendees vs 28,000 – which leads to less sessions and smaller parties, but that’s a given. “Why is the InfoSec community different than the Virtualization community?” This is the real concern, the cultural differences between the two communities that have the most overlap with my job responsibilities and personal interests. One notable difference is that in InfoSec, there aren’t many well known practitioners of security, though there are heroes and rockstars. It also seems to be a less vocal community, and when it does speak, it’s in generalities and news, such as 5 Common Attack Vectors or Who Was Hacked This Weekend. In Virtualization, there’s a lot of public recognition for people, even the niche topics, and the community gets down and dirty and shares very practical information in addition to higher level concepts. So, why this startling difference?

Security Practitioners can be insular

Many of you reading this probably first visited this site for virtualization content – which makes sense, as my first posts were on PowerCLI and Auto Deploy. As such, you’re probably familiar with the drill for conferences: get caught up on your timeline by 7am, then prepare for it to be blown up all day long. Check out the feeds for Storage Field Day 5 (#SFD5), the OpenStack Summit (#openstacksummit), and of course, VMworld (#vmworld, #vmworld2013). Dozens, sometimes hundreds, tweet about each keynote, allowing those not attending the pleasure of knowing what’s going on in near-real time. You can sometimes even convince an attendee to ask your question of the presenter! This extends past the keynotes, which are sometimes streamed, to the individual sessions, which are frequently not streamed and sometimes never recorded or put online. Even if you attend, it’s still interesting to read because inevitably another attendee caught something you missed or saw it differently, giving you additional insight (who else learned from Twitter that Cisco wasn’t on the NSX announcement slide at VMworld 2013?). These interactions create a lot of content ancillary to, but just as important, as the conference agenda itself.
Continue reading

Check Point Experience 2014 Recap

Last week, I attended Check Point Experience 2014 (CPX2014) in Washington, D.C. Here are some quick highlights from the conference:

  • There were around 1400 attendees, up from 650 a mere two years ago.
  • Security people cannot properly capitalize VMware either.
  • They also use ‘on-premise’ and make people twitch.
  • There is some conflation between orchestration and automation, and even confusion on what constitutes one or the other.
  • Foreign language translations can be fun! This isn’t a slight against the speakers (I certainly cannot speak their language!), I just think it’s healthy to laugh about these things, especially when the correct word is obvious and the meaning stays intact. If we weren’t always so uptight about things…

There were two more significant lessons I learned at CPX 2014, however.

The first is that Checkpoint has a lot of products that make up what they are calling Software Defined Protection. It’s a neat idea, though some of the products are not GA and hence not usable at this time, leaving the definition somewhat nebulous as far as real world examples go. However, it does define enforcement, control, and management layers (planes) and lays out products that work at each layer, plus pending integration with other tools and standards (a VMware-compatible virtual firewall, REST APIs, etc). Taken together, SDP has the potential to affect design and implementation with an end result not just of increasing security policies, but shortening the gap between malware creation and prevention.
Continue reading