ernstoud schreef op zondag 6 oktober 2024 @ 12:30:
[...]
Er heeft een Tweaker (terecht) geïnformeerd bij de developers naar de security van het Globalping platform (uiteraard is een probe een target, maar ook de backbone natuurlijk). Ik denk, zoals ik boven aangeef, dat Google e.a. wel een eigen analyse gedaan zal hebben.
Ik zal het duidelijker voor je opschrijven - de vorige keer noemde ik het alleen impliciet: Deze code draait niet op vertrouwde google infra. Daarnaast zegt dat iets binnen het netwerk van een cloud-provider draait niets over wie de infra beheert.
Telt overigens voor al deze meet-platformen: Dat een probe binnen een netwerk draait wil niet zeggen dat het beheerd wordt door de beheerders van dat netwerk.
De developer liet mij weten dat Globalping - een open source, community funded effort - zich geen professionele, onafhankelijke security analyse kan veroorloven. Echter, een student aan de IT faculteit van een universiteit in Praag is recent afgestudeerd met een zeer gedegen thesis over de security, inclusief code review, van Globalping.
Het is altijd een keuze

. Waar de waarde van security rapporten ook zeer sterk wisselt dus ik snap het erg goed als je daar niet op focust als bedrijf. Een security rapport zijn waarde hangt erg af van de reputatie van de partij die de test doet.
In het rapport van de bachelor-student mis ik een risico-analyse die vanuit architectuur perspectief kijkt. Imo moet je bijvoorbeeld als probe-host de server niet hoeven te vertrouwen en vice-verse.
De conclusie is:
“During the analysis of the Globalping probe, I did not manage to uncover any severe vulnerabilities in the application. The few vulnerabilities, that were identified, are mostly informative in nature. As a result of these steps, I produced a security report on the Globalping probe, whichis a valuable resource for both the developers of the Globalping platform and also for the users who aim to host a probe themselves"
Hetzelfde rapport:
The analysis of the Globalping probe uncovered the following security vulnerabilities: Lack
of authentication on the API, Insufficient input validation, Improper rate limiting, Insecure
communication, and outdated dependencies. While these may sound severe, for the probe, in
the context of the platform as a whole they do not pose a notable threat. The insufficient input
validation is mitigated on the API level and this finding is more informative in nature as in
suggesting best practices of defense in depth.
Beide geen impact overigens; het input validatie issue was iets dat ik zelf ook zag en dat nog steeds bestaat. Verder zou je absolute paden willen gebruiken
indien de code ook in omgevingen draait waar er andere binaries op het pad staan, niet van toepassing bij een container of hardware probe.
- Plaintext websockets ipv over TLS: ondertussen opgelost.
- Gebrek aan input-validatie met shell-injectie als resultaat: Vermoedelijk niet exploiteerbaar (afhankelijk van de execa library + unbuffer interacties). Maar hier vertrouwen op server-side validatie vind ik ongewenst gegeven de architectuur.
[
Voor 4% gewijzigd door
ANdrode op 06-10-2024 15:02
]