Archives for June 2019

A Third Florida Town Succumbs to Ransomware

I’m betting that there will some openings for IT positions coming soon in various Florida municipalities. Ars Technica reported today that a third (that’s right – third) city in Florida fell victim to ransomware. According to Ars, Key Biscayne, FL was breached using the Ryuk strain of ransomware (the same as Lake City, FL on June 10th which cost that city just shy of half a million dollars in bitcoin, and possibly the same as Riviera Beach, FL which cost that city $600k).

Key Biscayne became infected with Ryuk through what is known as a triple-threat attack: Emotet, in this instance, was brought into the network as a result of a successful phishing email. Emotet was used as a dropper to bring in the Trickbot trojan, which allowed the attackers lateral movement throughout the city’s infrastructure. At this point, the attackers had enough control to be able to infect the city’s systems with Ryuk – and game over. The city held a meeting tonight in which, one would assume, they’d decide on whether or not they need to pay the ransom or not. That decision has not yet been made known.

Let’s think about the different ways that this attack should have been – but was not – stopped in its tracks before it had a chance to wreak this havoc:

  • Employee Security Awareness training. Training employees to avoid clicking on phishing links will help; although it is still subject to human error and ignorance. I recommend conducting phishing security tests and following up with necessary training – KnowBe4’s training platform is an awesome tool for this purpose.
  • Key Biscayne’s MX record points to, meaning that they’re using email services through Office 365’s Exchange Online platform but also likely that they’re relying solely on Microsoft’s spam filtering. Microsoft is not ineffective at preventing phishing emails, but plenty of phishing emails will inevitably get through. Microsoft provides some advanced phishing prevention when users are assigned Advanced Threat Protection (ATP) licenses – it’s unclear if the city had subscribed to this additional license.
  • Lateral movement was allowed from the infected user’s workstation to the back-end server infrastructure. Key Biscayne is a small city with a population of only around 3,000. What likely happened here is that the city did not invest enough in their IT infrastructure. Most network admins these days recognize the importance of minimizing the possibility for lateral movement, but in an organization this small I imagine that it was not recognized as an important security control.
  • Why aren’t we restoring from backups? I’m making the assumption that they can’t, and that they’ll eventually be paying the ransom. Will this lesson ever be learned by our IT organizations? Back up your data, air-gap it so that the backups can’t be compromised, and have a disaster recovery plan in place that details how you’ll restore systems in a worst-case scenario such as this.

More details are sure to emerge regarding Key Biscayne’s ransom payment decision over the next few days. If anyone from the city happens to read this, please let us know if we can be of assistance in the recovery of your systems.

Actually, I’d say that Teams is Killing Slack

A recent article from Medium explained how Slack’s amazingly successful IPO prompted Microsoft to ban Slack internally in a seemingly jealous rampage. The article’s author, Michael Spencer, cited Friday’s report from GeekWire which revealed Microsoft’s internal Slack ban (at least bans on Slack versions other than Enterprise Grid) as well as the discouragement of other competing platforms such as Google Docs and AWS.

But I think the big picture is being missed here – I believe that Microsoft’s tactic was to help drive home the point that Teams is superior to Slack in terms of security. Security might be the single biggest advantage of Teams that Microsoft continues to dangle over Slack; and the internal ban is just another way to draw attention towards it. The timing was well-planned on Microsoft’s part; everyone is talking about the successful IPO, but Microsoft wants the conversation to swing back towards Slack’s deficiencies.

Further, the fact that they specifically call out Slack’s free/affordable versions (Free, Standard, Plus) while the expensive Enterprise Grid is exempt from the ban? That’s another good dig at Slack – Microsoft wants people to remember that affordable Slack = insecure Slack. Microsoft maintains the advantage of pricing, in many cases, due to the number of organizations that are already subscribed to Office 365’s plethora of other cloud services. Teams is a no-brainer for those organizations, who either gets Teams included completely included in their existing subscription or have it at least partially included. There’s also the free version which Microsoft introduced to compete directly with Slack’s free version.

So let’s not get too caught up with the idea that Microsoft is a jealous little kid throwing a temper tantrum in front of all of its employees. I think they’re better than that – and frankly, why would they be jealous when Teams seems to be product coming out on top anyway? Spiceworks conducted a study in December showing that more organizations reported using Teams than Slack. That same study showed that, while many companies are still using Skype for Business, many more will be switching to Teams very soon.

Google Docs and Amazon’s AWS are also discouraged from use according to Microsoft’s internal list. This is simply expected – why would Microsoft want to incur the costs of services that it already provides a competing solution for? What should be noted here is that their use is discouraged, not prohibited. Microsoft is allowing these competing services to be used when needed – perhaps for keeping up on their new features – but avoiding unnecessary costs of using them when Office or Azure will do the trick. But with Slack (and Grammarly, also) it is a complete ban on the lower versions and not just a discouragement. Sorry Slack, Microsoft says you’re not secure enough to play with the big boys.

Desjardins Group: Another Slap on the Wrist from Lawmakers

