Høyesterett tillater ransaking av Tidals USA-servere

[0laf]

Nei de sier ikke hvilken database som opprinnelig ble brukt, men de la dataene inn i en MySQL database for bearbeidelse av informasjonen de fikk fra csv filer.

 

Okey, jeg har kun skumlest rapporten, men jeg kan nesten garantere at Tidal ikke har benyttet CSV filer til logging av avspillinger, de har nok brukt en database hvor det er mulig å aggregere og kjøre oppslag på dataene i ettertid osv, CSV-dataene er nok bare en "utskrift" fra databasen til Tidal.

 

Tidal er anklaget for å manipulere antall avspillinger, de påståtte bevisene for slik manipulering ligger i disse datasettene, ikke fordi de ikke kan endres av Tidal, men nettopp fordi Tidal har endret dataene på en slik måte at det fremstår som om det er gjort med automatiserte scripts, ikke av faktiske brukere.

[Gjest Slettet-t8fn5F]

Okey, jeg har kun skumlest rapporten, men jeg kan nesten garantere at Tidal ikke har benyttet CSV filer til logging av avspillinger, de har nok brukt en database hvor det er mulig å aggregere og kjøre oppslag på dataene i ettertid osv, CSV-dataene er nok bare en "utskrift" fra databasen til Tidal.

 

Tidal er anklaget for å manipulere antall avspillinger, de påståtte bevisene for slik manipulering ligger i disse datasettene, ikke fordi de ikke kan endres av Tidal, men nettopp fordi Tidal har endret dataene på en slik måte at det fremstår som om det er gjort med automatiserte scripts, ikke av faktiske brukere.

Det er nok mer nærliggende å tro at de har brukt en high-availability clusters database i en eller annen form, men tanke på antall registreringer.

Bevisene for manipulering ligger i rapporten fra NTNU og den kom for snart et år siden.

[Spoki0]

Hvor har jeg benektet at logger ikke er filer?

 

Ikke vanskelig å se hvem som trenger kunnskap fra forumet her inne....

 

Sake til DN kan leses her.

https://www.dn.no/staticprojects/special/2018/05/09/0600/dokumentar/strommekuppet/?utm_source=front&utm_campaign=lsrjgr&fbclid=IwAR3m3BUcknr30aCFjakR0wdMW0P6Pin7B4fpSc7JjgYBrdioAcb4mSOqxmg

 

Og her er rapporten fra NTNU-Gjøvik

NTNU-rapport_til_publisering.pdf

Du nekter for at de er filer, fordi alle filer kan endres, slettes og manipuleres, uten at det blir skrevet til filen at de har blitt endret...

[Spoki0]

Og du tar bare mer og mer feil. Se her hva jeg har skrevet om logg-filer. Prøver litt større tesktstørrelse. Kanskje du da får det med deg.

 

Prøv i det minste å sammenligne det med en loggbok som man bare kan skrive til og sletter man noe, så står det tydelig at det er slettet, hvem som har gjort det og hvorfor de har gjort det.

Å skrive stort er bare sammenlignbart med å rope samme tullet om ighen, og tro at det gjør det til sannhet...

 

Ingen filer samsvarer med beskrivelsen av din magiske bok. Alle filer kan endres og slettes uten at det samtidig blir skrevet til filen hvem som har endret og slettet disse filene.

 

Det er faktisk dedikerte verktøy for å manipulere metadata om filen. Altså kan jeg forfalske hvem som endret filen sist, og når...

 

.

 

Alternativt har du satt en definisjon på loggfiler som ikke samsvarer med virkeligheten. Altså at det ikke finnes noe systemer i verden med logger per din definisjon. Forsøk gjerne å komme med eksempel på en logg du mener ikke kan manipuleres uten at det står skrevet i loggen...

[Gjest Slettet-t8fn5F]

Du nekter for at de er filer, fordi alle filer kan endres, slettes og manipuleres, uten at det blir skrevet til filen at de har blitt endret...

Hvor har jeg nektet for at de er filer?

Det jeg har sagt er at det er søtt de tror loggfiler er som en vanlig tekst fil. JFC!

 

