Hi All,

Let's not start that again...

As of late there has been a heated debate among the community that various forms of standards and compliance are effective/ineffective at actually securing systems and networks. Just a quick note:

First post I read today is from Ascension Risk Management. There was a point/counterpoint that was detailed that, suffice to say, leaned towards the fact that standards and compliance are not effective. In order for something resembling standards to be effective, it must be made too narrow or not actionable. This is a good argument, but it doesn't tell the whole story.

The next blog post I read is from Emergent Chaos. This post was about the fact that after Former/embattled/kind-of/not Senator Norm Coleman's campaign's infrastructure was broken into, and there may possibly have been a breach, donors found out via Wikileaks, rather than the campaign. One quote sticks out:

We need public, documented and debated standards of how such decisions should be made. With such standards, organizations could better make decisions about risk. Additionaly, both regulators and the public could be more comfortable that those piping up about risk were not allowing the payers to call the tune.

So within the same day, there is one school saying that standards are ineffective and there is another stating that we need more standards in order to shuffle through the varied methods people use in regards to security related tasks. What a vicious circle.

I am on the fence. I think that without standards, there are a good amount of small and medium sized businesses that would have no security or extremely lax security. Standards do help to push these organizations into doing more to protect data. On the other hand, with a competent security practitioner, these standards are simply "fill in the box" tests that people adhere to. That security practitioner is likely doing things to secure the infrastructure more than the standard accounts for.

I think standards are simply not scalable. If there must be policy, it should reflect the end result, not the means. It is better to say "you are liable for any breach that occurs" than "you are not allowed to have SSLv2 on your hosts". In this way, it should create an incentive to have network owners and operators think about how to go about security. If there's a breach, they are liable, after all.

well, if you can call them thoughts

Long time since my last post. There has been a lot going on in the personal aspects of my life. One of the things that I am happy about, though, is that Red Sox baseball is now in full swing. Today is the first of the infamous Red Sox/Yankees games.

So, speaking of Conficker...

Today's game is turning out to be as hyped up with no results as Conficker. Even the blogosphere is less active about Conficker Since April 1st. Admittedly, this worm is the first really widely spread worm since my intro to the technology industry. I was expecting to hear of/see infections first or secondhand, but I have not. While I'm happy the Conficker was contained in my area of the planet, It was hyped up quite a lot.

Today's game is not going so well for the hype either. Joba Chamberlain's outing was uneventful. This is similar to the April Fools Day event. Lots of hype, but no substance. In fact, Youk was walked twice - not beaned.

All of that being said, today's game will have a winner and there will be some events that are worth cheering or booing. This is like Conficker - there is substance, but it is not in the exciting, ratings grabbing manner. Daily attendants of either will find something interesting and there will be something new to learn.

Edit: This game (and the series as a whole) was actually quite exciting. Maybe the best is yet to come from Conficker...

Quick Update: Conficker did not display "Happy Birthday Vovo!" like I had hoped. (nor did it do much at all - but that doesn't mean it is any less troublesome).

My favorite new April Fool, the funny RFC, actually make a little bit of sense this year. In the past, it told you how to send IP in the most efficient manner to how to monitor your network properly. This year it is a way to teach IPv6 and get more IP addresses out there. It is a joke, because these addresses are not "real" but it's an interesting thought. I think I will use the analogy to explain IPv6 from now on... (I'll always give credit to rfc 5514). They actually made a facebook app :o)

Google introduced an automated you for gmail, but I liked the printed and mailed emails idea better (from a previous year).

And in case you want squeeze bacon, see ThinkGeek

Sorry for not posting for a bit, my personal life has been busy lately (we moved, hopefully the last time for a long, long time.).

There has been a lot said about the Conficker (downadup, kido, april fools day worm, etc...). I can't really add anything new that hasn't already been said on the Security Bloggers Network. What I would like to say is that I hope that what it does is simply make all the infected computers say "Happy Birthday, Vovo!" because the now infamous April 1st target is my Vovo's birthday and I always for get to call. (If it does do this, I swear, I didn't make it happen...).

(Yes this is my sense of humor, and if you like it then I am your friend for life - nobody gets me :o)

sort of...

A lot of people use Google to find information on a "target" or "mark". A lot of times this is either a person, organization or machine. If your mark is a person, there is now a web service that can do this easily, www.pipl.com. The New York Times outlines this with the article When Googling a Person (or Yourself) Isn't Enough.

