Imaging PCs for Offline Analysis

This is going to be a technical post with requirements for access rights that most people do not have, so it can be ignored. The intention is to file this information in a place that can be widely seen for the benefit of others needing this information.

In some circumstances, it can be helpful to “clone” a hard disk to a file image that can be used independently of the machine itself. This list of actions indicates how it can be done in the UoP environment :-

  1. Make some firmware changes :-
    1. Turn off ‘Secure Boot’
    2. Enable ‘Network Booting’ (not sure why it’s ever disabled)
    3. Enable “Legacy booting” (as many ipxe recipes require it)
  2. Turn off BitLocker encryption (an encrypted blob is tricky to analyse) :-
    1. Start → Control Panel → System and Security → BitLocker Drive Encryption
    2. Select drive, and “Turn Off BitLocker” (presumably needs admin)
    3. One turned off, the laptop becomes toxic and must remain on site in a physically secure environment.
  3. Perform the imaging :-
    1. Boot off the network (PXE)
    2. Continue to the iPXE menu and (currently) the testing menu.
    3. Select “Ghost for Linux” (either 1 or 2)
    4. Go through the wordage and select backup to a local filesystem – turn
      off compression (the default of “lzo” is rather useless and the usual destination performs compression transparently).
    5. Start an sshfs (sshfs username@148.197.8.78:)
    6. Create an image name – YYYYMMDD-description.img
    7. Start the backup
    8. Restore firmware settings.
  4. Turn BitLocker encryption back on.

Posted in Technical | Tagged | Comments Off on Imaging PCs for Offline Analysis

Zoom Desktop Vulnerability for macOS

Update: Apple is now silently pushing out an update to remove the Zoom “hidden feature” so you will be please to know that the geeky removal is no longer necessary. Just make sure you have opted in to all recent updates from Apple, and let it “phone home” for malware updates.

Update 2: It turns out (not entirely unexpectedly) that the little web server that Zoom installs is not only a vulnerability in itself, but it is also vulnerable to exploitation allowing an attacker to do just about everything with your computer that you can.

Update 3: In addition to Zoom, it seems that Bluejeans and Ring Central for Meetings may be licensed copies of Zoom and also install a little “helper” web server. It should be assumed that they are similarly vulnerable.

According to the security researcher who found the vulnerability (warning it gets quite technical quite quickly), when you install Zoom – usually at the last minute before a conference call where it is suggested that you install Zoom to show presentation slides – you open yourself to a vulnerability that allows a rogue web site to open your webcam without notification.

Indeed the vulnerability is still present after the Zoom client is removed in the ordinary way. Zoom apparently in addition to the actual client software also installs a web server to make re-installing the client software easier. On the down side, a malicious web site can redirect requests via that web server.

Not good news!

The current Zoom response amounts to “make sure your web cam is turned off” when inside the Zoom client (‘go into the Zoom settings window and enable the “Turn off my video when joining a meeting” setting.’)

Which doesn’t seem quite adequate.

The currently known fix for removing that hidden web server is unfortunately limited to terminal commands :-

$ sudo lsof -i :19421
{Look for the "PID" of the process listed - which may be nothing}
$ sudo kill PID
{meaning enter the number you used previously}
$ rm -rf ~/.zoomus
{if you want to be ultra cautious you could rename it instead: mv ~/.zoomus ~/that-dodgy-zoom-thing}

In addition you will want to remove the Zoom desktop client in the normal way (drag from the Applications folder to the trash icon).

Whilst this is being actively exploited, the current damage seems to be limited to suddenly finding yourself attached to a conference call with a bunch of random strangers all looking rather startled. Whilst this might sound amusing, this is probably the least of what might result.

Posted in Active Attacks, Technical | Tagged | Comments Off on Zoom Desktop Vulnerability for macOS

DNS Firewalls: What They Are, and What They’re Not

This posting is really a description of so-called “DNS Firewalls” intended for those who have to deal with security vendors regularly. Having said that, there are DNS firewalls for home users (I cannot make any specific recommendations), so it may be of wider interest.

Calling them “DNS Firewalls” is a bit deceptive (and it is even possible to persuade a security vendor’s salesperson to admit that it’s a bad name for them). Firewalls control network traffic whereas “DNS firewalls” allow you to apply a policy to DNS lookups.

