Ernstig lek in F5's BIG-IP-apparatuur maakt remote code execution mogelijk

Onderzoekers hebben een grote kwetsbaarheid gevonden in BIG-IP-netwerkapparatuur van F5. Inmiddels zijn er ook proofs-of-concept uitgebracht waarmee onder andere een authenticatieloze remote code execution kan worden uitgevoerd. Er zijn actieve aanvallen waargenomen.

De kwetsbaarheden werden vorige week ontdekt in BIG-IP-apparatuur van fabrikant F5. Die maakt netwerkapparaten waarmee bijvoorbeeld firewalls kunnen worden opgezet of gateways worden ingesteld op netwerken. Vorige week werd een ernstige kwetsbaarheid bekend in de Traffic Management User Interface van de Application Delivery Controller van het bedrijf. Met die kwetsbaarheid, die bekendstaat als CVE-2020-5902, kunnen aanvallers als ongeautoriseerde gebruiker een remote code execution uitvoeren. Diverse beveiligingsonderzoekers zeggen inmiddels een proof-of-concept te hebben gemaakt of werken daaraan. Daarmee zou het voor aanvallers eenvoudig zijn om zelf het lek uit te buiten.

BIG-IP-netwerken zijn interessant voor criminelen. De hardware van F5 wordt gebruikt bij grote, invloedrijke bedrijven. F5 zegt zelf dat de apparatuur wordt gebruikt in 48 van de 50 grootste bedrijven in Amerika. Bovendien is ook het lek interessant. Dat krijgt een CVSSv3-score van 10/10, wat betekent dat het gemakkelijk uit te buiten is, kan worden geautomatiseerd en op afstand kan worden uitgevoerd.

Inmiddels zeggen onderzoekers die honeypots hebben opgezet, dat het lek actief wordt aangevallen. Er zijn op dit moment nog geen gevallen bekend van bedrijven die actief zijn aangevallen. Dat betekent niet per se dat dat niet gebeurd is; bij andere grote netwerkaanvallen op bedrijfsapparatuur, zoals het lek in Citrix, bleken criminelen pas na lange tijd toe te slaan. Zo zouden in bedrijven die de Citrix-patch hebben doorgevoerd, alsnog backdoors zijn geplaatst.

Reacties (54)

[kodak]

Waarom zou je als eigenaar eigenlijk de Traffic Management User Interface voor iedereen van het internet bereikbaar willen hebben? Je zet de toegang tot je beheer interface volgens goed gebruik in een apart netwerk waar alleen beheerders toegang toe horen te hebben.

[Scriptkid]

Tja dat zelfde geld voor je router , toch zijn er duizenden devices te vinden die de management interface naar inet open hebben staan.

gemakzucht of onwetendheid.

[Rataplan_]

