LFI2RCE via Eternal waiting
Basiese Inligting
Standaard, wanneer 'n lêer na PHP geüpload word (selfs al verwag dit nie), sal dit 'n tydelike lêer in /tmp genereer met 'n naam soos php[a-zA-Z0-9]{6}, alhoewel ek sommige docker-afbeeldings gesien het waar die gegenereerde lêers nie syfers bevat nie.
In 'n plaaslike lêer insluiting, as jy daarin slaag om daardie geüploade lêer in te sluit, sal jy RCE kry.
Let daarop dat standaard PHP slegs toelaat om 20 lêers in 'n enkele versoek te laai (ingestel in /etc/php/<version>/apache2/php.ini):
Ook, die aantal potensiële lêernaam is 62*62*62*62*62*62 = 56800235584
Ander tegnieke
Ander tegnieke steun op die aanval van PHP-protokolle (jy sal nie in staat wees as jy net die laaste deel van die pad beheer nie), die bekendmaking van die lêernaam, die misbruik van verwagte lêers, of PHP laat 'n segmentasiefout ly sodat opgelaai tydelike lêers nie verwyder word nie. Hierdie tegniek is baie soortgelyk aan die vorige een, maar sonder om 'n nul-dag te vind.
Ewige wagtegniek
In hierdie tegniek moet ons net 'n relatiewe pad beheer. As ons daarin slaag om lêers op te laai en die LFI nooit te laat eindig nie, sal ons "genoeg tyd" hê om opgelaai lêers met geweld te ontsyfer en enige van die opgelaai lêers te vind.
Voordele van hierdie tegniek:
Jy hoef net 'n relatiewe pad binne 'n insluiting te beheer
Vereis nie nginx of 'n onverwagte vlak van toegang tot log lêers nie
Vereis nie 'n 0-dag om 'n segmentasiefout te veroorsaak nie
Vereis nie 'n padbekendmaking nie
Die hoofprobleme van hierdie tegniek is:
Moet spesifieke lêer(s) teenwoordig wees (daar kan meer wees)
Die kranklike hoeveelheid potensiële lêernaam: 56800235584
As die bediener geen syfers gebruik nie, is die totale potensiële bedrag: 19770609664
Standaard kan slegs 20 lêers in 'n enkele versoek opgelaai word.
Die maksimum aantal gelyktydige werkers van die gebruikte bediener.
Hierdie limiet saam met die voriges kan hierdie aanval te lank laat duur
Tydsbeperking vir 'n PHP-versoek. Dit behoort idealiter ewig te wees of die PHP-proses te dood sonder om die tydelike opgelaai lêers te verwyder, indien nie, sal dit ook 'n pyn wees
Hoe kan jy dan 'n PHP-insluiting nooit laat eindig nie? Net deur die lêer in te sluit /sys/kernel/security/apparmor/revision (ongelukkig nie beskikbaar in Docker-houers nie).
Probeer dit net deur te skakel:
Apache2
Standaard ondersteun Apache 150 gelijktijdige verbindinge, volgens https://ubiq.co/tech-blog/increase-max-connections-apache/ is dit moontlik om op te gradeer tot 8000. Volg hierdie stappe om PHP met daardie module te gebruik: https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04.
Standaard (soos ek kan sien in my toetse), kan 'n PHP-proses eeuwig duur.
Laat ons 'n bietjie wiskunde doen:
Ons kan 149 verbindinge gebruik om 149 * 20 = 2980 tydelike lêers met ons webshell te genereer.
Gebruik dan die laaste verbinding om potensiële lêers met brute force aan te val.
Teen 'n spoed van 10 versoek/s is die tye:
56800235584 / 2980 / 10 / 3600 ~= 530 ure (50% kans in 265h)
(sonder syfers) 19770609664 / 2980 / 10 / 3600 ~= 185h (50% kans in 93h)
Let daarop dat in die vorige voorbeeld ons ander kliënte heeltemal DoS!
As die Apache-bediener verbeter word en ons kan 4000 verbindinge misbruik (halfpad na die maksimum getal). Ons kan 3999*20 = 79980 lêers skep en die aantal sou verminder tot ongeveer 19.7h of 6.9h (10h, 3.5h 50% kans).
PHP-FMP
Indien daar in plaas van die gewone php-mod vir Apache om PHP-skripte uit te voer die webbladsy PHP-FMP gebruik word (dit verbeter die doeltreffendheid van die webbladsy, so dit is algemeen om dit te vind), is daar iets anders wat gedoen kan word om die tegniek te verbeter.
PHP-FMP maak dit moontlik om die parameter request_terminate_timeout te configureer in /etc/php/<php-weergawe>/fpm/pool.d/www.conf.
Hierdie parameter dui die maksimum aantal sekondes aan wanneer 'n versoek aan PHP moet beëindig (oneindig standaard, maar 30s as die parameter uitgekommentaar is). Wanneer 'n versoek deur PHP verwerk word vir die aangeduide aantal sekondes, word dit afgesluit. Dit beteken, as die versoek tydelike lêers aan die oplaai was, omdat die php-verwerking gestop was, sal daardie lêers nie uitgevee word nie. Daarom, as jy 'n versoek daardie tyd kan laat duur, kan jy duisende tydelike lêers genereer wat nie uitgevee sal word nie, wat die proses van hulle vind versnel en die waarskynlikheid van 'n DoS tot die platform verminder deur al die verbindinge te gebruik.
Dus, om 'n DoS te vermy aanvaar ons dat 'n aanvaller slegs 100 verbindinge op 'n slag sal gebruik en die maks verwerkingstyd deur php-fmp (request_terminate_timeout) is 30s. Daarom is die aantal tydelike lêers wat per sekonde gegenereer kan word 100*20/30 = 66.67.
Dan, om 10000 lêers te genereer, sal 'n aanvaller benodig: 10000/66.67 = 150s (om 100000 lêers te genereer sal die tyd 25min wees).
Dan kan die aanvaller daardie 100 verbindinge gebruik om 'n soek-brute force uit te voer. **** Met 'n spoed van 300 versoek/s is die tyd wat nodig is om dit te benut die volgende:
56800235584 / 10000 / 300 / 3600 ~= 5.25 ure (50% kans in 2.63h)
(met 100000 lêers) 56800235584 / 100000 / 300 / 3600 ~= 0.525 ure (50% kans in 0.263h)
Ja, dit is moontlik om 100000 tydelike lêers te genereer in 'n EC2 medium-grootte instansie:
Let daarop dat om die tydsbeperking te aktiveer, dit genoeg sal wees om die kwesbare LFI-bladsy in te sluit, sodat dit in 'n ewige insluitlus beland.
Nginx
Dit lyk asof Nginx standaard 512 parallelle verbindinge op dieselfde tyd ondersteun (en hierdie getal kan verbeter word).
Last updated
