Log4j - Log4Shell Critical 10/10 vulnerbility 11

[jallen2020]

Hey everyone, just wanted to let you know that the IP Office (onex specifically) is vulnerable to the Log4Shell vuln that is being actively exploited in the wild. You need to upgrade you Log4j versions immediately or your clients will get hacked.

If onex is internet facing, the system is vulnerable

https://www.wired.com/story/log4j-flaw-hacking-internet/

 

[Karli1000]

Has anyone closed the vulnerability in their system yet and can briefly describe how they did it? Especially for the Session Border Controller, this would probably be quite important. Unfortunately, at the moment I can only find the statement from Avaya that the SBC is affected, but no solution for it yet.

 

[gwebster]

I would expect that there is a lot of furious testing being done at the moment. You will then see mitigation measures posted.

 

[Karli1000]

There was a hotfix for the SBC today. However, there has been no indication that this hotfix closes the gap. Unfortunately, I have not found a way to check this myself.

 

[jallen2020]

For one-x I was able to verify vulnerability in this manner:

Below is the web tester that Huntress has provided free of charge.

You can access the tool here:

https://log4shell.huntress.com/

To test a onex system, visit the huntress link, and take the provided sample payload, plug it into the login fields in One-X and submit the login.

If the system is susceptible, the entries will show up on the huntress "results" page.

 

[Richard10d]

Using

https://log4shell.huntress.com/

I found one system with 11.0.4.6 was vulnerable.
I found one system with 11.0.4.3 was not vulnerable.

Searching the file system I did not find log4j-api-2.12.1.jar on the 11.0.4.3 but did find it on the 11.0.4.6. Both systems use One-X Portal

 

[Karli1000]

I can confirm that One-X Portal version 11.0.4.6 is affected by the vulnerability. Unfortunately, I have not been able to detect this in any other version. In addition, I was not able to verify the vulnerability in the Session Border Controller. According to Avaya this is affected.

 

[Nafetz]

I am a customer looking for solutions and hoping to get an update before being hacked.
There is list of Avaya products that are already confirmed to be affected of the vulnerability:

https://support.avaya.com/helpcenter/getGenericDetails?detailId=1399839287609

The session border controller is confirmed in this list. But no fix available as it seems at the moment.

 

[JayNEC]

Its possible that the SBC is only affected on the management interface and not the internet facing SIP interface.

New England Communications

http://www.necomm.com

 

[Okkie26]

My question is.

I see that IP Office platform is affected. But is this SE only or also IPO500(v2)?

And what about the UC module? I don't see that one mentioned.

 

[jallen2020]

For the SBC, yes it could be the management interface, but I'm also wondering if you craft a sip request using sipvicious or nmap with the payload as the domain of the invite request, if you could get it to run the payload that way, since all the bad requests are logged. Will try to test this at some point today, or maybe someone else can get to it first?

 

[nnaarrnn]

is this SE only or also IPO500(v2)?

Both. This is a Java vulnerability.

 

[PrimeABTech]

If a customer has an SCN across multi sites, would there be an risk there? I can't see it, but I also asked our Avaya Partner Manager but it sounds like they are not fully sure what this all encompasses.

Is it only for One X or Equinox clients that are coming in outside the firewall? If everything is sitting behind a firewall, is there any risk.

I am just struggling to understand this risk, on what can happen....

Wouldnt the security team just scan for the Java with the issue and replace that? I can't see how Java can be active inside the IPO?

Thanks

 

[Albus2]

Regarding IPO it is not IPO itself, but One-X Portal.
As long as One-X Portal is not used or at least not made available from public, you are safe.

No issue with 500v2 as it doesn't run such tools.

Unclear about ABSCE. As others already mentioned, it is maybe only the management interface. Or nothing accessible at all.

 

[derfloh]

On ASBCE it is probably also the reverse proxy…

Nevertheless… the bad guys are working on a work that needs only a single contact from public - might be a non Avaya device of the customer. After it’s infiltration it will be spread around within the local network. So you’re NOT safe even if IPO and it’s related services are not public facing.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[jallen2020]

I couldn't get the ASBCE to trigger on a SIP request, so it seems that functionality is safe.

Here was the nmap string I used (you will have to insert the specific payload you are using from the link I gave at the top of the page:

nmap -sU -p 5060 --script sip-call-spoof --script-args "sip-call-spoof.src='<payload>', sip-call-spoof.extension='<payload>', sip-call-spoof.ua='<payload>', sip-call-spoof.from='<payload>'"

It definitely could be the proxy too...will test that using a modded UA string and see if I get anything back.

 

[jallen2020]

Proxy test also came back clean. I set

X-Forwarded-For
User-Agent
X-Forwarded-Host

All to the payload and didn't get any hits when grabbing or attempting to grab files through the proxy.

Also, tried the same for management interface and no results. Could just be the versions of ASBCE I'm testing on aren't vulnerable.

 

[JayNEC]

lots of updates now to the "Remediation required?" column.

SBCE 8.0.1 are YES
8.0 and below are NO

IP Office 11.0.4 and above are the only ones that are YES now

New England Communications

http://www.necomm.com

 

[derfloh]

Check that article:

https://nakedsecurity-sophos-com.cd...nerability-how-to-safeguard-your-servers/amp/

The SBC is able to look up within LDAP Directories for valid MAC addresses or for a Routing decision.

Probably a Hotfix will follow soon and we should apply it.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[Albus2]

There is now PSN020554u for ASBCE 8.1.2 and 8.1.3 available:

https://download.avaya.com/css/public/documents/101079394

ASBCE 7.x and earlier is not impacted by this vulnerability, hence no action needed on ASBCE version 7.x or earlier.

ASBCE versions 8.0, 8.0.1, 8.1.0, and 8.1.1 will need to upgrade to 8.1.2 or 8.1.3 with the latest hotfix and then apply the specific
log4j hotfix mentioned below to mitigate the problem.

For ASBCE version 8.1.2
Make sure hotfix-5 (i.e. sbce-8.1.2.0-37-21246-hotfix-09282021.tar.gz) or higher is installed on the system.
Then install the hotfix sbce-8.1.2.0-37-21444-hotfix-12142021-log4jFix.tar.gz to address the CVE-2021-44228.

For ASBCE version 8.1.3
Make sure hotfix-1 (i.e. sbce-8.1.3.0-38-21245-hotfix-09242021.tar.gz) or higher is installed on the system.
Then install the hotfix sbce-8.1.3.0-38-21444-hotfix-12142021-log4jFix.tar.gz to address the CVE-2021-44228.