Okay, so these services have been around and the end of the world didn't show up. This is a typical kind of piece that is important to know about, but not to lose sleep over. The information that Pipl finds is not generated by searching databases that are normally off-limits. It does dig a bit deeper than google does by default, but all the info is still public. The bigger question when you find something about yourself that you didn't expect is how did the original recipient of this information make it public and why did I not know.

I think Pipl is a good thing because it allows average people find information that nefarious people may have found anyways. Thoughts?

I was typing an email to my wife and noticed that MS Outlook knows that Comcast should be capitalized. I wonder what other conglomerate is large enough and to have their name be known to Outlook.

In the "Digital Age"

I was driving home tonight and I was listening to "On Point, with Tom Ashbrook" (NPR). Today's topic was on "Cyberbullying", specifically a court case that may have far-reaching effects. Listen here.

The story starts with two Yale law students were harassed and libeled online by an internet community. This harassment and libel may have cost one or both of them job offers (by overly-sensitive prospective employers googleing them and having these nasty posts show first). There were also threats and stalking comments made (there were personal threats that made the individuals fear for their safety as the comments were made by people who had to have physically seen them).

To make matters worse, the host of these threads failed to act in a regulatory manner to take down these threads. Also, they (alegedly) deleted logs and subsequently disabled logging for users that post to threads, making it harder to find the anonymous culprits.

This last part troubles me. I believe in freedom of speech just like all Americans should. That being said, there are certain types of speech that should not be protected. When you feel threatened, you have a right to address that threat to ensure your personal safety and the safety of others. But if you don't know who is threatening you - other than the fact that it is some guy/girl with an internet connection - then what can you do? It is vital that the internet community self regulate certain content. If we, as hosts, don't self regulate then we may have to be regulated by an authority which is potentially far worse.

As a security practitioner, I feel that the failure of the host to pull the threads and put the users that caused this uproar on notice has caused there to be an open door for legislators to mandate certain restrictions on this type of content. This will make hosting less attractive for these new and exciting "Web 2.0" sites we all love (Why get involved in accounting for other people's words? Why become a legal target for lawsuits over content that someone else wrote?) . Also, security professionals will need to concern themselves with accounting for each logged in session. This detracts from the overall secuity of the site. Very bad news, indeed.

I hope this black mark can be sorted out without any far-reaching effects and I hope that hosts can learn to self regulate effectively enough to prevent any future legislation.

-Tim

What?



That's right, there is now a restaurant called Ubuntu in Napa region of CA. Competitor Knoppix seen pulling up with a food-mobile to serve your immediate nourishment needs, but never actually constructing a building. (OK that's a horrible joke)

iPhone Hype, get your iPhone hype here!

Those handsome, intelligent and engaging folks over at Astaro Internet Security have just introduced a very easy IPSec client auto-setup for an iPhone to connect to a protected LAN. This got me thinking. There is a lot of information available on securing your iPhone and other mobile devices from intrusion, but there isn't a lot of information available about securing your LAN from intrusion from your mobile users.

The idea of using a full IPSec tunnel for all network traffic is great for iPhone security. You are no longer sending data in the clear whether it's to your corporate mail server or gmail. This should cut back on some threats at the iPhone level. Because you are also giving access to your LAN, it can also create an all new set of issues on your LAN.

A lot of security types are used to thinking about mobile devices similar to laptops. After all, they are similar: they're mobile, they can hop on and off your local (trusted) wireless link, they have remote access capabilities, etc... I posit that they are, in fact, different in a few key ways. For instance most people turn their laptops off (or at least have them sleep) when they are actively traveling. This is not the case for mobile devices. The chances of a mobile device attaching to a rogue, unsecured or malevolent access point is far greater. Therefore the exposure to all sorts of nastiness is greater. How can you trust something like that on your LAN?

I would like to suggest some ideas (In bullet point goodness):

• Expect the Worst
• Always assume that a mobile device is owned and treat it as such, because it will be easier to deal with when it happens
  
• Segment Mobile Devices:
  
• Whenever possible, limit access to the LAN. Only give access to business critical infrastructure that is in a secure place, preferably segmented from any LAN.
• Set up different SSIDs, WLANS and access points specifically for mobile users when in the office.
  
• Do not allow mobiles to communicate with laptops and other wireless devices.
• Use Device Level Security
• Find reputable applications that protect the mobile device from intrusion
• Use VPNs when possible to ensure no data is sent in the clear. This can often have an effect on your LAN.
• Make Concise and Enforceable Usage Policies
• Make sure that anybody that can gain access to your network with a mobile device is subject to a strict usage policy. This can at least allow you to take action when/if an incident occurs. This policy should be different from any other current remote access policy as the concepts are different
  