Dat zal zeker de reden zijn. Maar in mijn ogen gaat er toch iets mis als je een F5 firewall (tienduizenden euro's vaak) inzet, en een 'ongeschoolde' IT'er hem laat inrichten...

[CAPSLOCK2000]

Dat zal zeker de reden zijn. Maar in mijn ogen gaat er toch iets mis als je een F5 firewall (tienduizenden euro's vaak) inzet, en een 'ongeschoolde' IT'er hem laat inrichten...

Dat is de appliance-paradox; er wordt geinvesteerd in een dure doos met geavanceerde software in de veronderstelling dat er dan bezuinigd kan worden op personeel. In praktijk pakt het makkelijk verkeerd om uit omdat zo'n doos een gespecialiseerde professional nodig heeft. Het is alsof je een slechte taxichauffeur helpt door een verlengde limousine te kopen in de verwachting dat zo'n dure limousine makkelijker rijdt dan een gewone taxi.

Je ziet het ook bij andere dingen. Gereedschap weegt nooit op tegen kennis. Ik heb liever een professionele timmerman met een hamer uit de speelgoedwinkel dan een peuter met een pneumatisch spijkerpistool.

De fout die gemaakt wordt is dat ze de kosten zo laag mogelijk willen houden en daarom investeren in efficientie. Bij efficientie is de prijs per "eenheid" wel laag, maar de totaalprijs niet. Als je die totaalprijs niet wil betalen dan haal je ook niet de efficientie die je verwacht en is het dus helemaal niet goedkoop.

[Mellow Jack]

Hoewel je reactie klopt is het in deze niet echt van toepassing.

Dit specifieke stukje, inrichten VLAN, loadbalancer cq. reverse proxy doe je 1 keer. Het is dus goed mogelijk een product te kopen, laten implementeren zonder dat je beheer club experts hoeven te zijn

[COW_Koetje]

Allemaal leuke kreten maar het zegt niks over security.
Als datzelfde vlan gerouteerd wordt naar een algemener Vlan, de reverse proxy alles toelaat en de LB (die alleen maar HA functionaliteit heeft een geen security toevoegt) verder geen filtering toepast heeft het allemaal geen enkele zin.
Juist het denken in Layers is belangrijk. Zorg ervoor dat er nooit direct toegang is maar segmenteer de lagen en zorg ervoor dat zelfs als iemand kan binnendringen ze niet makkelijk verder kunnen komen met de informatie die ze al hebben. Zorg er ook voor dat je altijd van A naar B en dan pas naar C kan (in plaats van direct mogelijkheden van A naar C) en dan nog blijven dit soort bugs een risico omdat ze simpelweg het mogelijk maken om juist die toegang te configureren op de apperatuur waarvan je denkt dat het je veilig houd.

Out of band netwerken blijven lastig en zullen altijd de zwakke plek zijn van de organisatie, je kan alleen de kans laten afnemen dat ook werkelijk misbruik gemaakt kan worden.

[Il Duce]

Waarom zou ik een dure expert inhuren voor de inrichting als ik het ook door een Indiër kan laten doen voor 5 euro per uur?

[Mellow Jack]

Als je die Indiër kan vertellen wat hij moet doen dan kan dat zeker. Let op, het is voor bepaalde culturen niet makkelijk om te zeggen dat je iets niet snapt

Maar iig, jou vraag, hoe simpel het ook lijkt, is niet heel simpel. Experts in Nederland zijn niet altijd even kundig dus die titel is niet zoveel meer waard. Maar een echte expert zet een goed design neer.... zoals in dit geval een fatsoenlijk lan/vlan ontwerp.

[the_stickie]

Inderdaad. Dit soort devices wordt afaik niet/amper verkocht zonder consultancy en onderhoudscontract.

Wat "expert" betreft: imo is een expert iemand die meer weet over een onderwerp dan jezelf. Iemand die zichzelf expert noemt gaat er compleet aan voorbij dat er héél veel anderen zijn die beter zijn. Als je met de techs zelf praat zal je vaak ook merken dat die expertrol iets is wat ze 'toegedeeld' krijgen... het is een deel van de salespitch. Ik vind die titel dan ook weinig waard.

Wat betreft dat soort design zie ik nooit dat het aan random Indiërs gegeven is. Als er Indiërs betrokken zijn is dat net vaak omdat een grote vendor hen inschakelt.

[Lick_A_Brick]

Ik vraag me dan ook af in hoe verre deze best practice wordt geforceerd door de leverancier.

OT: Hetzelfde geld voor default passwords, veel devices/software forceert je niet om direct je wachtwoord te wijzigen. Sla hem bij de eerste keer inloggen op in je password manager en je ziet de plain-text versie vrijwel nooit terug.

[Nederviking]

Ik vraag me dan ook af in hoe verre deze best practice wordt geforceerd door de leverancier.

Tjah. Als je je als router leverancier gaat bemoeien met wat voor forwards er door end-users in gezet worden van de wan kant naar de lan kant bevind je je ook op een hellend vlak. Als een end user vind dat die managment interface aan het internet moet hangen wat heb je daar concreet tegenin te brengen? Zeker als je het hebt over apparaten op enterprise niveau mag je er wel van uit gaan dat daar een mate van bewustheid achter hangt. En alstie dat op bijvoorbeeld trusted IP basis doet is dat ook niet eens echt een probleem.

Best practices zijn precies dat en geen verplichtingen.

[Reactie gewijzigd door Nederviking op 24 juli 2024 02:48]

[CAPSLOCK2000]

Tjah. Als je je als router leverancier gaat bemoeien met wat voor forwards er door end-users in gezet worden van de wan kant naar de lan kant bevind je je ook op een hellend vlak.

<knip>

Best practices zijn precies dat en geen verplichtingen.

Ik ben het met je eens dat het geen verplichting moet zijn, maar het is niet onredelijk om goede defaults te verwachten, gebruikers helpen om de juiste keuzes te maken en ze te waarschuwen als ze dat niet doen.
Dit is geen beschuldiging dat F5 het niet goed doet, ik ken die apparaten niet goeg genoeg om daar over te oordelen.

[Nederviking]

Ik ben het prima met je eens hoor, maar de persoon waar ik het op reageer heeft het over best practices forceren.
Dat je ergens een rode balk toont ofzo als de firewall onverstandige regels ziet is allicht prima en dat je "sane defaults" mag verwachten ben ik het ook volledig mee eens.

[Reactie gewijzigd door Nederviking op 24 juli 2024 02:48]

[Pietervs]

Zo'n rode balk kan natuurlijk ook weer mensen op het verkeerde been zetten, zeker degenen die minder sterk zijn in hun vak of in hele grote omgevingen: "he, ik zie geen rode balk dus het zal wel goed zijn"... tot blijkt dat ze met die firewall rule verkeer toelaten vanaf het internet naar een VLAN van waaruit er doorgehopt kan worden naar het management-VLAN. Maar geen rode balk, dus geen waarschuwing dat je op die manier je management-VLAN mogelijk open zet voor het internet.

Het blijft uiteindelijk mensenwerk, hoe goed de apparatuur en software ook is. PEBCAK blijft de zwakste schakel in het geheel.

[Z80]

Als standaard de managment interface in een apart netwerk hangt. Je met een kleine moeite de interface aan het lan kan knopen en met moeite aan de wan ben je al van een heleboel problemen af.
De klant kan nog steeds de managment interface aan elke poort naar keuze hangen. Maar moet dit dan wel bewust doen.

[Scriptkid]

Je vergeet dat de WAN pport geen Inet hoeft te zijn,

het is een router de WAN poort jan gewoon een upstream netwerk zijn waarvan jij wel bij je management interface wilt.


De fabrikant heeft daar geen inmenging mee.

[Keypunchie]

Een F5 is echter een net iets andere categorie apparaat dan een thuisroutertje.

Niet dat er geen incompetente IT-afdelingen bestaan, maar zelfs een wat middelmatige beheerder zorgt dat beheerinterfaces niet naar het publieke internet open staan.

Wat niet wil zeggen dat je daarmee veilig bent, want ook op je interne netwerk kan best een bedreiging opduiken, een gecompromitteerde server bijvoorbeeld.

Maar dan kom je wel op de next-level, waarbij er goed is nagedacht over netwerken en veiligheid. (Losse beheernetwerken, met stepping stone servers en interne firewalling/netwerk-segmentering). Dit valt in de praktijk, zelfs bij grote enterprises, nog wel eens tegen. Of er zijn idd. gemakzuchtige keuzes gemaakt.

@Scriptkid
Ik reageer op je opmerking
"Tja dat zelfde geld voor je router ," met een uitleg dat dit *geen* thuisrouter is.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 02:48]

[Scriptkid]

je weet dat je reageert in de tread over thuis routers ? ,

meschien eerst even kijken voordat je reageert.

[OMEGA_ReD]

Bij sommige routers bv Draytek wordt de UI beschikbaar op WAN als je gebruik wilt maken van SSL VPN. Vragen om problemen lijkt me. Weet niet of het bij dit product ook zo kan zijn.

[jurroen]

Persoonlijk vind ik gemakszucht geen legitieme reden. Er valt zeker wat voor te zeggen om core-infra op afstand te kunnen beheren, het kan bijvoorbeeld een ritje naar het datacenter besparen waar het niet strikt noodzakelijk is.

Echter: expose die management interfaces dan niet aan het publieke internet! Zet die in een eigen VLAN en achter een VPN (Wireguard, OpenVPN) met fatsoenlijke access policy. Als er dan een keer noodzaak is, je bent zo op een VPN ingelogd.

Het is (helaas) niet het geval dat je bij de aanschaf van een router, modem, server of andere apparatuur een leaflet krijgt die het belang uitlegt hiervan.

[COW_Koetje]

coulda shoulda woulda
In de praktijk zullen er dienstverleners zijn die toegang geven aan hun klanten aan dit portaal via makkelijker toegankelijke methodes. Tevens en dat is nu het grootste risico zouden besmettingen die er al zijn (en dus intern al op het netwerk zitten en toegang hebben tot de Out of Band netwerken) een aanval kunnen doen waarbij ze nog meer toegang krijgen op andere levels.

Omdat het niet goed te monitoren valt en Out of Band netwerken vaak ook geen virusscanning hebben of al aan de binnenkant van de firewall zitten en console porten zijn is een hack hier niet goed te detecteren en kan nog heel lang toegang geven aan mensen die niet op het netwerk horen te zitten.

Dit is precies de laag waar juist alles meer open moet staan omdat je anders geen beheer kan doen.

[kodak]

Daarom is er ook een best practice om de beveiliging van een beheernetwerk op orde te hebben. Juist omdat er andere beveiliging ontbreekt moet je dus ook andere maatregelen treffen.

Het maakt wel een verschil tussen een 10 als cvss score of een lager cijfer. Dat cijfer 10 is er volgens mij om aan te geven dat het niet ernstiger kan. En dat is onder normale omstandigheden dus wel het geval. Die 10 is dus van toepassing bij een situatie waarbij men de overige beveiliging niet goed genoeg op orde heeft. Natuurlijk wil dat niet zeggen dat het dus heel erg mee valt maar het hangt wel van de omstandigheden af. Het is nogal een verschil of er een kans is dat een paar miljard criminelen je met succes kunnen aanvallen of alleen de criminelen die er meer moeite voor moeten doen (of al gedaan hebben en geduldig zijn).

[COW_Koetje]

In de basis heb je gelijk maar er moet een level of trust zijn met je leverancier.
Op een moment moet je ervanuit kunnen gaan dat de appliance secure is omdat je niet meer beveiligingen kan aanbrengen zonder de werkzaamheden dusdanig te frusteren dat niemand meer kan werken.

Als dit dan uitkomt is dat best even slikken.

De 10 is een combinatie tussen, de mogelijkheid, de eenvoud en de potentie op schade (risico). In dit geval is dus de schade heel hoog, de kans heel hoog en het is te automatiseren dus bijzonder makkelijk uit te voeren op grote schaal. Daarom heeft het de 10 gekregen.

De schade wordt namelijk in dit geval dat dezelfde mensen die je juist buiten je netwerk wil houden nu de mogelijkheid hebben om nog meer toegangspaden te creeeren zonder dat je kan zien dat dit niet mag. En de monitoring te omzeilen c.q. logboeken weg te gooien.

[kodak]

De 10 is een combinatie tussen, de mogelijkheid, de eenvoud en de potentie op schade (risico). In dit geval is dus de schade heel hoog, de kans heel hoog en het is te automatiseren dus bijzonder makkelijk uit te voeren op grote schaal. Daarom heeft het de 10 gekregen.

Wel een combinatie waar overal kennelijk van het ergste is uitgegaan. Het is geen afronding naar boven. Dan is de kans inderdaad hoog. Maar het geeft zo wel een vertekend beeld voor al die bedrijven die wel aan best practice doen, wel aan segmentatie doen, wel rekening houden dat je het goed moet configureren. Het doel van de score is ook om duidelijk te zijn over de omstandigheden en die lees ik helaas niet terug bij deze score. Het lijkt zo gebruikt te worden om maar van het ergste uit te gaan maar dat lijkt me niet het doel van de score en beveiligen.

[COW_Koetje]

Ik denk dat dit ook komt door het verdienmodel van deze bughunters.
Als het je lukt om als eerste zoiets te vinden kan je best veel geld verdienen. Het vinden van security violations is gewoon big money geworden. Buiten de bonus van de concurentie voor het vinden natuurlijk. ;-)

