Säkerhetsslarv på Tietoevry: "Ofta var lösenordet admin"

Japp, samtidigt som komplexiteten ökar exponentiellt. "admin" kommer väl dom flesta ihåg. Ska man bara gå därifrån till att istället generera unika, komplexa lösenord, så har man gått från "nått alla kan minnas" till "en lösenordshanterare som måste vara gemensam för verksamheten där varje person bara ska ha access till det dom ska ha".

Lägg sedan till saker som integrationer/machine-to-machine-kommukikation så har det hela ballat ur delucks.

Jag skulle säga, iaf efter mina runt 20 år i IT-branschen, att hårdkodade/enkla lösenord i klartext i en konfig.cfg-fil är vanligare än <ett säkert system>.

Edit:
Kan ta som exempel, en setup jag jobbade i, som i min mening (och säkert många andras) var väldigt "bra" / "säker". Authen var certifikatsbaserad.
Problemet? Lösningen var så stor och komplex att det var -minst- en "driftstörning" i veckan som berodde på allt från att nått certifikat gått ut, till att det var problem i certkedjan, nån användare hade fel behörigheter för att accessa certet, nått cert hade inte fått korrekta rättigheter för att kunna göra det som det skulle kunna göra, you name it.

// This function generates a random password
function generatePassword($length = 16)
{
    // Define the characters that can be used in the random string
    $characters = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^*()_+{}|:?-=[]\;,./';
    $lowercase = 'abcdefghijklmnopqrstuvwxyz';
    $uppercase = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
    $special = '!@#$%^*()_+{}|:?-=[]\;,./';

    // Define the length of the characters
    $charactersLength = mb_strlen($characters);

    // Define the random string
    $randomString = '';

    // Loop through the length of the string
    for ($i = 0; $i < $length; $i++) {

        // Append a random character from the characters string to the random string
        // random_int is cryptographically secure!!
        $randomString .= $characters[random_int(0, $charactersLength - 1)];
    }

    // Now before we return the random string (password), we must check that it actually contains at least one number (0-9),
    // one uppercase letter (A-Z), one lowercase letter (a-z) and one special character (!@#$%^*()_+{}|:?-=[]\;,./)
    // otherwise just add one of each to the end of the string
    if (!preg_match('/[0-9]/', $randomString)) {
        $randomString .= random_int(0, 9);
    }
    if (!preg_match('/[A-Z]/', $randomString)) {
        $randomString .= $lowercase[random_int(0, mb_strlen($lowercase) - 1)];
    }
    if (!preg_match('/[a-z]/', $randomString)) {
        $randomString .= $uppercase[random_int(0, mb_strlen($uppercase) - 1)];
    }
    if (!preg_match('/[!@#\$%\^*()_+\{\}\|\:\?\-\=\[\]\\\\;\,\.\-\/]/', $randomString)) {
        $randomString .= $special[random_int(0, mb_strlen($special) - 1)];
    }

    // Now, return the random string
    return $randomString;
}

// Function that validates empty, min and max length of a string
// that is specifically of the type password using the reference to
// an error variable that will be set if the validation fails.
function validatePassword($input, &$errorReference, $minLength, $maxLength, $fieldName, &$allOK)
{
    // Check if the input is empty
    if (empty($input)) {
        $errorReference = "$fieldName is required!";
        $allOK = false;
    }  // Check if the input is too short
    else if (mb_strlen($input) < $minLength) {
        $errorReference = "$fieldName is too short! Must be at least $minLength characters!";
        $allOK = false;
    }  // Check if the input is too long
    else if (mb_strlen($input) > $maxLength) {
        $errorReference = "$fieldName is too long! Must be at most $maxLength characters!";
        $allOK = false;
    }  // Check if the input contains at least one uppercase letter
    else if (!preg_match("/[A-Z]/", $input)) {
        $errorReference = "$fieldName must contain at least one uppercase letter! (A-Z)";
        $allOK = false;
    }  // Check if the input contains at least one lowercase letter
    else if (!preg_match("/[a-z]/", $input)) {
        $errorReference = "$fieldName must contain at least one lowercase letter! (a-z)";
        $allOK = false;
    }  // Check if the input contains at least one number
    else if (!preg_match("/[0-9]/", $input)) {
        $errorReference = "$fieldName must contain at least one number! (0-9)";
        $allOK = false;
    } // Check if the input contains at least one special character
    else if (!preg_match("/[^a-zA-Z0-9]/", $input)) {
        $errorReference = "$fieldName must contain at least one special character! (!@#$%^*()_+{}|:?-=[]\;,./)";
        $allOK = false;
    }
}

