theguly (51)

see cve-2020-10220

see cve-2020-10220

see cve-2020-10220

see cve-2020-10220

quick assessment to add references:
good write up the vulnerability https://www.synacktiv.com/posts/pentest/how-to-exploit-liferay-cve-2020-7961-quick-journey-to-poc.html
working PoC https://github.com/mzer0one/CVE-2020-7961-POC

there is not so much to add here because synacktiv already explained what’s interesting: a preauth RCE on a commonly used in enterprise and internet faced framework. a framework NOT updated on regularly basis.

plus, based on my very own experience, liferay/tomcat on windows let you mostly land as SYSTEM. with an install base, according to shodan, of more than the half on windows, this is a very interesting vuln to exploit

not a real assessment, just a note: sudoers here is a mess, you can achieve LPE through at least other three GTFOBINS.

i love these type of vulnerabilities because they chain three findings normally considered low/medium to take over a full infrastructure.

we have:

1. a web page that doesn’t check user session ( commands.inc.php doesn’t have the if (!$session->logged_in) check and therefore no auth required upon access )
   
2. a trivial unescaped GET parameter used in a sql query in that page, therefore unauth sql injection
   
3. plaintext storage by default, therefore profit
   

rConfig has access to network devices, and of course credentials (both standard and privileged) are kept in her database.
what makes this attack even more useful, is that by default rConfig doesn’t encrypt data so this sql injection will grant an attacker the plaintext of every juicy information about network infrastructure monitored by this tool: ip, username, password, eventual privileged ones, full configuration.

since version 3.8.0 it’s possible to encrypt just passwords: http://help.rconfig.com/settings/mainsettings
so point 3) is partially solved. in this case, an attacker will try to read files using sql injection, if user has FILE grants, to decrypt passwords and get loot anyway.

