For the rest of June, I'll be providing a selection of stories from the news without comment or analysis. I've tried to highlight the a quote to sum up the most interesting or relevant part of the story in each case.
Here's the weeks reading and interesting snippets I've run across this week.
February 2019 The Singapore police raid Wirecard’s offices. BaFin announces a two-month ban on short selling, citing Wirecard’s “importance for the economy” and the “serious threat to market confidence”, after the share price falls below €100.
Key read: Inside an accounting scandal
A preliminary report by a top law firm unveiled a pattern of suspected book-padding across the group’s Asian operations
March 2019 The FT reports that half of Wirecard’s business is actually outsourced, with the payments processing handled by partners who pay Wirecard a commission.
Attempting to visit some of these Wirecard partners in the Philippines, the FT instead discovers a retired seaman and his family, who are bemused to learn that their house is supposedly the site of an international payments business.
Public cloud providers pay a lot of attention to the nightmare scenario, since it would also be a catastrophe for them. It’s one of the unusual cases where commercial interests support computer security rather than being at odds with it.
Cloud providers often have early access to vulnerability information, so they can patch a vulnerability before it’s publicly announced. They publish the details of many of their security procedures to reassure their customers. It is worthwhile reading these if you have doubts.
You would need to match the security of a cloud provider merely to keep pace with the risk. Fail to do so, and you are more likely to suffer a catastrophe than the provider.
Initially, Microsoft stated this bug was due to a memory corruption vulnerability and could be exploited by a specially crafted email sent to a vulnerable Exchange server. They have since revised their write-up to (correctly) indicate that the vulnerability results from Exchange Server failing to properly create unique cryptographic keys at the time of installation.
Specifically, the bug is found in the Exchange Control Panel (ECP) component. The nature of the bug is quite simple. Instead of having randomly-generated keys on a per-installation basis, all installations of Microsoft Exchange Server have the same validationKey and decryptionKey values in web.config. These keys are used to provide security for ViewState. ViewState is server-side data that ASP.NET web applications store in serialized format on the client.
The Australian Government is currently aware of, and responding to, a sustained targeting of Australian governments and companies by a sophisticated state-based actor. The title ‘Copy-Paste Compromises’ is derived from the actor’s heavy use of proof of concept exploit code, web shells and other tools copied almost identically from open source. The actor has been identified leveraging a number of initial access vectors, with the most prevalent being the exploitation of public facing infrastructure — primarily through the use of remote code execution vulnerability in unpatched versions of Telerik UI. Other vulnerabilities in public facing infrastructure leveraged by the actor include exploitation of a deserialisation vulnerability in Microsoft Internet Information Services (IIS), a 2019 SharePoint vulnerability and the 2019 Citrix vulnerability. The actor has shown the capability to quickly leverage public exploit proof of concepts (POCs) to target networks of interest and regularly conducts reconnaissance of target networks looking for vulnerable services, potentially maintaining a list of public facing services to quickly target following future vulnerability releases. The actor has also shown an aptitude for identifying development, test and orphaned services that are not well known or maintained by victim organisations.
Another RDP brute force ransomware strikes again, this time, Snatch Team! Snatch Team was able to go from brute forcing a Domain Administrator (DA) account via RDP, to running a Meterpreter reverse shell and a RDP proxy via Tor on a Domain Controller (DC), to encrypting all Domain joined systems in under 5 hours.
Snatch is a widely known variant due to it causing systems to reboot into safe mode before encrypting the system. SophosLabs has an excellent write up on Snatch which was very similar to what we witnessed.
That’s true in targeted attacks when attackers are willing to invest enough to break MFA, and there’s no easier way.
Let’s not get crazy - Multi-factor Authentication (MFA) is the least you can do if you are at all serious about protecting your accounts. Use of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.
Compared to password attacks, attacks which target non-password authenticators are extremely rare. When we evaluate all the tokens issued with MFA claims, we see that less than 10% of users use MFA per month in our enterprise accounts (and that includes on premises and third party MFA). Until MFA is more broadly adopted, there is little reason for attackers to evolve.
In The State of Ransomware in the US: Report and Statistics 2019, we examined the number of ransomware attacks on the U.S. public sector and the cost of those attacks. In this report, we will examine the number of attacks on both the public and private sectors for a number of countries and estimate the cost, including the cost of downtime, of those attacks on a country-by-country basis as well as estimate the overall global costs.
The Tor guard node rarely changes, even if the rest of the circuit changes often. Moreover, the tor daemon will never make a circuit using two nodes that are part of the same known family. So if he sees that my route uses niftyspinymouse, then he can immediate determine that my guard node is not any of these 68 Tor nodes.
Remember: the guard rarely changes but the other two hops change often. If he can repeatedly map out my circuit's last node, then he can build a large exclusion list. If he can exclude everything else, then he can find my guard node. And if he can't exclude everything, then he can probably whittle it down to a handful of possible guard nodes.
Identifying the possible guard node does not tell him my server's real address. However, there's a known attack where an attacker DDoS's the guard node. This will disable the guard and temporarily knock my service offline -- until my service renegotiates with a new guard. But the guard still doesn't identify where my server is located.
However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.)