Lastpass Hack fra August eskalerer

Not literally on the night before Christmas, but perilously close to it, LastPass admitted that:

The threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service.

Loosely speaking, the crooks now know who you are, where you live, which computers on the internet are yours, and how to contact you electronically.

The admission continues:

The threat actor was also able to copy a backup of customer vault data.

So, the crooks did steal those password vaults after all.

As an example of what not to do, consider the recent LastPass announcement that its customers’ backed-up password vaults had been stolen, despite the company’s initial assumption that they hadn’t.

LastPass claims to use 100,100 iterations of the HMAC-SHA256 algorithm in its PBKDF2 password generation process (we currently recommend 200,000, and OWASP apparently recommends 310,000, but let’s accept “more than 100,000” as satisfactory, if not exemplary)…

…but that’s only for master passwords created since 2018.

It seems that the company never got round to advising users with master passwords created before then that theirs had been processed with just 5000 iterations, let alone requiring them to change their passwords and thereby to adopt the new iteration strength.

This leaves older passwords at much greater risk of exposure to attackers using contemporary cracking tools.

fastwrite_1 (5) skrev:

Hm, lader til at 1password kunne være et godt alternativ.

arne_v (3) skrev:

#1 og #2

Ja.

Rigtig fine citater

fastwrite_1 (4) skrev:

Har I et godt alternativ til LastPass?
Har brugt den i årevis..

arne_v (10) skrev:

#9

Keepass havde en lille CVE i foråret.

https://nvd.nist.gov/vuln/detail/CVE-2022-0725

https://github.com/ByteHackr/keepass_poc

A flaw was found in keepass. The vulnerability occurs due to logging the plain text passwords in system log and leads to an Information Exposure vulnerability. This flaw allows an attacker to interact and read sensitive passwords and logs.

NOTE: Vulnerability Only Present in KeePass. Not in KeePassXC and Other Packages

arne_v (10) skrev:

#9

Keepass havde en lille CVE i foråret.

https://nvd.nist.gov/vuln/detail/CVE-2022-0725

https://github.com/ByteHackr/keepass_poc

Thanks for all the provided information. If I am able to reproduce (currently I am not), then I will definititely create a patch to fix it and let you know here.

larsp (13) skrev:

Linux KeepassXC kopierer også password med clipboard og har ikke dette problem. Efter 10 sekunder bliver clipboarded clearet, så det er marginalt bedre end manual copy paste af et password. Men ja, hvis man har noget malware installeret der logger clipboard indhold er det ret skidt.

arne_v (15) skrev:

#11 #12 #13 #14

Standard KeePass understøtter officelt Linux - det er ikke en fork.

arne_v (15) skrev:

Jeg er sikker på at både log niveau og log destination kan konfigureres. Men sammenhængen mellem den konfiguration og hvorvidt ens password manager skriver ens password i klar tekst til system loggen er ikke åbenlys for alle brugere.

arne_v (15) skrev:

Hvad KeePass kunne gøre var at lade programmet i tilfælde af at der bruger Mono checke log niveau og log destination og give en besked til brugeren hvis det er for farligt at bruge programmet!

using System;
using System.Windows.Forms;

namespace E
{
public class Program
{
[STAThread]
public static void Main(string[] args)
{
Console.WriteLine("{0} ({1} bit)", Environment.Version, IntPtr.Size * 8);
Clipboard.SetData(DataFormats.Text, "Super hemmeligt password");
string txt = (string)Clipboard.GetData(DataFormats.Text);
Console.WriteLine(txt);
Clipboard.Clear();
bool clr = Clipboard.ContainsData(DataFormats.Text);
Console.WriteLine(clr);
}
}
}

DrHouseDK (19) skrev:

Jeg synes dog KeePass er for kluntet med opbevaring af fil. Det er i min optik sådan lidt nørdet "for at være nørdet". Jeg er bevidst om at en KeePass-bruger vil være uenig. ;P

arne_v (18) skrev:

Efter at have kigget lidt på den famøse log så tror jeg ikke at logningen sker i Mono men i Qt.

Stakken er:

application--Mono Win Forms--Qt--X11

KeePass v1: C++/Qt4
KeePass v2 (Windows):  C#/WinForms
KeePass v2 (Linux): C#/Mono WinForms/Qt/X11 (pust)
KeePassX (fork af KeePass v1, men projektet er temmelig dødt)
KeePassXC (fork af KeePassX): C++/Qt5

DrHouseDK (19) skrev:

Jeg synes dog KeePass er for kluntet med opbevaring af fil. Det er i min optik sådan lidt nørdet "for at være nørdet". Jeg er bevidst om at en KeePass-bruger vil være uenig. ;P