This is getting ridiculous: companies continue to lose peoples’ personal data and no one seems to care to do anything about it. Where’d it happen at this time? The Desjardins Group credit union co-op, a financial institution that you’d expect would have some of the tightest controls to prevent this kind of breach.

According to CBC/Radio-Canada, this breach was not caused by the nefarious hacks that seem to frequent today, but rather by an insider – an employee who accessed the data of 2.9 million Caisse Desjardins members and decided to share the information outside of the company. Details are sparse, but supposedly the compromised information included “names, addresses, birth dates, social insurance numbers, email addresses and information about transaction habits,” but not passwords, security questions, nor PINs. Well there’s some silver lining: they only stole your personal information, not the information that would let money be withdrawn out of the credit union’s coffers. Doesn’t that make you feel better?

Let’s think for a moment about how this type of data breach would have been possible: First, the malicious insider had a nefarious reason to do it. Maybe it’s being sold? We’re not yet told who this data was shared with (or sold to) but if I was one of these members I’d be very concerned about identity theft right now. From an information security perspective the insider would have needed access to the databases containing this data. Or maybe they improperly accessed a backup copy of the data, stored without proper security controls? Then, they would have been able to obtain the data as well as share it without too many red flags being thrown up. Details are sparse, but if it was shared externally over the network then it apparently was not caught by any Data Loss Prevention (DLP) systems. If it was carried out on media such as a flash drive then there doesn’t appear to be much control around that. Thinking this through, it raises so many questions that need to be asked:

  1. Was the employee’s role one that would have given them access to this data? Or did they find a way around access controls?
  2. How did the action of downloading the data of 2.9 million users not throw up more red flags than it did? How was it allowed in the first place? Database queries to do this should have been setting off all kinds of alarms in any decent SIEM or IDS.
  3. Why did DLP or physical media controls not prevent the exfiltration of the data?
  4. Why was the data stored in an unencrypted format? The fact that some data was lost while other data was not suggests that the Desjardins Group, apparently, cares more about passwords/security questions/PINS more than it cares about the personal information of its 2.9 million members.

Despite the severity of this breach (and the apparent lack of security controls at a financial institution!) and other breaches like it, doesn’t it seem like lawmakers are not doing enough about it? CBC/Radio-Canada’s article states that “Quebec’s regulator of financial institutions, the Autorités des marchés financiers (AMF), described the situation as ‘very serious’ but said it is ‘satisfied with the actions’ taken so far by Desjardins Group” (para. 9). Sounds like Desjardins Group will just be getting a slap on the wrist to me. Maybe a small fine? In my opinion, organizations that fail to adequately protect consumer data should be fined in a massive way – one that sets examples for other companies – and the affected consumers should also receive direct financial compensation, not just the B.S. publicity stunt of being given a year of free credit monitoring. Money is what these companies know, and that’s what will make them start caring.

Microsoft, sometimes you annoy me

Microsoft Teams celebrated its 2-year birthday in March of this year. I really like Teams overall, but Microsoft has seriously slacked in some of the areas where it continues to need support. Whether these problems should be blamed on Teams or blamed on other products, they’re all still Microsoft.

Connectors for Flow are still in Preview?

One of Teams’ big selling points is integration with other apps. Above all else, I’d expect Microsoft’s own internal integrations to be fantastic and work flawlessly. Sadly, Microsoft has let me down in this regard. 2 years after general availability, the 11 actions that Flow can support when connecting to Teams are still listed as being in ‘Preview.’ Further, the capabilities that they give us are half-baked. I can’t use Flow to @mention a user unless it comes from the Flow bot? What?!

Hidden Annoyances – They Don’t Piss You Off Until You Find Them

For example: Cards are a great concept in Office 365, but they’re a real PITA to get working correctly. If you’ve ever tried to send more than the most basic Card to Teams you probably know what I mean. For instance, sending a card to Teams via Flow requires us to send a generic HTTP POST (see previous section – don’t get me started on why there isn’t native integration for this). This works, however it only works if you have the exact right template to use anything else just fails. MessageCardPlayground helps but still leaves a lot of usefulness to be desired. I haven’t tried AMDesigner yet but maybe it will help fill some of those Card-shaped holes in my heart?

Still on the subject of Cards, don’t go quickly thinking that you can easy POST back from Teams into Flow! No, that’d be too easy. For some reason Microsoft, in its ultimate wisdom, decided that when you click an action button in Teams that sends a POST back it will include a JSON Web Token (JWT) that completely breaks Flow’s ability to receive the message (it sounds like what technically happens is that Flow sees the JWT and then completely disregards the additional bearer token which is what it actually needs). Stack Overflow has a thread about this where it sounds like Microsoft is aware of the issue but really has no sense of urgency to make their products work well with each other. I’ve been forced to come up with a intermediary – a proxy of sorts – that my Card buttons can target, be stripped of the JWT, and then be sent to Flow for it to actually work properly.

Lack of Administrative Capabilities

