Disasters in BC

The auditor general has weighed in, and, surprise, surprise, we are not ready for an earthquake.

On the one hand, I’m not entirely sure that the auditor general completely understands disaster planning, and she hasn’t read Kenneth Myers and so doesn’t know that it can be counter-productive to produce plans for every single possibility.

On the other hand, I’m definitely with Vaugh Palmer in that we definitely need more public education.  We are seeing money diverted from disaster planning to other areas, regardless of a supposed five-fold increase in emergency budget.  In the past five years, the professional association has been defunded, training is very limited in local municipalities, and even recruitment and “thank you” events for volunteers have almost disappeared.  Emergency planning funds shouldn’t be used to pay for capital projects.

(And the province should have been prepared for an audit in this area, since they got a warning shot last year.)

So, once again, and even more importantly, I’d recommend you all get emergency training.  I’ve said it beforeI keep saying itI will keep on saying it.

(Stephen Hume agrees with me, although he doesn’t know the half of it. )


New computers – Windows 8 Phone

I was given a Win8Phone recently.  I suppose it may seem like looking a gift horse in the mouth to review it, but:

I must say, first off, that the Nokia Lumia has a lot of power compared to my other phone (and Android tablets), so I like the responsiveness using Twitter.  The antenna is decent, so I can connect to hotspots, even at a bit of a distance.  Also, this camera is a lot better than those on the three Android machines.

I’m finding the lack of functionality annoying.  There isn’t any file access on the phone itself, although the ability to access it via Windows Explorer (when you plug the USB cable into a Windows 7 or 8 computer) is handy.

I find the huge buttons annoying, and the interface for most apps takes up a lot of space.  This doesn’t seem to be adjustable: I can change the size of the font, but only for the content of an app, not for the frame or surround.

http://www.windowsphone.com/en-us/how-to/wp8 is useful: that’s how I found out how to switch between apps (hold down the back key and it gives you a set of
icons of running/active apps).

The range of apps is pathetic.  Security aside (yes, I know a closed system is supposed to be more secure), you are stuck with a) Microsoft, or b) completely unknown software shops.  You are stuck with Bing for search and maps: no Google, no Gmail.  You are stuck with IE: no Firefox, Chrome, or Safari.  Oh, sorry, yes you *can* get Firefox, Chrome, and Safari, but not from Mozilla, Google, or Apple: from developers you’ve never heard of.  (Progpack, maker(s) of the Windows Phone store version of Safari, admits it is not the real Safari, it just “looks like it.”)  You can’t get YouTube at all.  No Pinterest, although there is a LinkedIn app from LinkedIn, and a Facebook app–from Microsoft.

It’s a bit hard to compare the interface.  I’m comparing a Nokia Lumia 920 which has lots of power against a) the cheapest Android cell phone Bell had when I had to upgrade my account (ver 2.2), b) an Android 4.3 tablet which is really good but not quite “jacket” portable, and c) a Digital2 Android 4.1 mini-tablet which is probably meant for children and is *seriously* underpowered.

Don’t know whether this is the fault of Windows or the Nokia, but the battery indicators/indications are a major shortcoming.  I have yet to see any indication that the phone has been fully charged.  To get any accurate reading you have to go to the battery page under settings, and even that doesn’t tell you a heck of a lot.  (Last night when I turned it off it said the battery was at 46% which should be good for 18 hours.  After using it four times this morning for a total of about an hour screen time and two hours standby it is at 29%.)

(When I installed the Windows Phone app on my desktop, and did some file transfers while charging the phone through USB I found that the app has a battery level indicator on most pages, so that’s helpful.)


Crafting a Pen Testing Report

You close the lid of your laptop; it’s been a productive couple of days. There are a few things that could be tightened up, but overall the place isn’t doing a bad job. Exchange pleasantries with the people who have begrudgingly given up time to escort you, hand in your visitors badge and head for the door. Just as you feel the chill of outside against your skin, you hear a muffed voice in the background.

“Hey, sorry, I forgot to ask, when can we expect the report?”

Sound familiar?

Ugh, the report. Penetration testing’s least favorite cousin, but ultimately, one of the most important.

There are thousands of books written about information security and pen testing. There are hundreds of hours of training courses that cover the penetration testing process. However, I would happily wager that less than ten percent of all the material out there is dedicated to reporting. This, when you consider that you probably spend 40-50% of the total duration of a pen test engagement actually writing the report, is quite alarming.

It’s not surprising though, teaching someone how to write a report just isn’t as sexy as describing how to craft the perfect buffer overflow, or pivot round a network using Metasploit. I totally get that, even learning how the TCP packet structure works for the nineteenth time sounds like a more interesting topic.

A common occurrence amongst many pen testers. Not allowing enough time to produce a decent report.

No matter how technically able we are as security testers, it is often a challenge to explain a deeply technical issue to someone who may not have the same level of technical skill. We are often guilty of making assumptions that everyone who works in IT has read the same books, or has the same interests as us. Learning to explain pen test findings in a clear and concise way is an art form, and one that every security professional should take the time to master. The benefits of doing so are great. You’ll develop a better relationship with your clients, who will want to make use of your services over and over again. You’ll also save time and money, trust me. I once drove a 350 mile round trip to go and explain the contents of a penetration test report to a client. I turned up, read some pages of the report aloud with added explanations and then left fifteen minutes later. Had I taken a tiny bit more time clarifying certain issues in my report, I would have saved an entire day of my time and a whole tank of gas.