Q: Does KeePassXC support (KeePass2) plugins?
A: No, KeePassXC does not support plugins at the moment and probably never will. KeePassXC already provides many of the features that need third-party plugins in KeePass2 out of the box, so for most things you don't even need plugins, nor should you ever want them. Plugins are inherently dangerous. Many KeePass2 plugins are barely maintained (if at all), some have known vulnerabilities that have never been (and probably never will be) fixed, and none of them are as thoroughly tested and reviewed as we test and review code that goes into our main application. We find that encouraging users to install untested (and often quickly-abandoned) third-party plugins is inherently incompatible with the security demands of a password manager. If you really need external functionality not available in KeePassXC, you can look for "plugins" that use the KeePassXC-Browser API, which is a much more secure way of sharing passwords with third-party applications than loading those applications as plugins directly into KeePassXC.

larsp (23) skrev:

Så KeePass v2 har åbenbart et plugin system. Tsk tsk tsk. Det er jo creeping featuritis så det batter, og den slags hører bare ikke hjemme i en password manager.

Athinira (24) skrev:

Det kan altid diskuteres. Det er vel op til den individuelle bruger. Selvfølgelig er det ikke nødvendigvis en god ide at benytte plugins som aldrig opdateres, men i sidste ende er du jo nødt til at stole på folk der skriver din software, uanset om det er KeePass, KeePassXC eller/og pluginudviklere.

larsp (26) skrev:

Ja, den kode der kører i et password wallet program er noget man skal kunne stole på til højeste grad, og derfor er én udvikler med review og test procedurer bedre end dertil at have en bunke tilfældige pluginudviklere. Jeg håber (meget) at KeePass2's plugin system har noget sikker signering af pluginkode så malware ikke lige kan snige en plugin ind fra siden der stjæler hele pivtøjet.

sand (28) skrev:

Jeg bruger Bitwarden, som jeg skiftede til efter at have brugt Keypass et par år, men sync gennem Google Drive eller OneDrive eller min Synology Nas gik som regel galt før eller siden. Så jeg kiggede mig om efter et godt alternativ der IKKE hed LastPass...

Er godt tilfreds med Bitwarden og kan dele udvalgte data med ungerne og fruen.

Athinira (27) skrev:

Browsere er sgu også sikkerhedskritiske applikationer, da vi bruger dem til mange sikkerhedskritiske ting. Vi ordner vores Netbankforretninger i dem. Vi indtaster vores kreditkort i dem når vi shopper online. Vi indtaster vores adgangskoder i dem. Hvorfor er det ikke i orden at en password-manager bruger plugins, men browsere gør?

Min pointe er at det ikke er så stor en sikkerhedsrisiko som folk gør det til ift. mange andre ting.

larsp (31) skrev:

Ja, browsere er også sikkerhedskritiske applikationer, i højeste grad. Derfor har jeg flere browsere installeret, eg. Chromium, Firefox, Opera, og bruger dem til forskellige formål. Én browser er så clean som muligt og bliver brugt til web bank og lignende. Denne browser har ikke installeret plugins! En anden browser bruges til generel browsing, og en trejde får den hårdt bagfra med de ondeste session cookies fra eg. Facebook og Google. Men da jeg ikke bruger den trejde browser til generel browsing minimerer det hvad disse konglomerater kan tracke om mig. Det er småirriterende at holde styr på nogle gange, men sund fornuft IMO.

Mock (32) skrev:

Jeg har selv kigget på alternativer. og hvis det kommer til man bare som privatbruger søger alternativ så ville jeg nok rate dem i denne rækkefølge

1Password
Bitwarden
Dashlane
Google Chrome
Keepass

Selv kan jeg godt klare mig med chrome password manager, som ikke har det fedeste feature set. men klare opgaven til privat brug. til erhverv står den desværre stadig på lastpass da der er nogle enterprise features vi ikke finder i de andre produkter.

Athinira (34) skrev:

2) Det kører via. web, hvilket introducerer SSL/TLS som en risikofaktor
Aka. du skal stole fuldt på SSL/TLS-protokollen.

Der er vi et eller andet sted tilbage til diskussionen mellem Larsp og mig. Hvor han ikke stoler på plugins, så stoler jeg generelt ikke på at SSL og hele certifikat-systemet ikke kan undermineres. Det er blevet gjort mange gange.

arne_v (35) skrev:

Hvor stor en procentdel af de steder hvor du bruger et password hentet fra password manager bliver det sendt over SSL/TLS?

larsp (31) skrev:

Vi har alle udviklet vores egne principper og teknikker til at holde styr på ting som passwords, som matcher vores risikotolerance. Jeg siger ikke at plugins generelt er udelukket mht. password.

Athinira (33) skrev:

Dette er så din - ja undskyld udtrykket - sølvpapirstilgang til browsing.

Athinira (34) skrev:

Jeg benytter 2 forskellige databasefiler til KeePass, en til über-sikre passwords som jeg ikke altid har åben (tænk krypteringsnøgler mm.), og en til almindelige passwords.