Känns som att dessa "snillen" gjorde ett test där det kollades om dom har något innanför pannbenet. Och svaret blev: admin, lösenord, 123456 och dinmamma är lösenord med extremt hög säkerhet i deras ögon. Dagen efter deras anställning så får dom mail att deras avlägsna släkting från Afrika har dött och lämnar efter sig 10 miljoner Euro. Allt dom behöver göra är att ladda ner ett program och sedan skriv in deras personnummer och bankkonto and sedan godkänn med Bank-Id.

Vi ser bara "*******", men när du läser det visas det som "Sommar2024".

Precis som de sa fokus var på att hålla upp höga vinster. och ja bra säkerhet kostar pengar.

https://www.aftonbladet.se/nyheter/a/g7xme5/efter-sifferskand...

De är vana.

Ja dom är duktiga på att göra fel och skylla ifrån sig, det är nog något som aldrig kommer att gå ur dom.

Eaxkt, hur många kunder väljer TietoEvry idag och vad kostar inte ev. skadestånd?

En sak att 1177 ansluter "internetsladden" fel, men jag kan tycka att det är värre att ett företag som ska tala om för andra hur IT-fungerar använder standardlösenord.

Fast om man minns hur det hela började så var det ju en opatchad känd sårbarhet i en Cisco ASA och hade inte något öht med lösenord att göra så frågan blir ju om detta då är en helt orelaterad miss eller om det bara handlar om en missnöjd före detta anställd som sprider felaktig information som Tieto påstår.

Det används rätt frekvent i många bolag.

Problemet är användarna och deras oförmåga att skriva in komplexa lösenord. Samt företags illvilja att införa passwordless.

Jag jobbar på ett bolag där man inte har Hello för att en anställd anser att det är osäkert med biometrisk inloggning.

Det är vanligare att lösenord stjäls än att en användare blir bestulen på sin enhet OCH sin pinkod/lösenkod.

Istället så ser jag användare skriva ner sina 14 tecken långa komplexa lösenord på en Post-it och klistrar på skrivbordet....

Vilket å andra sidan är betydligt säkrare (om angriparen inte har fysisk tillgång till lokalerna) än att ha ett lösenord som finns med på top-100-listan i sin region. Även dåliga vanor kan vara bättre eller sämre. 🙃

Men med det sagt: det är inte jättesällan jag ser någon utvecklare eller tekniker dela skärm med en kollega, med sessionshemligheter fullt läsbara i ett textredigeringsprogram istället för att använda lösenordshanterare, dess API, eller miljövariabler. Otroligt många växer aldrig förbi hur de arbetade när de var 19 oavsett hur kvalificerade roller de lyckas få. Det handlar helt enkelt inte bara om att ge folk rätt verktyg och träning, utan det måste vara svårare att göra fel än att göra rätt, och det är ett riktigt tufft mål att försöka nå.

Ett annat problem som SvD-artikeln tar upp är det som kallas segmentering. Det gäller problemet att ett intrång kunde påverka så många olika kunder. Är det någon som känner till det?

I artikeln låter det som att man kom in på servrar som hanterar VMs och kunde därför orsaka större skada.

Jo, har ingen insyn i TietoEvry. Däremot har jag sett ÅrstidÅrtal samt FöretagsnamnÅrtal ett flertal gånger tidigare, så är inte direkt förvånad.