Begynn med å lese denne. Kanskje får du noe inni skallen din, men jeg tviler.

https://en.wikipedia.org/wiki/Log_file

 

Så kan du lese denne.

https://en.wikipedia.org/wiki/Audit_trail

Endret 2. april 2019 av Slettet-t8fn5F

[Spoki0]

Hvor har jeg nektet for at de er filer?

Det jeg har sagt er at det er søtt de tror loggfiler er som en vanlig tekst fil. JFC!

Alle filer kan endres og manipuleres vilkårlig, uten at det logges noe sted. Siden du tror loggfiler ikke kan endres og manipuleres vilkårlig uten at det logges, så er det en logisk feilslutning a kalle dem filer. De oppfyller nemlig ikke kriteriene for å være filer, siden alle filer kan endres og manipuleres vilkårlig...

Du har kansje ikke oppdaget dette selv...?

 

Igjen, prøv å kom med ett eksempel på en loggfil som ikke kan manipuleres uten at det står skrevet i loggfilen at den er manipulert...

[Spoki0]

Begynn med å lese denne. Kanskje får du noe inni skallen din, men jeg tviler.

https://en.wikipedia.org/wiki/Log_file

 

Så kan du lese denne.

https://en.wikipedia.org/wiki/Audit_trail

Bra, du oppgir en link til hva en loggfil er. Usikker på om du har lest den selv, for den motstrider på ingen måte det vi andre sier, at de er filer som kan manipuleres...

 

Etterpå lister du opp audit trail, og tror dette bekrefter at det ikke kan manipuleres. Tvert om står det presisert at vanlige brukere ikke bør få tilgang til prosessene som opprettholder dette, implisitt nettop for å forhindre at de manipulerer loggene. Linken påstår på ingen måte at det er umulig å forfalske...

[Gjest Slettet-t8fn5F]

Bra, du oppgir en link til hva en loggfil er. Usikker på om du har lest den selv, for den motstrider på ingen måte det vi andre sier, at de er filer som kan manipuleres...

 

Etterpå lister du opp audit trail, og tror dette bekrefter at det ikke kan manipuleres. Tvert om står det presisert at vanlige brukere ikke bør få tilgang til prosessene som opprettholder dette, implisitt nettop for å forhindre at de manipulerer loggene. Linken påstår på ingen måte at det er umulig å forfalske...

Og igjen ilegger du meg påstander jeg ikke har kommet med. Vennligst les hele setningene jeg skriver og ikke stopp, når du kommer til et punkt i setningen som passer deg.

 

Du kan jo begynne med å fortelle hvor man skal manipulere logger i et HA-Cluster database kjørende i skyen, noe som er mest sannsynlig Tidal har benyttet. La oss begynne med et enkelt antall som 1000 noder fordelt over flere kontinenter.

[seventhwave]

Og igjen ilegger du meg påstander jeg ikke har kommet med. Vennligst les hele setningene jeg skriver og ikke stopp, når du kommer til et punkt i setningen som passer deg.

 

Du kan jo begynne med å fortelle hvor man skal manipulere logger i et HA-Cluster database kjørende i skyen, noe som er mest sannsynlig Tidal har benyttet. La oss begynne med et enkelt antall som 1000 noder fordelt over flere kontinenter.

Hvor i all verden er du på vei nå?

 

Jeg trodde vi alle nå var enige om at logger uansett er snakk om filer.

Om det skrives til en tekstfil (slik f.eks. Zimbra gjør), CSV-filer, MS SQL, MySQL, IBM DB2), så består alle av én eller flere filer.

Det er det som er byggestenen for alt.

Og alle filer kan enkelt manipuleres, det er det vel nå også felles forståelse for?

 

Men så kommer du opp med noe som er fullstendig uforståelig for meg.

 

Du begynner å blande inn clustering/high availability, og at det har noe med loggfiler å gjøre !?

Du må da være kjent med hva som er formålet med HA?

Enhver endring du gjør på én node, replikeres automatisk over til alle de andre.

 

Det innebærer også at f.eks. endring av en fil på en node, også blir endret på de andre.

 

