Clop-ransomwaregroep eist losgeld van minstens 66 bedrijven na Cleo-datalek

De ransomwaregroep Clop heeft gegevens van minstens 66 bedrijven te pakken gekregen na misbruik van kwetsbaarheden in Cleo-software. Deze organisaties hebben volgens de hackers nog niet gereageerd op hun eisen, wat wil zeggen dat er mogelijk meer getroffenen zijn.

Volgens een screenshot van een X-gebruiker hebben de cybercriminelen een lijst met tientallen deels geblurde namen gepubliceerd op hun leksite. Het gaat om bedrijven waarvan de gegevens zijn gestolen via het Cleo-lek, maar nog niet hebben gereageerd op de verzoeken van Clop. Organisaties die wel aan het onderhandelen zijn, zouden dus niet in deze lijst zijn opgenomen. De hackers dreigen ermee de volledige lijst openbaar te maken op maandag 30 december en bestanden online te zetten indien de getroffenen geen contact opnemen.

De ransomwarebende kon de data bemachtigen door een zeroday te misbruiken in Cleo-software, zoals LexiCom, VLTransfer en Harmony. De groepering heeft aan Bleeping Computer bevestigd dat het om de bugs CVE-2024-50623 en CVE-2024-55956 gaat, die in beide gevallen misbruikt kunnen worden om code van een afstand uit te voeren. Cleo heeft de kwetsbaarheden inmiddels verholpen.

Reacties (18)

[Karebare]

Noot: ik ben geen IT-er en dus geen ervaring op dit vlak.

