Oracle waarschuwt voor bug in WebLogic Server dat actief wordt aangevallen

Oracle waarschuwt dat een lek in WebLogic Server dat inmiddels gepatcht is actief wordt misbruikt. Door het lek uit te buiten is het mogelijk om bijvoorbeeld cryptomalware of ransomware uit te rollen op een server.

Oracle waarschuwt in een patch-update dat WebLogic-servers actief worden aangevallen. Het is niet bekend om hoeveel aanvallen het gaat en op wat voor soort servers die worden uitgevoerd. Wereldwijd zijn er tienduizenden servers die de software draaien.

Oracle heeft halverwege april een patch doorgevoerd. Die was onder meer voor kwetsbaarheid CVE-2020-2883. Die kwetsbaarheid zat in versies 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 en 12.2.1.4.0 van de WebLogic Server. Oracle repareerde het lek, dat een kwetsbaarheidscore van 9,8 op een schaal tot 10 kreeg, nadat Trend Micro dat had ontdekt. Veel serverbeheerders hebben de patch dus nog niet doorgevoerd. Inmiddels staat wel een proof of concept van de bug online.

Aanvallers kunnen het lek uitbuiten door een geïnfecteerde payload via Oracles eigen T3-protocol te sturen. De aanval vindt plaats op het moment dat de server de payload uitpakt. Volgens Oracle is geen interactie van de gebruiker nodig om het lek uit te buiten. Daardoor kunnen hackers een systeem overnemen.

Oracle waarschuwt dat het lek kan worden misbruikt om malware te versturen, zoals ransomware of cryptojackers. Omdat er geen gebruikersinteractie nodig is zou het ook mogelijk zijn om dergelijke servers geautomatiseerd in botnets op te nemen.

WebLogic Server is in het verleden vaker aangevallen. Oracle waarschuwt bedrijven hun software zo snel mogelijk up-to-date te brengen.

Reacties (16)

Op ons werk worden de weblogic-instanties zovaak gepatched dat mensen er bijna een fulltime job aan hebben. Ook slaan we regelmatig de integrale testen van onze eigen software over, behalve een simpele smoke-test. Dat was een aantal jaren geleden ondenkbaar.

Maar het begint onderhand wel een blamage te worden, omdat mijn inziens de lekken meestal in de proprietary delen van het oude Oracle zitten. De verbinding naar Oracle DB, en nu weer T3, dat ook weblogic only is, en niet in de orginele J(2)EE-spec zit.

Teveel en te snel te mooi gemaakt om er enorme bedragen mee te kunnen vragen, en dan ook nog de 35-jarige history meeslepen is niet ideaal.

@Bene Ok, erg interessant over T3, en de 'oude' serialisatiemogelijkheden. Dat is inderdaad een java-mogelijkheid die er al jaren inzit, en er echt niet zomaar uit kan.
Natuurlijk moet een Weblogic-omgeving ingekapseld draaien. Ik zeg ook niet dat dat niet gebeurt, maar we vertrouwen in principe niets, dus moet alles zsm gepatched worden, ook om te voorkomen dat een indringer op een ander niveau nog iets met ongepatchte omgevingen kan, onafhankelijk van de positie. Uitgangspunt is dat systemen zoveel mogelijke veilig zijn.

Een ander deel van mijn frustratie van de laatste opmerking zit vooral in de enorme licentiebedragen voor zowel Weblogic als zeker ook de database, maar ze kunnen het niet zodanig veilig maken dat het niet wekelijks gepatched moet worden.

[Reactie gewijzigd door koppie op 1 mei 2020 20:42]

Een ander deel van mijn frustratie van de laatste opmerking zit vooral in de enorme licentiebedragen voor zowel Weblogic als zeker ook de database, maar ze kunnen het niet zodanig veilig maken dat het niet wekelijks gepatched moet worden.

WebLogic wordt eens per kwartaal gepatched, net als bijna alle andere Oracle producten.

Dit is een java deserialisatie probleem, niet een T3 bug. We krijgen al drie jaar lang dezelfde exploit met iedere patch een andere chain toegegooid. Dat blijft doorgaan totdat de huidige serialisatie klassen uit java (of WebLogic) zijn geschreven wat een enorm probleem gaat geven met compatibiliteit.

Wat je kunt doen is zorgen dat er geen ongeautoriseerde toegang meer mogelijk is tot je naakte WebLogic servers. Met een proxy server ervoor ben je al klaar. Dan hoef je ook niet meer zo hard te patchen. Dat advies staat ook in elk Oracle whitepaper over WebLogic inrichting.

[Reactie gewijzigd door Bene op 1 mei 2020 23:22]

Het is geen Java deserialisatie probleem. Standaard serialisatie was niet gemaakt voor public communicatie, alleen voor trusted peers. En dan voornamelijk eigenlijk local-only.
Maar zoals zo veel technologie worden zaken vaak gebruikt op plekken waar het oorspronkelijk niet voor gemaakt was, en dan komen er opeens nieuwe zaken bij kijken.
CVE-2015-6420 is al bijna 5 jaar geleden. Als je nu nog steeds Java deserialisatie security issues hebt in je software is het echt geen Java deserialisatie probleem.