Teams does offer more administrative capability that Skype ever did – but it still isn’t enough. Where is our ability to restrict posting permissions to individual channels within Teams? Sure we can do that for the General channel, but that isn’t enough. Where is our ability to have new Teams members auto-follow (not just auto-favorite) certain channels? Microsoft needs to remember that Teams is being used for organizations where people are not always (actually, are seldom) technically inclined – they don’t care to spend their time going into each channel and clicking “Follow this channel” even if it is something that would help them. PS – anyone reading this who wants to help get this changed, get on UserVoice and help bump it up!

Experience: Duo Security Multifactor Authentication with Office 365

Duo Security is an industry leader in MultiFactor Authentication (MFA) and zero-trust security solutions. Many organizations choose to federate their on-premise identity – Active Directory – with Microsoft so that users have a Single Sign On (SSO) experience when accessing 365 – this is, in many cases, achieved using ADFS. Duo conveniently provides a plugin for ADFS so that MFA can be bolted on to the existing SSO solution.

In fact, I found it to be just about that easy. In my ADFS 4.0 environment Duo’s plugin installed seamlessly and was instantly available for MFA within ADFS. The great thing about this is that, when your users authenticate through a web browser (such as to OWA), if they’re not already enrolled they can be prompted to enroll at that time. This makes user onboarding simple and easy.

Duo’s combination of access policies can be combined with ADFS’ claim rules for a very customizable experience. In my case, I chose to simply require 2FA only for extranet connections:

ADFS access control rules

Just to be sure, I also whitelisted my public IP address within Duo’s application policy. The solution works beautifully – if we connect from outside of our network to OWA (via a web browser), the user will see Duo integrated with the ADFS login page as a next step after a successful login:

Duo's two-factor authentication (2FA) prompt in ADFS

The “Gotchas”

Now, let’s talk about the caveats of this solution. They are few, but they do need to be planned for

Modern Authentication

Non-browser connections (such as those from Outlook installed on user desktops) will now require Modern Authentication. This won’t be a big deal for most organizations, but it does restrict what Outlook clients can be used as well as what mobile mail clients can be used as well. Outlook 2013 or newer is required, though Outlook 2013 will require a registry change to be compatible. For mobile clients, check out Duo’s KB article for more detail.

Mail Relay

Microsoft’s documentation lists 3 options for how to relay mail through Exchange Online, the first of which is SMTP Client Submission – relaying through Exchange Online using an authenticated connection on port 587. This is commonly accomplished using the Windows built-in SMTP relay in IIS, and if this is how you’re relaying then this method will stop working. A good workaround is to add a connector for the IP address that your mail relay sends from, and then reconfiguring it to send to on port 25. For more information, see option #3 of the same Microsoft article.

Alternatively, if you have another domain setup in your 365 account that is not managed (configured for ADFS), you can use an account in this domain to continue to relay since the login for this account will not be subject to Duo’s MFA.

PowerApps / Flow / Other 365 services

Connectors setup in PowerApps and Flow will need to re-authenticate, with MFA, based on the policies setup within Duo. This will be a pain because it will require human interaction to do so. As mentioned in the previous paragraph, if you have a non-managed domain setup in your tenant then it may be easiest to create these connections with an account from one of these domains.

ASCO Industries Falls Victim to Ransomware

Help Net Security reported yesterday that ASCO Industries, an aerospace manufacturing company, was impacted by a ransomware infection severe enough for them to suspend their manufacturing operations around the globe.

It continues to amaze me how effective ransomware is at grinding a business operations to a halt. Ransomware isn’t new by any means; however, organizations don’t seem to be taking the threat seriously. Employees remain extremely vulnerable to phishing tactics that often let malware into the network, however IT departments should be more prepared for this sort of outbreak than they seem to be. Ransomware should be curable with a quick restore of infected systems, and then you’re back online. Users workstations? Re-image and call it a day.

The blame here does fall on the IT organization themselves for being ill-prepared. I don’t pretend to be knowledgeable about the ins-and-outs of ASCO Industries’ IT environment, but today’s hyper-connected world demands that IT professionals rise to the call of taking reasonable measures to protect their environment. We’re not talking about anything crazy, just common protective measures such as:

  • Backups of all servers to meet RTO/RPO as determined by business needs.
  • Endpoint protection – a reputable antivirus and intrusion prevention solution. It won’t catch everything but it is still an absolute necessity.
  • A segregated network. In this specific example it seems logical that the manufacturing network should be separate and more locked-down than other client networks – so why was the production line impacted?
  • An incident response plan: so a workstation does get infected, what do we do? This doesn’t have to be rocket science, it might be as simple as disconnect from the network until the station is re-imaged.
  • Security awareness training. This is no longer optional – staff need to be trained on threats such as phishing, social engineering, and basic information security concepts.

The biggest problem that I’ve seen is lack of urgency on the IT organization’s part to accomplish these bare minimums. It may also be influenced by insufficient understanding (and maybe lack of proper budget allocation) from the C-level executives in the organization. One thing I’m sure of is that the folks at ASCO Industries are re-evaluating those priorities right now.