[iRobbery]

Dat is zeker best practice, maar ook dat netwerk is vaak niet hermetisch afgesloten. Ook daar kunnen client PCs compromised worden en vanaf daar dan de big 5 netwerk apparatuur aan te vallen. Het is inderdaad wel een hekje extra voor de hacker/scriptkiddie om over te springen.

[jurroen]

Dit soort apparatuur is niet iets wat je als consument aanschaft voor het thuisnetwerk, maar eerder iets wat binnen grote bedrijven, datacenters etc gebruikt wordt. Best practice is dan: bescherm ook tegen "insider aanvallen". Ik mag hopen dat het lateraal kunnen bewegen binnen een netwerk en tot alle apparatuur kunnen komen eerder uitzondering dan regel is

[Qwerty-273]

Klopt, maar een best practise strookt niet altijd met de praktijk. Het zal niet de eerste keer zijn dat door reorganisaties en andere grote bedrijfsveranderingen dat exclusieve beheernetwerk ook opengezet is naar het standaard productie netwerk (want lastig om elke keer beheerstations uit te rollen, of specifieke stations toe te voegen aan dit netwerk). En door andere veranderingen het gast netwerk ook toegang heeft tot het productie netwerk want dat is handiger tijdens hoog prio stokpaard project van een of andere hoge bobo.

