IPS (Intrusion Prevention System) and IDS (Intrustion Detection System) both use technology that watches internet traffic and looks for attacks or intrusions using signatures and does some action based on any signatures the traffic matches. An IPS has the ability to block traffic that it considers suspicious, while an IDS only has traffic mirrored to it and cannot prevent any traffic from reaching it’s destination.

A good analogy for IDS/IPS is a spam email detector. The spam detector looks at your email before you receive it and looks for patterns or words that usually mean the email is a spam message (I’ll let you infer common spam email subjects here). If it sees one it is confident is spam, it puts it in your spam folder and doesn’t tell you. If it sees a message that could be spam, but could also be legitimate email (your friend offering to sell you a car) it might mark it as potential spam, but still deliver it to your inbox).

For the IDS/IPS technology the signatures are looking at packets and protocols instead of words (Not sure what your familiarity is with internet and network protocols, let me know if you have questions there). Some good examples of things IPS looks for can be found in the IPS Weekly Reporting (one is here for reference).

Threats on the internet are changing constantly, so whenever the IPS vendor releases a new version of their signatures we download and apply it. This allows our IPS, which is older, to look for threats that have only been released very recently, similar to how a virus scanner can find new viruses.

SIEM is really the business of looking for anomalies in data. Let’s say we track your computer’s login activity for a month and you log on to your computer daily at 8 am and 12:30 pm (when you arrive for the day and when you get back from lunch). Then suddenly and without warning we see your ID active at 3 am. That’s an interesting anomaly.

Going a level higher (and more mature in most definitions) let’s say we also track your email login activity. Every day when you log in to your computer you also log into email and check your messages. So everyday at 8 am we see a computer login and then an email login. But then at 3 am we don’t see an email login. Now we’re extra suspicious of the 3 am activity because it doesn’t follow your normal behavior.

This is a simply example, but I’m sure you can see how we could get really creative with this and tie behavior of different systems together. This is why an academic version of SIEM pushes for all of the data to be in one tool. It would be very difficult for a human to watch all of these different log sources for abnormal behavior. If you have all of this data in one tool you can automate the sequence of events and then generate alarms or alerts based on what the automated process detects.

When implemented this can still require human contact. For our example, when you logged on at 3 am, you were probably just awake and wanted to get some work done that didn’t require email. So when an alert is generated, it goes to a SIEM analyst and he does a quick investigation, notices that all of your web traffic looked normal (to google.com and espn.com), and nothing else suspicious was going on. He marks it uninteresting and moves on. But if you had gone to known malicious websites, he would assume an attack had gained access to your computer and would escalate it to the next level to be researched.

After the researcher realizes that what websites you go to could be checked after noticing your computer is logged into and your notes is opened, he could add that to the alarm process and tell the alarm not to fire if no suspicious web traffic is detected (this last part is called tuning).

The premise is that normal employee behavior is consistent and steady over time, while an attack will look abnormal when compared to that typical employee behavior.

Java is the Watchmen, Javascript is the Avengers.

Javascript is the kid who practices air hockey and competes in tournaments. Java is the kid who’s like, “Hey man, wanna play some airhockey?”

Java is Canada (perhaps a little boring, but steady and dependable), Javascript is America (a little less dependable, but wild and crazy and anything goes)

Java is Morgan Freeman, Javascript is Samuel L. Jackson

Java is an iPhone, Javascript is an Android phone (see what I did there?)

Java is the oldest child, Javascript is the youngest

Java is Mick Jager, Javascript is Carly Rae Jepsen

Java is a grenade launcher, Javascript is a laser gun that breaks down sometimes

Java is a stocking cap, Javascript is a Liberty hat

I trust I’ve made my point.

DDoS is in the news again with a novel new method of creating high volume attacks, this time WordPress is the source and target of this attack using a ping back feature.

What happened?

A creative attacker used an old bug which causes a word press blog to request a page from another site. The proper use is for word press to keep track of the pages that contain a link to it.

The tool is called a “ping back”. Here’s how it normally works:

Blog A has a post.
Site B posts something on it that contains a link to the Blog A post
Site B informs Blog A that it has posted a link to Blog A’s post
Blog A requests the Site B page with the link to verify

In this case, an attacker manipulated this exchange so that it went like this

Blogs A-Z have posts
Site 1 is the victim
Attacker tells Blogs A-Z that Site 1 linked to them
Blogs A-Z request pages from Site 1
Site 1 becomes unavailable

Caching Trick

A lot of web servers use an idea caching (actually a lot of things in computer science use this idea). The concept is that if you know something could be asked for a lot, why not keep it some place easy to get to? This is the same idea as putting frequently checked out library books at the front of the library to avoid traffic jams in the back rows (if you’re old enough to know what a library is).

