Category: Security

Jul 16

How To Write A DNSSEC Practice Statement (DPS)

Are you planning to start using DNSSEC with your domain – and are you planning to start signing your domain yourself? In other words, are you going to be doing all the signing on your own server and/or in your own facilities?  (Versus using a service at a DNS hosting provider that does all the DNSSEC-signing for you.)

If you are, then a good place to start your planning is with the creation of what is called a “DNSSEC Practice Statement” or more simply a “DPS”.  A DPS is a document that outlines how you are implementing DNSSEC for your domain – and what security measures you are putting in place.

Basically, it is a statement that can help other people understand whether they can trust the security you put in place.

Typically the DPS documents created so far are for Top-Level Domains (TLDs) as they have been the focus of much of the DNSSEC deployment efforts to date.  For second-level domains, very often you may be able to use the services of your DNS hosting provider to sign your domains and so a full DPS may not be needed. But if you sign your own domain, a DPS can be a useful way to plan out the security for your signing.

Regardless of what you do, the existing DPS documents make for great reading to help you understand the security you may or may not need to put in place to ensure the security and integrity of our DNSSEC operations.

The place to begin for many of you may be to take a look at this Internet-Draft that explains the rationale for creating a DPS and provides a sample framework:

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework

Some of you who like to simply dive into examples to see how a DPS is written may want to start looking through the examples we’ve added to this page:

DNSSEC Practice Statements

In particular you may want to start with the “.SE” DPS as the folks from .SE have been very involved with creating the entire DPS framework.  As you look through the examples, you’ll see a variety of different styles and lengths, from the very simple to the very complex.

If you have 15 minutes to spare, this video from 2010 offers Anne-Marie Eklund-Löwinder from .SE explaining the value of a DPS and what should be included:

The important aspect of a DNSSEC Practice Statement is to capture in one document how you are implementing DNSSEC and how you are securing the tools, servers and other components involved with DNSSEC.  Even if you are an enterprise who might never publicly publish a DPS, writing such a document can be a very useful exercise to ensure you are planning for all the necessary aspects of using DNSSEC to sign your domain.

P.S. If you create and publish a DPS, we’re always looking for more examples to add to our DPS page. Please let us know where your DPS is located online so that we can consider adding it to the page.

Jun 20

Webinar TODAY on IPv6 Security By Researcher Joe Klein

Want to understand the security aspects of IPv6?  In about 8 hours, at 4:00pm US Eastern on June 20, 2012, security researcher Joe Klein will be giving a presentation on “IPv6 – Security Threat or Stronger Defenses?”

The webinar/webcast/whatever-you-want-to-call-it is part of a series of information security seminars scheduled through BrightTALK.  We have no affiliation with either Joe Klein or BrightTALK, but we’ve interviewed Joe before about DNSSEC security and based on that think this should be an interesting presentation.  The abstract for the session is:

For the last 15 years, IPv6 has been specified and tested, and is now embedded in many of our operating systems and devices.  The presentation will discuss the current IPv6 threat and mitigation landscape, covering a long history of compromises while also discussing methods that allow new security frameworks and innovative defenses that are not available in the current IPv4 Internet

There is no cost for attendance, although you do have to provide BrightTALK with all of your contact information. Presumably an archive will be available for later viewing if you are unable to watch it live, as that is typically how these sessions are structured.

 

 

May 23

New Nmap Version 6 Provides Full IPv6 Support, Useful IPv6 Tools

NmapThe big news this week out of The Nmap Project was the release of Nmap 6, “the product of almost three years of work, 3,924 code commits, and more than a dozen point releases since the big Nmap 5 release in July 2009.” The big addition of interest to us, of course, was the deep support for IPv6, detailed in a lengthy section at:

http://nmap.org/6/#changes-ipv6