Diluted: “SSH version one should be disabled as it contains high severity vulnerabilities that may allow an attacker already on the network to intercept and decrypt communications, although the risk of an attacker gaining access to the network is very low, so this reduces the severity.”

Clarified: “It is advisable to disable SSH version one on these devices, failure to do so could allow an attacker with local network access to decrypt and intercept communications.”

Why is a penetration test report so important?

Never forget, penetration testing is a scientific process, and like all scientific processes it should be repeatable by an independent party. If a client disagrees with the findings of a test, they have every right to ask for a second opinion from another tester. If your report doesn’t detail how you arrived at a conclusion, the second tester will have no idea how to repeat the steps you took to get there. This could lead to them offering a different conclusion, making you look a bit silly and worse still, leaving a potential vulnerability exposed to the world.

Bad: “Using a port scanner I detected an open TCP port”.

    Better: “Using Nmap 5.50, a port scanner, I detected an open TCP port using the SYN scanning technique on a selected range of ports. The command line was: nmap –sS –p 7000-8000.”

The report is the tangible output of the testing process, and the only real evidence that a test actually took place. Chances are, senior management (who likely approved funding for the test) weren’t around when the testers came into the office, and even if they were, they probably didn’t pay a great deal of attention. So to them, the report is the only thing they have to go on when justifying the expense of the test. Having a penetration test performed isn’t like any other type of contract work. Once the contract is done there is no new system implemented, or no new pieces of code added to an application. Without the report, it’s very hard to explain to someone what exactly they’ve just paid for.

Who is the report for?

While the exact audience of the report will vary depending on the organization, it’s safe to assume that it will be viewed by at least three types of people.

Senior management, IT management and IT technical staff will all likely see the report, or at least part of it. All of these groups will want to get different snippets of information. Senior management simply doesn’t care, or doesn’t understand what it means if a payment server encrypts connections using SSL version two. All they want to know is the answer to one simple question “are we secure – yay or nay?”

IT management will be interested in the overall security of the organization, but will also want to make sure that their particular departments are not the cause of any major issues discovered during testing. I recall giving one particularly damming report to three IT managers. Upon reading it two of them turned very pale, while the third smiled and said “great, no database security issues then”.

IT staff will be the people responsible for fixing any issues found during testing. They will want to know three things. The name of the system affected, how serious the vulnerability is and how to fix it. They will also want this information presented to them in a way that is clear and organized. I find the best way is to group this information by asset and severity. So for example, “Server A” is vulnerable to “Vulnerability X, Y and Z. Vulnerability Y is the most critical”. This gives IT staff half a chance of working through the list of issues in a reasonable timeframe. There is nothing worse than having to work your way backwards and forwards through pages of report output to try and keep track of vulnerabilities and whether or not they’ve been looked at.

Of course, you could always ask your client how they would like vulnerabilities grouped. After all, the test is really for their benefit and they are the people paying! Some clients prefer to have a page detailing each vulnerability, with affected assets listed under the vulnerability title. This is useful in situations where separate teams may all have responsibilities for different areas of a single asset. For example, the systems team runs the webserver, but the development team writes the code for the application hosted on it.

Although I’ve mentioned the three most common audiences for pen test reports, this isn’t an exhaustive list. Once the report is handed over to the client, it’s up to them what they do with it. It may end up being presented to auditors, as evidence that certain controls are working. It could be presented to potential customers by the sales team. “Anyone can say their product is secure, but can they prove it? We can, look here is a pen test report”.

Reports might even end up getting shared with the whole organization. It sounds crazy, but it happens. I once performed a social engineering test, the results of which were less than ideal for the client. The enraged CEO shared the report with the whole organization, as a way of raising awareness of social engineering attacks. This was made more interesting, when I visited that same company a few weeks later to deliver some security awareness training. During my introduction, I explained that my company did security testing and was responsible for the social engineering test a few weeks back. This was greeted with angry stares and snide comments about how I’d gotten them all into trouble. My response was, as always, “better to give me your passwords than a genuine bad guy”.

What should the report contain?

Sometimes you’ll get lucky and the client will spell out exactly what they want to see in the report during the initial planning phase. This includes both content and layout. I’ve seen this happen to extreme levels of detail, such as what font size and line spacing settings should be used. However, more often than not, the client won’t know what they want and it’ll be your job to tell them.

So without further ado, here are some highly recommended sections to include in pen test reports.

  • A Cover Sheet. This may seem obvious, but the details that should be included on the cover sheet can be less obvious. The name and logo of the testing company, as well as the name of the client should feature prominently. Any title given to the test such as “internal network scan” or “DMZ test” should also be up there, to avoid confusion when performing several tests for the same client. The date the test was performed should appear. If you perform the same tests on a quarterly basis this is very important, so that the client or the client’s auditor can tell whether or not their security posture is improving or getting worse over time. The cover sheet should also contain the document’s classification. Agree this with the client prior to testing; ask them how they want the document protectively marked. A penetration test report is a commercially sensitive document and both you and the client will want to handle it as such.
  • The Executive Summary. I’ve seen some that have gone on for three or four pages and read more like a Jane Austen novel than an abbreviated version of the report’s juicy bits. This needs to be less than a page. Don’t mention any specific tools, technologies or techniques used, they simply don’t care. All they need to know is what you did, “we performed a penetration test of servers belonging to X application”, and what happened, “we found some security problems in one of the payment servers”. What needs to happen next and why “you should tell someone to fix these problems and get us in to re-test the payment server, if you don’t you won’t be PCI compliant and you may get a fine”. The last line of the executive summary should always be a conclusion that explicitly spells out whether or not the systems tested are secure or insecure, “overall we have found this system to be insecure”. It could even be just a single word.