Change management en een duidelijk netwerk design is cruciaal om dat ook op de langere termijn te waarborgen in een organisatie (zeker met vele grotere veranderingen in de organisatie).

[kodak]

Daarom is het ook zo belangrijk om die CVSSv3-score van 10/10 goed te begrijpen. Het is geen kwestie van het is een 10 dus is het heel erg maar het is een 10 afhankelijk van de omstandigheden zoals weten of je werkelijk scheiding in je netwerken hebt en waarom je de beheerders en de software en hardware die ze gebruiken wil vertrouwen.
Voor bedrijf x die door fusies en "besparen" op beheer de best practice niet meer volgt is het dus heel anders dan voor bedrijf y dat genoeg kennis en tijd inzet om dat wel te doen.

Al vermoed ik dat de bedrijven waarvoor het een 10 is waarschijnlijk ook niet snel kunnen patchen en de organisaties waarvoor het geen 10 is daardoor het patchen juist wel beter op orde hebben en het voor hun geen 10/10 zal zijn.

[Reactie gewijzigd door kodak op 24 juli 2024 02:48]

[Douweegbertje]

Niet, maar SSRF (Server Side Request Forgery) is wel degelijk een ding die men vaak vergeet

[kr4t0s]

Bij veel producten(f5, palo alto, fortinet) in AWS/Azure wordt tijdens de installatie management poort aan het internet gehangen. Het is natuurlijk verstandig om hier in elk geval hier een ACL op te zetten en beter nog te managen via VPN of Expressroute.