Nmap (“Network mapper”) is a free utility for scanning networks that has been available since 1997 and is a key tool for network and systems administrators, not just for security but also for managing networks. Nmap has had support for IPv6 since 2002, but just in time for World IPv6 Launch the appropriately named Nmap 6 provides full IPv6 support, including:

  • easy usage by just adding “-6” to the command line
  • raw IPv6 port scanning
  • IPv6 operating system detection system
  • a range of IPv6 host discovery techniques (given that brute-force scanning of IPv6 address space is problematic)
  • IPv6 Neighbor Discovery ping
  • an IPv6-only scanning test sitePlus the various websites associated with Nmap have been dual-stacked so that they can be reached over IPv4 or IPv6.

And, as a bonus for the old-skool crowd, this gem could be found later in the release notes:

Nmap now supports the old-school Gopher protocol thanks to our handy gopher-ls NSE script. We even support Gopher over IPv6!

So for all of you out there with gopher servers running on IPv6, nmap will work for you!

Seriously, though, the IPv6 support found in Nmap 6 will go a long way in helping network administrators understand what IPv6 devices are running on their network. Available for download for Linux, Windows, Mac OS X or in source form, Nmap 6 is a tool you’ll want to have. I’ve already installed it on my systems and look forward to trying out these new options!

Apr 25

Microsoft Security TechCenter: DNSSEC and DNS Amplification Attacks

Security Tech Center LogoWhat are the security risks related to using DNSSEC with regard to “DNS amplification attacks”? In a recent article at Microsoft’s Security Tech Center, Greg Lindsay dives into exactly that question.

First, though, he explains how a DNS amplification attack is a form of a Distributed Denial of Service (DDoS) attack that uses DNS queries combined with source address spoofing to send a large volume of traffic at a target system. He provides some examples of exactly how such an attack could be carried out.

Nicely, we get to see some examples of how DNSSEC will be implemented in the forthcoming Windows 8, both at the command line and in the GUI.  (I will be curious as Windows 8 rolls out to learn more about the “DNSSEC zone signing wizard” apparently available in the DNS Manager.)

He ends with a note that:

Signing a DNS zone and adding DNSSEC records to a DNS response increases the total size of a response, but does not increase the risk for DNS amplification past the existing limit placed on the server for UDP response size. 

Since the TCP conversation cannot be easily spoofed, these additional records do not inherently increase the severity of DNS amplification attacks.

and concludes with useful advice about how to help prevent DNSSEC amplification attacks.

I found it a very useful article regardless of whether you use Microsoft DNS servers or not.  Good to get this kind of information out there so that IT security teams can understand how to address and mitigate potential risks.

 

Apr 24

New Internet-Draft: Security Implications of IPv6 on IPv4 networks

IETF LogoWhat are the security implications of having native IPv6 support on IPv4-only networks? What are the security implications of the automatic enabling of IPv6 transition mechanisms such as tunneling?

In a new Internet-Draft out this week, security researcher Fernando Gont of the UK’s Centre for the Protection of National Infrastructure seeks to explore those very questions:

http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets

As the abstract says:

This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on “IPv4-only” networks, and describes possible mitigations for the aforementioned issues.

and the introduction states in part:

Most general-purpose operating systems implement and enable by default native IPv6 support and a number of transition-co-existence technologies.  In those cases in which such devices are deployed on networks that are assumed to be IPv4-only, the aforementioned technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes.

For example, a Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/co-existence technology is leveraged for that purpose.  Additionally, an IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6.  Finally, some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network.  Thus, these mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure.  That is, the aforementioned technologies might inadvertently allow incoming IPv6 connections from the Internet to hosts behind the organizational firewall.

In general, the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled traffic.  Among such controls is the enforcement of filtering policies, such that undesirable traffic is blocked.

Fernando Gont goes on to discuss the various threats and the ways to mitigate the threats on the edge of the IPv4-only network.

