Forumets säkerhet 2018-02-18

[Rickard95]

Hallå

Jag är intresserad av en genomgång av det som inträffade igår på forumet. Att jag och många fler varit inloggade i andras namn känns väl sådär. Känslig information eller av privat karaktär som kan finnas i våra pm, har den varit tillgänglig för andra?

Mvh Rickard

[sintra]

Vad hände igår, förutom att jag bara fick "404" då jag försökte komma in på forumet?

[MattsP]

Jag såg ut att vara inloggad som Arstuga ibland och nohab ibland, men det var fortfarande bara mina uppgifter och pm som visades. Vilket kändes lite betryggande.

/Matts

[kasoe]

Tror inte det var någon större säkerhetsmiss, det bara såg ut som man var någon annan. Så funkade det för mig, så fort jag klickade på något så "var jag mig själv" igen... Senare så hamnade man på inloggningssidan så fort man klickade på något, sen blev det 404...

Även om man blev uppfattad som någon annan så funkade inte forumet så jag är inte så oroad, men visst vore det intressant att veta vad som hänt. Hackat? Då upphör ovan att gälla...

Men oavsett ovan, kalasbara att forumet är igång igen!

Hälsar,
Anders Ö

[Administratör]

Hej!

Igår blev det något fel på sessionshanteringen på forumet. Det gjorde att man till synes kunde bli inloggad som någon annan. Vem du blev inloggad som var helt slumpmässigt, förutom att det alltid var någon som också var inloggad eller varit inloggad nyss. Om man klickade på foruminlägg, eller olika länkar, exempelvis "Visa inlägg sedan ditt senaste besök", "Visa alla olästa inlägg", etc så blev man plötsligt inloggad som ytterligare någon annan, eller som sig själv igen, eller så loggades man ut.

Det har rapporterats några fall där detta gjort att man kunnat läsa andras personliga meddelanden. På grund av detta valde vi att stänga ner forumet så fort vi blev medvetna om problemet.

Problemet måste ha legat hos vår webbleverantör. I morse gjorde vi forumet tillgängligt igen, och allt verkar nu fungera normalt. Trots att vi inte ändrat något i forumet. Vi hoppas att det ska fortsätta fungera felfritt framöver. Vi ska naturligtvis kolla med vår leverantör och se om de vet vad som orsakade problemet.

Mvh Admin

[cgn1954]

Vem är leverantör?

[jaxne]

Om det är bekräftat att det var sessionshanteringen kan det ju mycket väl vara så att det var servern som hade något fel i denna hantering och något som leverantören får se över.
Men om leverantören inte känner till något fel med detta så är det lämpligt att se över om den version av SMF som körs har några säkerhetsbrister som kunnat låta obehöriga komma in och ställa till det. Ser att det finns nyare versioner tillgängligt. Det är då också lämpligt att se över tidsstämplar på filer på servern och se ifall någon har ändrats vid en tidpunkt den inte borde blivit det.

[Rickard95]

Hallå

Det har rapporterats några fall där detta gjort att man kunnat läsa andras personliga meddelanden. På grund av detta valde vi att stänga ner forumet så fort vi blev medvetna om problemet.

Mvh Admin

Det var ju inte bra. Nu tror jag inte någon skada är skedd men det känns ändå otrevligt/olustigt att någon kan/har kunnat läsa det som skrivs i förtroende mellan olika parter. Jag fick dock höra av en person att detta problem uppstått tidigare. När, var och hur vet jag ej. Med facit i hand så känns det bäst att föra privata konversationer via mail i fortsättningen om de mot all förmodan är av känsligare art.
Tack för infon

Mvh Rickard

[BenWah46]

Jag anar att forumet ligger på one.com. Vad jag förstår är det möjligt att köra mediawiki därifrån. One.com är väl  inte sämre än de flesta vettiga serverhotellen och framför  allt verkar det inte ligga i fåran för någon snabb sammanslagning och uppköp. Det större fel jag kan erinra mig är när det var översvämmat i Köpenhamn för ett par år sedan. Då gick det inte att köra förrän vattnet sjunkit undan.

