Down or Not?

Wednesday, October 10th, 2012 | Jim Cheetham | Comments Off

Here, this looks like a good joke … downornot.com is down!

Except of course, it isn’t down …

Or perhaps it is …

So, is DownorNot.com down, or not?

The problem here is that the meaning of “it” in the phrase “is it up or down?” is different each time. For the human, “it” is the service provided by the website, and that service is certainly non-functional (it looks like the website’s usage of the Google AppEngine service has gone over quota; and the developer who wrote their website didn’t anticipate this error. In this case, we would also anticipate that the service behind the website is also broken at the moment, whereas often a service and a website are separate). For isitup.org, “it” seems to be the initial contact with the site’s webserver, which is responsible for handling the HTTP conversation. For downforeveryoneorjustforme.com, “it” is the same thing, the webserver and not the application, but they are going a couple of steps further, following the redirections and noticing that the final page is delivered with an error status … and in this case, the failure of the application is reflected in the webserver status code. It doesn’t have to be.

Let’s ask isitup.org again, but this time go straight to www.downornot.com instead of just downornot.com …

So, if you are monitoring or testing a service, make very very sure that you understand what the question “Is it up?” is supposed to mean — and this depends on who is asking. Then, make very sure that you understand how your monitoring tools work, what you are asking them to do, and how to interpret them. Obviously, this isn’t as easy as it sounds …

If you are not careful, this is what you end up with :-

The future of computer threat response

Thursday, August 23rd, 2012 | Jim Cheetham | Comments Off

Dan Geer is a voice in the IT Security world that should be listened to, and he has co-authored a short but intense article in the IEEE S&P Cleartext column that addresses the reality of the rapidly-changing threats that we all face.

Stand Your Ground” has a few key messages, which I’ll try to summarise :-

  • Minimise the number of targets; stop adding new services without effective defences, remove old services. Use the savings to fund better security for what remains.
  • Distrust the internal network; distrust any service that is not continually verified. Defend against outbound traffic as well as inbound traffic.
  • Do not assume perfection is possible; plan for failure modes that reduce services sensibly. Reduce the time-to-repair with automation instead of extending the mean-time-between-failure.

For more reading and a less technical take on these ideas, here’s another article about Dan’s thoughts from Ben Tomhave, a GRC (Governance, Risk & Compliance) consultant.

Half a million Aussie credit card numbers fly to Eastern Europe

Wednesday, August 22nd, 2012 | Mark Bedford | Comments Off

In an article from Wired thieves allegedly stole half a million Australian credit card numbers. The raid on an unnamed business in Australia used keystroke logging software on POS terminals then transferred the information back to Eastern Europe. The POS terminals had default passwords and stored transaction data insecurely. They were accessed using an unsecured Microsoft Remote Desktop connection. But the notable quote is

“The network was setup by some local suppliers who didn’t understand IT security,” Det. Sup. Marden told the magazine. “It was a disaster waiting to happen.”

As is often the case in many incidents, most of the layers of defence were turned off, left with default values, or just were not considered necessary. Had any one of the following been in place this particular incident could have been averted: changed the vendors default password, forced access to the terminals via a VPN, AV software on the workstations, IDS on outward network traffic, logging and monitoring of authentication services. Lastly, had the Aussie business performed an independent information security audit these would have been identified and the costly compromise could have been avoided.

The dangers of testing in a live environment

Monday, August 6th, 2012 | Jim Cheetham | Comments Off

On August 1 2012, the New York Stock Exchange started to record significantly unusual levels of activity at 0930, as the markets opened. Trade rates were running at 30% above normal. By the end of the day one trader alone, Knight Capital Group Inc, had burnt over $440 million. The trades damaged market values for the whole day and almost destroyed Knight completely.

Technical analysts Nanex have posted a great analysis of the pattern of trades that enabled them to identify the likely origin of the trades, and to present a reasonable theory that seems to fix the facts: Knight seem to have released an internal trade testing application onto their production servers. It tested the live NYSE market. It lost money, because making money was not a requirement for testing.