A bad way to end an executive summary: “In conclusion, we have found some areas where security policy is working well, but other areas where it isn’t being followed at all. This leads to some risk, but not a critical amount of risk.”

A better way: “In conclusion, we have identified areas where security policy is not being adhered to, this introduces a risk to the organization and therefore we must declare the system as insecure.”

  • Summary of Vulnerabilities. Group the vulnerabilities on a single page so that at a glance an IT manager can tell how much work needs to be done. You could use fancy graphics like tables or charts to make it clearer – but don’t overdo it. Vulnerabilities can be grouped by category (e.g. software issue, network device configuration, password policy), severity or CVSS score –the possibilities are endless. Just find something that works well and is easy to understand.

  • Test Team Details. It is important to record the name of every tester involved in the testing process. This is not just so you and your colleagues can be hunted down should you break something. It’s a common courtesy to let a client know who has been on their network and provide a point of contact to discuss the report with. Some clients and testing companies also like to rotate the testers assigned to a particular set of tests. It’s always nice to cast a different set of eyes over a system. If you are performing a test for a UK government department under the CHECK scheme, including the name of the team leader and any team members is a mandatory requirement.
  • List of the Tools Used. Include versions and a brief description of the function. This goes back to repeatability. If anyone is going to accurately reproduce your test, they will need to know exactly which tools you used.

  • A copy of the original scope of work. This will have been agreed in advance, but reprinting here for reference purposes is useful.
  • The main body of the report. This is what it’s all about. The main body of the report should include details of all detected vulnerabilities, how you detected the vulnerability, clear technical expiations of how the vulnerability could be exploited, and the likelihood of exploitation. Whatever you do, make sure you write your own explanations, I’ve lost count of the number of reports that I’ve seen that are simply copy and paste jobs from vulnerability scanner output. It makes my skin crawl; it’s unprofessional, often unclear and irrelevant. Detailed remediation advice should also be included. Nothing is more annoying to the person charged with fixing a problem than receiving flakey remediation advice. For example, “Disable SSL version 2 support” does not constitute remediation advice. Explain the exact steps required to disable SSL version 2 support on the platform in question. As interesting as reading how to disable SSL version 2 on Apache is, it’s not very useful if all your servers are running Microsoft IIS. Back up findings with links to references such as vendor security bulletins and CVE’s.

Getting the level of detail in a report right is a tricky business. I once wrote a report that was described as “overwhelming” because it was simply too detailed, so on my next test I wrote a less detailed report. This was subsequently rejected because it “lacked detail”. Talk about moving the goalposts. The best thing to do is spend time with the client, learn exactly who the audience will be and what they want to get out of the report.

Final delivery.

When a pilot lands an airliner, their job isn’t over. They still have to navigate the myriad of taxiways and park at the gate safely. The same is true of you and your pen test reports, just because its finished doesn’t mean you can switch off entirely. You still have to get the report out to the client, and you have to do so securely. Electronic distribution using public key cryptography is probably the best option, but not always possible. If symmetric encryption is to be used, a strong key should be used and must be transmitted out of band. Under no circumstances should a report be transmitted unencrypted. It all sounds like common sense, but all too often people fall down at the final hurdle.


CyberSec Tips: E-Commerce – tip details 2 – fake sites

Following on with some more of the tips from an earlier post, originally published here:

The next three tips are pretty straightforward, and should be followed:
Don’t click on offers in email.
If it sounds too good to be true, don’t fall for it.
Don’t fall for fake eBay or PayPal sites.

Good advice all around.  In terms of fake eBay or PayPal sites, check the URLs, if you can see them, or the places you end up.  Often fraudsters will try and register sites with odd variations on the name, such as replacing the lower case letter l in PayPal with a digit 1, which can look similar: paypal.com vs paypa1.com.  Or they will send you to a subdirectory on either a legitimate site (for example, googledocs.com/paypal) or on a straight scam site (frauds.ru/paypal).  Or sometimes the URL is simply a mess of characters.  If the site isn’t pretty clearly the one you want, get out of there.


CyberSec Tips: Malware – advice for the sysadmin

This is possibly a little out of line with what I’m trying to do with the series.  This advice is aimed a little higher than the home user, or small business operator with little computer experience.  Today I got these questions from someone with an advanced computer background, and solid security background, but no malware or antivirus experience.  I figured that this might apply to a number of people out there, so here was my advice:


> Question 1: What is the best way to obtain some good virus samples to
> experiment with in a clean-room environment?

Just look for anything large in your spam filters  :-)

> What I see doing is setting up a VM that is connected to an isolated
> network (with no connection to any other computer or the internet except
> for a computer running wireshark to monitor any traffic generated by the
> virus/malware).

VMs are handy when you are running a wholesale sample gathering and analysis operation, but for a small operation I tend not to trust them.  You might try running Windows under a Mac or Linux box, etc.  Even then, some of the stuff is getting pretty sneaky, and some specifically target VMs.  (I wonder how hard it would be to run Windows in a VM under iOS on ARM?)

> Also, any other particular recommendations as to how to set up the
> clean-room environment?

