How SHA-1 Is Broken

(This gets very esoteric very quickly)

Those of you paying attention may have realised that very recently (January this year), browsers started complaining about security when connecting to sites whose SSL certificates used the SHA-1 hashing algorithm within the certificate. This was due to a theoretical weakness in the algorithm known about as far back as 2005.

What has changed since then is that Google researchers have now demonstrated the attack, and whilst it is not practicable (with the possible exception of nation state attackers), it is now well past time that SHA-1 was gracefully retired. Especially when you consider that a methodology that is not sensibly practicable today may well be usable in 5-10 years.

SHA-1 is a cryptographic hashing algorithm whereby any individual lump of data can be uniquely expressed with a single hash and no other lump of data can share that hash value. Or more precisely it is difficult to generate a collision whereby two lumps of data hash to the same value. If you run a SHA-1 tool against a file, it should return a unique value unless the file is identical :-

The first command shows incorrect behaviour whereby two different files result in identical hash values; the second command shows the correct behaviour demonstrating that the files contain different contents.

In practice, an attacker would have to produce a lump of data that generates the same SHA-1 hash value as a the lump of data that she wanted to ‘impersonate’, which has not been demonstrated. Google’s researchers have simply generated two lumps of data which generate the same SHA-1 hash value … which is somewhat easier.

Cryptographic hash functions are used as a building block to build secure cryptography, and using a weak hashing algorithm will fundamentally result in less secure cryptography.

Posted in Technical | Tagged , , | Comments Off on How SHA-1 Is Broken

Phishing: What To Do In The Aftermath

In the event that you have given away your account details in response to a phishing attack, and either discovered yourself that your account is compromised or you have been told so by IS, then there are some steps to take in the aftermath :-

  1. Change your password to one that is long and strong.
  2. Turn on “two factor” authentication.
  3. Check the signature set for your account; phishers are known to have set inappropriate signatures to be attached to all outgoing emails. The quick check? Send a quick email to your personal email address and check what the signature says.
  4. Check the “rules” for incoming email messages to make sure nothing has been added. Phishers have been known to set up new rules to delete all incoming messages.

 

Posted in Email, Passwords | Comments Off on Phishing: What To Do In The Aftermath

Don’t Automatically Trust Email!

Email is a very easy to forge – so easy that if you try to impress a hacker by claiming to have forged email, they’ll fall about the floor laughing. So you should not automatically trust email – there are usually indicators showing the origin is suspicious …

2016-12-01_0920

This example is a bit obvious and not only because it has a big warning added by Google :-

  • Look at the email address (“Golan <jjulio@unifap.br>”) – why does the email address not match the name? The name at the end of the email is “Ella Golan” which is included as a comment to the email address, but bears no relation to the actual email address (“jjulio@unifap.br”). Now legitimate emails can have this signature, but it is a useful indicator.
  • The email contents mention Israel, so why is a Brazilian email address being used – the .br at the end of the domain name is a country-based domain using the ISO 3166-1 two letter country code.
  • The subject (“Hey”) is informal to an extreme degree (as well as an example of a poor subject), yet the contents of the email are formal. Suspicious?
  • The wording of the actual email itself are somewhat odd. Of course people don’t always write perfect English, but it is still a useful indicator.

The more dangerous emails tend to be ones that ask you to do something directly :-

Good Day

Please do check attached document
It is secure via Adobe file
Awaiting to read from you
Many thanks

Andrew

Again the English is a little odd. But there are still some additional indicators here :-

  • Is it usual for an attachment to be included? And without mentioning anything about what is inside?
  • Secured by something written by Adobe? Well that is probably more a security insider’s joke. But do you commonly deal with attachments secured in this way?
  • If it is supposedly from someone within your organisation, why are they not using your organisation’s method of sharing files?

The key thing to grasp is that email itself cannot be trusted, but emails not worthy of trust often give themselves away in little ways. Learn to pick up on those untrustworthy little ways, and mark each email with a trustworthiness score … and if it comes out as a bit suspicious, try contacting the sender to confirm they really did send it.

You can of course always ask a colleague to check the email as well.

Posted in Email | Comments Off on Don’t Automatically Trust Email!

Analysis Of A Phishing Attack

The following is the analysis of a real phishing attack that we have seen, together with some indications of how a phishing attack can be detected. For the impatient, some of those indicators are listed below :-

  1. Are you expecting to receive a document from the person sending it? You may want to check back with them to be sure they really intended to send it.
  2. Don’t open suspicious attachments, but if you do, does it contain something sensible? Sending a PDF document containing a link to a shared cloud storage folder doesn’t actually make sense – the link could be contained within the original email.
  3. Are there inconsistencies in the words? For example does the message mention Google Drive, but the link say Dropbox?
  4. Don’t follow suspicious links contained within suspicious attachments, but if you do, and it takes you to a Google logon screen :-
    1. Are you already logged into Google? You shouldn’t need to re-authenticate that quickly.
    2. Does it actually look like the Google logon screen? It might look similar but are there differences?
    3. Does the location bar (where your browser shows the address of the current page) mention Google? If it doesn’t, back away from the page slowly.
    4. Does the location bar contain a green padlock? If it doesn’t, your login credentials won’t be encrypted which is very suspicious.