PM-funktionen bör väl inte vara en ersättare för egen e-post utan just för att föra vidare diskussioner som man kanske inte vill publicera direkt. OM den skulle ha högre säkerhet än så så kostar det bara pengar eller merarbete för administraören/-rna. Man måste ändå se forumet för vad det är: ett trevligt (för det mesta)utbyte av åsikter och erfarenheter inom MJ-hobbyn). Det är inte ett högsäkerhetssystem för kritiska affärsförbindelser. Skriver man något elakt om någon som på så sätt av misstag kommer i dagen får man väl stå sitt kast. Begränsningarna kanske man kan skriva en rad om någonstans i PM-funktionen så att ingen missförstår alltför lätt.

Däremot är det vanebildande med SvMJF och forumet jämte Wikin har samlat på sig en hel del information som inte släpas ihop på ett och samma ställe så lätt och ingen vill väl förlora tillgången till allt det som skrivits, visats och sagts under åren. Så ett bra backupsystem skadar ju inte, dvs ett som är fysiskt fristående och körs då och då så att det inte blir alltför stora hål om något skulle gå på tok. Men det räcker väl med ett bra USB-minne.

[Arstuga]

Nix, inte One, men jag har just nu lyckats glömma vilket annat webbhotell det är... Men det finns det ju dom som vet. Per Lind t.ex, som står för fiolerna.

Jag anar att forumet ligger på one.com. ...

[ulwen]

Det var Surftown som var översvämmat och det är där SvMJF är hostat.
One.com var aldrig drabbat då deras serverhallar ligger på helt andra ställen.

[PerH]

En IP-koll visar att vår leverantör är Surftown, ett Danskt företag med datacenter i Köpenhamn.
Kallar man sig för Surftown så är det ju inte konstigt att man fyller sitt datacenter med vatten?
Läs mer om Surftowns vatenskada

One.com som Bengt pratar om ligger dock inhyrda i Interxions datacenters i Stockholm.

Håller med föregående talare som rekommenderade att uppdatera forumet till nyaste versionen, det är inte omöjligt att just php-config filen haft ett säkerhetshål så sessionshanteringen kunnat modifierats.

När man ändå kikar på uppgradering så ta tag i wikin samtidigt, dumt om den försvinner. Fortfarande ganska gott om tid, men oftast blir det stressigt då man glömt det till det är kniven mot strupen.

[kasoe]

När man ändå kikar på uppgradering så ta tag i wikin samtidigt, dumt om den försvinner.

Där pågår arbete vet jag med bestämdhet...

Hälsar,
Anders Ö

[Boris]

Att skicka känslig info via e-post är inte så himla säkert det heller

[nohab]

Nej precis, okrypterad e-post är ungefär som vykort, alla som hanterar det på vägen kan läsa det...

[hakang]

Nej precis, okrypterad e-post är ungefär som vykort, alla som hanterar det på vägen kan läsa det...

Definitionen på 'adressat': Den sista personen som läser ett vykort...

[nohab]

[Per Lind]

19/10 gäller nuvarande betalning till så det är ingen överhängande brådska att byta webbhotell.
Lämpligt vore väl att få både Forumet som Wikin på samma kostnad?
-Per

[kasoe]

Lämpligt vore väl att få både Forumet som Wikin på samma kostnad?

För att inte starta fler spekulationer och initiativ kring Wikin...
Jag upprepar att jag med bestämdhet vet att arbete kring att "rädda" wikin pågår med bra fart och kraft.

När jag kikade in så upptäckte jag att jag själv ingick i admin-gruppen och det pågår idag kontakter mellan alla admin (en har ännu inte svarat...) och vi kikar på export/import av Wikin. Webhotell och annat finns på plats.

Kostnaden är också löst även om vi kanske kikar på att göra någon sorts "Donationsknapp" så de som vill kan slänga in en tia eller två till stöd för att den ska fortleva.

