Linux-security

Kissé vicces a fordítás de a lényeg kibogarászható talán:
http://translate.google.hu/translate?hl=hu&sl=zh-CN&u=http://bbs.chinau…

kb. az ott leírtakat találtam egy gépen. Meglepően kevés találatot kaptam rá google-n. A gyanús az lett hogy a linken is látható "Iptables [12688]: segfault at 0000000000000000 rip 000000000804e837 rsp 00000000ffeb1fb0 hiba 4 "-hez hasonló bejegyzéseket találtam a logokban továbbá állandóan leállt az smbd és az nmbd. Megnézve nemcsak https://malwr.com/analysis/NmRkNDVkMjJhZTc5NDA5NDhkMzZhOWY5YTgyZjkzZTg/ eltűnt, a binárisok le is törlődtek. Egészen addig amíg chattr-rel le nem tiltottam azt már nem figyelte erre kb. percenként killelte őket. A binárisban nézelődve egy webcím is látható, http://kill.et2046.com/fuckopen.txt

Feltöltve és megnézetve víruskeresővel és malwarekeresővel nem találnak semmi gyanúsat, az egyik ilyen: https://malwr.com/analysis/NmRkNDVkMjJhZTc5NDA5NDhkMzZhOWY5YTgyZjkzZTg/

Látott már valaki ilyet és tudja hogy jön be? A gépen fut egy régen összerakott nem leszedhető php alkalmazás mint elsőszámú gyanusított.

Sziasztok!

Sajnos a minap bekaptuk egy .htaccess hacket, sajnos egy csomó mappába és almappába bepakolták. Azért írom ezt a témát, hogy aki ilyennel találkozik, az ki tudja pucolni a szerverét.

A hack lényege, hogy a .htaccess tartalmát meghagyja majd kb 1000 üres sor után bepakol egy jópár sor kártékony kódot, így szinte észrevehetetlen, valamint minden mappába és almappába betolja.

Innen letölthető

Tisztítás:


mkdir -p /root/hacked/moved
find / -size +30k -name .htaccess > /root/hacked/a.txt


Ez megtalálja az összes .htaccess fájlt amiben kártékony kód van.

Hozzunk létre egy scriptet

nano /root/hacked/cleaner.sh


A script tartalma ez legyen


#! /usr/bin/env bash
while read line
do
filename=${line//\//_}
mv $line $1/$filename
done < a.txt


Futtassuk

chmod +x /root/hacked/cleaner.sh
/root/hacked/cleaner.sh /root/hacked/moved


Ezután láthatjuk a hackelt fájlokat a /root/hacked/moved könyvtárban, a /-eket _ ra cserélve.

Az, hogy hogyan tolták fel, még nem tudom, valószínüleg valamelyik weboldal hibás kódján keresztül.

Remélem valaki számára hasznos lesz.

Üdv,
Gábor

Érdekelne, kinek milyen tapasztalata van/volt a RAM-ban lévő adatok titkosításával?

Mire gondolok...? Konkrétan - nitro / fagyasztásos / cold boot nevezd ahogy tetszik, vagy virtuális gép suspend->read etc elgondolásokon alapuló támadások... nos... ezeknek inkább megnehezítése, mintsem kivédése, de... legalább valami hasonló.

Egyelőre ez nagyon bíztatónak tűnik:

http://linuxaria.com/howto/protect-linux-from-cold-boot-attacks-with-tr…

Továbbá igaz ez BSD, de CryptKeeper: http://tastytronic.net/~pedro/docs/ieee-hst-2010.pdf

De nem akarok több zsákutcámat felsorolni, ebből már kb. látható, mi felé tapogatózok...

Lényegében... A CPU-ban tárolt dolgok védelme annyira nem kritikus illetve szükségtelen is ebben az esetben, mivel főleg a crypt partícióról beolvasott, memóriában épp futó nagyobb programrészek/adatok olvasásvédelméről volna inkább szó.

Magyarán az nem gáz, ha X mega cache-nyi working adat kikerül, csak ne legyen már az egész nyitott könyv egy kis mezei fagyasztás vagy "suspend gombos" leállítás számára. Ennyi az elképzelés...

L.

Létezik ilyen? Tegnap olvastam a hírt:

Totális lehallgatás

"De nem csak ruházati és barátságos technológiák miatt lehet emlékezetes Sochi, hanem a háttérben meghúzódó biztonsági óvintézkedésekről is biztosan hallunk majd eleget. Az NSA botrány közepette ugyanis az olimpiai játékok védelmére hivatkozva gyakorlatilag mindenkit megfigyelnek majd, aki a városba lép. Az orosz városban bevezetett Vitok-IP-n keresztül az egész hálózati forgalmat - kezdve a levelektől, a HTML oldalakon át, a csevegésekig - monitorozzák majd, hogy így szúrhassák ki a terrorista gyanús személyeket. A megoldás olyannyira megkerülhetetlen, hogy az Egyesült Államok korábban azt javasolta a Sochiba utazó állampolgárainak, hogy csak "tiszta" elektronikus berendezéseket vigyenek magukkal, amelyekről semmilyen érzékeny adatot nem lehet leolvasni."

Ilyet nem lehet kikerülni, SSH forgalom is visszafejthető?

Forrás: http://pcworld.hu/tudomany/sochibol-szeretettel-elkepeszto-technologiak…
illetve http://www.norsi-trans.com/pdetail/vitok-ip/

Sziasztok!

Egy kérdésem lenne:

Hogy lehet megoldani iptables-szel (vagy bármi mással), hogy kimenő forgalom 1 bizonyos hálókártyán (eth1) menjen ki?

Rendszer: Debian 7.2

köszi

Valamit ki akartam próbálni, sima felhasználóként mondom:

cd /root

Erre végrehajtja. Nézek ls-t, valóban látom, ami benne van. Hm, érdekes, nézzük a jogokat:

drwxr-xr-x.  12 root root  4096 Dec 28 14:17 root

Iziben átírtam 0700-ra. Vajon tévedésből lett a Fedora 20-ban ez? Remélem, nem én írtam át, s hagytam így véletlenül.

Akinek van Fedorája - elsősorban 19-es vagy 20-as verzió -, nézze már meg, hogy így van-e!

Sziasztok!

Egy drupal7 oldalon el tudnak valamit érni (azon túl, hogy a keresett oldal nem található) egy ilyen url-el?

http://257.258.259.260/cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E

érthetőbben:

http://257.258.259.260/cgi-bin/php5?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -n

Hi!

Elérkezett az idő, hogy a "kis" firewall.sh scriptemet újragondoljam. Ugyanis a script közelít az 1500 sorhoz és most kell a hálózati részt teljesen újraszabni további bővülés miatt.
Tehát van egy gateway a következőkkel:
- közel 20 VLAN
- minden VLAN brindge-ban, hogy OpenVPN-el a távolról jövőket a megfelelő VLAN-ba tudjam beengedni
- transparent proxy
- másik telephelyekről (fix IP-vel) különböző portokra csatlakoznak programok
- külföldről egyedi portokra jönnek távfelügyeletre

Szóval szép vegyes felvágott, arról nem is beszélve, hogy egyes VLAN-ok között is vannak apróbb átjárások.

Mivel a másik telephely most lesz direkt bekötve, annak a szabályai is átjönnek részben és így kezd elég sok lenni.

A kérdés: ki mivel szerkeszti/szerkesztené az ekkora szabályrendszert?

Most találtam rá a FirewallBuilder-re, de első látásra elég komplex. ;-)
Van esetleg ezzel valakinek tapasztalata? Érdemes vele foglalkozni?

