Commentary

General ideas about the world of security

BadBIOS

In recent days there has been much interest in the “BadBIOS” infection being reported by Dragos Ruiu.  (The best overview I’ve seen has been from Naked Security.)  But to someone who has lived through several viral myths and legends, parts of it sound strange.

  • It is said to infect the low-level system firmware of your computer, so it can’t be removed or disabled simply by rebooting.

These things, of course, have been around for a while, so that isn’t necessarily wrong.  However, BIOS infectors never became a major vector.

  • It is said to include components that work at the operating system level, so it affects the high-level operation of your computer, too.
  • It is said to be multi-platform, affecting at least Windows, OS X, and OpenBSD systems.

This sounds bit odd, but we’ve had cross-platform stuff before.  But they never became major problems either.

  • It is said to prevent infected systems being booted from CD drives.

Possible: we’ve seen similar effects over the years, both intentionally and un.

  • It is said to spread itself to new victim computers using Software Defined Radio (SDR) program code, even with all wireless hardware removed.

OK, it’s dangerous to go out on a limb when you haven’t seen details and say something can’t happen, but I’m calling bullshit on this one.  Not that I don’t think someone couldn’t create a communications channel without the hardware: anything the hardware guys can do the software guys can emulate, and vice versa.  However, I can’t see getting an infection channel this way, at least without some kind of minimal infection first.  (It is, of course, possible that the person doing the analysis may have made a mistake in what they observed, or in the reporting of it.)

  • It is said to spread itself to new victim computers using the speakers on an infected device to talk to the microphone on an uninfected one.

As above.

  • It is said to infect simply by plugging in a USB key, with no other action required.

We’ve seen that before.

  • It is said to infect the firmware on USB sticks.

Well, a friend has built a device to blow off dangerous firmware on USB sticks, so I don’t see that this would present any problem.

  • It is said to render USB sticks unusable if they aren’t ejected cleanly; these sticks work properly again if inserted into an infected computer.

Reminds me somewhat of the old “fast infectors” of the early 90s.  They had unintended effects that actually made the infections easy to remove.

  • It is said to use TTF (font) files, apparently in large numbers, as a vector when spreading.

Don’t know details of the internals of TTF files, but they should certainly have enough space.

  • It is said to block access to Russian websites that deal with reflashing software.

Possible, and irrelevant unless we find out what is actually true.

  • It is said to render any hardware used in researching the threat useless for further testing.

Well, anything that gets reflashed is likely to become unreliable and untrustworthy …

  • It is said to have first been seen more than three years ago on a Macbook.

And it’s taken three years to get these details?  Or get a sample to competent researchers?  Or ask for help?  This I find most unbelievable.

In sum, then, I think this might be possible, but I strongly suspect that it is either a promotion for PacSec, or a promo for some presentation on social engineering.

 

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

Someone always checks up on you

I would like to start by thanking Smit Bharatkumar Shah from http://about.me/smitbshah for bringing to our attention that our site has a potential security vulnerability that could be used by malicious attackers to preform phishing and/or clickjacking attacks. With his help we were able to prevent this attack from occurring. No customers have been affected by this issue.

Our ScanMyServer.com service has been providing security scan reports and vulnerability information for sites from all over the world; but we did however neglect to do one small thing, which is scan our web site with the same service. If we had, ScanMyServer.com would have shown us of the potential issue. How embarrassing is that?!

We have checked our logs for any sign that the vulnerability has been exploited or our customers have been misused but nothing came out. Due to the nature of this issue, any attack would have been recorded in the logs.

The solution for the above mentioned vulnerability is a simple two step fix:
1) Run:
a2enmod headers

2) Add to /etc/apache2/conf.d/security the following line:
Header always append X-Frame-Options SAMEORIGIN

If any of you finds any other issues in our site, please contact us at support@beyondsecurity.com and we will be happy to credit you with the find. Thanks for making our service better!

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

Risk management and security theatre

Bruce Schneier is often outrageous, these days, but generally worth reading.  In a piece for Forbes in late August, he made the point that, due to fear and the extra trouble casued by TSA regulations, more people were driving rather than flying, and, thus, more people were dying.

“The inconvenience of extra passenger screening and added costs at airports after 9/11 cause many short-haul passengers to drive to their destination instead, and, since airline travel is far safer than car travel, this has led to an increase of 500 U.S. traffic fatalities per year.”

So, by six years after the event, the TSA had killed more US citizens than had the terrorists.  And continues to kill them.

Given the recent NSA revelations, I suppose this will sound like more US-bashing, but I don’t see it that way.  It’s another example of the importance of *real* risk management, taking all factors into account.

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

“Poor” decisions in management?

I started reading this article just for the social significance.  You’ve probably seen reports of it: it’s been much in the media.

However, I wasn’t very far in before I came across a statement that seems to have a direct implication to all business management, and, in particular, the CISSP:

“The authors gathered evidence … and found that just contemplating a projected financial decision impacted performance on … reasoning tests.”

