Treba ja hodne cestuji, tudiz jsem v zahranici na mobilu. Dorazi mi treba 10spamu a ja za prenos nevyzadanych informaci platim realne penize. Ano, delete funguje, ale co kdyz dostavate 100 spamu denne? 100x delete je treba 5 minut casu, do mesice to mate 100 minut casu, za ktere Vas firma plati. Porad nevidite problem? Jestli ne, tak tady uvedte svou e-mailovou adresu a muzete mackat delete az dokud pochopite ze spam je problem.
u vetsiny spamu mi hosting odpovedel ze nevi jestli jsem se registroval na odber obchodnich sdeleni a tudiz nic neudelali, u odesilatele spamu mi rekli, ze jsem se registroval a maji dokonce mou IP adresu nekde z Asie ale samozrejme nevyzaduji potvrzeni adresy pres e-mail, tudiz muzete zaregistrovat kohokoliv. Reseni pres UOOU je neefektivni, za pul roku vyresili prd, protoze v idealnim pripade e-mail vytvari 1 firma, hosting ma dalsi firma, rozesila je dalsi firma pres dalsiho providera a vsichni delaj jakoby nic.
vlastne jsme nastavili co bylo mozne v sekci "Bezpecnost webove aplikace", protoze ostatni sekce nejsme schopni ovlivnit + "-ExecCGI" pro vypnuti vsech CGI scriptu.
Vim ze je to as delikatni zalezitost, ale podelite se s nami s protiopatrenimi co jste zavedli? Jsem laik a premyslim o tom, zda zaridit vlastni server nebo nejaky serverovy prostor pronajmout. A protoze sdelujete informace o bezpecnosti tak me zajima reseni vaseho zabezpeceni, byt jste nezjistili jak se tam utocnik dostal.
a] hosting pouziva modul ruid, ktery si sami napsali http://websupport.sk/~stanojr/projects/mod_ruid/ takze i CGI bezi pod unikatnim uzivatelem
b] heslo zustalo stejne, takze ho ani neprepsali. pochybuji ze by ho prepsali a pak vratili zpet, kdyz tam okolo zanechali takovou paseku.
c] security klice nejsou saltem hesla, ale pouzivaji se pro salt session cookie. kdyz je prepises, tak se jen zrusi vsechny sessions.
jinak souhlasim. nejspis se dostali k nam pres jiny web na stejnem serveru, pomoci vyuziti nektere zranitelnosti. pokud ano, tak uz zrejme nebude utok funkcni, protoze jsem to aktivne resil s hostingem a predpokladam, ze chybu napravili. tot prave moje spekulace, kterou jsem nechtel nikoho na stejnem hostingu plasit, pokud nemam dukaz.
1. přes hacknutí jiného nezabezpečeného webu na sdíleném hostingu si povolili spuštění CGI skriptů
2. Pomocí CGI skriptu, na který se logicky nevztahují restrikce PHP, si přečetli přístupy do databáze v konfiguračním souboru WP wp-config.php
3. v databázi přepsali hash hesla uživatele admin za jim známou hodnotu
4. přihlásili se jako admin s novým heslem - WordPress, byť má jiné klíče a salty ve wp-config.php, toto umožňuje
O žádné sofistikované prolamování sezení tedy (podle mého skromného názoru) nešlo, nebo by alespoň byli idioti, kdyby to dělali tak složitě, když to lze jednoduše výše uvedeným způsobem.
uprimne? ne
nikdo nechce pomoct, nikdo nema cas, kazdy chce mit vsechno hned a vetsinou je pro ne problem si i neco precist... vim o cem mluvim a myslim ze nema cenu se o tom rozepisovat. pral bych takovym at si to semnou alespon na tyden vymeni :]
druha cast je cca z 60% hotova, bude po korekture publikovana v pristim tydnu
ÚOOÚ je jen další banda nic nedělajících úředníků. Případy řeší z 99% tím, že prohlašuje, že neshledala nikde žádné provinění. Prostě netáhla! Hlásil jsem 3 společnosti, které jedou klasicky na "nefunkční unsubscribe" - klasický podvod jak od školáka. ÚOOÚ mi v jednom případě ohlásila, že neshledala na straně firmy žádné porušení zákona. Ve dvou dalších případech mi nikdo ani neodpověděl. Kašlou na to. Pondělí středa úřední dny a zbytek týdne čumí z okna.... státní úřad.
Dobry den,
rad bych se zeptal na jednu vec. Konkretne me zaujal nasledujici config. radek:
webmaster localhost = (apache) ALL, (root) /usr/bin/su apache
Zajimalo by me, zda neni prvni pravidlo "(apache) ALL" zbytecne - tedy prece jeho vyznam je obsazen v pravidle nasledujicim "(root) /usr/bin/su apache" - kdy mohu spustit shell uzivatele apache, tak pod nim mohu vykonat libovolny rikaz pod uzivatelem apache. Nebo jsem neco prehledl ?
Treba ja hodne cestuji, tudiz jsem v zahranici na mobilu. Dorazi mi treba 10spamu a ja za prenos nevyzadanych informaci platim realne penize. Ano, delete funguje, ale co kdyz dostavate 100 spamu denne? 100x delete je treba 5 minut casu, do mesice to mate 100 minut casu, za ktere Vas firma plati. Porad nevidite problem? Jestli ne, tak tady uvedte svou e-mailovou adresu a muzete mackat delete az dokud pochopite ze spam je problem.
u vetsiny spamu mi hosting odpovedel ze nevi jestli jsem se registroval na odber obchodnich sdeleni a tudiz nic neudelali, u odesilatele spamu mi rekli, ze jsem se registroval a maji dokonce mou IP adresu nekde z Asie ale samozrejme nevyzaduji potvrzeni adresy pres e-mail, tudiz muzete zaregistrovat kohokoliv. Reseni pres UOOU je neefektivni, za pul roku vyresili prd, protoze v idealnim pripade e-mail vytvari 1 firma, hosting ma dalsi firma, rozesila je dalsi firma pres dalsiho providera a vsichni delaj jakoby nic.
Tak tak. Nikdy jsem nerozuměl, těm agresivním komentářům, vyjadřující, nízké sebevědomí, a nespokojenost se svým životem.
Autoři zapomněli na thc, podporuje kreativitu, mění stavy vědomí, člověk při otevření kódu může přijít na nové věci, nebo něco udělat jinak, lépe.
Zajímavej článek a rozbor, díky
Aký má vplyv dlhodobé užívanie? Neškodí to? Respektíve čo sa stane po vysadení?
Dobrý den,
můžete nějak blíže vysvětlit to "naše další opatření mu zabrání dostat se ze subdomény"?
Děkuji.
Dobry den,
vlastne jsme nastavili co bylo mozne v sekci "Bezpecnost webove aplikace", protoze ostatni sekce nejsme schopni ovlivnit + "-ExecCGI" pro vypnuti vsech CGI scriptu.
Staci takto?
Dekuji
Vim ze je to as delikatni zalezitost, ale podelite se s nami s protiopatrenimi co jste zavedli? Jsem laik a premyslim o tom, zda zaridit vlastni server nebo nejaky serverovy prostor pronajmout. A protoze sdelujete informace o bezpecnosti tak me zajima reseni vaseho zabezpeceni, byt jste nezjistili jak se tam utocnik dostal.
Dekuji M
Diky za komentar
a] hosting pouziva modul ruid, ktery si sami napsali http://websupport.sk/~stanojr/projects/mod_ruid/ takze i CGI bezi pod unikatnim uzivatelem
b] heslo zustalo stejne, takze ho ani neprepsali. pochybuji ze by ho prepsali a pak vratili zpet, kdyz tam okolo zanechali takovou paseku.
c] security klice nejsou saltem hesla, ale pouzivaji se pro salt session cookie. kdyz je prepises, tak se jen zrusi vsechny sessions.
jinak souhlasim. nejspis se dostali k nam pres jiny web na stejnem serveru, pomoci vyuziti nektere zranitelnosti. pokud ano, tak uz zrejme nebude utok funkcni, protoze jsem to aktivne resil s hostingem a predpokladam, ze chybu napravili. tot prave moje spekulace, kterou jsem nechtel nikoho na stejnem hostingu plasit, pokud nemam dukaz.
Udělali to IMHO takto jednoduše:
1. přes hacknutí jiného nezabezpečeného webu na sdíleném hostingu si povolili spuštění CGI skriptů
2. Pomocí CGI skriptu, na který se logicky nevztahují restrikce PHP, si přečetli přístupy do databáze v konfiguračním souboru WP wp-config.php
3. v databázi přepsali hash hesla uživatele admin za jim známou hodnotu
4. přihlásili se jako admin s novým heslem - WordPress, byť má jiné klíče a salty ve wp-config.php, toto umožňuje
O žádné sofistikované prolamování sezení tedy (podle mého skromného názoru) nešlo, nebo by alespoň byli idioti, kdyby to dělali tak složitě, když to lze jednoduše výše uvedeným způsobem.
Velmi pekny clanok:) vdaka
uprimne? ne
nikdo nechce pomoct, nikdo nema cas, kazdy chce mit vsechno hned a vetsinou je pro ne problem si i neco precist... vim o cem mluvim a myslim ze nema cenu se o tom rozepisovat. pral bych takovym at si to semnou alespon na tyden vymeni :]
druha cast je cca z 60% hotova, bude po korekture publikovana v pristim tydnu
omlouvam se za to vecne zdrzovani
nedá sa to nejak zorganizovať aby niekto pomohol?keby sa nieco naslo kludne pomozem...mna sice nic nenapada v com mozem pomoct, ale mozno vas hej :D
snad to vyjde!
uvedomuju si jak dlouho to trva a samotneho me to stve
Na vánoce to nevyšlo..
Tak žeby na nový rok? :)
ÚOOÚ je jen další banda nic nedělajících úředníků. Případy řeší z 99% tím, že prohlašuje, že neshledala nikde žádné provinění. Prostě netáhla! Hlásil jsem 3 společnosti, které jedou klasicky na "nefunkční unsubscribe" - klasický podvod jak od školáka. ÚOOÚ mi v jednom případě ohlásila, že neshledala na straně firmy žádné porušení zákona. Ve dvou dalších případech mi nikdo ani neodpověděl. Kašlou na to. Pondělí středa úřední dny a zbytek týdne čumí z okna.... státní úřad.
uz su tie vianoce fakt blizko tak aby to už bylo :D
možno ako vianočné prekvapenie? :)
Zaujímavá knižka v ktorej aktívne riešite hlavolamy a šifry sa volá rébusbook. Viac na:
www.rebusbook.szm.com
nieco kupite aj bez toru napr. www.sigint.sk ,
nechcem tu robit reklamu, no je tam toho dost...
www.sigint.sk
poznate este nejake weby na SK ?
Díky, to jsem potřeboval, fakt dobrej výběr!
Dobry den,
rad bych se zeptal na jednu vec. Konkretne me zaujal nasledujici config. radek:
webmaster localhost = (apache) ALL, (root) /usr/bin/su apache
Zajimalo by me, zda neni prvni pravidlo "(apache) ALL" zbytecne - tedy prece jeho vyznam je obsazen v pravidle nasledujicim "(root) /usr/bin/su apache" - kdy mohu spustit shell uzivatele apache, tak pod nim mohu vykonat libovolny rikaz pod uzivatelem apache. Nebo jsem neco prehledl ?
Dekuji za odpoved
tesim sa, ze bude stretnutie. ale Praha je trochu daleko, takze skor nepridem.
ten ML nefunguje uz strasne dlho.
vie niekto kedy bude fungovat ? ine ML tam funguju
... pesimista je člověk se zkušenostmi ...