To be fair, the implementation for the most common DNS server is called “Response Policy Zones” (RPZ) which is a little bit on the geeky side. But to be summed up, it allows you to specify a policy when looking up names in the DNS.

What Does It Do?

When you look up names in the DNS – which happens in the background whenever you make a network connection – the DNS server performs that lookup on your behalf. If a “DNS Firewall” is turned on, it can do one of two things :-

  • Return a value indicating that the name doesn’t exist (a web browser will show an error page saying something similar to “foo.zonky.org’s server IP address could not be found.”)
  • Return an answer to a query that is not the correct answer. Or in other words lie. This can be used to provide an alternate service, or to present a web page explaining why the page is being blocked.

Of course high-end commercial “DNS firewalls” offer to do quite a bit more, but the chief cost is really the threat information feeds that gets turned into a policy. Catching phishing attacks automatically and rapidly.

Posted in Firewall, General | Tagged | Comments Off on DNS Firewalls: What They Are, and What They’re Not

The Future of Windows 7

As you may be aware, Microsoft have expectations that everyone running Windows 7 will upgrade to Windows 10 (and some refuseniks are so upset that they are ditching Windows for Linux!). As part of that, Microsoft will no longer be supporting Windows 7 from January 2020 which is approximately half a year away.

As such, there will be significant security issues with running a Windows 7 machine on any network (both wired and wireless).

University Build Machines

University build machines that login using Active Directory credentials (i.e. the standard network login username/password) will cease working from the 1st August 2019. There are currently warning banners appearing on logins.

Extensions to this deadline are being granted in exceptional circumstances where the justification is sufficient.

Non-standard Machines

Machines running Windows 7 that do not connect to Active Directory (or specifically pick up a group policy) will not be troubled by the 1st August deadline. However they are very much subject to the January 2020 deadline; after that date Windows 7 machines may very well be removed from the network simply for running Windows 7.

Those still running Windows 7 need to be aware of this, and start making plans for a migration. There are numerous possibilities that include (but are not necessarily limited to) :-

  1. Contacting the vendor of the machine querying about an upgrade path. Many specialised manufacturers will already have upgrade plans in place.
  2. Remove the machine from the network; if the network connection is merely required for convenience, it may be easiest to remove the network connection and rely on USB memory sticks.
  3. Migration to the “legacy” network with severe network restrictions in place; this is a separate network with only permitted traffic allowed through the firewall. Required network traffic will have to be requested, approved and allowed for any network connections to succeed.

Posted in Uncategorized | Comments Off on The Future of Windows 7

The Big RDP Vulnerability (CVE-2019-0708)

Microsoft have released a whole bunch of patches to fix security vulnerabilities this Tuesday (which is quite normal of course), but one unusual aspect was the release of a patch for older versions of Windows that do not normally get patches.

Which is a bit of an indication that this vulnerability has the potential of being a bit more serious than the usual – Microsoft does not release patches for mostly unsupported operating systems simply when that operating system is vulnerable, but when there is the potential for mass outbreaks potentially causing network-wide disruption.

On the other hand, when the more excitable members of the security community start jumping up and down shouting “It’s Armageddon”, we do have to take their assessment with a pinch of salt.

It is potentially very serious and worth prioritising mitigation measures, but there is no obvious indications that any active exploits are out there in the wild. As yet.

The Links

The Vulnerable Operating Systems

If you are running one of the following operating systems, you should not only install the patch but also make immediate plans to upgrade – nobody is issuing patches to protect you; patches are release to protect the Internet from you!

  1. Windows XP
  2. Windows Server 2003

(And yes, some people do still run such operating systems; in fact I do myself although they are on isolated networks for penetration testing purposes)

If you are running one of the following operating systems, you should install the patch and make plans to upgrade soon.

  1. Windows 7
  2. Windows Server 2008
  3. Windows Server 2008R2

What Is Vulnerable?

RDP (Remote Desktop Protocol). Which is a means of connecting to a Windows machine remotely – very frequently used for server management. Which you may very well think that it doesn’t effect Windows desktop installations, but it can be turned on (and sometimes is).

If it is vulnerable, an attacker can run their own code remotely as the user SYSTEM (which is even more privileged than the Administrator user). But more specifically :-

  • RDP without Network Level Authentication (which is not on by default): An attacker can run their code without credentials.
  • RDP with NLA: It has been reported that this is only vulnerable if the attacker has valid credentials. That does not mean it should not be fixed urgently however!
  • RDP gateway: Some organisations run a single exposed RDP gateway through which people can proxy RDP connections to machines on the inside. I’m not aware of any clear statements whether these are vulnerable or not.