Maar het is niet alleen management port, ook de self IP's zijn kwetsbaar als het Default profiel op de self IPs staat.

[Reactie gewijzigd door kr4t0s op 24 juli 2024 02:48]

[MuKkEzZz]

Handig om te vermelden: de kwetsbaarheid bevindt zich in de Traffic Management User Interface (TMUI), een interface die als beheer-omgeving conform best practices niet publiek toegankelijk hoort te zijn.

[kr4t0s]

Klopt niet helemaal, ook Self IPs zijn kwetsbaar als port 443 openstaat, die staat open als het Default profiel op de Self IP staat.

[Reactie gewijzigd door kr4t0s op 24 juli 2024 02:48]

[kodak]

Een self ip is een mogelijkheid om je netwerkverkeer te scheiden. Dat je daarmee ook een management interface toegankelijk kan maken wil niet zeggen dat je de scheiding tussen gewoon verkeer en beheer dus goed toepast. Ik lees niet dat die self ip de kwetsbaarheid is, dus moet een beheerder waarschijnlijk de keuze hebben gemaakt om zowel gewoon verkeer als beheer via die self ip te verwerken. Dat klinkt niet als best practice.

[kr4t0s]

Als je geen Virtual servers met port 443 in dat subnet geconfigureerd hebt zal de web GUI laden op het Self IP, dit is standaard gedrag. Om het te voorkomen kun je Self IP Port Lockdown op None zetten. Moet je natuurlijk niet op de high availability interfaces doen dan maak je de HA stuk.

[MuKkEzZz]

Je hebt gelijk:

"For an attacker to exploit the vulnerability described in K52145254 they would need to be able to access the Web GUI on the F5. This would include the management interface if it has access from the Internet. It will also include Self IP addresses that have a port lockdown setting that allows access to port TCP/443."

[TijsZonderH]

Goede toevoeging! Ik ken de software zelf niet dus ik dacht dat TMUI gewoon de standaard UI was waar je op kon inloggen en het klonk nogal duh om dat er specifiek bij te vermelden, maar nu ik het zo lees is dat inderdaad nuttig om erbij te zetten.

[kodak]

De CVSSv3-score van 10/10 lijkt me daarbij ook een journalistieke opmerking waard of die wel klopt. Het gaat bij die score namelijk ook heel sterk om de omstandigheden om op de hoogste waarde uit te komen. Er lijkt bij het bepalen geen rekening te zijn gehouden dat je een beheerinterface niet zomaar via internet bereikbaar moet hebben. Doe je dat wel dan kom je pas op 10 uit. Die 10/10 is dus in het meest ongunstige geval.