And onto the analysis …

A number of people received an email “from” someone at the University containing a PDF attachment together with a suggestion that it contained something worth reading. Opening the attachment from a previously unknown correspondent and with an oddly worded email was the first mistake.

If you do receive such attachments, it is worth checking with the sender to see if it is legitimate.

If you do make the mistake of opening it, the first odd thing to notice is that the attachment is named “Scan…” but contains content that obviously isn’t scanned :-

2016-11-29_1003

So if this is a google drive document, why isn’t it being shared in the normal way? Which looks more like :-

2016-11-29_1009-ano

(I’ve erased the name of the sharer and the name of the document)

In addition, if you hover your mouse over the button you get a pop-up with the link address in :-

2016-11-29-10-04-38

So the text says “Google Drive” and the link says “Dropbox”? Another suspicious indication.

If you download the link from Dropbox (in a controlled manner!), the “document” is actually a web page with a base64 encoded content (with a page title of “Zeuxhaxor” (if that doesn’t look suspicious to you, your suspiciousness needs tweaking)) that sends you onto another web page hosted at http://freecabin.net/.

If you visit the page, you end up faced with the following (without the hand-drawn lines) :-

2016-11-28_1350-hi

This also has plenty of indications that something is wrong :-

  1. Aren’t you already logged into Google? Why do you need to login again?
  2. Look at the location bar (where the two black hand drawn lines are): Why is the address “freecabin.net”?
  3. Look at the location bar again: Where is the green padlock you would see on a secure page? Do you really want to send out your username and password insecurely?

Phishing attacks are intended to dupe you into leaking your username and password combination, and as such the attacker tries to make things look as authentic as possible. However there are usually many small signs that something is wrong – at least wrong enough to check with someone before you leak your account details.

Posted in Active Attacks, Email | Tagged , | Comments Off on Analysis Of A Phishing Attack

How Often Should I Patch?

The short version: “It varies”.

“Have you applies the latest security fixes from your operating system vendor to your machines?” I asked, trying to a learn a little more about Fred’s security posture.

Fred replies with hesitation, “We apply security patches every three months. The last time we deployed fixes was … um … two-and-a-half months ago.”

I scratched my aching head and said, “Two major buffer overflow attacks were released last week.”

  • From the first edition of Counter Hack by Ed Skoudis, and very outdated.

Applying operating system patches to a system reduces the known risk associated with the operating system to zero, but that known risk starts increasing the moment the system finishes it’s final post-patch reboot. The risk might increase very quickly or very slowly, but the increase in risk looks something like …

risk

 

You might choose to patch when the level of risk reaches 50, but to do so you will need to assess the level of risk associated with every security vulnerability that each patch fixes. And that level will vary on the nature of the vulnerability, and the nature of the server in question.

As an example, a patch that fixes a privilege escalation vulnerability that requires an authenticated account to work with can be assessed as being very low risk for a server that is not widely available (i.e. no Internet access). Whereas the risk assessment for a server that is open to the Internet, and has a very large number of accounts that can authenticate, should be very high.

However carrying out a full risk assessment for each server on the network, and for each patch that is released would be exceptionally expensive.

As an alternative we resort to patching every N days where N is a balance between the risk of known security vulnerabilities, and the disruption to the business of patching. Of course if the disruption of patching is exceptionally damaging to the business, ways to design the infrastructure that allows for patching without disruption should be pursued.

Looking at how long N can be, there is no value of N that is safe. Even if you patch every day, there is still a small window of opportunity when an attacker may succeed. All we can do is reduce the risk.

So is patching every three months sufficient? Well it is better than not patching at all, but no security professional could possibly say that it is sufficient without risking being accused of professional misconduct. And yes there will be occasions like that given in the quote at the top where patching every three months will allow an attacker in.

Posted in General | Tagged , | Comments Off on How Often Should I Patch?

Friday’s DDoS Attack And The Mirai IoT Worm

It may have reached your attention that there was a significant denial of service attack against a widely used DNS provider – the service provider for organisations such as Twitter, Github, and Amazon. The effect was to make certain services unreachable leading some to believe that the Internet was down!

Some of the major links may provide additional information :-

The details of the attack are still being disclosed, but it appears very likely that a widely known ‘bot army of compromised “Internet of Things” devices was used to perpetrate a simplistic denial of service attack against Dyn DNS. Specifically their DNS infrastructure in the US which may or may not have been a specific Dyn DNS customer.

