Rapid7 vindt nieuwe kwetsbaarheid in eerder misbruikte Ivanti-tool MobileIron

Ivanti heeft een nieuwe, ernstige authenticatieomzeilingskwetsbaarheid erkend in MobileIron Core. Die software bleek onlangs al lek te zijn, waardoor Noorse ministeries werden gehackt. Nu is er een nieuwe bug gevonden, maar daar komt geen patch voor omdat het oude versies treft.

De kwetsbaarheid wordt getrackt als CVE-2023-35082. Die werd ontdekt door beveiligingsonderzoekers van Rapid7 toen die onderzoek deden naar het eerdere lek in MobileIron. Rapid7 geeft weinig details over de bug. Het enige dat daarover bekend is, is dat het gaat om een authenticatieomzeiling die van een afstand kan worden ingezet. In een aparte blogpost zegt Ivanti dat dat mogelijk is om op afstand te doen, op machines die openbaar vanaf internet bereikbaar zijn.

Ivanti zegt dat het de kwetsbaarheid niet gaat repareren, omdat dat niet nodig is. De bug, die een CVSS-score van 10 krijgt, zit in versie 11.2 en lager van MobileIron Core. Die versie krijgt sinds 15 maart vorig jaar al geen updates meer. In plaats daarvan is er een nieuwe versie van de software beschikbaar, die vorig jaar werd omgedoopt naar Ivanti Endpoint Manager Mobile. Daarin zit de kwetsbaarheid niet.

Het is de tweede keer in korte tijd dat er een kwetsbaarheid wordt gevonden in MobileIron Core, een tool waarmee telefoons kunnen worden beheerd. De vorige keer dat dat gebeurde was eind juli in een spraakmakende zaak. Toen erkende de Noorse overheid gehackt te zijn via een bug in MobileIron. Die bug was een zeroday waar inmiddels wel een patch voor is. Het is tot dusver niet bekend of deze nieuwe kwetsbaarheid ook eerder is misbruikt. Het is deze bug die Rapid7 onderzocht toen het de nieuwe bug vond.

Update: In de lead stond aanvankelijk dat er een patch beschikbaar is, maar dat is niet het geval omdat het een oude versie betreft.

Reacties (23)

[MiesvanderLippe]

Dat gebeurt wel vaker met dit soort tools. Als eenmaal bekend is dat er zo'n grove programmeerfout in zit, is het interessant om verder te zoeken. Met zoveel extra ogen zie je nog eens wat...

[MrMonkE]

Ook als het net in het nieuws geweest is met een grote hack zoals recent dmv exploits in deze software.
Maar iedereen is er natuurlijk opgedoken. The good, the bad and the MrMonkE.

[Bor]

MobileIron Core 11.2 has been out of support since March 15, 2022. Therefore, Ivanti will not be issuing a patch or any other remediations to address this vulnerability in 11.2 or earlier versions.

Wie deze oude versie draait mag zich achter de oren krabben en meer inzetten op patch management. De versie ik kwestie is al tijden out of support. Het lek is in de opvolgende versie volgens Ivanti niet aanwezig gezien het daar min of meer per ongeluk werd opgelost.

The vulnerability was incidentally resolved in MobileIron Core 11.3 as part of work on a product bug. It had not previously been identified as a vulnerability.

[Reactie gewijzigd door Bor op 25 juli 2024 09:53]

[RobinJ1995]

Uit de blogpost van mijn werkgever (Rapid7) --

According to CISA’s advisory, the vulnerability allows a remote unauthenticated attacker to access personally identifiable information (PII) and add an administrator account on the affected EPMM server, to allow for further system compromise.

Het klinkt dus wel degelijk redelijk serieus. Leuk dat het "end of life" software is, maar hoeveel bedrijven maken hier nog gebruik van?
Het erge is dat het er vooral op lijkt dat werknemers van bedrijven die (persoonlijke of werk) telefoons van werknemers hiermee beheren risico lopen, niet zozeer de interne infrastructuur van bedrijven zelf.

De CVE biedt ook erg specifieke informatie over hoe het lek werkt, en het lijkt echt heel erg makkelijk te misbruiken: https://attackerkb.com/topics/8vqyuSfHRq/cve-2023-35078

