02.02.2017 Inglise keele tunnitöö

Drupal PSA-2014-003 - Public message of a critical error

NB! This is a sequel to the error notification SA-CORE-2014-005 and is not connected to the new threat.

On 15 October Drupal published the SQL injection vurnelability in main code (SA-CORE-2014-005). Mass automated attacks that hit websites that used Drupals webengine began in a couple of hours after the notification.  If the website has not been parched against this problem before 01:00-t on 16 october - ie seven hours after the notification, then the website owner may suspect a breakin has occurred.

Updating drupal to version 7.32 is probably not enough to get rid of the problem. But - if you havent updated your Drupal's website yet, go do it now!

...and after that continue reading this post. Updating did fix the vurnelability, but dosen't remove the backdoor to the websites that have already been broken into.

How to recognize if the website has been broken into? One sign is that the webengine is already patched. So - when patching and it appears that this has already been done but you didn't do it, then that is a sign on a breakin. The reason is that some of the attackers have installed a mistake in the victims webengine just to stay as the only person who broke into the webengine.

Some opportunities to spot the backdoors

• Search for files that were downloaded after 15th which you werent apart of installing
• Search for files that include strings "eval" or "base64", rate them according to their content, whether it might be a backdoor
• Search the logs, if you didn't already. In additon to the web server logs, regularly check the other things like postserver logs

Preventive measures as well as the futurre of its security break-ins, and finding errors assets, should be set up an ongoing logging search: The ongoing monitoring; network traffic monitoring and profiling; check the firewall(s), local server rules and install the hack detected assist devices (IDS). If the server does not have a decent backup, then its the last time to start one.

Referring to the Drupals creators created instructions.

Data and damage evaluation

The attackers may have copied all data in your site and might use it in any way. To future activities we recommend you to read Drupals documentary: "Your Drupal site got hacked, now what".

Recovery

• Attackers may have created backdoors to databases, filesystems or other places.
• Attackers may have used other running processes or other accessible websites and systems in your web server.

Finding a backdoor in 100% success is very complicated process which you can never be sure of. Therefore we recommend you to restore your website to a backup created before 15th october.

1. Deactivate your website, rreplace it with a temporary static HTML website.
2. Notificate your website administrator and point out that other systems in the same server may be compromised.
3. Create a new backup of your current website status.
4. Best solution is to recover the website from a backup created before 15th october to be sure that there is no backdoors set up by the attackers.
5. Update your recovered backup webengine to the last version before 15th october.
6. Restart your website.
7. Closely inspect all your files, codes or devices that require bringing over from the infected version to the latest website.

Drupal PSA-2014-003 – avalik teavitus kriitilisest veast

NB! See on järg veateavitusele SA-CORE-2014-005 ning ei ole seotud uue haavatavusega.

15. oktoobril andis Drupal avalikult teada SQL injection haavatavusest Drupali tuumikkoodis (SA-CORE-2014-005). Automatiseeritud massilised ründed Drupali veebimootorit kasutavatele veebidele algasid paari tunni jooksul peale teavitust. Kui veebisaiti ei ole antud probleemi vastu paigatud enne kella 01:00-t 16. oktoobril – st 7 tunni jooksul peale teavitust, siis võiks veebilehe haldaja eeldada, et sissemurdmine on aset leidnud.

Drupali 7.32 versioonile uuendamine ei ole suure tõenäosusega enam piisav probleemist vabanemiseks. Siiski – kui Sa ei ole oma Drupalit kasutavat veebilehte veel uuendanud, siis mine tee seda kohe!

… ning peale seda jätka selle teate lugemist. Uuendamine parandas küll selle haavatavuse, kuid ei eemaldanud tagauksi nendes veebides, kuhu on juba sisse murtud.

Kuidas ära tunda seda, kas veebilehele on juba sisse murtud? Üks märk on see, et veebimootor on juba paigatud. Seega – kui paikamisel selgub, et seda on juba tehtud, aga seda ei teinud Teie, siis see on tunnus sissemurdmisest. Põhjus on see, et mõned ründajad on paiganud vea ohvri veebimootoris, et jääda ainukeseks sissemurdjaks.

Mõned võimalused tagauste tuvastamiseks (loetelu ei ole ammendav!):

• otsi faile, mis on tekkinud peale 15. kuupäeva ning mille tekitamises sa ise kindlasti ei ole osalenud,
• otsi faile, mis sisaldavad stringe “eval” ja/või “base64”, hinda nende sisu alusel, kas tegemist võib olla tagauksega,
• seira logisid, kui sa seda juba ei tee. Lisaks veebiserveri logidele vaata regulaarselt üle ka muud, näiteks postiserveri logid.

Ennetavate meetmetena nii selle kui tulevaste turvavigade leidmiste ja sissemurdmiste varalt, tuleks üles seada jatkuv logide seire; võrguliikluse seire ja profileerimine; üle vaadata tulemüüri(de) reeglid ning lokaalsesse serverisse paigaldada sissemurdmist tuvastada abistavad vahendid (IDS). Kui serveril puudub korralik varundus, siis on viimane aeg sellega alustada.

Refereerime järgnevalt ka pisut Drupali loojate toodud juhendit.

Andmed ja kahjude hindamine

Ründajad võivad olla kopeerinud kõik teie saidis leiduvad andmed ning võivad seda ära kasutada mistahes viisil. Edasiseks tegevuseks soovitame lugeda Drupali dokumentatsiooni: ”Your Drupal site got hacked, now what”.

Taastamine

• Ründajad võivad olla andmebaasi, failisüsteemi või muudesse kohtadesse tekitanud tagauksi.
• Ründajad võivad olla ära kasutanud teisi teie veebiserveris jooksvaid või sellelt ligipääsetavaid veebisaite ning süsteeme.

Tagauste ülesleidmine on väga keeruline protsess mille 100% edukuses ei saa peaaegu kunagi kindel olla. Seetõttu soovitame oma saidi kogu mahus taastada enne 15. oktoobrit tehtud varukoopiast:

1. Deaktiveerige veeb, asendades selle ajutise staatilise HTML leheküljega.
2. Teavitage oma serverihaldurit ning rõhutage, et teised samas serveris olevad süsteemid võivad samuti olla kompromiteerunud.
3. Tehke veebi hetkeseisust uus varukoopia.
4. Parim lahendus on veeb enne 15. oktoobrit tehtud koopiast taastada täiesti uude serverikeskkonda, et olla kindel, et kusagil pole ründajate seatud tagauksi.
5. Uuendage enne 15. oktoobrit tehtud varukoopiast taastatud veebimootor viimasele versioonile.
6. Taasaktiveerige veeb.
7. Vaadake põhjalikult üle kõik failid, kood või seaded, mida on vaja üle tuua veebi viimasest, nakatunud versioonist.

https://blog.ria.ee/2014/10/