Flere hackinggrupper udnytter sårbarhed i Microsoft Exchange: 100.000 organisationer påvirket globalt

arne_v (3) skrev:

#2

Formentligt mest det første.

Exchange og OWA er rigtigt mange linier kode. Statistisk set er det forventeligt at der er fejl i så stor en kode base. Når systemerne er tilgængeligt via internet (og det er OWA i sagens natur), så kan sikkerhedsfejl nemt udnyttes. Når systemerne indeholder værdifulde oplysninger så er der nogen som vil investere tid og penge i at finde sikkerhedshuller.

larsp (8) skrev:

#6, #7 derfor findes der automatisk stavekontrol ;)

Moderne programmeringssprog bør kunne forbedre situationen. Utallige svagheder skyldes simple fodfejl som buffer-overruns i C kode. Sprog som rust kan finde den slags compile time.

Det gælder dog ikke alle fejl. Nogle gange laver man bare en tanketorsk i API design der kan udnyttes. Skal ikke kunne sige om det er tilfældet her.

larsp (8) skrev:

#6, #7 derfor findes der automatisk stavekontrol ;)

larsp (8) skrev:

Moderne programmeringssprog bør kunne forbedre situationen. Utallige svagheder skyldes simple fodfejl som buffer-overruns i C kode. Sprog som rust kan finde den slags compile time.

CVE-2021-26855: CVSS 9.1: a Server Side Request Forgery (SSRF) vulnerability leading to crafted HTTP requests being sent by unauthenticated attackers. Servers need to be able to accept untrusted connections over port 443 for the bug to be triggered.
CVE-2021-26857: CVSS 7.8: an insecure deserialization vulnerability in the Exchange Unified Messaging Service, allowing arbitrary code deployment under SYSTEM. However, this vulnerability needs to be combined with another or stolen credentials must be used.
CVE-2021-26858: CVSS 7.8: a post-authentication arbitrary file write vulnerability to write to paths.
CVE-2021-27065: CVSS 7.8: a post-authentication arbitrary file write vulnerability to write to paths.

larsp (8) skrev:

Det gælder dog ikke alle fejl. Nogle gange laver man bare en tanketorsk i API design der kan udnyttes. Skal ikke kunne sige om det er tilfældet her.

using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;

namespace Read
{
public class Program
{
public static void Main(string[] args)
{
BinaryFormatter binser = new BinaryFormatter();
using(Stream f = new FileStream("o.bin", FileMode.Open, FileAccess.Read))
{
object o = binser.Deserialize(f);
}
}
}
}

using System;
using System.Runtime.Serialization;

namespace SomeLib
{
[Serializable]
public class SomeClass : IDeserializationCallback
{
public string S { get; set; }
static SomeClass()
{
Console.WriteLine("Maybe I should have deleted some files 1");
}
public SomeClass()
{
Console.WriteLine("Maybe I should have deleted some files 2");
}
void IDeserializationCallback.OnDeserialization(Object sender)
{
Console.WriteLine("Maybe I should have deleted some files 3");
}
}
}

Warning

The BinaryFormatter type is dangerous and is not recommended for data processing. Applications should stop using BinaryFormatter as soon as possible, even if they believe the data they're processing to be trustworthy. BinaryFormatter is insecure and can't be made secure.

...

Warning

The BinaryFormatter.Deserialize method is never safe when used with untrusted input. We strongly recommend that consumers instead consider using one of the alternatives outlined later in this article.

arne_v (12) skrev:

Jeg ved ikke om Exchange+OWA er 1 MLOC eller 10 MLOC, men den gamle tommelfinger regel om 1 fejl per 1000 linier kode vil betyde henholdsvis 1000 og 10000 fejl med de kode størrelser.