• Training is considered somewhat "controversial" as you can't ensure that people will learn from it and listen. However, it is a good start and most people will be receptive (or face your wrath).

As always I would love to hear some feedback. Let me know if anything I've said has worked successfully. Report bugs in this theory to bugtaq... (or in the comments section)

-Tim

Hi All,

Just passing this info on. I just read on The Register that fully updated and patched Adobe Reader applications running on fully patched Windows systems are vulnerable to a new exploit. The original info from the Reg. article is at Shadow Server but Adobe fully recognizes the Vulnerability here. More info from US-CERT here.

Apparently, this exploit leverages a known vulnerability in the way MS Windows XP/2003 handles URIs. Using that vulnerability, it is possible to open a trojaned pdf file and have your PC injected with arbitrary commands.

The "Fix" stated in that article is to disable Acrobat Javascript (We all have Javascript off already right???). I can assume (but have not tested) that the Firefox NoScript add-on can save you from this. Adobe, on the other hand, "strongly recommends" updating to 8.1.1 of the Adobe Acrobat (Reader) application.

Here is a quote from pdp of GNUCitizen (credited with the find)

http://www.gnucitizen.org/blog/0day-pdf-pwns-windows

I am closing the season with the following HIGH Risk vulnerability:
Adobe Acrobat/Reader PDF documents can be used to compromise your
Windows box. Completely!!! Invisibly and unwillingly!!! All it takes
is to open a PDF document or stumble across a page which embeds one.

The issue is quite critical given the fact that PDF documents are in
the core of today's modern business. This and the fact that it may
take a while for Adobe to fix their closed source product, are the
reasons why I am not going to publish any POCs. You have to take my
word for it. The POCs will be released when an update is available.

Adobe's representatives can contact me from the usual place. My advise
for you is not to open any PDF files (locally or remotely). Other PDF
viewers might be vulnerable too. The issues was verified on Windows XP
SP2 with the latest Adobe Reader 8.1, although previous versions and
other setups are also affected.

A formal summary and conclusion of the GNUCITIZEN bug hunt to be expected soon.

cheers

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

-Tim

SPF - I need 200, how 'bout you?



Anecdotally, I have seen more reports of targeted "spoofed domain" spam. This is a troubling scenario if your domain really is targeted rather than just picked up by a bot. I'll outline a rather nasty one, no names given of course.

The Idea is that you receive an email from yourself or another user on your domain. A common one is that everyone on your domain gets an email from someone claiming to be a domain admin. You may think that you need to have a pwn'd machine on your network for this to happen, but that is not the case. As long as someone knows your email domain, this attack vector is easy to produce manually as well as automatically.

The incident that was reported to me is interesting. There was a learning institution that had a user's mail account compromised. This quickly meant that the IP address and domain name were blacklisted. The admin is now stressed to begin with and is not necessarily thinking straight.

Next, the compromised account was flushed out and the un-blacklisting process started when everyone got an email from a "domain admin." The email address looked authentic to the unsuspecting users because it cam from the correct domain. This new admin asked everyone on the domain to click a link and enter their usernames and passwords or their email account would be deleted. (uh-oh) Well, another email went out from the real admin telling them not to reply no matter what. And most listened...

(we all know what the ... means)

long story short, an SPF (Sender Policy Framework) record could have saved this "spear phishing" attack from happening. SPF is basically a DNS record for your domain. It specifies the IP addresses (or hostnames) for hosts that are allowed to send for your domain. Normally, after specifying the allowed servers, it has a '-all'. the - means "not allowed", all means - well, all. This is very important.

He had a security appliance that was checking for SPF from all domains. This would also check for *his own* domain. It diligently checked SPF and allowed the message anyways. Why? If he had an SPF record, it would say that the server that sent the message was not allowed to send the message. As it turns out, his domain has an SPF record, but it didn't tell the appliance to drop the message. Instead it had '~all', which means "this is bad, but let it go anyways".

I guess auditing may have been a good thing here. It's strange how a single character can ruin an entire day or more.

-Tim

(or life imitating art?)




Above is a comic from one of my favorite geeky websites, www.xkcd.com. I like the site because there are 3 comics a week that are funny because they usually hit close to home. Just by looking at the image above, you know that the people that we are trying to keep away from our networks are in the right panel.