Så jag tror att jag talar för hela admin-gruppen när jag säger att:
Arbete pågår, Wikin kommer fortleva i stort sett i samma format men på annan plats!

Hälsar,
Anders Ö

[haba]

Eftersom sådan här forummjukvara ofta är skriven av folk som inte kan det där med säkerhet så där superbra, så finns det alltid zillioner med buggar  i det hörnet av Internetvärlden. Så den som står för forummjukvaran (om det nu tex är hostingprovidern) måste vara snabb på att uppgradera till senaste version annars så står man snart med byxorna nere. Som tur är MJ-fora inte särskild attraktiva att attackera eftersom det finns få "smaskiga" saker att ta reda på. Inte många blir upprörda på lokbilder i bara mässingen.

Harald.

[Spirit]

Inte många blir upprörda på lokbilder i bara mässingen.

Jodå!! Tänk om det sitter några nitar fel, då tar det hus i helsike! 

Skämt åsido, jag jobbar just nu med IT-säkerhet. Det är inget vidare att tänka i banan att det inte finns smaskiga saker att ta reda på, hackning sker ofta i andra syften än att få information.

Sen att forumutvecklare skulle vara värre än andra mjukvaruutvecklare stämmer inte. Men det är, precis som du säger, oerhört viktigt att den som står för mjukvaran är pigg med uppdateringar. Nya exploits dyker upp hela tiden.

[haba]

Skämt åsido, jag jobbar just nu med IT-säkerhet. Det är inget vidare att tänka i banan att det inte finns smaskiga saker att ta reda på, hackning sker ofta i andra syften än att få information.

Jo, men om man "endast" kan bli en annan identitet i ett forum så är det lite minde allvarligt än om man kan tex kamma hem alla personers lösenord.

Sen att forumutvecklare skulle vara värre än andra mjukvaruutvecklare stämmer inte.

Jag tycker inte PHP hjälper och mycket sånt är skrivet i PHP.

Men det är, precis som du säger, oerhört viktigt att den som står för mjukvaran är pigg med uppdateringar. Nya exploits dyker upp hela tiden.

;-)

Harald.

[jaxne]

Jo, men om man "endast" kan bli en annan identitet i ett forum så är det lite minde allvarligt än om man kan tex kamma hem alla personers lösenord.

Men ifall det var så att någon lyckades modifiera filer på servern så finns möjligheten att den som gjort det kunnat läsa ut data ur databasen. Förhoppningsvis sparas lösenord krypterat så att ifall de hamnar i orätta händer är det svårt att få ut något av det, men tyvärr finns det fortfarande många system som sparar lösenord i klartext.

Jag tycker inte PHP hjälper och mycket sånt är skrivet i PHP.

Vad hjälper inte PHP med? PHP är mig veterligen inte osäkrare än något annat alternativ. Allt handlar om att den som skriver koden ser till att förhindra alla kända och tänkbara sätt som obehöriga kan ta sig in. Sedan vad för applikation och vilket språk det är skrivet i spelar ingen roll så länge det inte finns brister i kärnan som sedan hanterar koden.

[haba]

Men ifall det var så att någon lyckades modifiera filer på servern..

Det har det väl inte varit frågan om enligt beskrivningen ovan.

Vad hjälper inte PHP med?

Att skriva sin kod strukturerad.

Kolllade lite snabbt lite commits. PHP inbjuder till sånt här:
 https://github.com/SimpleMachines/SMF2.1/commit/038abd54bf3e7dddd718d3886926382fb8ed71e6

Man måste hålla tungan extremt rätt i mun när $arr har ingen typ, till exempel skall det vara $key eller $key2 i innersta substr?

Man kan säkert skriva bra kod i PHP. Man kan även skriva kod utan pekarfel i C. Men språken hjälper ju inte precis till.

Sedan vad för applikation och vilket språk det är skrivet i spelar ingen roll så länge det inte finns brister i kärnan som sedan hanterar koden.