If an attacker sends a request to an API endpoint such as /mifs/aad/api/v2/ping, then the API can be called successfully without authentication.

It appears that the aaddispatcher servlet processes the request, which disables the security filter chain from processing any more filters and no authentication is performed. For reasons currently unknown, the request is then serviced by the servlet that handles API requests (CXFServlet).

[Reactie gewijzigd door RobinJ1995 op 25 juli 2024 09:53]

[himlims_]

is er een manier om te verifiëren of je kwetsbaar bent?

voor de vorige bug; https://github.com/securekomodo/citrixInspector

[Reactie gewijzigd door himlims_ op 25 juli 2024 09:53]

[Bor]

Je linked naar een tool om een niet gerelateerde citrix netscaler kwetsbaarheid te controleren
Dat is niet 'de vorige bug' dus.

Controleren of je kwetsbaar bent is het simpelste door naar de geïnstalleerde versie te kijken. Zit je lager dan het vereiste patch niveau dan ben je kwetsbaar. Voor de rest kan je kijken of de servers via het internet bereikbaar zijn. Hiervoor is geen "tool" nodig.

[Reactie gewijzigd door Bor op 25 juli 2024 09:53]

[Jerie]

Zo'n tool (Python scriptje) automatiseert het. Check de code, bovenaan staan hashes en versienummers. Dat zijn er nogal wat om handmatig te checken.

https://github.com/secure...ve_2023_3519_inspector.py

Doorgaans doe je dit dmv de advisory, CVE, of patch note van de vendor. Het lijkt mij eigenlijk vooral de bedoeling van zo'n tool om massaal servers te checken. En dan denk ik eigenlijk toch vooral aan kwaadaardige bedoelingen. Dan neig ik er naar het met je eens te zijn over het nut van een dergelijke tool.

[killercow]

door naar het versienummer te kijken, of een van de ondertussen ruim beschikbare Proof of concept's te proberen.
Zie ook: https://github.com/minvws...rdination/pull/1528/files voor de version check op de 'gefixte' issue cve-2023-35078

[Reactie gewijzigd door killercow op 25 juli 2024 09:53]

[Bor]

Met openbare proof of concept zou ik voorzichtig zijn en niet zo maar alles proberen uit elke willekeurige bron. Soms doen "tooltjes" meer dan gewenst / verwacht.

[killercow]

MinVWS, je kent ze wel, dat nederlandse ministerie

[Bor]

Ik ken OpenKAT natuurlijk (daar valt nog wel wat winst te behalen uit het oogpunt van gebruiiksvriendeljjkheid). Je had het in jouw reactie over meerdere proof of concepts wat fetelijk iets anders is dan een check of iets kwetsbaar is (namelijk demonstreren dat misbruik mogelijk is). Dat insinueert ook meerdere bronnen. Ik adviseer om welke bron en welke code dan ook eerst goed zelf te controleren om zeker te zijn dat er geen vervelende bijwerkingen zijn.

[GoBieN-Be]

Je link is voor een kwetsbaarheid in Citrix Gateway/Netscaler, heeft niks te zien met deze of de vorige Ivanti bug.

[JustFogMaxi]

Ivanti is samenraapsel van opgekochte tools/bedrijven, wat een zooi is dat zeg.

[SunnieNL]

Microsoft is ook een samenraapsel van opgekochte tools/bedrijven. Citrix, Google en VMware ook. En zo kan ik nog wel even doorgaan. In alle producten van die vendors' zitten ook security problemen en bugs. Zeker als je naar producten gaat kijken die al meer dan een jaar EOL zijn.
Dus die bedrijven zijn ook allemaal een zooi?

In theorie zou niemand last mogen hebben van deze bug. Je gaat immers geen EOL producten meer gebruiken in je productie omgeving. Daar zit geen support meer op. De "zooi" zou ik dan ook liever laten slaan op de mensen die hun producten niet updaten. Zeker als die producten een groot deel van hun clients beheren.

[Frame164]

Ieder IT landschap is een samenraapsel van verschillende tools, en van verschillende leveranciers.

[mutsje]