Hadde du i stedet snakket om backup, og at man kunne samstille backuper langt tilbake i tid, for å oppdage unaturlig endringer i loggfilene (i dette tilfellet antall ganger en låt har blitt avspilt, kanskje ved å manipulere databasen tilbake i tid), hadde jeg kunnet følge deg.

 

Men slik du uttrykker deg nå, føler jeg at du har sporet helt av.

Endret 2. april 2019 av seventhwave

[Gjest Slettet-t8fn5F]

Hvor i all verden er du på vei nå?

 

Jeg trodde vi alle nå var enige om at logger uansett er snakk om filer.

Om det skrives til en tekstfil (slik f.eks. Zimbra gjør), CSV-filer, MS SQL, MySQL, IBM DB2), så består alle av én eller flere filer.

Det er det som er byggestenen for alt.

Og alle filer kan enkelt manipuleres, det er det vel nå også felles forståelse for?

 

Men så kommer du opp med noe som er fullstendig uforståelig for meg.

 

Du begynner å blande inn clustering/high availability, og at det har noe med loggfiler å gjøre !?

Du må da være kjent med hva som er formålet med HA?

Enhver endring du gjør på én node, replikeres automatisk over til alle de andre.

 

Det innebærer også at f.eks. endring av en fil på en node, også blir endret på de andre.

 

Hadde du i stedet snakket om backup, og at man kunne samstille backuper langt tilbake i tid, for å oppdage unaturlig endringer i loggfilene (i dette tilfellet antall ganger en låt har blitt avspilt, kanskje ved å manipulere databasen tilbake i tid), hadde jeg kunnet følge deg.

 

Men slik du uttrykker deg nå, føler jeg at du har sporet helt av.

Ja de kan manipuleres, men ikke uten at det registreres en plass. På en vanlig tekstfil kan man forandre innholdet uten noen form for sporbarhet, men det kan man ikke på loggfiler. 

Å redigere innholdet i en kryptert databasefil derimot, gjøres på en helt annen måte enn å åpne en tekstfil, men det er jo søtt at noen tror de kan gjøre det.

 

Nei. Man får ikke endre på noder, så fremst ikke det gjøres fra en manager (som også fungere som en node).

 

Nei ingen automatikk i det ved endring av en fil, men om du endrer innholdet i en database derimot, så replikeres innholdet etter fastsatte regler. Ikke tro at databaser lagres som ukrypterte filer, så enhver forandring av de filene vil gjøre innholdet uleselig for databasen.

[0laf]

Hvor i all verden er du på vei nå?

 

Jeg trodde vi alle nå var enige om at logger uansett er snakk om filer.

Om det skrives til en tekstfil (slik f.eks. Zimbra gjør), CSV-filer, MS SQL, MySQL, IBM DB2), så består alle av én eller flere filer.

Det er det som er byggestenen for alt.

 

 

Vel, det finnes ting som Redis, som lagrer alt i minnet, med mindre man spesifikt aktiverer persistent lagring osv. så alternativer finnes, selv om det sannsynligvis er lite relevant her?

 

Ja de kan manipuleres, men ikke uten at det registreres en plass. På en vanlig tekstfil kan man forandre innholdet uten noen form for sporbarhet, men det kan man ikke på loggfiler.

 

 

Igjen, "loggfiler" er ikke noe magisk i denne sammenhengen, det er sannsynligvis en helt vanlig tabell i en RDBMS som logger avspillinger som gjøres på klientsiden i Tidal sine apper osv.

 

Slike oppføringer kan enkelt endres uten at det registreres noe sted.

Dersom det skulle være noe system som sporer endringer gjort i databasen, så må det systemet være spesielt laget av Tidal, og jeg tviler på at de skulle ha behov for noe slikt?

 

Å redigere innholdet i en kryptert databasefil derimot, gjøres på en helt annen måte enn å åpne en tekstfil, men det er jo søtt at noen tror de kan gjøre det.

De fleste databaser har slike sikkerhetslag, hvor filene krypteres, men det er jo helt irrelevant ettersom TIdal har tilgang til sin egen database uansett, og disse filene ikke lagrer noe historikk over endringer som default, med mindre Tidal har laget et slikt system.

[seventhwave]