Fel tänkt. Här handlar det om fel inom applikationen. Kärnan håller ju inte isär olika användare på ett forum. Det är forumkoden. Kärnan har väldigt lite med säkerheten mellan användare i ett forum att göra eftersom alla dessa haneras av forumkoden i en databas och inte som olika datoranvändare (logins) på sjäva datorn.

Harald.

[jaxne]

Det har det väl inte varit frågan om enligt beskrivningen ovan.

Inget definitivt besked har lämnats. Det som sades var att det troligen var fel hos leverantören gällande sessionshantering. Men det finns fortfarande liten sannolikhet att obehöriga gjort åverkan. Sessionshanteringen hanteras ju främst av servern, men om obehörig vill få access i systemet kan ju sessionshanteringen ha satts ur spel i PHP-koden. Det som hände var ju att sessionsvariabler lokalt i datorn för besökare ej hade betydelse utan man kom in i en annan session än den förväntande. Tills dess att vi får information om att det faktiskt var fel på server hos leverantör kan man inte utesluta andra möjligheter även om sannolikheten kankse är låg.

Att skriva sin kod strukturerad.

Kolllade lite snabbt lite commits. PHP inbjuder till sånt här:
 https://github.com/SimpleMachines/SMF2.1/commit/038abd54bf3e7dddd718d3886926382fb8ed71e6

Man måste hålla tungan extremt rätt i mun när $arr har ingen typ, till exempel skall det vara $key eller $key2 i innersta substr?

Man kan säkert skriva bra kod i PHP. Man kan även skriva kod utan pekarfel i C. Men språken hjälper ju inte precis till.

Självklart kan man skriva bra kod så väl i PHP som andra språk, även om strukturen blir enklare i andra språk. Det jag ville ha sagt är att PHP i sig inte är något problem. Att hålla en bra struktur handlar om att vara väl insatt i det språk man skriver. Men så länge man vet hur man hantera det språk man skriver är inte språken i sig några problem om man har kunskapen om eventuella falluckor att undvika. Men jag är medveten om att vissa språk är enklare än andra så jag förstår hur du menar.

Fel tänkt. Här handlar det om fel inom applikationen. Kärnan håller ju inte isär olika användare på ett forum. Det är forumkoden. Kärnan har väldigt lite med säkerheten mellan användare i ett forum att göra eftersom alla dessa haneras av forumkoden i en databas och inte som olika datoranvändare (logins) på sjäva datorn.

Det jag syftar på med kärnans inblandning är att även om all användarhantering hanteras av forumkoden så anropar ju i sin tur forumkoden serverns PHP-kärna där forumkoden exekveras. Om det finns en brist i kärnan kan detta utnyttjas för att få exekveringen att brista i säkerhet oavsett hur forumkoden ser ut om kärnans brist ej är känd sedan innan och tilltäppt på annat vis. I detta fall har ju sessionshanteringen gått fel och även om forumkoden fungerat korrekt så kan ju kärnan ha haft problem med hanteringen av sessioner där i om det nu är fel hos leverantör. Detta i sin tur kan ju bero på många orsaker där det inte är helt utesluten möjlighet att servern kan ha attackerats då den troligen kör mycket fler applikationer än detta forum, beroende på serverstruktur. Men det finns ju mycket som kan gå fel på servern som kan orsaka detta, så om nu ingen otillbörlig åverkan gjorts så är det ju mycket möjligt att ett fel i kärnan oavsett hur det uppkommit ställt till att sessionerna inte hanteras korrekt och då har man ju troligen inte kunnat förhindra detta med en annan forumkod.
För att förtydliga så se till exempel de nyligen rapporterade säkerhetshålen Meltdown och Spectre i Intel-processorer. Där är det säkerhetshål i hårdvaran som möjliggör läsning ur minnesareor som inte ska vara tillåtet hur som helst enkelt förklarat. Har man ett program med hög säkerhet som exekveras på sådan processor kan man omöjligen med i detta program förhindra att andra program kan komma åt dess känsliga minne. Så slutsatsen jag ville få fram är att oavsett hur säker ens applikation är så finns det fler faktorer som rör hårdvara och exekvering som har stor inverkan som är svårare att styra över.