To be serious, miscreants don't use bleeding edge technology to target your facebook page (unless they're really bored), people with nefarious purpose will break in using the computational equivalent of a $5 dolar wrench. I like this comic because it puts so much into perspective. We need to be secure from the ubergeeks on the left, but we need to be watchful for the thugs on the right. Besides, the thugs on the right are more likely to post embarrassing things about you or your company online.

Let's take the scenario in the comic as real life. I just left my company laptop on the seat in the airport while I went to the bathroom. The two guys grabbed my laptop and noticed that a sticker on it says "property of [fortune 500 company]" -- SCORE!!! They boot it up and notice that it's encrypted. They aren't going to take it and work on the encryption at home, they're going to wait for me to leave the bathroom and coerce me to give them any password necessary.

Here's what can stop this:

• Educate users that their laptop is, in essence, their livelihood. They wouldn't leave their wallet on the seat, why should they leave their laptop?
• Try not to advertise the added value of a laptop. Stealing my mom's photos is less valuable than stealing my company's financial and customer data. It's one thing to say "if found return to [a discrete address(make sure when people here aren't vulnerable to social engineering] another to tell everyone that there is important data in here.
• Encryption is still a good idea. It's better to know that anyone can't just get into the laptop's data if this situation arises.

Granted, this article lacks some real substance, but at least you got a chuckle from the comic ;)

-Tim

Oh The Humanity!!

Nobody seems to be untouched by the Hindenburg economy. Right now there is so much hatch battening happening that nobody can afford to move forward. What does this mean to security practitioners (other than having to do more with even less)? It means that as attacks and attackers become more sophisticated, we as an industry, are not able to move into a good position to fight back.

Anecdotally, there are an astounding number of SMEs that have old systems and systems administrators/security folk have to put band-aids on everything from printers that are only a little broken to network security appliances that only have a small amount of vulnerability. Essentially, there are a lot of companies that offer services that are customizable by subscriptions. If you have cutbacks and now can not afford that IPS subscription, well, that's too bad - it still has to work, somehow.

This is not so much of an informational post as a post to express solidarity among the admins of the world that have to make things run extremely smoothly with nothing more than two paper clips and rubber bands. Keep it going and keep smiling.

Four Words: "Then Some Magic Happens"

It has become very clear to me recently that admins that are in charge of web clients do not fully understand the HTTPS (SSL) protocol. I was involved in one such incident recently that ended very badly due to a misunderstanding of this protocol. So, here is the HTTPS (SSL) protocol explained as plainly as I can - I hope this sheds some light on what I can not easily find on google (with a short attention span):

SSL is designed mainly for two main security tenets, Confidentiality and Authentication (Before the posts start, yes I know that the "A" in "CIA" doesn't stand for authentication). When I browse to a trusted site, I want to know that I am talking only to the person that I want to talk and that my data is not being seen by anybody else.

The way that SSL achieves this is by using trusted third parties (Certificate Authorities a.k.a CAs) and Public Key Infrastructure. I won't go into details about Public Key cryptography, but just know that if you have a public key in your possession and you use it to encrypt data, the only system that can decrypt that message is a system that possesses the private key (and vice-versa). PKI is used for authentication.

Part of the whole process is setting up encryption. Encryption is negotiated within the SSL protocol's initial handshake - at the same time as calculating authentication. Once the handshake is finished, a tunnel is created using a less computationally hungry process known as symmetric key cryptography (again, I won't go into detail, just know that once this is negotiated the traffic is now encrypted).

As you can see I have created a (rather crude) diagram of SSL with steps 1-6. This may be an over-simplification, but it is definitely a good foundation. Here's a description:

1. When any modern browser is installed, it is sent with several CA issuer certificates. These issuer certificates contain a public key for the issuer, among other information.


2. When a web designer decides to use SSL he needs to purchase a certificate that is signed using the CA's private key.


3. The web browser starts a connection to an HTTPS site. Along with this request the client sends all supported encryption schemes.


4. As a response to the browser's connection request, the Server sends a copy of the certificate from step 2. Along with this transmission is the server's answer to the encryption negotiation.


5. Once a certificate is downloaded, the signature of the certificate (that was signed using the CA's private key) is checked using the CA's public key (installed in the browser in step 1 - note that there is no need to use the network for this). No error is thrown if this verification checks out.


6. The connection succeeds, the client can now download and upload to the web site with the security of encryption.