This is only the initial draft of this document and while it certainly may evolve through the IETF process, it is already a good start for IT security staff seeking to understand how to allow IPv6 on internal networks while preserving network security.  Some of the advice to IT security teams out there on the Internet is just to “disable IPv6″… but the reality is that with World IPv6 Launch in June and the continuing IPv4 address depletion, turning off IPv6 is no longer a smart answer.  Far better to look at documents like this and understand how to secure your infrastructure while enabling IPv6 experimentation and usage.

Kudos to Fernando Gont for putting this document together and we look forward to seeing it develop further. He is seeking comment so if you do have feedback on the document, his contact information is at the end.

Apr 23

WordPress 3.3.2 Out With Security Fixes – Upgrade Now!

Wordpress orgIf you are a user of WordPress, as I am for several of my sites, you really should update your site to WordPress 3.3.2. If you take a look at the Codex page for the release:
http://codex.wordpress.org/Version_3.3.2

You'll note that the release is pretty much all about security fixes to underlying libraries and other aspects of the software.

While yes, I'm a "security guy" who may care about these kind of things more than others, the reality is that I'm in the "content business" and I want my content always to be available. Having my site taken down by attackers is NOT a way to do that.

So I always upgrade WordPress - particularly when there are security issues involved.

The beautiful thing is that you should just be able to go into your site and click the "Update automatically" link to make it happen. Yes, backup your database first to be safe... but do go in and do the update.

Particularly because if the upgrade fixes "cross-site scripting attacks", you have to know that attackers are out there right now trying to exploit those attacks against sites that have NOT yet upgraded.

So don't be a target... upgrade!

If you found this post interesting or useful, please consider either:

Feb 23

Three Critical Reasons High Schoolers Should Restrict The Privacy Of Their Facebook Pages

Tonight purely by accident I stumbled upon the Facebook page of a student I know at one of our local high schools. I didn't know he was on Facebook but he had commented on a post in my NewsFeed by someone who turns out to be a mutual friend.

Curious to know if it was the person I thought it was, as his Facebook profile picture was not a photo of him, I clicked on the link to his name expecting to see the standard "basic info" you see for everyone and then the privacy message that usually greets you:

Privacy

Instead, I saw everything...

Walls Wide Open

His Facebook "Wall" was wide open for all to see.  Anyone. I saw all his posts... all his photos... all the comments between him and his various friends. I clicked on the Info link and learned all about where he goes to school (which I knew), his musical tastes, the sports he likes, movies, television shows, games, religious views...

And I got to see all of his friends...

... probably a good half of whom ALSO had wide open walls.

In the course of maybe 10 or 15 minutes of flipping around, I learned a good bit about some of the region's high school age students, saw a whole bunch of photos, read a few conversations that probably weren't meant to be public (or at least to be read by 40+ year-old men sitting at home on their computers)...

...and generally got increasingly concerned about the amount of information these students were perhaps inadvertently disclosing about themselves and their lives.

Now, this is, after all, what Facebook seems to want. They generally default to public sharing, and so if you don't take active steps to protect your privacy, all your content will be shared with the world. And while some people are quite okay with that, I'm personally not.

If I could say anything to these high schoolers or their parents - and to all the others reading this post, it would be that there are three critical reasons why you might want to think about restricting your Facebook privacy a bit more.

1. Security

The most obvious one is the security angle. There are a lot of sickos out there. I've been online for now almost 30 years and I've seen all sorts of seriously warped stuff... information security has always wound up as part of what I've been involved with, and some of what I've had to do has taken me to seriously vile and heinous parts of the Internet.

There are warped people out there. There are thieves and scammers and fraudsters and perverts and others who prey on people online. They've always done this... Facebook just makes it ultra-easy to do. They can start commenting or "liking" your posts and photos. Striking up friendships. Sending you messages. Wanting to meet, etc., etc.