As a result, their DNS infrastructure was clobbered and because many sites chose a very short caching value, the names disappeared off the Internet.

This sort of attack could be mitigated in a number of ways (not all are realistic or possible) :-

  • Dyn DNS could increase their defences against denial of service attacks. Which I am sure they are doing – they already had defences, but not sufficient for this level of attack.
  • People who run DNS for their company should consider increasing the amount of time the names are cached for. If the Dyn DNS servers disappear off the Internet, it won’t be as noticeable if the values they would have returned are already cached elsewhere.
  • IoT manufacturers should pay far greater attention to the security of their devices. Most IoT customers are not likely to have sophisticated IT professionals available to deal with security updates.
  • ISPs should look at blocking traffic from infected machines to prevent denial of service attacks. There is always the argument that the average customer of an ISP isn’t sophisticated enough to know that his Internet connected curling-tongs are joining into a co-operative effort to blast a DNS server into rubble, but there does come a point where being nice to the naive needs to take second place to protecting the Internet as a whole.

To get a quick peek under the curtain of the problem, let’s take a look at the size of the problem we see here. For October so far, we have denied :-

mirai

Each of those bars represents a single day in October, and the height corresponds with the millions of connection attempts we have blocked. Individual infected devices (cameras or DVRs apparently) is making many connection attempts of course, the following shows the number of unique devices making telnet connections (don’t be confused by the scale – it’s hundreds of thousands so the peak is approximately 1 million) :-

mirai-ip

This is a big problem.

Posted in Active Attacks, Technical | Tagged , | Comments Off on Friday’s DDoS Attack And The Mirai IoT Worm

Free Converters May Come With Unwanted Gifts

I read this morning a post on another blog site about an experiment that someone tried. They converted a PDF file to a DOC file using five different free web-based converters and found that three of the results were malware-infected.

And previously we have had issues where people have downloaded free software by carelessly searching for it on the Internet, and found versions packed with malware.

The moral of the story? Be wary of searching for tools on the Internet; there are very many useful tools out there – indeed the Internet is constructed to a very major extent from free tools – but there are also many sources of malware.

Posted in General, Malware | Comments Off on Free Converters May Come With Unwanted Gifts

Do Not Attach Network Equipment to the UoP Network

It can be very tempting for a quick solution (especially for a temporary bodge) to attach network equipment up the University network. Don’t do it.

Please!

In the past it was unusual for network equipment to be so widely available, so this has not previous been a problem. However, with widespread home networks, it is becoming a problem. Naïvely attaching domestic (or enterprise) network equipment to a production network can have rather severe consequences.

On occasions entire building networks have been taken out of service due to this sort of issue.

Network switches, routers, and bridges can in some circumstances cause all sorts of disruption at a low level, which can be very hard to trace.

Any wireless equipment will cause a performance issue for anyone within the range of the transmitter.

Even ordinary computers can be configured in a way that will work perfectly fine in a domestic environment, but can cause disruption on an enterprise network.

Lastly it should be noted that attaching unauthorised equipment can (and has in some cases) resulted in your connection to the UoP network being withdrawn with no notice.

Posted in General | Comments Off on Do Not Attach Network Equipment to the UoP Network

Do You Know Email’s “BCC” Header?

There are a number of stories going around at the moment relating to unintentional release of email addresses in terms of allowing third parties access to the email addresses. This is almost always a mistake made by someone who used conventional email software (such as the standard Google Mail interface) without thinking carefully enough.

Now in most cases this does not matter too much … except possibly a brief moment of embarrassment. After all an email address is not that private, or is it?

There are two parts to why leaking email addresses even to a limited audience can be considered to be a bad thing :-

  1. People do sometimes want to keep their email address private; at the very least once an email address becomes public knowledge, spam starts arriving surprisingly quickly.
  2. Releasing an email address in association with some other piece of information can be surprisingly sensitive. If email being sent implies that the recipients are interested in HIV services, the recipients may be somewhat disconcerted to learn their membership is now effectively public.

And of course there is another reason why leaking email addresses can be a bad idea. News organisations can jump on the story as an easy way of populating their front page!

The golden rule here is if you are sending emails to more than five people who do not know each other, either use a specialised piece of software to send the emails, or use the “BCC” (Blind Carbon Copy) header.

To make things easier for people migrating from paper memos, the inventors of email used three common terms for listing addresses that email should be sent to – To (the public recipient), Carbon Copy (for public others who may be interested), and Blind Carbon Copy (for private copies). At least these terms were common in the days of formal paper memos!

The key field to remember for the purposes of this blog posting is “BCC”.

When you compose an email, you are normally given a list of fields to enter email addresses into :-

2016-07-26_1107

In this case (Gmail), click on the “Bcc” on the right-hand side of the “To” field and a new field will be shown :-