It is hard to come up with a test environment for software that acts in a realistic manner, especially when you do not want to let the software itself be aware that it is being tested (because that will change its behaviour, and then it isn’t a proper test, is it?). It is also hard to construct tests that have to change the system state, when testing things that write to databases for example. And if you do accidentally run the test in a live environment, you can always recover from backups, right?

No, not always. Not $440 million’s worth of real-world money …

 

Wired reviews 4 external hard drives with built in keypads

Wednesday, August 1st, 2012 | Gene Teo | Comments Off

I’ve posted before about external hard drives with built-in encryption. These devices have their own keypad to enter the password/decryption key. If you should happen to connect it to a computer infected with a keystroke logger, the key will not be revealed (although such a computer may have other malware installed on it!)

Wired have a four-way comparison of:

  • Apricorn Aegis Padlock 3
  • Rocstor Rocsafe MX
  • Lenovo ThinkPad USB 3.0 Secure Drive
  • DataLocker DL3

 

Stronger PHISH are getting smellier

Tuesday, July 24th, 2012 | Mark Bedford | Comments Off

I came across this phish the other day and it is quite compelling. It seems that resorting to sarcasm is the latest social engineering attack for luring users into supplying their credentials:

Do you think we are joking, the username and password which you provide is not correct, we are contacting you to inform you that your <domain> mailbox has exceeded to 90% of its quota. And when it reaches 100%, new messages will be rejected and bounce back to the sender. To avoid missing mail, please keep your mailbox at a reasonable size. Fill the below: provide the below completely and correctly, because the info you provide to us we can’t reset your <domain> because is not the correct info. Note we are contacting you for the last time.

User name:
Password:
Retype Password:
Date of Birth:

The reply to email address was obviously not from within the organisation. I am pleased to say that no Otago users responded.

There isn’t a police investigation under way

Monday, June 25th, 2012 | Gene Teo | Comments Off

Update: Graham Cluley at Sophos has also blogged about this email variant, with some additional detail.

A new variant of the “Do [Something Important] by opening the attached file” scam has arrived. The goal is to trick you into running the malware that is attached. While most Antivirus software will detect and prevent you from running known malware, 100% accuracy is impossible, and new malware variants may not be detected whey they have just been released. Here’s what the email looks like:

Subject: The police investigation is under way now. You’ll be really sorry about what you have done.
Hello there
Do you know who posted these photos online?? This is strange cause there’s your FB acc there. Why did you do it and how did you get my photos?? This is a crime actually do you know?? I put one photo in attachment. We have to clear this thing or else I’ll have to contact my lawer!

Falsehoods [people] believe about [topic]

Wednesday, June 20th, 2012 | Jim Cheetham | 1 Comment

I’ve just picked up a nice new entry on the “Falsehoods [people] believe about [topic]” meme … this one is “Falsehoods programmers believe about networks” and comes from Errata Security, a very good resource.

Here’s the top 5 :-

  1. Data on the network cannot be altered.
  2. Encrypted data on the network cannot be altered.
  3. Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs
  4. If it’s inside my perimeter firewall, that means I have total control over it
  5. If it doesn’t return an error, then send() sent all the data that was asked of it.

A small list at the end is “Falsehoods network administrators believe about networks” …

  1. There is no IPv6 on my network
  2. NAT automatically blocks all inbound attacks
  3. We know all the devices attached to our network at any given time

This joins the two well-known “Falsehoods programmers believe about …”; Time and Names, their top entries are …

  1. There are always 24 hours in a day.
  2. Months have either 30 or 31 days.
  3. Years have 365 days.
  4. February is always 28 days long.
  5. Any 24-hour period will always begin and end in the same day (or week, or month).
  1. People have exactly one canonical full name.
  2. People have exactly one full name which they go by.
  3. People’s names fit within a certain defined amount of space.
  4. People’s names do not change.
  5. People’s names change, but only at a certain enumerated set of events.
  6. People’s names are written in ASCII.
  7. People’s names are written in any single character set.
  8. People’s names are all mapped in Unicode code points.
  9. People’s names are case sensitive.
  10. People’s names are case insensitive.

 