Elmélkedtem még Zorp-on is, de sajnos azzal sincs tapasztalatom illetve kérdés, hogy meglévő debian-ra telepíthető -e?

Minden ötletet, javaslatot szívesen fogadok.

Szerencsére én nem voltam közvetlenül érintve, de hátha másokat érint és még nem tud róla.
Nem kell más, mint egy sima debian -apache2-php5-cgi default telepítés...

/* This is a code execution bug in the combination of Apache and PHP.
On Debian and Ubuntu the vulnerability is present in the default install
of the php5-cgi package. When the php5-cgi package is installed on Debian and
Ubuntu or php-cgi is installed manually the php-cgi binary is accessible under
/cgi-bin/php5 and /cgi-bin/php. The vulnerability makes it possible to execute
the binary because this binary has a security check enabled when installed with
Apache http server and this security check is circumvented by the exploit.
When accessing the php-cgi binary the security check will block the request and
will not execute the binary.
In the source code file sapi/cgi/cgi_main.c of PHP we can see that the security
check is done when the php.ini configuration setting cgi.force_redirect is set
and the php.ini configuration setting cgi.redirect_status_env is set to no.
This makes it possible to execute the binary bypassing the Security check by
setting these two php.ini settings.
Prior to this code for the Security check getopt is called and it is possible
to set cgi.force_redirect to zero and cgi.redirect_status_env to zero using the
-d switch. If both values are set to zero and the request is sent to the server
php-cgi gets fully executed and we can use the payload in the POST data field
to execute arbitrary php and therefore we can execute programs on the system.
apache-magika.c is an exploit that does exactly the prior described. It does
support SSL.
/* Affected and tested versions
PHP 5.3.10
PHP 5.3.8-1
PHP 5.3.6-13
PHP 5.3.3
PHP 5.2.17
PHP 5.2.11
PHP 5.2.6-3
PHP 5.2.6+lenny16 with Suhosin-Patch
Affected versions
PHP prior to 5.3.12
PHP prior to 5.4.2
Unaffected versions
PHP 4 - getopt parser unexploitable
PHP 5.3.12 and up
PHP 5.4.2 and up
Unaffected versions are patched by CVE-2012-1823.
*/

Itt az exploit linkje: http://www.exploit-db.com/exploits/29290/

Ha régi v. ismert már, akkor sorry és törlöm a bejegyzést...

Egy felhasználóm crontabjában (/var/spool/cron/crontabs) ezt találtam:

* * * * * /dev/shm/lib/y >/dev/null 2>&1

Szerintem ez egy sikeres vagy sikertelen disznóság maradványa.
A /dev/shm most üres.
Láttatok már ilyet?