larsp (37) skrev:

Hmm... Den ene keepass database er ikke sikker nok til visse hemmeligheder? Pudsigt ;) Når det kommer til stykket tænker vi nok ikke så forskelligt igen.

larsp (37) skrev:

Jeg har selv brændt fingrene på at lave et program pluginbaseret i min udviklerkarriere, og jeg har set så mange gange hvordan gode programmer bliver bøvlede og buggy efter det besluttes at næste version af programmet skal have 50% af funktionaliteten flyttet ud i plugins!

arne_v (40) skrev:

Jeg tror ikke at MS i bakspejlet er specielt glade for IE og ActiveX plugins. I Java verdenen har OSGI aldrig fået nogen stor success. I .NET verdenen har alle lykkeligt glemt alt om MAF.

arne_v (42) skrev:

Jeg vil kalde det et fejlagtigt koncept. Det er ikke smart at tillade web sider at loade ikke sandboxet native kode hvor det eneste man ved er at den udstiller nogle bestemte interfaces (IOleControl etc.).

ASLR og DEP løser ikke problemet. De er ikke relevante for de typiske custom ActiveX plugin. De er relvante for kode udførende sandbox plugins, men disse eksisterer (eksisterede) også til andre browsere med andre plugin teknologier (typisk via NPAPI) og er et selvstændigt problem. Og ActiveX modellen blev da også først lagt i graven længe efter at ASLR og DEP var introduceret.

Athinira (43) skrev:

arne_v (42) skrev:

Jeg vil kalde det et fejlagtigt koncept. Det er ikke smart at tillade web sider at loade ikke sandboxet native kode hvor det eneste man ved er at den udstiller nogle bestemte interfaces (IOleControl etc.).

ASLR og DEP løser ikke problemet. De er ikke relevante for de typiske custom ActiveX plugin. De er relvante for kode udførende sandbox plugins, men disse eksisterer (eksisterede) også til andre browsere med andre plugin teknologier (typisk via NPAPI) og er et selvstændigt problem. Og ActiveX modellen blev da også først lagt i graven længe efter at ASLR og DEP var introduceret.

Jeg sagde ikke de var årsagen. Jeg gav dem bare som eksempler på teknologier der ikke var opfundet da ActiveX blev til.

Athinira (43) skrev:

Om de er relevante for de typiske ActiveX-plugins er jo ikke specielt relevant, da vores bekymring her er malware. Malware er vel næppe heller ikke dit typiske AX-plugin.

Athinira (43) skrev:

Når det så er sagt, så er det som du nævner ekstremt kritisk at AX ikke blev kørt i en sandbox.

Athinira (43) skrev:

Omkring selve konceptet, så er det - ligesom mange andre pluginteknologier som kørte i browseren dengang, herunder Java og Flash - værd at huske på hvordan verden så ud dengang.

Athinira (43) skrev:

Java, AX og Flash blev jo opfundet for at opfylde et behov.

Athinira (43) skrev:

Det var før HTML5, og websider dengang havde ikke specielt meget funktionalitet der var spændende som var understøttet i browsere, og browser extensions eksisterede så vidt jeg husker fx kun i Forefox og ikke i Microsofts browser.

Athinira (43) skrev:

Vil du påstå at behovet for udvidet browserfunktionalitet ift. hvad HTML tillod dengang ikke eksisterede? :-)

sand (28) skrev:

Jeg bruger Bitwarden, som jeg skiftede til efter at have brugt Keypass et par år, men sync gennem Google Drive eller OneDrive eller min Synology Nas gik som regel galt før eller siden. Så jeg kiggede mig om efter et godt alternativ der IKKE hed LastPass...

Er godt tilfreds med Bitwarden og kan dele udvalgte data med ungerne og fruen.

Athinira (45) skrev:

og jeg elsker hurtig-oplåsningsfunktionaliteten med PIN-kode samt understøttelsen af biometri (sidstenævnte dog kun i det normale program, ikke i browserplugin).

arne_v (40) skrev:

#plugins

Det er meget banalt at sige at man bør bruge en plugin model når man har brug for det og ikke bruge en plugin model når man ikke har brug for det.

Men det er sandt.

Og hvis vi nu siger hvornår man har brug for den, så begynder det at have lidt substans:
- man har brug for en plugin mpdel hvis man ønsker at understøtte at andre (slutbrugere eller trediepart) kan lave udvidelser til ens program
- man har brug for en plugin model hvis man ønsker at slutbrugerne kan konfigurere hvilken funktionalitet de ønsker kørende i programmet

Hvis man skal have en plugin model er det så op til en at lave en god plugin model.

larsp (46) skrev:

PIN koder til at låse PC mm. op. :) Endnu en ting jeg aldrig rigtig har forstået.