As soon as I read that, I flashed on the huge stress we place on cost/benefit analysis in the CISSP exam.  And, of course, that extends to all business decisions: everything is based on “the bottom line.”  Which would seem to imply that hugely important corporate and public policy decisions are made on the worst possible basis and in the worst possible situation.

(That *would* explain a lot about modern business, policy, and economics.  And maybe the recent insanity in the US Congress.)

Other results seem to temper that statement, and, unfortunately, seem to support wage inequality and the practice of paying obscene wages to CEOs and directors: “… low-income people asked to ponder an expensive car repair did worse on cognitive-function tests than low-income people asked to consider cheaper repairs or than higher-income people faced with either scenario.”

But it does make you think …

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

Google’s “Shared Endorsements”

A lot of people are concerned about Google’s new “Shared Endorsements” scheme.

However, one should give credit where credit is due.  This is not one of Facebook’s functions, where, regardless of what you’ve set or unset in the past, every time they add a new feature it defaults to “wide open.”  If you have been careful with your Google account in the past, you will probably find yourself still protected.  I’m pretty paranoid, but when I checked the Shared Endorsements setting page on my accounts, and the “Based upon my activity, Google may show my name and profile photo in shared endorsements that appear in ads” box is unchecked on all of them.  I can only assume that it is because I’ve been circumspect in my settings in the past.

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

“Identity Theft” of time

I really should know better.

Last night, hoping that, in two hours, Hollywood might provide *some* information on an important topic, even if limited, I watched “Identity Thief,” a movie put out by Universal in 2013, starring Jason Bateman and Melissa McCarthy.

It is important to point out to people that, if someone phones you up and offers you a free service to protect you from identity theft, it is probably not a good idea to give them your name, date of birth, social security/insurance number, credit card and bank account numbers, and basically everything else about you.  This tip is provided in the first thirty seconds of the film.  After that (except for the point that the help law enforcement might be able to give you is limited) it’s all downhill.  The plot is ridiculous (even for a comedy), the characters somewhat uneven, the situations crude, the relationship unlikely, the language profane, and the legalities extremely questionable.

(The best line in the entire movie is: Sandy – “Do you know what a sociopath is?” Diane – “Do they like ribs?”  I know this may not seem funny, but trust me: it gives you a very good idea of how humorous this movie really is.)

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

The Common Vulnerability Scoring System

Introduction

This article presents the Common Vulnerability Scoring System (CVSS) Version 2.0, an open framework for scoring IT vulnerabilities. It introduces metric groups, describes base metrics, vector, and scoring. Finally, an example is provided to understand how it works in practice. For a more in depth look into scoring vulnerabilities, check out the ethical hacking course offered by the InfoSec Institute.

Metric groups

There are three metric groups:

I. Base (used to describe the fundamental information about the vulnerability—its exploitability and impact).
II. Temporal (time is taken into account when severity of the vulnerability is assessed; for example, the severity decreases when the official patch is available).
III. Environmental (environmental issues are taken into account when severity of the vulnerability is assessed; for example, the more systems affected by the vulnerability, the higher severity).

This article is focused on base metrics. Please read A Complete Guide to the Common Vulnerability Scoring System Version 2.0 if you are interested in temporal and environmental metrics.

Base metrics

There are exploitability and impact metrics:

I. Exploitability

a) Access Vector (AV) describes how the vulnerability is exploited:
– Local (L)—exploited only locally
– Adjacent Network (A)—adjacent network access is required to exploit the vulnerability
– Network (N)—remotely exploitable

The more remote the attack, the more severe the vulnerability.

b) Access Complexity (AC) describes how complex the attack is:
– High (H)—a series of steps needed to exploit the vulnerability
– Medium (M)—neither complicated nor easily exploitable
– Low (L)—easily exploitable

The lower the access complexity, the more severe the vulnerability.

c) Authentication (Au) describes the authentication needed to exploit the vulnerability:
– Multiple (M)—the attacker needs to authenticate at least two times
– Single (S)—one-time authentication
– None (N)—no authentication

The lower the number of authentication instances, the more severe the vulnerability.

II. Impact

a) Confidentiality (C) describes the impact of the vulnerability on the confidentiality of the system:
– None (N)—no impact
– Partial (P)—data can be partially read
– Complete (C)—all data can be read

The more affected the confidentiality of the system is, the more severe the vulnerability.

+b) Integrity (I) describes an impact of the vulnerability on integrity of the system:
– None (N)—no impact
– Partial (P)—data can be partially modified
– Complete (C)—all data can be modified

The more affected the integrity of the system is, the more severe the vulnerability.

c) Availability (A) describes an impact of the vulnerability on availability of the system:
– None (N)—no impact
– Partial (P)—interruptions in system’s availability or reduced performance
– Complete (C)—system is completely unavailable

The more affected availability of the system is, the more severe the vulnerability.