Sen gör blir det inte bättre av att företag skapar onödigt krångliga lösenordspolicys, vilket ofta slutar med att anställda överlistar systemet med lösenord som Kajsastina!1, Kajsastina!2 etc.

Tyvärr tror jag att de resonerar helt i kronor och ören.
De räknar helt enkelt med att han genom sitt agerande drog in mera pengar till "dem" än vad denna smäll nu kostar.
Det lär ju vara yttersta få kunder som har klansuler i avtal/upphandlingar som gör att de skulle vinna eller ens kunna bryta avtalet pga detta. Kör vi på spåret upphandling så spelar det ingen roll för upphandlaren måste (typ) alltid välja det billigaste budet som lever upp till kraven upphandlaren ställt. Så hur ator är skadan? Kan du tom vara så att det är mer lönsamt att helt enkelt skita i allt som kostar "extra" och hålla nere alla kostnader så man kan placera sig lägst och vinna alla upphandlingarna.

Ibland kan det vara upphandlarens "fel" då denna helt enkelt formulerat upphandlingen på ett sådant sätt företaget anser sig leva upp till dennes krav, fast de egentligen inte gör det. Eller så har upphandlaren helt enkelt inte angivit allt den bör ha angivit.

Sen kan det ibland vara så att det upphandlaren vill ha är svårt att uppnå alt att väldigt få, tom en ensam part, kan leverera det.

Sen har vi ju fall där företaget helt enkelt säger att vi kan leverera X och har rutiner för Y som är ren lögn.

Eller en blandning av allt ovan. Oavsett så är det ju dåligt skött av företaget i det här fallet. Men tyvärr kan det rent pengamässigt ha genererat mest vinst till ägarna.

Edit: Sen ska man skilja på lösenords komplexitet/autentiseringsmetod för Gittan som läser lite mail och skriver lite i word på sin maskin som sitter i ett segmenterat nät och servrarna som huserar alla de kritiska VMarna.

Det kostar ju inget extra att se över alla lösenorden och byta dem från default. Såklart lite tid, men den är försumbar om den görs vid initial installation. En lösenordshanterare som är centralt managerad kostar ju lite licenskostnad dock. Men har man inte råd med det så hade det ändå varit ett steg upp att lagra det i klartext.

Kan ju vara klumpiga misstag som att man kopplar ihop systemen med SSO via radius eller något, men glömmer bort default-admin kontot. Något som egentligen ska bytas och sparar på en säker plats som ett break glass-konto.

Om det nu var en sårbarhet i en brandvägg som gjorde att man kom in, så spelade inte de dåliga lösenorden någon roll. Däremot underlättade det ju stort att lösenorden internt var dåliga vid nästa steg. Då man snabbt kunde få kontroll över de interna systemen, innan man blev upptäckta.

Medans jag inte på något vis, tro mig, inte på något vis alls försvarar dessa snedsteg och brister så är jag inte helt säker på om Kimmo bör avgå för det som hänt.

Enligt deras annual report 2023 så arbetar de i 90+ länder och har 24159 heltidsanställda. Räknar man konsulter så blir det nog mycket mer. Rimligtvis så handlar det om ett flertal tusen olika kunder. Som VD har man ju såklart ansvar, men man kan inte heller förväntas ha personlig översyn och ansvar i något sådant enormt.

Nu är det inte så att jag känner Kimmo, men hur vet vi att det källan sagt stämmer?

Det jag hoppas på däremot är att de som fått jobben delegerade till sig att se till att ansvarskedjan hålls blir hängda.
Det är ganska oförsvarbart att fela när det kommer till säkerhet.

Det är nackdelen med den här typen av lösning. Som kund delar man på en serverpark med en massa andra kunder. Och för att kunna göra det så sköts allt via samma admin-konsol. Så utan att ge sig på någon av kunderna och istället ge sig på den gemensamma leverantören (tietoevry) påverka alla kunder. Såvida man nu inte tog sig in via en kund, för att sedan utnyttja en väg som i mina ögon inte ska finnas.

Fördelen med att dela servrar är ju att kostnaden blir lägre och tillförlitligheten högre i kombination.