This post tries to keep the complexity manageable while making a point clear. We are not systems engineers/kernel developers, so feel free to point out any mistakes/misunderstandings. This post probably does not present anything new for people who are working in systems engineering and/or kernel development.
Why is that of any interest to an application developer?
Storage is getting faster and faster, while the performance of single CPU cores does not increase to the same degree. Blazingly fast NVMe Storage Devices have reached PCs, Smartphones, Gaming Consoles, and Server Systems in the Cloud. The importance of fast and low latency storage in the cloud can not be understated. AWS recently even went that far to develop and release their own SSDs (AWS Nitro SSD) based on the AWS Nitro System for specific EC2 instance types [1].
Many application developers are not particularly educated about storage hardware, kernels, and file system APIs. This post is basically what application programmers should know when programming with modern storage devices in mind.
ein Artikel von Nicolas Wyderka, Niklas Schildhauer, Lucas Crämer und Jannik Smidt
Projektbeschreibung
In diesem Blogeintrag wird die Entwicklung der Applikation- und Infrastruktur des Studienprojekts sharetopia beschrieben. Als Teil der Vorlesung System Engineering and Management wurde besonders darauf geachtet, die Anwendung nach heutigen Best Practices zu entwickeln und dabei kosteneffizient zu agieren
an article by Carina Szkudlarek, Niklas Schildhauer and Jannik Smidt
This post is going to review the zero day exploit of the Microsoft Exchange Servers starting in January 2021. It will look into the methods of SSRF and the exploitation of mistakes in the deserialization of input values to procure privileged code execution.
INTRODUCTION
In early 2021, several vulnerabilities were discovered in the Microsoft Exchange server software of the 2010, 2013, 2016 and 2019 releases that could be used by attackers to gain access to such an Exchange server.
With Exchange Server, Microsoft offers a service with which e-mail communication can be controlled in networks, but electronic communication can also be checked for harmful files such as viruses. All incoming and outgoing e-mails end up on the corresponding Exchange server. From there they are distributed to the recipients. Although there are alternatives, numerous state and private-sector institutions around the world rely on Microsoft Exchange servers.
On January 6, 2021 the security company Volexity observed several attacks via a previously unpublished Exchange vulnerability. In the course of the following weeks there were additional individual attacks on selected Exchange servers.
Microsoft instantly planned to release a security patch. However, the responsible attacker group Hafnium had already started a large amount of mass scans starting several months prior to january 6th when the attack was first exploited (see R[17]) . Exchange servers that were vulnerable were automatically infected with a webshell. Less than a week later, Microsoft published several security updates. However only a few hours after the publication of these unscheduled updates for the known vulnerabilities, the unprecedented infection of all unpatched Exchange servers accessible via the Internet began. As a result, administrators had little time and opportunity to react.
Generally, the exploit of overall four known vulnerabilities can be used as a gateway to penetrate deeper into the corporate network, as the Exchange servers are often publicly accessible. Yet it only affects on-premise Microsoft Exchange Server and not Exchange Online or Microsoft 365.
According to estimates, generally around 250,000 Exchange servers worldwide are open like a barn door to cyberattacks. 30,000 US customers have already been hacked, according to Heise [R1] tens of thousands of Exchange servers are affected in Germany alone, some of them in German federal authorities, according to the BSI [see: R2]
You must be logged in to post a comment.