Normally this concept would help mitigate the attack because the pages being requested would’ve been cached and returned more quickly. But the attacker used a random number to reduce the number of times a cache would be effective. Enough techno-babble, here’s the caching scenario in story form.

Normal caching:

Library Visitor 1(LV1): Hello, do you have War and Peace?
Librarian (LR): Yes, we have our copy right here.
LV2: Hello, do you have War and Peace?
LR: Yes, we have it right here.
LV3: Hello, do you have War and Peace?
…..
…
..
.

Attack to spoof caching:

Library Attacker 1 (LA1): Hello, do you have a book called Sunshine Falls on the Moon Softly? I think it’s by Edgar Allen Poe.
LR: Hmm, I’ve never heard of that book. I’ll have to search.
LA2: Hello, do you have a book called Moon light falls on the sun forcefully? I think it’s by Whitman.
LR: Hmm, I’ve never heard of that book. I’ll have to search when I’ve found SFOTMS by Poe.
LA3: Hello, do you have the book called…
LR: *Collapes under the exhaustion*

You get the picture.

WordPress has some documentation on how to turn off the ping back action

My wife and I were watching the 700 club show recently and they did a piece about cyber security. The article and video can be found here.

The guest on the show describes a number of cyber threats
before recommending his book as a way to know how to protect yourself from them. I haven’t read the book, so I can’t comment on it’s content, but let’s break down some of the “cyber threats” he describes:

1. Attacks on our electric grid

2. A cyber hacking unit which is “the most sophisticated perhaps in the world”