2016-07-26_1108

(The “Cc” field works in the same way)

The “Bcc” field can be filled with email addresses in the normal way, but the difference is that when someone receives the email they will not be able to see to whom it was sent.

You may think that this does not apply to you right now, but there is no harm in getting to know about “Bcc” and used to using it. It doesn’t cause any harm, and being familiar with it may save you from some embarrassment at some point in the future.

Posted in Email | Tagged , , | Comments Off on Do You Know Email’s “BCC” Header?

TeamViewer: People Being Hacked

There are many reports that those using the TeamViewer application are being subjected to hacks with their bank accounts being emptied and similar problems. The details of how the attackers are breaking in are not available, but it seems likely that it is the result of unfortunate configuration settings.

If you are using TeamViewer, you should consider one or more of the following :-

  1. Stop using TeamViewer. If you do not use it, you cannot be hacked. However it should be possible to use TeamViewer safely if you follow the instructions below.
  2. Download the latest version of TeamViewer. The latest version is less likely to be vulnerable to exploits than earlier versions, and the instructions below apply to version 11.
  3. Set up the configuration as guided below. The most likely way that the attackers can get in to your computer is through an insecure configuration.
  4. Only run TeamViewer when necessary.

Another possibility is to use Bomgar which is licensed for University use – speak to the IS Servicedesk to see if it is a possibility.

Configuring Strong Random Passwords

First start the TeamViewer application:

2016-06-03_0853

We need to change the security settings, so select “Options” from the “Extras” menu, and select “Security” on the tab down the left-hand side. For OSX, the menu options are slightly different – “TeamViewer”, and then “Preferences” and the appearance is different :-

2016-06-03_0949

First of all, do not configure a Personal password as a randomly generated password is better (although for unattended access a personal password is required, but in this case you should use a long (at least 12 characters) and strong password and pay careful attention to the other steps in this guide).

And do not configure “Grant easy access”.

The next thing is to change the password strength of the random password to “Very Secure” :-

2016-06-03_0952

Whilst “Very secure” might seem a little extreme, it is not so extreme whilst an active attack is ongoing – and I suspect weak random passwords are the way in for the attackers.

One further thing we need to do is to go to the “Advanced” tab and show the settings :-

2016-06-03_1034

In the “Advanced settings for connections to this computer” we want to change the “Random password after each session” to “Generate new” :-

2016-06-03_1037

This causes TeamViewer to change the random password after each session.

Configuring Rules for Connecting

If you use a TeamViewer account, there are a few other things we can set up. On the very same page of settings we have a set of rules we can configure to determine who can connect :-

2016-06-03_0955

The first option is specifying whether a TeamViewer client can use the logon screen; leaving it set to “Not allowed” is the most secure option here.

The next thing to do is to set up a whitelist; click on the “Configure” button next to the “Black and whitelist” :-

2016-06-03_1040

The “Allow access only for the following partners” needs to be selected – by default this works as a list of people who are not allowed to connect, and filling in that list could be quite tedious! By only allowing specified “partners” to connect we can limit this list to just your account.

Click on “Add” and select yourself. The whitelist will be updated to include your name :-

2016-06-03_1042

(Obviously the name you see will be different here)

Configuring Two-Factor Authentication

Lastly, it is very strongly recommended that you set up two-factor authentication on your TeamViewer account. To begin with you will need an authenticator app on your phone such as the Google Authenticator (the one I used).

Log in to the web page at https://login.teamviewer.com/ and you should get to the management console with a web page that has the following at the top left :-

2016-06-03_1056

At this point select your name at the right which should drop down a menu :-

2016-06-03_1058

Select the “Edit profile” option and you should see a “Profile settings” screen displayed which will include :-

2016-06-03_1059

Click on the “Activate” next to “Two factor authentication” to start the process; first a warning screen :-

2016-06-03_1100

The next screen shows a QR code to enable two-factor authentication in your phone’s app :-

2016-06-03_1102-obscrured

(I have obscured the QR code deliberately)

Scan this with your authenticator app, and it should be added to the list within your app, and it will generate a code to be used on the next screen :-

2016-06-03_1109

Once you activate this, you will be shown a further screen containing a special code to deactivate two-factor authentication. Record this safely – such as within your personal KeePass password store.

Once enabled, you will need to use the authenticator app to enter an additional time-based code every time you log in.

Further Information

The following links are to more information on the incidents :-

  1. http://www.tripwire.com/state-of-security/featured/teamviewer-hack-pc-hijack/
  2. http://www.theregister.co.uk/2016/06/01/teamviewer_mass_breach_report/
  3. https://www.reddit.com/r/teamviewer/comments/4ktys8/teamviewer_security_best_practices/
Posted in Active Attacks, Technical | Tagged | Comments Off on TeamViewer: People Being Hacked