Sinds Ivanti begonnen is met opkopen van bijvoorbeeld Res en Mobile Iron is support ook down the drain gegaan. Zal mij voor bijvoorbeeld RES benieuwen hoelang support nog in Den Bosch zit , met MI idem dito. Hoelang voordat support compleet naar India gemoved is en men masaal overstapt naar andere producten.
Andere bedrijven doen het ook maar supporten dan ook beter zeg maar.

[Dennisb1]

Dus je vind in een EOL product (al ruim een jaar) een lek, tja...
Daarom is het blijven updaten van je kritische software ook zo belangrijk...

Die zal je vast in WinXP ook onwijs veel gaan vinden.

Vervelend blijft het natuurlijk wel.

[Reactie gewijzigd door Dennisb1 op 25 juli 2024 09:53]

[Frame164]

Ik zag pas ergens een leuk plaatje metcijfers over vulnerabilities. Conclusie was dat als je veilig wilt zijn je gemiddeld maximaal 8 maanden oude software moet gebruiken. Iets wat we gevoelgsmatig allemaal weten maar in dat plaatje was het met echte cijfers onderbouwd.

[CAPSLOCK2000]

Ik zag pas ergens een leuk plaatje metcijfers over vulnerabilities. Conclusie was dat als je veilig wilt zijn je gemiddeld maximaal 8 maanden oude software moet gebruiken. Iets wat we gevoelgsmatig allemaal weten maar in dat plaatje was het met echte cijfers onderbouwd.

Kun je dat toelichten, zoals het er nu staat vind ik het een beetje verwarrend. Ik neem aan dat je niet bedoelt dat als je 1 systeem van 70 maanden oud neemt en 7 systemen van 1 maand dat je dan goed zit omdat je software gemiddeld 8 maanden oud is

Ik neem aan je bedoelt dat op het moment van release er veel fouten worden gevonden in nieuwe software, het dan afneemt met een minimum na 8 maanden waarna het aantal bekende fouten weer begint te stijgen (terwijl de leverancier waarschijnlijk werkt aan de volgende versie)?

Ik zit al een tijd op de trein dat je gewoon altijd de nieuwste versie wil draaien en zo snel mogelijk. Misschien is dat niet het beste voor security en stabiliteit op zeer korte termijn maar wel op de wat langere termijn. Systemen en problemen worden namelijk steeds moeilijker als ze ouder worden. Een bug gefixed krijgen in een nieuwe release lukt nog wel maar na 5 jaar is het een stuk lastiger.
Je weet nooit waar onverwachte problemen optreden waardoor een systeem niet tijdig vervangen kan worden. Zorg er daarom voor dat systemen tip top in orde zijn op het moment dat je ontdekt dat je niet meer (tijdig) kan onderhouden of vervangen. Dan heb je nog tijd om een andere oplossing te zoeken voor je zonder support komt te zitten, of met zo'n oude versie moet werken dat support je niet goed meer kan helpen. Ook als je zou willen overstappen naar een ander product dan gaat dat typisch beter als je de migratie kan beginnen met iets moderns.

(Doelbewust) Releases overslaan is in mijn ogen dan ook uit den boze, dan moet je bij het volgende onderhoud een dubbele stap nemen en heb je twee keer zo veel kans dat het mislukt. Als het mislukt heb je eigenlijk geen marge meer over om naar een andere oplossing te zoeken.

Het ligt natuurlijk wel een beetje aan het soort software en het releaseschema en de omstandigheden van de applicatei. Sommige applicaties komen iedere maand met een nieuwe versie en anderen maar eens in de 3 jaar. Niettemin blijft het streven om zo nieuw mogelijk te draaien. Met hartbewaking gaan we anders om dan met een slimme stofzuiger.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 09:53]

[Bor]

Of dit klopt hangt natuurlijk compleet af van de bronnen waarop dit gebaseerd is en hoe oud de data is. Doorgaans is bijblijven de beste optie ipv te vertrouwen op oudere software. De kans op het ontdekken van lekken neemt namelijk ook toe met het verstrijken van tijd.

[CAPSLOCK2000]

Dus je vind in een EOL product (al ruim een jaar) een lek, tja...

Voor aanvallers is het leuk om te weten dat het gat niet meer gepatched zal worden, het product is immers EOL.

[Dennisb1]

Zou mij niks verbazen als dit als zeroday al tijden bekend was en ze nu balen dat het uitgelekt is.