3. Cyber attacks on stock exchanges (“They could just hack into it. They’ve hacked the NASDAQ multiple times, they’ve hacked the NYSE, they’ve hacked the Navy, the White House, the NSA, you name it.”

4. That we have no way of preventing the stock exchange from being shut down, we just have to be ready to bring it back up

5. High frequency trading algorithms that could crash any exchange in the world (“He walked out with high frequency trading algorithms” “Those are the computers that trade continually”)

As a side note he described someone as “walking out with algorithms” as though they’re candy bars you could shop lift. Algorithms are ideas, like recipes. They can be written down, but they can also be explained to someone who would then just know it.

6. Associated Press Twitter feed hack that claimed the white house has been struck which caused the stock market to drop

7. EMP from a nuclear bomb that would “shut everything down” (“You could be isolated and alone, and you wouldn’t know what to do”)

Now that is a lot of topics, covering a broad range of ideas and threats. It sounds very scary, but there are a number of read flags that come up for me when listening to this.

Fast transitions between unrelated topics and threats
We start with “high frequency trading algorithms” and then jump to hijacking a twitter account and doing some social engineering. Those are very different things. They are related because they involve stock markets, but they require different skills sets and talents. These kinds of transitions make things seem connected and sound scary, but unless there is some evidence of a connection explained it’s usually less concerning than it may sound.

Dramatic terminology
Here I’m referring to the line about being “isolated and alone and not knowing what to do” or the line in the opening about “effecting the average American’s retirement account”. These are emotional appeals, not factual or logical appeals. Loneliness or financial security from a retirement account are big emotional deals, but unless someone can explain specifically what the threat to those things is, you probably shouldn’t react emotionally to the information.

This also applies at some levels to the targets he described. Supposedly our enemies have simply hacked into the NSA, White House (what does that mean, exactly? Computers inside of the white house, perhaps? Obama’s Facebook maybe?), and a number of other high profile targets. But no details are given. These are all very patriotic targets that generate an emotional response.

The threat descriptions end with a sales pitch
My favorite hash tag (that apparently only I use) is: #iquestionyourmotives Anytime that someone uses emotional appeals and then offers to sell you something, take a step back and find a third party to discuss it with.

The author’s area of expertise
The author is probably a brilliant man, but if you look at his qualifications he is an economist, not a security expert or even a computer scientist. I’m not saying he doesn’t know things about those fields, but just like you should take any financial advice I give with a grain of salt, we should probably take his cyber security warnings with a grain of salt as well.

Generalized Statements of Impossibility
Any time some one says there is no way to do something involving a computer it should throw up a red flag. Of course we have methods of preventing attacks on different stock exchanges, just like we have methods of preventing attacks on anything else (IPS/IDS, Firewalls, SIEM, anti-virus, etc).

There are other red flags for me, but that’s all I’ll list.

This is very good reporting. It is interesting and exciting to watch, the guest is an excellent speaker. But it is not good education. It doesn’t present actual examples of attacks or vulnerabilities and it doesn’t point people towards accessible resources that can be used to improve the situation. Rather than scaring the public we are better off educating them to be concerned about things that are actually threatening than trying to panic them with dramatic terms that may or may not mean anything.

As a disclaimer, I’m lazy with my file IO. As lazy as I can be. Which is why I love left shift
(<<) in groovy. You don't have to worry about streams, opening or closing files, nothing. Groovy goodness takes care of it all for you. But with most syntactic shortcuts, there can be a catch.

Let’s look at an example.

This code took over 6 minutes to write a 600 KB 3172 line file. This is easy to write (go left shift!) but it’s also a really bad way to do it. Let’s look at a better method:

It’s an extra line, and you don’t get to use left shift, but this snippet was able to write the same file in 0.07 seconds. Why do you ask? The answer is really in what is missing from the Groovy File API documentation examples: There is no instruction to close the file. As it turns out, left shift is a complete operation that opens the file, writes your object to the end, and closes the file again. And it’s that opening and closing of the file that takes a lot of time. The second code block keeps the file open for writing until it is actually done.

Technically this is a linear function, but the added time of waiting for the operating system to open the file is significant enough to actually matter here.

Lesson learned: Groovy is cool, and the things it will take care of for you are convenient, but you should always know what those short cuts are doing in the background. If you don’t, you could wind up writing extremely inefficient (or even broken) code.

1. It should never be necessary to open traffic to the entire internet from a single app. A company can only own so many IPs, and those should be spelled out so that we can keep the firewall as narrow as possible
2. I realize that proxy servers should be inline at this point, but a number of enterprises still use explicit proxy’s. If your app is aware of the proxy for it’s main operation, it should also be aware of it when the app is updating.

A lot of media attention has been given to the unrest in Ukraine and Russia. With so much media focus, it’s not surprising that terms like Cyber Security and Cyber Warfare will come up a lot. But there are often gaps in the information presented.

My sister asked an interesting question about this article. Specifically a comment from Cloudflare: How can they not know the target of the attack?

That does seem odd. At it’s core, the internet is a structure for transferring information. So how can you not know the intended recipient of the information?

Well, the internet is usually more complicated than it would seem at first glance. For this question there are two factors driving the additional complexity: IPv4 exhaustion and Clouflare being a web hosting company.

Normally when information travels through the internet it is directed to an IP address and a port number. The IP address represents (more or less) a computer on the internet, and the port number represents (more or less) an application running on that computer. For instance most http (web) goes over port 80, https (secure web traffic) goes over port 443.

There are 65,535 available ports so you’ll probably never have more applications running on a computer than there are port numbers. But there are only 4,294,967,296 IP addresses available in IPv4. This might sound like a lot, but to put it in perspective Forbes estimated that there were 8.7 billion internet connected devices in 2012. So we’re out of IP addresses. Way, way out of IP addresses. So what do we do?

The answer we came up with was changing an IP address from representing one computer to representing a gateway to a number of computers. And instead of port numbers representing applications, they represent a specific computer and an application.

So now our DDoS attacker doesn’t have to target a specific computer, he can target that gateway device represented by an IP and potentially impact any computers that are sitting behind it. And he may or may not choose to use a port number to specify a specific application and computer behind that gateway.

Add to that the fact that Cloudflare is a hosting company. That means they run websites and internet services for other companies. One of their computers (represented by an IP address and a port number) could have websites for more than one company on it. The attacker may have been going after website A, but impacted websites B, C, and D in the process.

It can quickly become verify difficult or impossible to determine what an attacker was going after, and answers like “we’re not sure who the intended target was” start to sound completely reasonable.

Now that’s an interesting proposition. Let’s take a closer look. For sources, I’m using the digital attack map and this article by the BBC

There were two DDoS attacks hitting Ukraine from unknown sources on December 7th.

My BBC article shows a large attack taking place on December 8th.

There are no major DDoS attacks hitting Ukraine for a while, but then there’s one on January 26th.

And the BBC shows some unrest on the 28-29

There was activity on February 25th

And then a lot of political activity February 23rd – 28th.

Obviously three occurrences is not proof. It’s also not clear that these DDoS attacks are significantly higher than attacks going on anywhere else in the world with no such corresponding political unrest. But it is interesting to correlate internet attacks with real world happenings.

As a disclaimer, I have no insider information so I’m not accusing or revealing anything. Just asking the question.

The name that occurred to me today was IBM. If I were an NSA analyst tasked with gathering useful information about people one of my first targets would be IBM. The reason why is easy enough to see if we list a few of IBM’s major products:

IMS/DB2 – Database with a significant userbase in the financial industry
WAS – A web application server with significant user base in the financial industry
z/OS and Mainframes – Large servers with a significant userbase in the financial industry
RAD – Development platform primarily for applications running on WAS
Guardium – Database transaction monitoring software with significant userbase in the financial industry

A pattern does seem to be emerging. And yet the only real bit of news I’ve been able to find on IBM cooperating with the NSA is a lawsuit in which IBM tried to deny much of a connection.

If anyone has more information on IBM and the NSA or PRISM, feel free to share.