Please note the abbreviated metric names and values in parentheses. They are used in base vector description of the vulnerability (explained in the next section).

Base vector

Let’s discuss the base vector. It is presented in the following form:

AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]

This is an abbreviated description of the vulnerability that brings information about its base metrics together with metric values. The brackets include possible metric values for given base metrics. The evaluator chooses one metric value for every base metric.

Scoring

The formulas for base score, exploitability, and impact subscores are given in A complete Guide to the Common Vulnerability Scoring System Version 2.0 [1]. However, there in no need to do the calculations manually. There is a Common Vulnerability Scoring System Version 2 Calculator available. The only thing the evaluator has to do is assign metric values to metric names.

Severity level

The base score is dependent on exploitability and impact subscores; it ranges from 0 to 10, where 10 means the highest severity. However, CVSS v2 doesn’t transform the score into a severity level. One can use, for example, the FortiGuard severity level to obtain this information:

FortiGuard severity level CVSS v2 score
Critical 9 – 10
High 7 – 8.9
Medium 4 – 6.9
Low 0.1 – 3.9
Info 0

Putting the pieces together

An exemplary vulnerability in web application is provided to better understand how Common Vulnerability Scoring System Version 2.0 works in practice. Please keep in mind that this framework is not limited to web application vulnerabilities.

Cross-site request forgery in admin panel allows adding a new user and deleting an existing user or all users.

Let’s analyze first the base metrics together with the resulting base vector:

Access Vector (AV): Network (N)
Access Complexity (AC): Medium (M)
Authentication (Au): None (N)

Confidentiality (C): None (N)
Integrity (I): Partial (P)
Availability (A): Complete (C)

Base vector: (AV:N/AC:M/Au:N/C:N/I:P/A:C)

Explanation: The admin has to visit the attacker’s website for the vulnerability to be exploited. That’s why the access complexity is medium. The website of the attacker is somewhere on the Internet. Thus the access vector is network. No authentication is required to exploit this vulnerability (the admin only has to visit the attacker’s website). The attacker can delete all users, making the system unavailable for them. That’s why the impact of the vulnerability on the system’s availability is complete. Deleting all users doesn’t delete all data in the system. Thus the impact on integrity is partial. Finally, there is no impact on the confidentiality of the system provided that added user doesn’t have read permissions on default.

Let’s use the Common Vulnerability Scoring System Version 2 Calculator to obtain the subscores (exploitability and impact) and base score:

Exploitability subscore: 8.6
Impact subscore: 7.8
Base score: 7.8

Let’s transform the score into a severity level according to FortiGuard severity levels:

FortiGuard severity level: High

Summary

This article described an open framework for scoring IT vulnerabilities—Common Vulnerability Scoring System (CVSS) Version 2.0. Base metrics, vector and scoring were presented. An exemplary way of transforming CVSS v2 scores into severity levels was described (FortiGuard severity levels). Finally, an example was discussed to see how all these pieces work in practice.

Dawid Czagan is a security researcher for the InfoSec Institute and the Head of Security Consulting at Future Processing.

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.

Bank of Montreal online banking insecurity

I’ve had an account with the Bank of Montreal for almost 50 years.

I’m thinking that I may have to give it up.

BMO’s online banking is horrendously insecure.  The password is restricted to six characters.  It is tied to telephone banking, which means that the password is actually the telephone pad numeric equivalent of your password.  You can use that numeric equivalent or any password you like that fits the same numeric equivalent.  (Case is, of course, completely irrelevant.)

My online access to the accounts has suddenly stopped working.  At various times, over the years, I have had problems with the access and had to go to the bank to find out why.  The reasons have always been weird, and the process of getting access again convoluted.  At present I am using, for access, the number of a bank debit card that I never use as a debit card.  (Or even an ATM card.)  The card remains in the file with the printed account statements.

Today when I called about the latest problem, I had to run through the usual series of inane questions.  Yes, I knew how long my password had to be.  Yes, I knew my password.  Yes, it was working until recently.  No, it didn’t work on online banking.  No, it didn’t work on telephone banking.

The agent (no, sorry, “service manager,” these days) was careful to point out that he was *not* going to ask me for my password.  Then he set up a conference call with the online banking system, and had me key in my password over the phone.

(OK, it’s unlikely that even a trained musician could catch all six digits from the DTMF tones on one try.  But a machine could do it easily.)

After all that, the apparent reason for the online banking not working is that the government has mandated that all bank cards now be chipped.  So, without informing me, and without sending me a new card, the bank has cancelled my access.  ( I suppose that is secure.  If you are not counting on availability, or access to audit information.)

(I also wonder, if that was the reason, why the “service manager” couldn’t just look up the card number and determine that the access had been cancelled, rather than having me try to sign in.)

I’ll probably go and close my account this afternoon.

    SecuriTeam Secure Disclosure

    SecuriTeam Secure Disclosure (SSD) helps researchers turn their vulnerability discovery skills into a highly paid career. Contact SSD to get the most for your hard work.