With your wall wide open, you are giving them all the info they need for "social engineering" to know exactly what to say to you. They know the music you like, the TV shows you like, etc. They've seen your photos, so they know what you look like, what you like to wear, etc. It's insanely easy for them to gain your confidence and trust.

You are also giving them your location. You are letting them know where you are, what you are doing. It's a wonderful way that your friends can know where to meet you (and it is. I personally use it that way.)... it's unfortunately also a way for a stalker to find you. And sure, it may not ever happen in your town/city, but why give out all this info when you don't really need to?

You also give away where you are not. Believe it or not, people's homes have been robbed after they were posting publicly about going away from their homes.

Location info... and really all this personal information... is really best shared only with those you trust.

2. Employers Check Facebook

The second reason to restrict your info is because if you are a high school student looking for even a part-time job, guess what that potential employer is going to do?

Yes, they (or at least the smart ones) are going to search for you on Google and Facebook and see what turns up.

In 2012, you're pretty crazy as an employer if you are NOT doing background checks on the Internet. Who needs to call references when you can just go to a search engine and learn more about potential employees than you probably ever wanted to know? (including all the "stupid sh__" they did last weekend?)

It's real. It happens. And stuff lives on in Google's caches far longer than you would ever think.

3. Colleges Check Facebook

In a similar way, college admission officials check Facebook. (Another article claims 80% of colleges use Facebook in recruiting.) Need I say more?

If you are in the process of applying to colleges, you probably don't want admissions officials reading your wall conversation with a friend where you are trashing one potential college and talking about another. Nor do you potentially want them seeing your writing, spelling, photos, etc. (unless, of course, it's awesome and might help you get into a school).

Managing your "online reputation" is something that you have to start thinking about NOW.

How To Close The Walls

To start, the best thing to do is to go into Facebook's "Privacy Settings" that, today, anyway, are found in the drop-down arrow next to your name in the upper right corner of the web version of Facebook:

FacebookSettings

Facebook unfortunately has a way of changing these settings around from time to time. But if you go down to "Privacy Settings" you'll get the window you see below, where you can make two important changes:

  1. Set your default privacy to "Friends".
  2. Change all past posts to be set to "Friends".

FacebookPrivacySettings

Note that when you click that "Manage Past Post Visibility" you'll see a window pop up that warns you that all posts shared with friends or the public in the past will be restricted. Then you'll get ANOTHER window just confirming that you really, really want to do this and warning you that you can't undo it and will have to manually change it on each post if you want to share those posts publicly again. Finally, you'll be able to change the setting.

You may also want to click "Edit Settings" next to "How You Connect" and restrict who can find your profile, who can send you messages, who can write on your timeline, etc. Here are my settings, which I have changed from whatever Facebook sets as the default settings (probably "Everyone" for all of them):

FBPrivacySettings

If you do these three steps,

nothing will really change for you on Facebook!

You'll still be able to interact with your friends. You'll still be able to write on each other's walls. You can still tag each other in photos, send each other messages, etc.

It's just that now when anyone who isn't your friend goes to see your Facebook profile... whether they are other students who aren't your "friend", parents of other students, potential employers, college admission officials... or sick creeps... or just random people out on the Internet... all they will see is this:

Privacy

All that other personal information stays within the circle of the people you have accepted as "Friends" on Facebook.

And YOU are in control of what employers, college admission officials and everyone else sees.

NOTES:

  1. These privacy settings do not completely remove the chance your info can be publicly disclosed. Your info and photos go out to your Friends' Newsfeeds, and they can then in turn "share" your info out to other people... and somewhere along the way may be someone whose settings are more public. However, you are greatly restricting the potential of that with these settings.
  2. There's a separate conversation that could be had about how you could selectively post certain items publicly to create a public profile that would actually be positive for employers/colleges to see.  For instance, notes about awards you've won, volunteer activities you've accomplished, great photos you've taken or articles you've written, etc.  But again, you are in control of that information.

If you found this post interesting or useful, please consider either:

Dec 02

Today’s VUC Call – Philippine Phone Phreaking Funding Terrorists

For those interested in telecommunications security, today's (Dec 2, 2011) VoIP Users Conference (VUC) call at 12 noon US Eastern will cover the recent arrests of 4 Philippine men who defrauded AT&T of close to $2 million and were employed by an alleged terrorist organization who was using the proceeds of the scam to fund their activities.

Eric Klein of Humbug Labs will be the guest on the VUC call discussing this and other fraud issues. It should be an interesting discussion.

You can join the live call via SIP, Skype or the regular old PSTN. There is also an IRC backchannel that gets heavy usage during the call. It will be recorded so you can always listen later.

If you found this post interesting or useful, please consider either:

Dec 02

Philippine Phone Phreakers Arrested After Funding Terrorists

CIDG

One of the big news items in telecom security this past week was the arrest in Manila of 4 men accused of defrauding AT&T of almost $2 million USD and then using those funds to finance a terrorist organization. The Philippine National Police issued a statement (annoyingly you have to scroll down to the “November 24, 2011″ entry) that explained the terrorist link:

Sosa said that Kwan and the other hackers in Manila were being used by the Zamir’s terrorists group to hack the trunk-line (PBX) of different telecommunication companies including the AT&T. Revenues derived from the hacking activities of the Filipino-based hackers were diverted to the account of the terrorists, who paid the Filipino hackers on a commission basis via local banks.

The joint operation between the Philippine Criminal Investigation and Detection Group (CIDG) and the US FBI is per the statement a result of a long-standing effort within the FBI to combat this kind of fraud.

It’s not clear yet exactly how the fraud was perpetrated and whether or not there was any “VoIP” involved. Ars Technica, in a lengthy piece, “How Filipino phreakers turned PBX systems into cash machines for terrorists, indicates that the attackers used traditional attacks against PBXs to compromise voicemail systems that allow outbound calling (DISA) and then passed that list of compromised PBXs along to others who sold this access as a way to cheaply call into premium rate services (similar to 900-numbers in the US).

There’s also a note in the Ars Technica article that the attackers used good old default passwords to get into many of these PBXs. :-( Assuming the prosecutions move forward we will hopefully learn more as the cases go to trial.

Regardless of the precise mechanism, it’s a great reminder that people need to check the traditional security mechanisms of their PBX systems, and REMOVE/CHANGE default passwords!

If you are interested in discussing this case, it will be the topic of today’s (Dec 2, 2011) Voip Users Conference (VUC) call at 12 noon US Eastern. All are welcome to join – or to listen to the conversation later once the recording is posted.

Oct 25

All Mobile Apps Developers (iOS, Android, Windows, Blackberry, etc.) Need To Read Troy Hunt’s Post

As I mentioned on my Disruptive Telephony blog today, this post by Troy Hunt really should be mandatory reading for anyone developing applications for mobile platforms:

Secret iOS business; what you don’t know about your apps

Yes, his post is about Apple’s iOS, but I’m unfortunately rather confident that the results would be similar if someone were to do a similar analysis with a proxy server on apps on Android, Blackberry, Windows Phone 7, WebOS and any other mobile platform.

These are application design problems.

As programmers, we all take “short cuts” from time to time… I’m as guilty of that as anyone… but sometimes those shortcuts have grave consequences.

Mobile developers need to read Troy’s piece… and then look at their own apps and see how they can change. Actions like:

  1. Securing the transport of login credentials! (DUH!!!)
  2. Not stuffing giant images down onto mobile devices when those images are going to be restyled in HTML to be tiny.
  3. Being wary about what info is gathered by apps – and also disclosing that to customers (and perhaps offering a way to opt out).

The list can go on… Troy’s article has other ideas in it, too… but the point is that in the rush to get a mobile app out there, some of these security and privacy issues (and bandwidth costs!) really do need some attention!