Als ik dit lees dan denk ik: bedrijven komen in de problemen o.w.v. een bug in een programma van een externe partij. In welke mate kunnen kosten ten gevolge van die bug verhaald worden op die externe (IT) firma? In dit artikel heb je natuurlijk een eindeloze discussie over de waarde van die gegevens (en dus de schade) maar wat als er bv. rechtstreeks geld wordt buitgemaakt, waar de waarde dus makkelijker te bepalen is (XXX.XXX euro's gestolen = schade). Kan je de producent van de software, die ervoor zorgde dat digitale inbraak mogelijk werd, hiervoor aansprakelijk stellen? Kan je je daar ofwel als afnemer van de software ofwel als leverancier tegen verzekeren?

Mijn buikgevoel zegt me nl. dat ik dit meer en meer zie gebeuren en gelet op de soms verstrekkende gevolgen van dergelijke bugs zou ik hopen dat een software leverancier niet wegkomt met enkel een "oh, foutje, sorry". Of zie ik dat verkeerd?

[OruBLMsFrl]

Verzekeren tegen cybercriminaliteit kan. Zulke verzekeringen zullen wel eisen stellen aan je omgeving en de premies zijn ook echt wel bedragen. Verzekeren tegen software foutjes in het algemeen ofwel omzet derving wordt een algemene omzet verzekering volgens mij, dat is zo goed als onbetaalbaar voor zo een uitgebreide dekking.

Die leverancier is niet snel aansprakelijk, in algemene voorwaarden wordt zoiets haast altijd beperkt tot 'commerciële inspanningen tot herstel'. Ofwel moet redelijk en betaalbaar zijn voor de leverancier om jouw probleem te herstellen. Jij moet backups maken en kunnen herstellen en noodplannen hebben en oefenen, alle redelijkheid in commerciële inspanning van de klant kant ook.

[Reactie gewijzigd door OruBLMsFrl op 27 december 2024 14:37]

[kodak]

Die leverancier is niet snel aansprakelijk,

Dat gaat allang niet meer zomaar op. Veel software is geen klassieke levering meer van een product maar levering van diensten aan leveranciers, klanten en ander belanghebbenden van het bedrijf dat de dienst inkoopt. En hoewel het bedrijf dat die dienst inkoopt dan verantwoordelijkheid heeft kan een dienstverlener zich niet zomaar verschuilen voor het veroorzaken van onwettige gevolgen zoals een datalek. En tegenstrijdigheden als beweren een robuuste product of dienst te leveren, of zelfs dat een product of dienst voldoet aan wettelijke eisen zoals die voor verwerken van persoonlijke gegevens, zullen ook niet zomaar minder belangrijk zijn dan eenzijdige voorwaarden.

Daar komt nog bij dat bedrijven die naar anderen wettelijke verantwoordelijkheden hebben, zoals bij verlies van hun persoonlijke gegevens, niet zomaar die kosten voor lief nemen. Waarbij voorwaarden en beweringen alsof het vooral nog om commerciele inspanning gaat waarschijnlijk ook makkelijker betwist kunnen worden. Omdat een commerciële inspanning niet zomaar boven de wettelijke eisen staat.

[OruBLMsFrl]

Tegelijk kun je niet jouw eigen wettelijke verantwoordelijkheid afschuiven op een leverancier, juist onder de GDPR is dat niet meer mogelijk. Anders krijg je constructies dat beursgenoteerde international NV alle gevoelige zaken onderbrengst bij het lokale AllSafe in een land waar dat wel goed werkt dat afschuiven. Vervolgens gaat het onvermijdelijk een keer mis bij AllSafe en gaat beursgenoteerde international NV 'de volledige schade' verhalen. AllSafe meteen failliet, directeur daar door het stof.
En beursgenoteerde international NV kan natuurlijk niet zonder zitten, dus die komen meteen met een nieuwe gespecialiseerde partner op de proppen, noem ze DataSecure, die het vertrouwen moet herstellen en nooit de fouten van AllSafe BV meer mag maken. Voor een goede overdracht zal AllSafe nog zorgen door wat van de oude AllSafe mensen bij DataSecure in te laten werken. Een klein dingetje wel, nu is DataSecure van precies dezelfde mensen als AllSafe al was, en zijn die allemaal dikke vrienden met beursgenoteerde international NV. Dit was allemaal vooropgezet en al meermaals als cyclus herhaald, en de schade naar consumenten toe nooit verantwoord. want steeds gingen die risico BV's failliet...

Daarom dat de GDPR dit soort risico's expliciet verantwoordelijkheid maakt en niet overdraagbaar maakt van in dit voorbeeld de beursgenoteerde international NV. Nadeel daarvan is wel dat de leverancier dus ook wat meer uit de wind is, dus die zit vooral met risico reputatieschade als het een legitieme speler is op dat vlak. Je kunt het natuurlijk altijd vragen aan een leverancier welke voorwaarden zij kunnen aanbieden, en mocht je er een vinden die solvent genoeg is om een hele bedrijfsomzet te verzekeren voor een paar weken van al hun klanten bij een incident en dat toch wil aanbieden zeker doen. Ik ben ze nog niet tegengekomen. En als de EU dat ooit verplicht gaat het snel stoppen met zulke dienstverleners, gaan de laatste paar daarvan ook snel genoeg buiten de EU hun hoofdkantoor houden, want dat is domweg niet te doen, na elk groter incident zo een heel bedrijf failliet moeten verklaren omdat iedereen het kaalplukt, daar moet je een balans in vinden.

[Vaevictis_]

Las laatst een interessante statement vanuit cisa, die vinden security issues een software kwaliteitsgebrek waarvoor de leverancier altijd aansprakelijk is. Als ze dit nu eens juridisch gaan regelen.

[Polderviking]

Zo'n statement zomaar even is leuk maar wat houd dat in bij bijvoorbeeld open source software?
Ik moet gelijk denken aan bijvoorbeeld zo'n gevalletje Log4j wat overal en nergens in verwerkt zit.

[ChefA]

In de meeste open source licenties is aansprakelijkheid afgedekt. Je aanvaardt de software vaak "as is".

Om even twee voorbeelden aan te halen van veel toegepaste open source licenties, deze van toepassing zijnde paragrafen:

Apache 2.0:

8. Limitation of Liability.
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

GNU 3:

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Beide paragrafen bevatten een uitsluiting van aansprakelijkheid en stellen dat de auteurs, bijdragers of andere partijen die betrokken zijn bij de software niet verantwoordelijk zijn voor eventuele schade die voortvloeit uit het gebruik van de software. Dit omvat directe, indirecte, incidentele, bijzondere of gevolgschade. Zelfs als deze partijen op de hoogte zijn gesteld van de mogelijkheid van dergelijke schade, blijft hun aansprakelijkheid uitgesloten, tenzij dit wettelijk verplicht is of schriftelijk anders is overeengekomen.

[Polderviking]

Ja, bekend mee, maar als dat water houd nemen softwareleveranciers gewoon een soortgelijk artikel op in hun voorwaarden, en dan ben je weer terug bij af en heb je juridisch dus precies niks geregeld.

[Reactie gewijzigd door Polderviking op 30 december 2024 18:07]

[Mathijs Kok]

Ahhh, een wet die foutloze software eist, dat lijkt me een geweldig idee.

Windows 11 bevat op dit moment ongeveer 2900 geregistreerde bugs en een aantal daarvan is zeker potentieel een security gevaar. Ik vraag mijn geld maar vast terug.

[Reactie gewijzigd door Mathijs Kok op 27 december 2024 17:33]

[kroegtijger]

Dat is precies een van de discussies die nu heel veel gaande zijn en hangt onder meer af van waar de data weggeschreven wordt, hoe de SLA's in elkaar zitten en welke afspraken daarover gemaakt zijn. Helaas is de wereld in dit opzicht niet zo zwart/wit. De getroffene zal altijd proberen de schade te verhalen, terwijl de leverancier van het product en/of dienst altijd die verantwoordelijkheid juist weer af wil schuiven. Uiteindelijk zal er toch iemand voor het bonnetje moeten opdraaien en dus maken advocaten daar vaak overuren mee

[Red Boll]

Zal heel erg afhankelijk zijn van de situatie wat de (on)mogelijkheden zijn.

Heeft niet alleen toepassing op IT ook. Wat als je OV dienstverlener treinen of bussen krijgt met allerlei gebreken en je kunt daardoor niet meer aan je contractuele verplichtingen kunt voldoen aan je eigen klanten.

Ik denk dat je dat via civiel recht moet gaan aanvechten wanneer een mogelijke verzekering de schade niet dekt.

[dev-random]

De fabrikant in kwestie heeft mitigerende maatregelen aanbevolen waaronder een software update. Het lijkt me nog niet dat ze hier heel erg nalatig zijn geweest.

Ondersteund door generieke implementatie adviezen zoals tijdig updaten, het minimaliseren van het aanvalsoppervlak, etc. zal een leverancier snel de verantwoordelijkheid bij de klant leggen. Hoogstwaarschijnlijk aangevuld met een disclaimer als "wij zijn niet verantwoordelijk voor enige vorm van schade voortkomend uit het gebruik van product x of dienst y"

Ga je hier van te voren niet mee akkoord dan koop je het product maar niet, sterker nog, als leverancier verkoop ik het niet eens aan je! Soms komt er om dergelijke redenen nog een (lokale) leverancier tussen te zitten die op papier een stukje verantwoordelijkheid op zich neemt.

Ik ben géén jurist, maar voordat er juridische consequenties volgen als gevolg van een hack dankzij buggy software, lijkt het me dat een leverancier gatenkaas voorwaarden moet hanteren én zwaar nalatig moet zijn geweest. Of een rechter moet oordelen naar een utopie waarin perfect veilige software bestaat.

[martin_v_z]

Stel er wordt data gestolen bij een bedrijf uit product x. Maar ze zijn binnen gekomen via een bug in product y.

Wie zou jij dan verantwoordelijk zien? De makers van product y? Of de klant die de gegevens van product x niet op een afgeschermde omgeving heeft gezet?

Hetzelfde geldt voor ransomware waarbij gegevens op computers worden encrypt. Is de leverancier van het product waarbij ze zijn binnengekomen verantwoordelijk voor de schade of had de klant maar backups moeten hebben?

Dan kan het ook nog eens dat de hackers niet 1 bug hebben gebruikt maar bijvoorbeeld een fout in het OS in combinatie met een fout in een andere softwarepakket.

En dan hebben we nog de servicevoorwaarden waarbij vrijwel altijd gemeld staat dat dit soort schade voor eigen rekening zijn. Bij een rechter zal een bedrijf waarschijnlijk naast de schade moeten kunnen aantonen dat de leverancier nalatig heeft gehandeld.

[TheMak]

Volgens mij wordt in het algemeen vervolgschade niet vergoed. Dit omdat je anders voor verzekeringen gaat betalen ipv diensten. Het rechtsgevoel zegt mij dat de leverancier moet betalen, maar ik vertrouw op duizenden jaren rechtspraak en wijzere mensen dan ik dat het verstandiger is on de huidige situatie te handhaven.

[pringelen]

Belangrijk om te weten is in dit geval wanneer de bedrijven getroffen zijn door Clop.

Was de fix al beschikbaar en hebben deze bedrijven nagelaten om deze zsm door te voeren, of zijn ze getroffen voordat de fix beschikbaar is gesteld.

In het laatste geval vind ik het redelijk dat de bedrijven aanspraak kunnen maken op een schade vergoeding. De getroffen bedrijven moet dan wel duidelijk kunnen aantonen, dat dit komt door de bug.

[Willem_54]

Alle date via wetgeving verplicht versleutelen en de bevoegde personen uitsluitend via multi factor authenticatie/ autorisatie toegang verschaffen tot encryptie sleutels.
Dat is eenvoudig toe te passen en zeer effectief.

[Luno]

Als particulier heb je het makkelijker, dan is er veel meer een grijze lijst waaraan leveranciers moeten voldoen.

Persoonlijk ben ik van mening dat een SLA die alle gevolgschade uitsluit nietig moet zijn.

Elke SLA waarin staat dat bij een bepaalde storing een bedrag xxx verschuldigd is, terwijl die storing bedrag yyy jouw gaat kosten is het papier niet waard als yyy>xxx. Leverancier: Jammer dan oplossen kost ons meer dan xxx, dus dat betalen we, en zoek het verder maar uit.

Dit in m'n achterhoofd heb ik jarenlang uitstekende zaken gedaan met een firma waarbij we geen SLA hadden, maar projecten naar voldoening uitgevoerd werden. Dit itt een andere die zich verschool achter alle kleine uitzonderingen.
Idem ditto met een leverancier die ISO9000 goed op orde had. De bug die we melde was uitstekend in het systeem te volgen (werd alleen niet opgelost). Andere leverancier met soortgelijk pakket, zonder ISO9000 had vrijwel altijd een dag een een fix, of in elk geval een workaround.

De laatste 20 jaar ben ik allergisch geworden voor SLA's, ISO9000 en sollicitanten met massa's Microsoft certificaten..

[mjl]

ISO9xxx zij nou ook niet de standaarden waar je goede cyber security afspraken op baseert, die gaan met name over het hebben van kwaliteitsystemen, ISO2700x is een eerste stap in de goede richting, maar een SoC2 - type 2 assurance is al een stuk beter bijv. Er zijn meerdere maatstaven het NIST2 framework is een goede om te volgen bij het selecteren van een leverancier of dienst.

Je kunt de gok blijven nemen natuurlijk om de goede buur in te huren met alle goede bedoelingen van beide partijen, maar als puntje bij paaltje komt en het gaat goed mis, waar sta je dan met vage afspraken? Het blijft het afwegen van je bedrijfs risico, is de leverancier voor jou niet van levensbelang? Dan kan je lagere eisen stellen en zonder een SLA aan de slag, is de dienst wel belangrijk voor je? Dan maak je ook duidelijke afspraken daarover, ook met je goede buur.

En ja, je zult genoeg sollicitanten hebben die zwaaien met certificaten, leuk maar als ze bijv. de juiste houding en ervaring niet hebben dan heb je er nog niks aan. Ook bij personeels selectie moet je je goed ingelezen hebben in de materie en diep doorvragen om er achter te komen of de persoon in kwestie echt zoveel meebrengt als op het CV staat.