I’m particularly paranoid, especially if you haven’t had a lot of background in malware, so I’d tend to recommend a complete airgap, with floppies.  (You can still get USB 3 1/2″ floppy drives.)  CDs might be OK, but USB drives are just getting too complex to be sure.

> Question 2: What products are recommended for removing viruses and malware
> (i.e. is there a generic disinfector program that you recommend)?

I wouldn’t recommend a generic for disinfection.  For Windows, after the disaster of MSAV, MSE is surprisingly good, and careful–unlikely to create more problems than it solves.  I like Avast these days: even the free version gives you a lot of control, although it seems to be drifting into the “we know what’s best for you” camp.  And Sophos, of course, is solid stuff, and has been close to the top of the AV heap for over two decades.  F-Secure is good, although they may be distracted by the expansion they are doing of late.  Kaspersky is fine, though opinionated.  Eset has long had an advantage in scanning speed, but it does chew up machine cycles when operating.

Symantec/Norton, McAfee, and Trend have always had a far larger share of the market than was justified by their actual products.

As always, I recommend using multiple products for detection.

> I assume the preferred approach is to boot the suspect computer from USB
> and to run the analysis/disinfection software from the USB key (i.e. not to boot
> the infected computer until it has been disinfected).

A good plan.  Again, I might recommend CD/DVD over USB keys, but, as long as you are careful that the USB drive is clean …

> Question 3: How/when does one make the decision to wipe the hard drive and
> restore from backup rather than attempt to remove the malware?

If you have an up-to-date backup, that is always preferred when absolute security is the issue.  However, the most common malware is going to be cleanable fairly easily.  (Unless you run into some of the more nasty ransomware.)

Pushing backup, and multiple forms of backup, on all users and systems, is a great idea for all kinds of problems.  I’ve got a “set and forget” backup running to a USB drive that automatically updates any changes about every fifteen minutes.  And every couple of days I make a separate backup (and I have different USB drives I do it to) of all data files–which I then copy on to one of the laptops.  I just use an old batch file I created, which replaces any files with newer versions.  (Since it doesn’t delete anything I don’t change, it also means I have recovery possibilities if I make a mistake with deleting anything, and, by using multiple drives, I can rotate them for offsite storage, and even have possibilities of recovering old versions.)

> Question 4: Any recommended books or other guides to this subject matter?