Dat de gekozen oplossing niet geschikt was voor de implementatie wil natuurlijk niet zeggen dat de problemen van die oplossing niet mee tellen. Het is hier onmogelijk dat het een bestaat zonder het ander. Dat het na verloop van tijd nog zo is zorgt er niet spontaan voor dat een van de onderdelen van het probleem niet meer mee zou tellen. Er komen eerder problemen bij. Bijvoorbeeld omdat na verloop van tijd steeds duidelijker lijkt te worden dat een bedrijf er geen grip op krijgt om deze risicovolle combinaties te onderkennen, dat tijdig te doen en het ook nog eens goed te verhelpen.

Maar wie is er nu dom genoeg om een Weblogic server rechtstreeks aan het net te hangen?
Ik werkte ooit met Weblogic 5 en ben er in meer of mindere mate mee bezig geweest tot Weblogic 11 en heb echt nooit de illusie gehad dat je dit rechtstreeks aan het internet zou moeten willen knopen.
Altijd een proxy er voor hangen en simpel weg de server er achter alleen met de proxy laten communiceren.
Toen was het een Apache server nu waarschijnlijk een nginx maar het concept blijft het zelfde een proxy op die basis is veel meer een standaard oplossing er zijn letterlijk miljoenen servers die die software draaien. En dus zijn er veel meer aanvallen geweest en bugs gepatched dan bij een closed source relatief weinig gebruikte oplossing zo als Weblogic. Omdat het overgrote deel van de wereld zijn webservers draait op een Apahe/nginx server is de beveiliging gewoon beter op te zetten om die simpele reden.

Maar daarnaast waarom draaien mensen nog Weblogic of een andere j2ee server tegenwoordig? Zo'n 20 jaar geleden ja hot en happening en zo, maar vandaag de dag? Ik kan me niet helemaal voorstellen dat er echt nog voordelen zijn te vinden om zo'n ultra bloated stuk middleware vertraging te gebruiken om je applicatie nog even trager te maken dan het al is.

Heeft iemand kunnen kijken of WebCenter Sites ook geraakt is, of heeft die T3 niet aan boord?
Ik loop dood op een maintenance pagina wanneer ik de details wil bekijken.

https://i.postimg.cc/G2SG9SKg/image.png

Maar het begint onderhand wel een blamage te worden, omdat mijn inziens de lekken meestal in de proprietary delen van het oude Oracle zitten.

Laat Oracle het Open Source maken; dan kunnen honderden programmeerliefhebbers zien wat er allemaal lek is in het systeem. Uiteraard voor een vergoeding, als ze iets vinden.

[Reactie gewijzigd door kimborntobewild op 3 mei 2020 18:17]

Ja, goed idee! Maar dat gaat helemaal tegen het idee van Oracle in. Dit itt bijvoorbeeld IBM/Red Hat.

...maar ze kunnen het niet zodanig veilig maken dat het niet wekelijks gepatched moet worden.

Je zou je af kunnen vragen of je dan niet op zoek moet naar betrouwbaardere software... Je zou je zelfs kunnen afvragen of je wel voldoet aan AVG/GPDR, als je software gebruikt waarvan je weet dat er vaak lekken in worden gevonden. (Maar ja, dan zou je Windows ook niet kunnen gebruiken...)

Een van de eerste dingen die ik op mijn opleiding leerde bij web connected applicaties programmeren is dat je de client z'n request, en andersom de server z'n antwoord, moet valideren en standaard niet moet vertrouwen.
Dat vertrouwen lijkt hier wel aanwezig te zijn.

Maar dan nog iets over het artikel: ik vind het nogal rommelig geschreven en soms niet kloppend: zie bijvoorbeeld de zin "Veel serverbeheerders hebben de bug dus nog niet doorgevoerd."

lol.. mooie ja... admins die bugs gaan doorvoeren, maw implementeren. Bugfix zou logische zin maken.

paar jaar terug hadden we ook weblogic die exploited werd en bitcoin miners werden geinstalleerd. Alleen door proxies konden ze er geen kont mee. leuk als annekdote

paar jaar terug hadden we ook weblogic die exploited werd en bitcoin miners werden geinstalleerd. Alleen door proxies konden ze er geen kont mee. leuk als annekdote

Hmm... maar de criminelen hadden dus wel toegang tot jullie systemen? Ze konden immers programma's (miners) installeren. Is er een rebuild van de server gedaan? En zijn de kosten daarvan gedeclareerd bij Oracle?

We zijn hard van weblogic weggerend. Willen ook graag van oracle DB wegmigreren, maar dat is wat minder makkelijk dan java naar springboot apps migreren momenteel

Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 45