plus, the webapp uses PDO which supports stacked queries. public exploits (https://www.exploit-db.com/exploits/48261) abuses this to execute INSERT statement adding new administrator, giving the chance to have RCE by chaining this CVE to CVE-2019-19509 (RCE) and LPE to root with CVE-2019-19585.

as a bonus, we could chain this sqli to CVE-2020-10221 to get RCE: even if strong password are enforced (classes/usersession.class.php line 338), users’ passwords are hashed using md5. a bruteforce is not that easy but way easier than against passwords hashed using modern algorithm.

despite the age of this vuln, we still find vulnerable Alfresco, therefore it’s worth a quick assessment to me.

having tried to exploit /proxy?endpoint i think there is no known way to execute a “useful” attack.

endpoint parameter can be abused to only do GET, so to achieve a write against an internal endpoint you should first have to find something that accepts modification using GET. possible, but uncommon.
HTML for the requested endpoint will be sent back to the attacker, and this could be a useful information, but mostly info disclosure. again depends on what’s in internal network, still possible but uncommon to find really juicy stuff.

plus, if my skills in reading java code are good enough, a quick code review in source code revealed that just http and https protocols are supported by calling Classe. no file:// or something can be used to achieve, say, LFI.

still useful to map internal network or dirty other servers’ log, and to collect information, but this vuln has a quite limited value to me.

after having spent some time trying to traverse webroot, i feel like saying that it’s “unlikely” that ajp will let you read file through the filesystem, because of how tomcat segregates the environment.
i’d love being proven wrong.

having file upload on the docroot, as other said, it’s possible to achieve RCE quite easily.
(un)fortunately, the file can be anything, even a valid image with the classic code-append like we all did in php. given this behaviour, it’s trivial to bypass upload filters.

on 29th of january 2020 this github[1] repo came up, with some newsfeed, speakin about a RCE via deserialization on Liferay 6.0.2

i’m aware that liferay is widely used to build both internal and internet-facing webapp, and a possible preauth RCE would be awesome.

actually i don’t remember which post i read first, because github repo doesn’t speak about any version, but i’m sure i’ve read somewhere 6.0.2: also exploit-db speaks about 6.0.2, if my memory plays tricks on me, i’m not alone.

from the very low info we see at said github repo, we understand that the vulnerability is at /api/liferay which is NOT present in 6.0.2, nor on the filesystem neither on configuration as route.

testing a more recent version, i saw that 6.1 branch actually has /api/liferay but by default it’s limited to “localhost”.
it could be possible to open it to more IPs of course, but i don’t see it happen so frequently to have a 0.0.0.0 as trusted host.

i think this vulnerability doesn’t affect 6.0 branch, it could affect 6.1 branch but not on default configuration.
plus, it’s not yet clear if this is pre-auth or post-auth.
i’ll dig newer branches as soon as i can.

p.s.: exploitability is rated against a possible 6.1, and the fact that ysoserial makes java deserialization quite easy.

[1] https://github.com/chakadev/Liferay-CE-Portal-Java-Deserialization

20200329 edit:
lowering value, adding required auth

as stated on CVE details, this vulnerability let an attacker to bypass authentication on AMT and reach web panel as admin.

at first glance this vulnerability looks not that useful, because – at least from my tests – by bypassing authentication you can:

• reboot/shutdown/poweron the host
  
• boot from alternative devices, for example PXE
  
• other “useless” stuff
  

and if in theory running a live system to access original host filesystem to exfiltrate hashes/data could be awesome, i’ve seen no engagement where you can actually reboot a box without heavy issue from the owner. because AMT works also when the host is shutdown, it could be interesting to poweron an inactive host and take full control of it, but we have another options:
(un)fortunately, AMT also let a user to access using KVM, so an attacker can use (or leech at) a running interactive session.

the bypass is very easy, just specify response=“” in Authorization header, and can also be automated on any intercepting proxy like burp or zap, so you could route all your traffic to burp and have the auth bypass

what i’ve tested so far are this blog post, to setup a KVM connection from linux:
https://www.cyberciti.biz/faq/remotely-access-intel-amt-kvm-linux-desktop/
and this awesome opensource client:
https://www.meshcommander.com/meshcommander

unfortunately, engagement’s time didn’t let me to finish my test.

for a quick vulnerability check:
https://www.exploit-db.com/exploits/43385

CVE here doesn’t show the real impact of this vulnerability and also the data is partial/misleading.

Axis2 version 1.6.2 let an attacker to read files on local filesystem. admin password is written in plaintext in a XML configuration file.
chaining this two easy vulnerabilities, an attacker is able to login as admin to Axis2 and to deploy a new webservice to achieve remote code execution.

things get worse beause we mostly find Axis2 internet-faced

to retrieve the config file an attacker can just exploit the LFI in a very basic way:
GET /axis2/services/Version?xsd=../conf/axis2.xml
then scrolling down to read username/password parameters

with given credentials, axis2_deployer (https://www.rapid7.com/db/modules/exploit/multi/http/axis2_deployer) from metasploit will let him to deploy a meterpreter session

disclaimer: CVE owner here.

because of what opmanager needs to operate, a successful exploitation will give an attacker very often privileges access to lot of network device and system.
this lead to lot of lateral movement and juicy owning.

i didn’t have the chance to test on later version, but given vendors reply i think also recent one are vulnerable.

p.s.: i’m rating exploitability as medium because an attacker has to exploit another sql injection vulnerability to dump the database. even if opmanager has a poor security history, this vulnerability by itself isn’t straightforwardly exploitable.

just to add the exploit and proper tag
https://github.com/Ridter/cve-2020-0688

this product runs as SYSTEM by default, and the exploit is quite reliable (thanks sinn3r), therefore when found this will be an easy win.
not so common nowdays but still present on some old setup.

plus, as far as i saw this product was in place just because of a default installation.
hoply, this will be discontinued with windows7 EOS.

jboss is widely used in enterprise, and we sometimes found it internet exposed.
there are ready to use exploit and scanner ( https://github.com/joaomatosf/jexboss ) that let an attacker to blindly abuse this.

(un)fortunately, jboss by default runs as limited user, therefore LPE is needed to get root.

note: CVE owner here.

this vulnerability doesn’t have so much value today because the product has been discontinued and aerohive has been acquired. all MSP are now moving to extreme cloud platform.