Ja de kan manipuleres, men ikke uten at det registreres en plass. På en vanlig tekstfil kan man forandre innholdet uten noen form for sporbarhet, men det kan man ikke på loggfiler. 

Å redigere innholdet i en kryptert databasefil derimot, gjøres på en helt annen måte enn å åpne en tekstfil, men det er jo søtt at noen tror de kan gjøre det.

 

Nei. Man får ikke endre på noder, så fremst ikke det gjøres fra en manager (som også fungere som en node).

 

Nei ingen automatikk i det ved endring av en fil, men om du endrer innholdet i en database derimot, så replikeres innholdet etter fastsatte regler. Ikke tro at databaser lagres som ukrypterte filer, så enhver forandring av de filene vil gjøre innholdet uleselig for databasen.

 

Jeg får runde av med denne kommentaren i denne tråden, for dette er nyttesløst.

 

Du du fremviser så åpenbare store hull i kunnskapen, at det blir det helt umulig å diskutere, og jeg har ikke noe nytte av det, når det gjelder å tilegne meg ny kunnskap.

 

> På en vanlig tekstfil kan man forandre innholdet uten noen form for sporbarhet, men det kan man ikke på loggfiler. 

 

Har du ennå ikke tatt det inn over deg, loggfiler er ofte tekstfiler?

Videre, om logger skrives til en database, f.eks MS SQL, er det helt trivielt å endre innholdet på SQL-serveren med SQL Server Management.

Har man satt opp et cluster, vil evt endringer du har gjort, bli spredt over alle nodene.

 

> en manager (som også fungere som en node).

 

Her rakner det fullstendig.

En manager er ikke en node, det er en brukertilgang !

Akkurat hvilken node du jobber mot, er helt irrelevant, det trenger du som manager ikke å forholde deg til.

Det man derimot vet, er at endringene man gjør, blir spredt over hele clusteret.

Alle som har manager-tilgang (evt administrator-tilgang) hos Tidal til log-databasen, kan manipulere denne helt fritt, uten å legge igjen direkte synlige spor.

Og nettopp dét, er det trolig ganske mange hos Tidal som har hatt.

 

> Ikke tro at databaser lagres som ukrypterte filer, så enhver forandring av de filene vil gjøre innholdet uleselig for databasen.

 

Igjen, dette har du åpenbart ingen kunnskap om.

 

SQL-databaser lagres da slett ikke kryptert, "by default"

Uansett, med Manger / Administrator-tilgang, omgås denne sikkerhetsmekanismen, 

Kryptering av en SQL-database, har som hovedformål å forhindre ekstern hacking fra å stjele verdifulle data, i fall de skulle få tak i SQL-filene (med understreking, dette er også fil(er) !)

 

 

Til slutt, jeg observerer at du velger å ikke gi svar på spørsmålene mine tidligere i denne tråden, når det gjelder manipulering av Windows Event-log / RDC etc.

Årsaken til det synes ganske åpenbar...

[seventhwave]

 

 

Vel, det finnes ting som Redis, som lagrer alt i minnet, med mindre man spesifikt aktiverer persistent lagring osv. så alternativer finnes, selv om det sannsynligvis er lite relevant her?

 

 

 

Igjen, "loggfiler" er ikke noe magisk i denne sammenhengen, det er sannsynligvis en helt vanlig tabell i en RDBMS som logger avspillinger som gjøres på klientsiden i Tidal sine apper osv.

 

Slike oppføringer kan enkelt endres uten at det registreres noe sted.

Dersom det skulle være noe system som sporer endringer gjort i databasen, så må det systemet være spesielt laget av Tidal, og jeg tviler på at de skulle ha behov for noe slikt?

 

 

De fleste databaser har slike sikkerhetslag, hvor filene krypteres, men det er jo helt irrelevant ettersom TIdal har tilgang til sin egen database uansett, og disse filene ikke lagrer noe historikk over endringer som default, med mindre Tidal har laget et slikt system.

 

> Vel, det finnes ting som Redis, som lagrer alt i minnet, med mindre man spesifikt aktiverer persistent lagring osv. så alternativer finnes, selv om det sannsynligvis er lite relevant her?