Haven’t seen anything terrifically useful recently, unfortunately.  David Harley and I released “Viruses Revealed” as public domain a few years back, but it’s over ten years old.  (We released it about the time a vxer decided to upload it to http://vxheavens.com/lib/ars08.html  He probably thought he was hurting our sales, but we figured he was doing us a favour  :-)


CyberSec Tips: Email – Spam – Phishing – example 3 – credit checks

A lot of online security and anti-fraud checklists will tell you to check your credit rating with the credit rating reporting companies.  This is a good idea, and, under certain conditions, you can often get such reports free of charge from the ratings companies.

However, you should never get involved with the promises of credit reports that come via spam.

Oddly, these credit report spam messages have very little content, other than a URL, or possibly a URL and some extra text (which usually doesn’t display) meant only to confuse the matter and get by spam filters.  There are lots of these messages: today I got five in only one of my accounts.

I checked one out, very carefully.  The reason to be careful is that you have no idea what is at the end of that URL.  It could be a sales pitch.  It could be an attempt to defraud you.  It could be “drive-by” malware.  In the case I tested, it redirected through four different sites before finally displaying something.  Those four different sites could simply be there to make it harder to trace the spammers and fraudsters, but more likely they were each trying something: registering the fact that my email address was valid (and that there was a live “sucker” attached to it, worth attempting to defraud), installing malware, checking the software and services installed on my computer, and so forth.

It ended up at a site listing a number of financial services.  The domain was “simply-finances.com.”  One indication that this is fraudulent is that the ownership of this domain name is deeply buried.  It appears to be registered through GoDaddy, which makes it hard to check out with a normal “whois” request: you have to go to GoDaddy themselves to get any information.  Once there you find that it is registered through another company called Domains By Proxy, who exist solely to hide the ownership of domains.  Highly suspicious, and no reputable financial company would operate in such a fashion.

The credit rating link sent me to a domain called “transunion.ca.”  The .ca would indicate that this was for credit reporting in Canada, which makes sense, as that is where I live.  (One of the redirection sites probably figured that out, and passed the information along.)  However, that domain is registered to someone in Chicago.  Therefore, it’s probably fraud: why would someone in Chicago have any insight on contacts for credit reporting for Canadians?

It’s probably fraudulent in any case.  What I landed on was an offer to set me up for a service which, for $17 per month, would generate credit ratings reports.  And, of course, it’s asking for lots of information about me, definitely enough to start identity theft.  There is no way I am signing up for this service.

Again, checking out your own credit rating is probably a good idea, although it has to be done regularly, and it only really detects fraud after the fact.  But going through offers via spam is an incredibly bad idea.


CyberSec Tips: Email – Spam – check your filters

Spam filters are getting pretty good these days.  If they weren’t, we’d be inundated.

But they aren’t perfect.

It’s a good idea to check what is being filtered out, every once in a while, to make sure that you are not missing messages you should be getting.  Lots of things can falsely trigger spam filters these days.

Where and how you check will depend on what you use to read your email.  And how you report that something is or isn’t spam will depend on that, too.

If you use the Web based email systems, like Gmail, Yahoo, Outlook/Hotmail, or others, and you use their Web interface, the spam folder usually is listed with other folders, generally to the left side of the browser window.  And, when you are looking at that list, when you select one of the messages, somewhere on the screen, probably near the top, is a button to report that it isn’t spam.

It’s been a couple of weeks since I did this myself, so I checked two of my Webmail accounts this morning.  Both of them had at least one message caught in the spam trap that should have been sent through.  Spam filtering is good, but it isn’t perfect.  You have to take responsibility for your own safety.  And that means checking the things you use to keep you safe.


CyberSec Tips: Email – Spam – Fraud – example 4

Sometimes it’s pretty easy to tell a fraud.  Some of these guys are just lazy:

> From:               ”PINILLA, KARINA” <pinillak@friscoisd.org>
> Subject:
> Date sent:          Mon, 2 Dec 2013 22:05:05 +0000

> Do you want your X-mas money and bonus for gift,if Yes contact me at this email:
> david.loanfinancialcomany12@gmail.com

You don’t know this person.  No subject for the message.  No explanation of why they are going to give you money.  (Although the name chosen for the email would seem to indicate that they want to emulate a pay-day loan company–which are pretty much rip-offs anyway.)  Poor grammar and spelling.

A while back someone seriously theorized that this lack of care might be deliberate.  Only stupid people would fall for a “come-on” like this, and it would be easier to defraud stupid people.  Unfortunately, as the song says, the world is full of stupid people …


CyberSec Tips: Email – Spam – Phishing – email accounts – example 1

Sometimes phishers are after more than your bank account or credit cards.  These days a lot of them want your email account.  They can use it to send spam, to your friends, and those friends will trust a message from you.  (That’s a more reliable form of social engineering to get them to install malware on their computers.  Or give up their bank accounts and credit card numbers …)

> Dear user
> Your email has exceeded 2 GB, which is created by Webmaster, you are currently
> running at 2.30GB, you can not Send or receive new messages until you check your
> account.Complete the form below to verify your account.

Sometimes the email phishers will send you this “over quota” message.  Other times it may be that you are, supposedly, sending out malware or spam yourself.

> Please complete the details below to confirm your account
> (1) E-mail:
> (2) Name:
> (3) Password:
> (4) Confirm Password:

Here they just flat out ask you for your user name and password.

Spam isn’t the only thing they can do with your account.  These days Web based email accounts can be linked to storage space and other functions.  Google accounts are very valuable, since they give the phishers access to Google+ (with lots of personal information about you), YouTube, and Google Drive (which still has Google Docs in it, and can be used to set up phishing Websites).

Again, watch for telltale signs in the headers:

To:                 Recipients <web@epamig.br>
From:               HELP DESK<web@epamig.br>
Date sent:          Sun, 01 Dec 2013 14:01:47 +0100
Send reply to:      647812717@qq.com

It isn’t “to” you, and the “reply” isn’t the same as the “from.”


CyberSec Tips: E-Commerce – tip details 1 – search engines

Our local paper, like just about everyone else, recently published a set of tips for online shopping.  (They got them from Trend Micro Canada.)  The tips are mostly OK, as far as they go, but I figured they could use a little expansion.

“Don’t rely on search engines to find a shopping site.

“Search results can lead to malicious websites that will take your credit card and other confidential data or infect your computer with a virus. Instead, bookmark reliable online shopping sites.”

As a general rule, it’s best to be careful whenever you go to a site that is new or unknown to you.  However, I’d have to take this tip with a grain of salt.  I did a (Google) search on London Drugs, a chain in Western Canada (widely known in the tech community for their computer departments) (about which I have written before), and the first five pages gave results that were all from, or legitimately about, that company.  Quick checks on other retailers got similar results.

It makes sense to bookmark a “known good” link if you shop someplace regularly.  But if you are going to a new site, you can get into just as much trouble by guessing at a domain name, or even just fumbling typing the URL.  Fraudsters will register a number of domain names that are very similar to those of legitimate companies; just a character or so off; knowing that slipping fingers will drive people to their sites.  Some of those malicious sites look very much like the real thing.  (Others, promoting all kinds of questionable services and deals, are obviously false.)

Always be careful, and suspicious.  If anything seems off, get out of there, and maybe do a bit of research before you try again.  But don’t just avoid search engines as a matter of course.


CyberSec Tips: Email – Spam – Fraud – example 3

This one is slightly interesting, in that it contains elements of both 419 and phishing.  It’s primarily an advance fee fraud message.  First off, the headers:

> Subject: Dear Winner!!!
> From: CHELPT <inf8@hotline.onmicrosoft.com>
> Date: Thu, 28 Nov 2013 17:45:06 +0530
> Reply-To: <morrluke@careceo.com>
> Message-ID: <XXX.eurprd01.prod.exchangelabs.com>

Again, we see different domains, in particular, a different address to reply to, as opposed to where it is supposed to be from.

> Corporate Headquarters
> Technical Office Chevrolet promotion unit
> 43/45 The Promenade…
> Head Office Chevrolet motors
> 43/45 The Promenade Cheltenham
> Ref: UK/9420X2/68
> Batch: 074/05/ZY369
> Chevrolet Canter, London, SE1 7NA – United Kingdom

My, my, my.  With all that addressing and reference numbers, it certainly looks official.  But isn’t.

> Dear Winner,
> Congratulations, you have just won a cash prize of £1,000, 000, 00. One million
> Great British Pounds Sterling (GBP) in the satellite software email lottery.
> On-line Sweepstakes International program held on this day Satur day 23rd
> November 2013 @05:42.PM London time. Conducted by CHEVROLET LOTTERY BOARD in
> which your e-mail address was pick randomly by software powered by the Internet
> send data’s to;
> ——————————————————————————–
> Tell: +44 701 423 4661             Email: morrluke@careceo.com Officer Name: Mr.
> ——————————————————————————–

As usual, you have supposedly won something.  If you reply, of course, there will start to be fees or taxes that you have to pay before the money is released to you.  The amounts will start out small (hey, who wouldn’t be willing to pay a hundred pound “processing fee” in order to get a million pounds, right?) but then get larger.  (Once you’ve paid something, then you would tend to be willing to pay more.  Protecting your investment, as it were.)  And, of course you will never see a cent of your winnings, inheritance, charity fund, etc, etc.

> Below is the claims and verifications form. You are expected to fill and return
> it immediately so we can start processing your claims:
> 1. Full Names:
> 2. Residential Address:
> 3. Direct Phone No:
> 4. Fax Number
> 5. Occupation:
> 6. Sex:
> 7. Age:
> 8. Nationality:
> 9. Annual Income:
> 10. Won Before:
> 11. Batch number: CHELPT1611201310542PM
> 12: Ticket Numbers: 69475600545-72113
> 13: Lucky numbers: 31-6-26-13-35-7

But here, they are starting to ask you for a lot of personal information.  This could be used for identity theft.  Ultimately, they might ask for your bank account information, in order to transfer your winnings.  Given enough other data on you, they could then empty your account.

> We wish you the best of luck as you spend your good fortune thank you for being
> part of our commemorative yearly Draws.
> Sincerely,
> Mrs. Susan Chris.

Oh, yeah.  Good luck on ever getting any of this money.


CyberSec Tips: Email – Spam – Phishing – example 2

Some of you may have a BarclayCard credit card.  You might receive a reminder message that looks like the one below.  (Actually, the only credit card company I know that actually sends email reminders is American Express, which I think is a black mark on their security record.)

> Subject: Barclaycard Payment is due
> From: “Barclaycard” <barclaycard@card.com>
> Received: from smtp.alltele.net

If you look at the message headers, you might note that this message doesn’t come from where it says it comes from, and that’s something of which to beware.

> Your barclaycard payment is due
> Visit your card service section below to proceed
> hxxp://www.equivalente.it/rss/re.html

You might also note that, it you do have a BarclayCard, it’s probably because you live in the UK.  And the server they want you to visit is in Italy: .it


CyberSec Tips: Email – Spam – Fraud – example 2

Another advance fee/419 fraud is the lottery.

> Subject: Dear User
> To: Recipients <info@notizia348.onmicrosoft.com>
> From: Alexander brown <info@notizia348.onmicrosoft.com>

Again, your email address, which supposedly “won” this lottery, is missing: this message is being sent to many people.  (If you really had won millions, don’t you think they’d take a bit more care getting it to you?)

> Dear Internet User,
>  We are pleased to inform you again of the result of the Internet Promotional
>  Draws. All email addresses entered for this promotional draws were randomly
>  inputted from an internet resource database using the Synchronized
> Data Collective Balloting Program.

Sounds impressive.  But it really doesn’t mean anything.  In the first place, you never entered.  And why would anyone set up a lottery based simply on random email sent around the net?  There is no benefit to anyone in that, not even as a promotion.

>  This is our second letter to you. After this automated computer ballot,your
>  email address was selected in Category A with Ref Number: GTL03-2013 and
>  E-Ticket Number: EUB/8974IT,this qualifies you to be the recipient of t
> he grand prize award sum of (US$2,500,000.00) Two Million, Five Hundred Thousand
> United States Dollars.

This is interesting: it presents still more impressive stuff–that really has no meaning.  It starts by saying this is the second message to you, implying that you missed the first.  This is intended to make you anxious, and probably a bit less questioning about things.  Watch out for anything that tries to rush or push you.

The numbers, of course, are meant to sound official, but are meaningless.

>  The payout of this cash prize to you will be subject to the final validations
>  and satisfactory report that you are the bona fide owner of the winning email
>  address. In line with the governing rules of claim, you are requ
> ired to establish contact with your designated claims agent via email or
> telephone with the particulars below:
>  Enquiry Officer: Mr. Samuel Trotti
> Phone: +39 3888146161
> Email: trottioffice@aim.com

Again, note that the person you are to contact is not the one (or even the same domain) as sent the message.

>  You may establish contact with the Enquiry Officer via the e-mail address above
>  with the information’s necessary: Name:, Address:, Phone:, Cell Phone:, Email:,
>  Alternative Email:, Occupation:, Ref Number and E-Ticket Number. All winnings
>  must be claimed within 14 days from today. After this date all unclaimed funds
>  would be included in the next stake. Remember to quote your reference
>  information in all correspondence with your claims agent.

This is interesting: the amount of information they ask from you means that this might not simply be advance fee fraud, but they might be doing phishing and identity theft, as well.


CyberSec Tips: Email – Spam – Fraud – example 1

A lot of the advance fee fraud (also called 419 or Nigerian scams) these days say you’ve been named in a will:

> Subject: WILL EXECUTION!!!
> To: Recipients <clifordchance08@cliffordchance854.onmicrosoft.com>
> From: Clifford Chance <clifordchance08@cliffordchance854.onmicrosoft.com>

Note in this case that the message is sent “to” the person who sent it.  This is often an indication that many people have been sent the same message by being “blind” copied on it.  In any case, it wasn’t sent specifically to you.

> Late Mr.Robert Adler bequeathed US$20,500,000.00 USD, to you in his will.More
> info,contact your attorney(Clifford Chance Esq) via email
> address:clf.chance@hotmail.com  Tell+44-871-974-9198

This message doesn’t tell you very much: sometimes they have a reference to a recent tragic event.

Note also that the email address you are supposed to contact is not the same address that sent the message.  This is always suspicious.  (So is giving a phone number.)

If you look into the headers, there are more oddities:

> From: Clifford Chance <clifordchance08@cliffordchance854.onmicrosoft.com>
> Reply-To: <clf.chance@hotmail.com>
> Message-ID: <XXXX@SINPR02MB153.apcprd02.prod.outlook.com>

There are not only three different email addresses, but three different domains.  Microsoft owns Hotmail, and Hotmail became Outlook, so it’s possible, but it’s still a bit odd.


It’s What’s on the Inside that Counts

The last time I checked, the majority of networking and security professionals were still human.

We all know that the problem with humans is that they sometimes exhibit certain behaviors that can lead to trouble – if that wasn’t the case we’d probably all be out of a job! One such behavior is obsession.

Obsession can be defined as an idea or thought that continually preoccupies or intrudes on a person’s mind. I’ve worked with a number of clients who have had an obsession that may, as bizarrely as it seems, have had a negative impact on their information security program.

The obsession I speak of is the thought of someone “breaking in” to their network from the outside.

You’re probably thinking to yourself, how on earth can being obsessed with protecting your network from external threats have a negative impact on your security? If anything it’s probably the only reason you’d want a penetration test in the first place! I’ll admit, you’re correct about that, but allow me to explain.

Every organization has a finite security budget. How they use that budget is up to them, and this is where the aforementioned obsession can play its part. If I’m a network administrator with a limited security budget and all I think about is keeping people out of my network, my shopping list will likely consist of edge firewalls, web-application firewalls, IDS/IPS and a sprinkling of penetration testing.

If I’m a pen tester working on behalf of that network administrator I’ll scan the network and see a limited number of open ports thanks to the firewall, trigger the IPS, have my SQL injection attempts dropped by the WAF and generally won’t be able to get very far. Then my time will be up, I’ll write a nice report about how secure the network is and move on. Six or twelve months later, I’ll do exactly the same test, find exactly the same things and move on again. This is the problem. It might not sound like a problem, but trust me, it is. Once we’ve gotten to this point, we’ve lost sight of the reason for doing the pen test in the first place.

The test is designed to be a simulation of an attack conducted by a malicious hacker with eyes only for the client. If a hacker is unable to break into the network from the outside, chances are they won’t wait around for a few months and try exactly the same approach all over again. Malicious hackers are some of the most creative people on the planet. If we really want to do as they do, we need to give our testing a creativity injection. It’s our responsibility as security professionals to do this, and encourage our clients to let us do it.

Here’s the thing, because both pen testers and clients have obsessed over how hackers breaking into stuff for so long, we’ve actually gotten a lot better at stopping them from doing so. That’s not to say that there will never be a stray firewall rule that gives away a little too much skin, or a hastily written piece of code that doesn’t validate input properly, but generally speaking “breaking in” is no longer the path of least resistance at many organizations – and malicious hackers know it. Instead “breaking out” of a network is the new route of choice.

While everyone has been busy fortifying defenses on the way in to the network, traffic on the way out is seldom subject to such scrutiny – making it a very attractive proposition to an attacker. Of course, the attacker still has to get themselves into position behind the firewall to exploit this – but how? And how can we simulate it in a penetration test?

What the Pen Tester sees

The Whole Picture

On-Site Testing

There is no surer way of getting on the other side of the firewall than to head to your clients office and plugging directly into their network. This isn’t a new idea by any means, but it’s something that’s regularly overlooked in favor of external or remote testing. The main reason for this of course is the cost. Putting up a tester for a few nights in a hotel and paying travel expenses can put additional strain on the security budget. However, doing so is a hugely valuable exercise for the client. I’ve tested networks from the outside that have shown little room for enumeration, let alone exploitation. But once I headed on-site and came at those networks from a different angle, the angle no one ever thinks of, I had trouble believing they were the same entity.

To give an example, I recall doing an on-site test for a client who had just passed an external test with flying colors. Originally they had only wanted the external test, which was conducted against a handful of IPs. I managed to convince them that in their case, the internal test would provide additional value. I arrived at the office about an hour and a half early, I sat out in the parking lot waiting to go in. I fired up my laptop and noticed a wireless network secured with WEP, the SSID was also the name of the client. You can probably guess what happened next. Four minutes later I had access to the network, and was able to compromise a domain controller via a flaw in some installed backup software. All of this without leaving the car. Eventually, my point of contact arrived and said, “So are you ready to begin, or do you need me to answer some questions first?” The look on his face when I told him that I’d actually already finished was one that I’ll never forget. Just think, had I only performed the external test, I would have been denied that pleasure. Oh, and of course I would have never picked up on the very unsecure wireless network, which is kind of important too.

This is just one example of the kind of thing an internal test can uncover that wouldn’t have even been considered during an external test. Why would an attacker spend several hours scanning a network range when they could just park outside and connect straight to the network?

One of my favorite on-site activities is pretending I’m someone with employee level access gone rogue. Get on the client’s standard build machine with regular user privileges and see how far you can get on the network. Can you install software? Can you load a virtual machine? Can you get straight to the internet, rather than being routed through a proxy? If you can, there are a million and one attack opportunities at your fingertips.

The majority of clients I’ve performed this type of test for hugely overestimated their internal security. It’s well documented that the greatest threat comes from the inside, either on purpose or by accident. But of course, everyone is too busy concentrating on the outside to worry about what’s happening right in front of them.

Good – Networks should be just as hard to break out of, as they are to break in to.

Fortunately, some clients are required to have this type of testing, especially those in government circles. In addition, several IT security auditing standards require a review of internal networks. The depth of these reviews is sometimes questionable though. Auditors aren’t always technical people, and often the review will be conducted against diagrams and documents of how the system is supposed to work, rather than how it actually works. These are certainly useful exercises, but at the end of the day a certificate with a pretty logo hanging from your office wall won’t save you when bad things happen.

Remote Workers

Having a remote workforce can be a wonderful thing. You can save a bunch of money by not having to maintain a giant office and the associated IT infrastructure. The downside of this is that in many organizations, the priority is getting people connected and working, rather than properly enforcing security policy. The fact is that if you allow someone to connect remotely into the heart of your network with a machine that you do not have total control over, your network is about as secure as the internet. You are in effect extending your internal network out past the firewall to the unknown. I’ve seen both sides of the spectrum, from an organization that would only allow people to connect in using routers and machines that they configured and installed, to an organization that provided a link to VPN client and said “get on with it”.

I worked with one such client who was starting to rely on remote workers more and more, and had recognized that this could introduce a security problem. They arranged for me to visit the homes of a handful of employees and see if I could somehow gain access to the network’s internal resources. The first employee I visited used his own desktop PC to connect to the network. He had been issued a company laptop, but preferred the big screen, keyboard and mouse that were afforded to him by his desktop. The machine had no antivirus software installed, no client firewall running and no disk encryption. This was apparently because all of these things slowed it down too much. Oh, but it did have a peer-to-peer file sharing application installed. No prizes for spotting the security risks here.

In the second home I visited, I was pleased to see the employee using her company issued XP laptop. Unfortunately she was using it on her unsecured wireless network. To demonstrate why this was a problem, I joined my testing laptop to the network, fired up a Metasploit session and hit the IP with my old favorite, the MS08-067 NetAPI32.dll exploit module. Sure enough, I got a shell, and was able to pivot my way into the remote corporate network. It was at this point that I discovered the VPN terminated in a subnet with unrestricted access to the internal server subnet. When I pointed out to the client that there really should be some sort of segregation between these two areas, I was told that there was. “We use VLAN’s for segregation”, came the response. I’m sure that everyone reading this will know that segregation using VLAN’s, at least from a security point of view, is about as useful as segregating a lion from a Chihuahua with a piece of rice paper. Ineffective, unreliable and will result in an unhappy ending.

Bad – The VPN appliance is located in the core of the network.

Social Engineering

We all know that this particular activity is increasing in popularity amongst our adversaries, so why don’t we do it more often as part of our testing? Well, simply put, a lot of the time this comes down to politics. Social engineering tests are a bit of a touchy subject at some organizations, who fear a legal backlash if they do anything to blatantly demonstrate how their own people are subject to the same flaws as the seven billion other on the planet. I’ve been in scoping meetings when as soon as the subject of social engineering has come up, I’m stared at harshly and told in no uncertain terms, “Oh, no way, that’s not what we want, don’t do that.” But why not do it? Don’t you think a malicious hacker would? You’re having a pen test right? Do you think a malicious hacker would hold off on social engineering because they haven’t gotten your permission to try it? Give me a break.

On the other hand, I’ve worked for clients who have recognized the threat of social engineering as one of the greatest to their security, and relished at the opportunity to have their employees tested. Frequently, these tests result in a greater than 80% success rate. So how are they done?

Well, they usually start off with the tester registering a domain name which is extremely similar to the client’s. Maybe with one character different, or a different TLD (“.net” instead of “.com” for example).

The tester’s next step would be to set up a website that heavily borrows CSS code from the client’s site. All it needs is a basic form with username and password fields, as well as some server side coding to email the contents of the form to the tester upon submission.

With messages like this one in an online meeting product, it’s no wonder social engineering attacks are so successful.

Finally, the tester will send out an email with some half-baked story about a new system being installed, or special offers for the employee “if you click this link and login”. Sit back and wait for the responses to come in. Follow these basic steps and within a few minutes, you’ve got a username, password and employee level access. Now all you have to do is find a way to use that to break out of the network, which won’t be too difficult, because everyone will be looking the other way.


The best penetration testers out there are those who provide the best value to the client. This doesn’t necessarily mean the cheapest or quickest. Instead it’s those who make the most effective use of their relatively short window of time, and any other limitations they face to do the job right. Never forget what that job is, and why you are doing it. Sometimes we have to put our generic testing methodologies aside and deliver a truly bespoke product. After all, there is nothing more bespoke than a targeted hacking attack, which can come from any direction. Even from the inside.


The Common Vulnerability Scoring System


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:


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.


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


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.