[R4gnax]

Er lijkt bij het bepalen geen rekening te zijn gehouden dat je een beheerinterface niet zomaar via internet bereikbaar moet hebben. Doe je dat wel dan kom je pas op 10 uit. Die 10/10 is dus in het meest ongunstige geval.

Als die beheer-interface op een groot corporate intranet bereikbaar is, dan is het even goed een 10/10 - vanuit willekeurig elk apparaat op het netwerk kan met de laagste permissies mogelijk in principe alsnog zo'n aanval ingezet worden.

BYOD laptop of telefoon en je kunt al de sjaak zijn.

Dit kun je natuurlijk vermijden door de remote beheer infrastructuur netjes in afgescheiden VLANs onder te brengen, en dat is ook sowieso de juiste practice, maar dat zal jammergenoeg lang niet overal het geval zijn.

[Reactie gewijzigd door R4gnax op 24 juli 2024 02:48]

[kodak]

Dan past de beheerder de best practice van scheiden van netwerken niet goed toe. Ook een groot beheernetwerk hoort scheiding te kennen. Het netwerken scheiden gaat namelijk niet alleen om het scheiden van gewoon verkeer en beheer maar om compartimenten maken als verdediging.

[ViTO_xp]

Het lijkt me eveneens niet de bedoeling dat de standaard (beheer) UI van (netwerk)apparatuur publiekelijk toegankelijk zou moeten zijn...

[DigitalExorcist]

Jij bent vast erg gezellig op feestjes.

https://www.vandale.nl/gr.../nederlands/betekenis/duh

[Reactie gewijzigd door DigitalExorcist op 24 juli 2024 02:48]

[Janbraam]

Mijn opmerking slaat nergens op, dus -1 snap ik.

Dat "duh" is kritiek op de stijl (niet mijn stijl en ik ben best wel streng hoe ik taal wil uitvoeren.. Uiteindelijk een zinloze discussie... Voorbeeld is "beter als" of "nooit niet"... tenenkrommend als je het mij vraagt..

Oh en als ik maar genoeg vodka (ofzo) heb gehad, word ik vanzelf lollig.. en misschien zelfs lastig... :-D

[6Pac]

Nee is een Amerikaans product.
Daar zitten standaard al de nodige achterdeurtjes in de code
Veel succes om alle Nederlandse banken ervan te overtuigen deze loadbalancers uit hun netwerk te halen.

https://en.wikipedia.org/wiki/F5_Networks

[Reactie gewijzigd door 6Pac op 24 juli 2024 02:48]

[Vorkie]

https://research.nccgroup...e-2020-5902-intelligence/

Nog een leuke tijdslijn van 5 Juli.

[DJMaze]

Komt wel overeen met mijn fail2ban logs.
Vondt het al vreemd gisteren, en kwam er dus gisteren achter wat de impact is.

[FireDrunk]

Druk aan het patchen! Gelukkig zit het lek in de Management Interface, dus als je die niet publiekelijk open hebt staan voor de hele wereld, is het risico beperkt(er).

[Verwijderd]

Met Shodan kun je vinden of je device publiekelijk te benaderen is met de volgende query:

http.title:BIG-IP&reg:-Redirect

[xjs678qr]

Het is niet omdat het niet publiek toegankelijk is, dat je het niet moet fix'n.

Opgelet: zelfs met de workaround kan iemand die legitiem toegang heeft tot de box, de vulnerability nog steeds exploiteren (bvb gebruikers met guest of auditor rechten!)

[Mathijs1]

Er staat ook al een metasploit module klaar om opgenomen te worden in die tool:
https://github.com/rapid7...bc1e2b8ccb5b4e84281242845

Mocht de complexity nog niet op Low staan in je eigen advisories dan maakt dit het zeker wel erg eenvoudig om te exploiten.

[Simkin]

Krijg al gerelateerde scans binnen:

2020/07/07 08:10:17 [error] 9710#9710: *8811 open() "/etc/nginx/html/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp" failed (2: No such file or directory), client: 145.220.24.19, server: xxx.eu, request: "GET /tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd HTTP/1.1", host: "xxx"

2020/07/07 08:57:39 [error] 9710#9710: *8842 open() "/etc/nginx/html/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp" failed (2: No such file or directory), client: 145.220.25.6, server: xxx.eu, request: "GET /tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd HTTP/1.1", host: "xxx"