Helt enig med deg, non-persistent databaseservere lagrer ikke ned på disk.

Da mister man også alle dataene ved omstart av databaseserveren (med mindre du ikke gjør dataene persistent, ved å skrive dataene ned på disk), og der tenker vi likt, ville vært lite egnet for Tidal sitt bruksområde.

 

Ellers følger jeg din tanke tidligere i tråden, de benytter trolig en av de mer vanlige SQL-platformene (eks MySQL, Oracle eller MS SQL, antageligvis) til å lagre loggene for avspillinger.

 

 

>Dersom det skulle være noe system som sporer endringer gjort i databasen, så må det systemet være spesielt laget av Tidal, og jeg tviler på at de skulle ha behov for noe slikt?

Ja, tvert i mot, det eksisterer åpenbart mange gode grunner til at Tidal nettopp ikke ville ønske å implementere slik sporing.

Endret 2. april 2019 av seventhwave

[Spoki0]

Og igjen ilegger du meg påstander jeg ikke har kommet med. Vennligst les hele setningene jeg skriver og ikke stopp, når du kommer til et punkt i setningen som passer deg.

 

Du kan jo begynne med å fortelle hvor man skal manipulere logger i et HA-Cluster database kjørende i skyen, noe som er mest sannsynlig Tidal har benyttet. La oss begynne med et enkelt antall som 1000 noder fordelt over flere kontinenter.

Hva med å lese egne linker istedenfor bare å lese tittelen? Det er ingenting i dine egne kilder som støtter opp om dine påstander.

 

Jeg stopper hele sulamitten, endrer de sentrale loggfilene akkuratt som en vanlig tekstfil, og så starter jeg det igjen. Rimelig enkelt altså...

[Gjest Slettet-t8fn5F]

Jeg får runde av med denne kommentaren i denne tråden, for dette er nyttesløst.

 

Du du fremviser så åpenbare store hull i kunnskapen, at det blir det helt umulig å diskutere, og jeg har ikke noe nytte av det, når det gjelder å tilegne meg ny kunnskap.

 

> På en vanlig tekstfil kan man forandre innholdet uten noen form for sporbarhet, men det kan man ikke på loggfiler. 

 

Har du ennå ikke tatt det inn over deg, loggfiler er ofte tekstfiler?

Videre, om logger skrives til en database, f.eks MS SQL, er det helt trivielt å endre innholdet på SQL-serveren med SQL Server Management.

Har man satt opp et cluster, vil evt endringer du har gjort, bli spredt over alle nodene.

 

> en manager (som også fungere som en node).

 

Her rakner det fullstendig.

En manager er ikke en node, det er en brukertilgang !

Akkurat hvilken node du jobber mot, er helt irrelevant, det trenger du som manager ikke å forholde deg til.

Det man derimot vet, er at endringene man gjør, blir spredt over hele clusteret.

Alle som har manager-tilgang (evt administrator-tilgang) hos Tidal til log-databasen, kan manipulere denne helt fritt, uten å legge igjen direkte synlige spor.

Og nettopp dét, er det trolig ganske mange hos Tidal som har hatt.

 

> Ikke tro at databaser lagres som ukrypterte filer, så enhver forandring av de filene vil gjøre innholdet uleselig for databasen.

 

Igjen, dette har du åpenbart ingen kunnskap om.

 

SQL-databaser lagres da slett ikke kryptert, "by default"

Uansett, med Manger / Administrator-tilgang, omgås denne sikkerhetsmekanismen, 

Kryptering av en SQL-database, har som hovedformål å forhindre ekstern hacking fra å stjele verdifulle data, i fall de skulle få tak i SQL-filene (med understreking, dette er også fil(er) !)

 

 

Til slutt, jeg observerer at du velger å ikke gi svar på spørsmålene mine tidligere i denne tråden, når det gjelder manipulering av Windows Event-log / RDC etc.

Årsaken til det synes ganske åpenbar...

Jøss skal si du brilljere med manglende kunnskap om databaser i skyen.

Les deg opp her og kom tilbake når DU! har fått kunnskapen på plass.

 