Passwords, policies, and cracking

Tuesday, May 22nd, 2012 | Jim Cheetham | Comments Off

Here’s an overview of a new OWASP project called Passfault, that tries
to help assess password strength in ‘real world’ terms :-
http://www.zdnet.com/blog/identity/your-passwords-dont-suck-its-your-policies/482

One of the developer’s assertions is that password-creation policies are
not helping users to create secure passwords.

His examples provided on the Analyser website suggest that the problem
he is attacking is what I would call “the fallacy of the pass*word*”.

 Weak Passwords that pass typical policies:
qwerQWER1234!@#$ – !1cracked – cracked7& -
Strong Passwords that fail typical policies:
udnkzdjeyhdowjpo – seattleautojesterarbol

I ran my diceware script (grabs random numbers from random.org and looks
up on the diceware wordlist) and tested the pass*phrase* “52nd temper
musk” (this was the first output from the script).

The passfault analyser said “Time To Crack: 17 centuries Total Passwords
in Pattern: 50 Quadrillion”. I’m not sure that his approach is
completely useful …

However, the overall idea is interesting. Instead of saying how
passwords should be formed, he is suggesting that they should be assessed in terms of how long they would take to crack. I have a few issues with that … First comes a glance at the Verizon Data Breach Investigations Report 2012, which tells us that “Brute force & dictionary attacks” are a reducing technique (although still at 29% a useful one). Their fuller results table for the Hacking mechanism shows :-

  • 55% — Exploitation of default or guessable credentials
  • 40% — Use of stolen login credentials
  • 29% — Brute force & dictionary attacks
  • 25% — Exploitation of backdoor or command & control channel
  • 6%  — Exploitation of insufficient authentication (e.g. no login needed)
  • 3%  — SQL injection
  • 1%  — Remote file inclusion
  • <1% — Abuse of functionality
  • 4%  — unknown

So having a “stronger” credential takes us out of the first 55% category — but so did even a weak password policy. Inside the 29% is still the best place to find password cracking carried out.

There are of course two main approaches to password cracking — online and offline. The Verizon stats don’t differentiate between the two, but I’m sure that online (where you just try credentials against the live service) is more common, because it is the easiest. In order to exfiltrate a stored password database, you have to have penetrated the organisation already, to some extent, and at that stage the password db is just an additional weapon.

Online password cracking should be dealt with by having account lockout and retry delay systems; there should be no way that the attacker should be able to test more than a small handful of potential passwords before the source of the attempts is blacklisted from the network, and the target accounts are locked (at this point you have to stop and consider your account lockout procedures: if your response is to send a “reactivate” link over external email, how do you verify it isn’t an attacker who is reading the target’s mailbox?).

So instead of instituting a password policy, even one that guides you to make selection by strength directly instead of indirectly, you’d be better off making sure that attackers can’t continue knocking at the doors all day long without being detected & blocked.

 

How MITMproxy has been slaying SSL Dragons

Monday, April 16th, 2012 | Jim Cheetham | Comments Off

I’ve just returned from the excellent OWASP regional conference in Sydney (the one with the long name of OWASP AppSec AsiaPac 2012), where I presented “How MITMproxy has been slaying SSL Dragons“.

The presentation covered the basics of what MITMproxy is (a developers/pen-testers HTTPS interception/modification proxy), why such software is useful, and what MITMproxy itself is especially good at.

The section on how to use MITMproxy ran about 90% successfully over the live Internet, which is always a risk for a demo at a conference!

The slides are available here, as the original LibreOffice ODP format, or as a PDF. They are Copyright © The University of Otago, released under the CC By-SA 3.0 NZ license.

 
 
 

Any views or opinion represented in this site belong solely to the authors and do not necessarily represent those of the University of Otago. Any view or opinion represented in the comments are personal and are those of the respective commentator/contributor to this site.