Balancing the probability of exploits being attempted, the probability of the RDP gateway product being exploitable, the impact of a compromise, and the impact of withdrawing the service, IS has blocked access to our RDP gateway – it is only used by a handful of special case users and the VPN is a viable alternative.

Is It Being Exploited?

Probably not. At least not just yet.

The graph above (which came out a bit smaller than expected) is the number of RDP probes against my home network. The faint line is the count of probes; the darker line is a trend line (exponential moving average which might not be the right one to use as my statistical neurons are very rusty and make a horrible grinding sound when I crank them into life).

Although there is an increase over the last couple of days, it isn’t dramatic enough to indicate anything other than either random variability or an increase in scanning for open RDP ports by security researchers (whitehats, greyhats, and blackhats).

The analysis of the University firewall logs shows much the same kind of activity except for a particularly aggressive scan for about an hour (which itself isn’t indicative of an active attack). However the analysis wasn’t as pretty.

The absence of signs indicating some active attack may well lead some to believe this was a bit of a false alarm, but it is too soon to say that for sure. Example code to exploit the vulnerability is supposedly out there.

It is also worth pointing out that WannaCry (a huge ransomware attack in 2017) made use of a vulnerability that was released into the public domain months before the attack, and the vulnerability was patched by Microsoft a month before the attack. So attacks could come tonight, next week, or next month.

Posted in Active Attacks, Technical | Tagged , , , | Comments Off on The Big RDP Vulnerability (CVE-2019-0708)

University Passes Cybersecurity Re-assessment

After a great deal of work from a number of people, the University has successfully renewed our CyberEssentials Plus certification. This means :-

  • We are assured that we have met a level of IT security. Not that it means we can relax and not do more, but that we are headed in the right direction.
  • We can now compete for contracts that require CyberEssentials accreditation and stay in compliance with contracts that require CyberEssentials; a significant amount of money (at least £1 million) comes to the University every year due to such contracts.

The independent audits who assessed our compliance were somewhat more rigorous this year than last year; we can expect more rigour next year.

Posted in General, News | Tagged | Comments Off on University Passes Cybersecurity Re-assessment

Yes, We’re Now Encrypted

If you have been paying attention, you will have noticed that our “security blog” was up until now only available via plain text; we now have a TLS certificate so the traffic to this site is encrypted.

With the exception of the handful of people who log in, this will not make a great deal of difference – a read only web site isn’t much safer with encryption than it is without.

But it is a relatively easy thing to do and this is a security site, so it makes sense to do so.

In some cases, older articles with media links will have the “mixed content” security warning on. If this is a big enough problem, let me know and I’ll fix it (it requires re-editing every post where this alert occurs which is kind of tedious).

Posted in News | Tagged , | Comments Off on Yes, We’re Now Encrypted

Passwords: Long and Strong

Yes, this is another blog posting about password strength, which we do keep going on about. That is because :-

  1. The password audit still shows that people are not getting the message (although for active staff we’re doing a great deal better than we used to).
  2. We continue to get security incidents related to compromised account passwords although probably a majority of these incidents are probably relating to phishing attacks rather than simple password strength.

Passwords are tedious, but there is in practice very little choice other than to set long and strong passwords to protect yourself and the University. Those who have had compromised accounts can attest to the pain of having an inbox crammed with thousands of spam bounces … and that’s nothing compared to some of the hair raising stories I’m not free to talk about.

Length

Password length is the single biggest factor in determining password strength – short is weak, and long is strong. Mathematically the strength of a password can be calculated with a formula :-

(Strictly speaking that is the maximum possible information entropy given that each character is chosen perfectly randomly which would require passwords such as: wJv9eqmvGXrjUld7IKVLugAbCdpJ99KI4LDTEeJUD4c)

The most important part of that equation in terms of making a password more random (“stronger”) is the length.

This is why we are beginning to recommend a password length of 14 characters!

Passphrases

(the following is from Xkcd)