https://www.cockroachlabs.com/docs/stable/orchestrate-cockroachdb-with-docker-swarm.html

 

For øvrig kan du la være med å uttale deg om hva jeg kan. Også der feiler du.

 

Så kan du ta å åpne ‪C:\Windows\System32\winevt\Logs\System.evtx i noe annet enn eventviewer, og så kan du manipulere ivei, om du forstår hva som står der.

Endret 2. april 2019 av Slettet-t8fn5F

[nebrewfoz]

Dunning-Kruger?

[process]

Dnh

[seventhwave]

Jøss skal si du brilljere med manglende kunnskap om databaser i skyen.

Les deg opp her og kom tilbake når DU! har fått kunnskapen på plass.

 

https://www.cockroachlabs.com/docs/stable/orchestrate-cockroachdb-with-docker-swarm.html

 

For øvrig kan du la være med å uttale deg om hva jeg kan. Også der feiler du.

 

Så kan du ta å åpne ‪C:\Windows\System32\winevt\Logs\System.evtx i noe annet enn eventviewer, og så kan du manipulere ivei, om du forstår hva som står der.

 

Jeg hadde egentlig lagt denne tråden til side, men siden du så konkret svarte på spørsmålet mitt, er det ryddig å gi et tilsvar.

 

 

Logger (databaser)=Filer

Så, da har vi begge stadfestet at Windows Event Log består av filer.

 

 

Audit log

I motsetning til de fleste logger, inneholder denne sterke sikkerhetsmekanismer, for å oppdage tampering.

Det var nettopp derfor jeg tok opp denne med deg, siden du åpenbart sitter med den feilaktige forståelsen at alle logger er bygd opp slik.

 

Sletter man f.eks. noen records i én av (Windows) loggene, vil det automatisk bli ført opp en record i en av de andre loggene, som viser at en slik handling er utført.

 

Mao den innholder audit trails, som nevnt tidligere i denne tråden.

 

 

Tampering resistant

Så, da er den vel umulig å modifisere da, uten at det kommer til syne, tenker du?

Så lenge man bruker front-end verktøyene Microsoft har utviklet, er svaret ja.

Har man derimot tilgang fysisk tilgang til filene, slik en administrator gjerne har, er svaret et rungende nei.

 

Det finnes mange verktøy for å modifisere event loggen, uten å etterlate seg noen spor.

Vi bruker til og med noen av disse som eksempler på sertifiseringskurs.

Det finnes etterhvert mange slike verktøy, hvis du leter litt rundt.

 

Eks

https://github.com/3gstudent/Eventlogedit-evtx--Evolution

 

Vi har også andre verktøy for hånd, hvor vi kan kopiere ut aktuell  evtx-fil, helt trivielt modifisere den, og deretter legge den tilbake.

Alt dette kan gjøres mens Eventlog-servicen er avslått for hele clusteret, slik situasjonen kan være hvis man tar ned hele clustert for å gjøre en system-wide software update (slik f.eks. banker gjør)

 

Det er med andre ord slik flere har forsøkt å formidle til deg i denne tråden, at logger ikke er sikret mot tampering, så lenge man har adgang på filnivå.

Et cluster vil heller ikke forandre på det.

 

 

Forsøk på å forhindre slik "hacking"

En mulighet er å i tillegg logge endringer på filnivå (med hash) som pushes til en ekstern Syslog-server, som den aktuelle administratoren av clusteret, ikke har tilgang til.

Men da er vi over på en teoretisk øvelse, og med rimelig stor sikkerhet ikke slik det er implementert hos Tidal.

Hvorfor skulle de...?

 

Når slik modifikasjon til og med er mulig på et verktøy Microsoft har lagt ned enorme ressurser nettopp for å forhindre,

hva tror du situasjonen er hos f.eks. Tidal, som trolig bare benytter en eller annen SQL-database til å lagre loggene sine?

Endret 4. april 2019 av seventhwave

[Computron]

Det er fristende å si "ikke mat trollet" her. Men på den andre side er det jo moro å se han prøve å ro seg ut av dette samtidig som han fortsetter å utøve den evige "Internet tough guy" holdningen sin.

Endret 5. april 2019 av Computron