Cyberweekly #84 - What would cyberwar look like?
Published on Saturday, January 11, 2020
Last week I deliberately avoided talking about the Iran/USA international issues because I felt like there was not enough real information and too much misinformation floating around and I didn't want to add to it. I meant to be explicit about it, and forgot while writing the introduction. I'm still going to avoid talking directly to the ongoing conflict. There are many better news sources on foreign affairs who are far more qualified than me to talk about that stuff.
I tend to avoid commenting on live issues at that level because international relations are far more complex than most people think. While we talk about nations like Iran and the US as if they are a single thing, in reality there are politically elected governments, the political bodies such as parliaments, congress etc, as well as government services such as departments for trade and state and foreign affairs. When we say "The US wants to do X", we are often shortcutting the context that matters to define who in the nation actually wants to do a thing.
Within nation state cyber affairs, this is true as well. It's easy to kind of think that a Nation's leader just kind of says "cyber-attack country X" and the nation somehow goes off and does it. In reality life is likely to be far more complicated.
Firstly, nations need to build up capability in these areas. They need to build or buy "weapons", or exploits. But unlike traditional militaries who can maintain some of their equipment for decades, exploits have a very short half life. Since the teams won't know when they need to use them, this means they need some way of rebuilding this stockpile constantly, and maintaining it. The nation needs to build capability not just at the pointy end, in exploits, but also in command and control infrastructure, supply chains, research and development and of course personnel with the skills to use the tools.
Then you need some form of reconnaissance and targeting process. Nations are bound by all kinds of military restrictions on what are valid targets during a military conflict. You aren't allowed to just randomly bomb companies or civilians. Because of the deniability of many cyber attacks, this process is far less regulated at the moment than it should be, but still, nations need to make priority decisions. Should they target military systems? Government systems? Critical national infrastructure? This targeting requires information on who those companies are, what sorts of computer systems they run and who works there.
The point of all of this is that actually building this capability and deciding to unleash it is a major effort on the part of a nation. Building these capabilities so they are ready to use has been a priority for many nations over the last decade, and the reason that we talk about the same countries all the time when we talk about nation state actors is because those are the most advanced nations in the world at the moment.
But critically, if there was a surge in attacks from Iran to US or UK based targets, then those targets had been painted months ago. You are really unlikely to be at any increased risk now than you were a few months ago. In all out cyberwar, we'll most likely see a set of surgical cyber strikes against existing military targets, disabling and confusing the military command and control structure and enabling traditional military capabilities to carry out their jobs with lowered resistance.
In reality, is this what cyberwar looks like? If it happens it will. But cyber offensive capabilities are far more commonly being used as a form of diplomatic soft power, the so called Grey Zone of "diplomatic space between peace and war".
This is the area where you want to conduct activities that send a strong message, but do not cause the breakout of war. These are the actions, such as diplomatic sanctions, snubbing of leaders, disputes over territory, economic influence, and spells of aggressive actions followed by a period of calm designed to prevent the breakout of all out hostilities. Cyber capabilities are a strong grey zone capability, and the sort of thing that we are far more likely to see in the cyber domain.
The thing with grey zone activities, is that because they take energy and effort, if outright conflict breaks out, the focus for a nation's command and control switches to the full on military capabilities and targets. Modern nations have a doctrine of hybrid warfare or fusion warfare, in which a nation can exert pressure through all of the controls, but the aims and targets of those capabilities get much more focused in that situation.
In essence, what I think I'm saying is that the breakout of hostilities internationally, is very unlikely to be accompanied by DDOS attacks and defacements on civil service websites and digital services, or ransomware breakouts on major international companies. All of the endless news reports about how many thousands of port scan attempts are happening from Iranian IP addresses are people over-reacting and misunderstanding what this stuff actually looks like. Instead we would see the nations cyber capabilities pointed very specifically at the targets as driven by the conflict.
In the meantime, two major VPN providers have significant CVE's out, and if you run either the Pulse Secure VPN or the Citrix VPN, you should patch, because those protections against amateurs running Kali will also protect you against many nation state attackers, as well as ransomware operators.
A crime has taken place and the detective needs your help. The detective gave you the crime scene report, but you somehow lost it. You vaguely remember that the crime was a murder that occurred sometime on Jan.15, 2018 and that it took place in SQL City. Start by retrieving the corresponding crime scene report from the police department’s database.
This is a lovely way of learning how to write SQL alongside a reference manual. What I like most is that the database is filled with thousands of false records, so it's not as simple as just exploring the raw data, you actually do have to filter and reduce the data to find the murderer.
Regardless of prevention measures taken, there is still some chance that an organization will experience a cyber event. Monitoring such residual cyber risk often falls to the chief information security officer (CISO). However, the actual ownership of cyber risk within an organization is generally unclear—even if the organization has a CISO or chief information officer (CIO) who is supposed to manage information security (14). Because cyber risk is a key part of an organization's overall business risk, all departments of an organization have a vested interest in how the organization manages residual cyber risk.
Researchers must devise a systematic approach for business units to increase their involvement in cyber decisions rather than these responsibilities being centralized only in the CISO or CIO role. Business unit operators need better incident response playbooks, including strategies for communicating with internal units, board members, shareholders, government officials, regulatory authorities, and the public (15).
This is an interesting read, if a little dense. But in essence they say that cyber risk being it's own little bubble, apart from traditional business risks, means that cyber risk professionals tend to only dabble in other fields such as mathematics, social sciences, management science, law and so forth. But this dabbling means that cyber risks tend to use the language and presentation of those fields, but without the underlying understanding that comes from actually studying in those fields.
They make a case that cyber risks should not be assessed and understood in isolation within a "security" team, but that as a field, it needs to be understood by multidisciplinary teams who have backgrounds in a variety of fields. My only real criticism here is that it's unclear whether they are talking about academic researchers and the field of academic research into cyber risk, or whether they are talking about companies and internal decisions about cyber risk. Either way, I agree that diversity of thought and transparency about how we estimate and understand risks is vital for building risk models that are actually useful.
We have computed the very first chosen-prefix collision for SHA-1. In a nutshell, this means a complete and practical break of the SHA-1 hash function, with dangerous practical implications if you are still using this hash function. To put it in another way: all attacks that are practical on MD5 are now also practical on SHA-1.
tl;dr; SHA-1 is broken if you are using it as a cryptographic signature. You should stop and move to something else. But it's not critically urgent, don't drop everything to fix it, just make upgrading higher priority on your todo list.
In reality, this is still a lot of money and effort to create a signed single file with a chosen prefix. To actually abuse this, you need to find a single place to add your signed file, where the addition of your file wont raise eyebrows. GPG's web of trust is a good example of somewhere where you could create a new identity, ask people to encrypt to it, and because you could fudge the signing process, people would think it was a new key, but the same identity.
But if you don't create new keys very often, or that's a manual process or easily visible process, the impact is lowered.
However, these attacks get a lot cheaper quite quickly. We might see this drop over the next few years to being doable with a home cracking rig for just thousands or hundreds of dollars. Additionally, the real worries are bigger more complex protocols that rely on SHA-1 underneath and have difficult upgrade mechanisms, as we've seen with issues in wireless protocols like WPA and WPA2, standards that require supporting what is now a broken signature can take a long time for fixes to actually be applied in real life.
[Unquotable because it's a PDF of a scanned document]
This sounds like it would be a boring document. But ICO decision notices and penalty notices are always quite interesting, especially for a firm of this size. If sentences like "malware installed on 5390 Point of Sale terminals", "attackers gained control of multiple domain administrator accounts", "significant SQL database reconnaissance and data theft", "POS devices not segregated from the corporate network", "did not have an effective system of logging and monitoring", "the vulnerability remained exploitable for four years" and wonderfully "running versions of java many years out of date (eight years)" don't pique your fancy, let me give you an overview.
Dixons Store Groups runs Currys PCWorld as well as Dixons Travel. That's somewhere a little over 500 retail locations in the UK (around 500 for Currys PC World and about 15 for Dixons Travel). In May 2017, they had a penetration test that said that their systems were "susceptible to critical vulnerabilities". The pen test even raised that they thought that the point of sale terminals may not be compliant with PCI DSS which is quite alarming.
They suffered a breach sometime before the 24th July 2017. We don't actually know when the breach was, but it seems that on the 24th July, the attackers installed malware onto some 5,390 point of sale terminals, the cash registers. This malware was able to collect payment card details from the credit card scanners . They say that over 5.6m credit card payment cards were affected by the breach. Now because of the way chip and pin works, the attackers only really got the card number (the PAN) and the expiry date. However, they also had access to internal servers. There are no records that actually record what the attackers did, because there isn't sufficient logging, but DSG's worst case scenario is that they had access to the non financial information such as name, address, phone numbers, date of birth and failed credit checks. They later increased the number of affected systems to cover 14 million people's data.
There's load more details in here, the systems weren't patched and basic security controls weren't in place, primarily because DSG maintain, they had good external perimeter firewalls and therefore didn't need to turn on local firewalls on the devices. There's definitely a case that says that given the attackers had domain admin accounts, they could probably disable or get around any controls they needed to. But that's not the point. The point of defence in depth is that you make the attacker work hard for each thing they have to get.
If this had been a month later, this would have fallen under GDPR. The ICO gave DSG the highest fine they were legally allowed to give, and I suspect that under GDPR, they would have given them an even more significant fine. This is the second find for Dixon Store Groups, as they also own Carphone Warehouse which was fined £400,000 last year for a similar style technical breach.
One minor, interesting point. 5.6m credit cards sounds really quite low spread across 5000 terminals over a year. That is only around a thousand transactions per terminal, or around 4ish per day. It's easy to read this as the main till system for PC World, but if it is, either the attackers didn't take every transaction, or there's something up with the numbers somewhere.
Here is what the Bestpetting team did in the PetFinder contest:
They fraudulently obtained adoption speed answers for the private test data (possibly by scraping our website) These data and answers were then encoded, obfuscated and hashed into an ID field that was disguised as part of their external "cute-cats-and-dogs-from-pixabaycom" dataset When processing the data, these hashed IDs were decoded and answers were retrieved for the predictions Only some of the encoded answers were used, so as to keep their final score "realistic" These processing codes were meticulously hidden and obfuscated under many nested layers of functions and codes, intentionally designed to be highly unreadable and seemingly mundane
Kaggle is a data science toolkit, mostly hosted Jupyter notebooks, but backed with rentable GPU's and a set of libraries for doing machine learning. They also run competitions, where organisations can provide sample data sets, and then teams compete to build the best matching algorithms that can get a good score against the test dataset.
Winning lots of these competitions gives you both money from the organisation that posted the competition, but critically kudos in the community which leads to jobs, advancement and potentially lucrative contracts.
In this case, a Kaggle Grandmaster (someone who was winning lots of competitions) was found to have cheated in the competition, going and finding the actual results that would be used in the test dataset and encoding the results in their algorithm. They also went to the effort to disguise that behaviour.
This sort of behaviour is common in any system where money changes hands, but what I think is more relevant here is that being a Kaggle Grandmaster can get you very good positions as a data scientist or machine learning developer at any number of startups and companies around the world. This halo effect might be worth far more than the actual reward money from the competition.
Improved patch adoption (new): End user security doesn't improve when a bug is found, and it doesn't improve when a bug is fixed. It improves once the end user is aware of the bug and typically patches their device. To this end, improving timely patch adoption is important to ensure that users are actually acquiring the benefit from the bug being fixed.
Google's ProjectZero does a lot of good work, and I'm personally pro disclosure, as I think that more attackers are aware of the vulnerabiliites that defenders in many cases, and there are more gains from pushing disclosure than the few net-loss situation.
But this new policy is a really good move, if for no other reason that quoted here. Previous, the 90-day deadline was all about getting the patch released. But that creates a race between the vendor making the patch available and users actually applying the patch, versus the attackers weaponising the disclosure. Allowing longer, until the vendor is confident that users have applied the patch should be a good thing.
Of course, this makes it clearer (and ProjectZero doesn't call this out), that the 90 day window is used both for root cause analysis, patch development, testing and end user patching. The longer you take to develop and write your patch, the less time you are giving your customers
However, if the data is released, it will open up a whole new world of business problems for Travelex
The Sodinokibi actors are right, too. No matter what happens, Travelex will incur further damage; either through the payment of a ransom, the public release of their data, or by the data being sold to other threat actors.
If the data is released, the attack will need to be classified as a data breach, notifications and free monitoring services will need to be offered, GDPR fines would be likely as are the risks of class action lawsuits.
When an organization suffers a ransomware attack, they usually try to hide the attack or downplay its impact to prevent customer concerns, damage to brand image, and a plunging stock price.
This commonly, though, backfires as the severity of the attacks ultimately leak and make the company look worse than if they had been transparent about it in the first place.
Now that many ransomware attackers are claiming to steal data before encrypting devices, it is more important than ever to be transparent about these attacks as they could now be classified as data breaches.
By hiding this information, companies are more likely to be hit with government fines and lawsuits as customers' personal information is compromised.
Instead, companies should follow Norsk Hydro's lead and be fully transparent during a ransomware attack by providing timely updates, customer notifications, and public information.
The travelex saga continues.
The threat of Unknown releasing the data is a real threat, in terms of it's damaging to the victim, and while one might think that the data is valuable to the attacker, they have such a wide gamut of victims that scaring a few is probably worth it to pick up the gains in paid ransoms for the next few.
As the article goes on to say, it's much better for companies to be clearer up front that they are dealing with a Ransomware incident and try to be transparent about the problems. It really is better in the long run.
Plus, Iranian hackers were actively targeting that sector, according to various cybersecurity reports. In July 2017, FireEye competitor CrowdStrike detected a malicious spear-phishing email targeting an employee at an unidentified Middle East petrochemical company. CrowdStrike tracks APT34 as Helix Kitten, a nod to Persian cats.
But Iranian hackers don't have an extensive track record of breaching complicated industrial control networks.
Early findings from the FireEye investigation into Triton complicated the Iranian narrative. The hackers had let slip a few clues that pointed toward Moscow, not Tehran.
This is a great writeup of one of the biggest "cyberwar" stories of the last few years. The Triton malware attack on the Petro Rabigh oil refinary in Saudi Arabia was in the same vein of attacks as StuxNet, NotPetya and WannaCry. But because it affected an oil refinery, it seems less well known.
More timely is the reminder that at this level, it was pretty clear that this was a nation state level attack, but yet attribution is still incredibly hard. There were signs that pointed to Iran, and signs that pointed to Russia. But even those signs could be wrong or deliberately planted. Nobody is willing to give absolutely certainty about which nation was behind the attack.
But while the brief military conflict has settled into an impasse, there’s a smaller skirmish that hasn’t stopped. While leaders weigh their options, pro-Iranian wannabe hackers who claim no government affiliation can deface unpatched websites run by individual Americans and small businesses but little else. It’s a tactic of online posturing and inflated threats — one at home in a conflict where tweets and perceived insults have often dictated the course of events.
The hacker who defaced Openshaw’s site goes by “Mr Behzad” and claims to be a 19-year-old operating out of a sense of patriotism. (It’s impossible to verify his identity with complete certainty, but he left his Telegram handle on the sites he defaced.)
“I do not work for the government. I work for my home country of Iran,” he told The Verge, adding a heart emoji after his country’s name. He said he learned how to deface sites through work programming and coding. “We want to know that if they harm our people or our country, we will not fail.”
The whole "Cyberwar" thing is going to drive me mad. This is report shows you some of the people that are the cause of those headlines.
While we know that real nation state sponsored cyber attacks do happen, the national state control apparatus is in place to give specific targets, to determine what is a valid target, and to make decisions about when it would cause diplomatic issues and when it's time to go.
Independent, civic minded hackers are not the same thing, and don't let the websites and vendors who want to sell you cyberwar tell you any different
Digital workspace and enterprise networks vendor Citrix has announced a critical vulnerability in the Citrix Application Delivery Controller (ADC) and Citrix Gateway. If exploited, it could allow unauthenticated attackers to gain remote access to a company’s local network and carry out arbitrary code execution.
The Citrix products (formerly the NetScaler ADC and Gateway) are used for application-aware traffic management and secure remote access, respectively, and are installed in at least 80,000 companies in 158 countries, according to Mikhail Klyuchnikov, a researcher at Positive Technologies. The U.S accounts for about 38 percent of vulnerable organizations.
Given the issues with patching the Pulse Secure VPN exploit, it's interesting to know that Citrix VPN's have a similarly bad exploit. This one is trivially easy to exploit and since VPN's are by design, at the hard edge of your network and normally provide ingress around all of your corporate network hardening, this is one to patch straight away.
If you want to test against your installation, or the installation provided by your managed service provider, you can use some example exploit code from TrustedSec.
This one is bad, and you should patch CVE-2019-19781 ASAP.