We recommend a method for generating passwords (or pass phrases) involving words :-

  1. Choose three to four random words. At least one of the words should be the kind of word not found in the vocabulary of the average Daily Fail reader. Such as pink, blank, whistle, prepositional.
  2. Capitalise at least one of the words at the end: pinK, blanK, whistlE, prepositionaL
  3. Pick one random symbol such as “/”, “<“, “#”, “@”, “=”, “;”, and insert in between the words: pinK/blanK/whistlE/prepositionaL

As an alternative you can use a rather useful password generator. It looks complicated, but once you load the “XKCD” preset, you are 9/10ths of the way.

Store the new password in a proper password manager (such as KeePass or KeePassXC), and then set your new password.

Safe Password Usage

  1. Do not tell someone what your password is. Especially your chosen password to your university account(s).
  2. Do not use the same password in multiple services – if one service gets compromised all your accounts with the same passwords become unsafe (or at risk).
  3. Where available, turn on multi-factor authentication (such as on your Google account). In the case of your university account it will not protect authentications that do not support multi-factor authentication but it will protect your university Google account. Even from phishing attacks!

“But They Aren’t Interested in Me”

Yes they are.

Attackers do want special accounts but they’re quite willing to work with ordinary accounts. We regularly see compromised accounts used by attackers to do things that are irrelevant to the account itself – specifically sending thousands of spam messages. Of course that is just what we can see!

Don’t underestimate the damage that can be caused by sending thousands of spam messages – not only do you get a very messy inbox to clean up, but your email address gets a permanent loss of credibility.

So yes you are a target, not because of who you are but of what you have (an account).

More on Multi-Factor Authentication

Multi-factor authentication (sometimes called “two step” although that makes me think of dancing which is scary enough to me never mind others) is a method by which a service (in particular anything provided by Google) can ask “can you confirm that it’s really you”. It doesn’t routinely ask this question – on my work desktop workstation, I typically get asked less than once a month.

It asks when it doesn’t recognise the machine you are connecting from (or that confirmation happened too long ago).

So whilst it does get in the way occasionally, the reduction in risk makes it well worth the trade-off.

Posted in Passwords | Comments Off on Passwords: Long and Strong

Do You Like Justin Bieber?

On of the stories I was reading this morning mentioned that some of those with Nest security cameras have been subjected to hack attacks. One of the attacks they were subjected to were hackers asking Alexa to play Justin Bieber (as a bit of a nasty shock) on the assumption that someone with a Nest security camera may well also have an Amazon product with Alexa built-in.

Allegedly the method of compromise was simply to try known combinations of email address and password – given that there are many web site leaks that have been archived around the place, such data is easily available.

This is a reminder to :-

  • Use a password manager (such as KeePass, KeePassX, Lastpass, etc.) to assist remembering passwords.
  • Use different passwords on each site … or at least for the important sites.
  • Periodically check on Have I Been Pwned to see if any of the sites that you use has been compromised.
  • Use two-factor (or multi-factor) authentication where it is available; particularly for “sensitive” sites such as Dropbox, banks, etc.

The question is, how often does this sort of attack occur? And how often does it succeed?

In general I can’t answer that, but we do see a continuous stream of password “guessing” attacks where an attacker tries to use lists of known email addresses and passwords to get in to various services. And by “continuous stream” we’re talking about in the region of 100,000 probes a day across all services.

In terms of successful attacks, it is somewhat less than that but we do get a trickle of notifications of either account compromises or of account credential leaks. This “trickle” amounts to between 3 and 118 incidents a month (since 2015), and a mean of 28 per month (since January 2018).

Posted in Active Attacks, Passwords | Comments Off on Do You Like Justin Bieber?

There Is No Such Thing As A Secure Web Site

On the left-hand side of the location bar, your browser will show you something like :-

Which is entirely correct and incorrect at the same time.

To be precise, what that little label (and the alternative green one) means is that the network traffic is either plain text or encrypted (when you get the green one). In the former case, anyone who can intercept the traffic can see anything that you send to the web site.

So if you are communicating with a web site, and sending any private information you want to make sure you have a little green label.

But that is not the end of the story. Just because a web site has a little green label does not make it secure. Data in transit to and from the site is encrypted so cannot be intercepted, but data at rest on the server is no more safe than it is on a plain text server.

If the server is not maintained properly, it could be successfully attacked, exploited, and all the data leaked. That little label does not say anything about how secure the actual site is.

Posted in General | Tagged , | Comments Off on There Is No Such Thing As A Secure Web Site