0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Benutzeravatar
shv
Beiträge: 60
Registriert: Sa 10. Nov 2018, 17:36

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von shv »

@Mijzelf,

Do you think it is possible to use weblogin.cgi from new fw5 firmware on fw4 devices?

-shv

Mijzelf
Beiträge: 92
Registriert: Mi 14. Nov 2018, 19:50

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von Mijzelf »

Nope. It's compiled for Armv7:

Code: Alles auswählen

root@NSA325:/lib# ln -s ld-linux.so.3 ld-linux-armhf.so.3
admin@NSA325:/tmp$ ./weblogin.cgi 
./weblogin.cgi: /usr/lib/libpam.so.0: no version information available (required by ./weblogin.cgi)
Illegal instruction

Benutzeravatar
shv
Beiträge: 60
Registriert: Sa 10. Nov 2018, 17:36

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von shv »

Zyxel wrote that the following characters can not be used for passwords anymore:

!  #  $  %  &  (  -  | 

Which characters are filtered by your patch and can therefor not be used for passwords?


Mijzelf
Beiträge: 92
Registriert: Mi 14. Nov 2018, 19:50

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von Mijzelf »

There are 2 cases, http GET and http POST. In case of GET all arguments have to be encoded in the URL, something like

Code: Alles auswählen

http://nas/adv,/cgi-bin/weblogin.cgi?username=admin%27%3Becho%20/usr/local/apache/web_framework/%5C%5C%3E%20%2Ftmp%2F1.sh+%23&password=x
In case of GET I've filtered away all % before the decoding, which boils down to every special character.

As far as I could find GET is not actually used to access weblogin.cgi, only POST

For POST the payload doesn't have to be encoded. There I filter away % (you still can use URL encoding), ; | $. & is implicitly filtered away, as it's the argument seperator.

I found the vulnerability can be exploited these ways:

Code: Alles auswählen

username=admin'; payload 
username=admin' | payload 
username=admin' > $( payload )
username=admin' < $( payload )
The first way executes simply two commands, some so far unknown executable with argument admin, and payload. The second pipes the output of the unknown executable to payload, the third and forth execute payload, to use the string formed by it's stdout as filename to pipe the output of unknown executable to, or pipe it's input from.
This will cause an error, of course, but meanwhile payload is executed.
I think I covered all these ways to exploit. If someone finds a way to still trigger the bug, let me know.
shv hat geschrieben:
So 22. Mär 2020, 13:54
Zyxel wrote that the following characters can not be used for passwords anymore:

! # $ % & ( - |
I have asked ZyXEL about ! ( - , as I don't see how these can be used. (The ( in combination with $ is a problem, but not ( alone.) Their answer was more or less that they had reconsidered it, and didn't see it too. In next firmware these characters will be allowed again. The forbidden characters will be:

Code: Alles auswählen

\: 0x5C 
": 0x22
$: 0x24
&: 0x26
’: 0x27
`: 0x60
<: 0x3C
>: 0x3E
^: 0x5E
It's remarkable that % nor | is in this list. Of course they can filter after URL decoding. And the % is no problem in the Linux command line AFAICS. But | is. Of course that is no problem when you can't end the argument in which the payload is embedded.

Keep in mind that this list also contains characters which can't be used for other reasons.

Benutzeravatar
shv
Beiträge: 60
Registriert: Sa 10. Nov 2018, 17:36

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von shv »

I asked from the user point of view. Which characters in someones current password will prevent to login after your patch was activated? This is still not clear to me. The user should know such restrictions to change the password if necessary. Will a password be rejected if the user tries to use such characters while changing a password after your patch was activated?

Mijzelf
Beiträge: 92
Registriert: Mi 14. Nov 2018, 19:50

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von Mijzelf »

Assuming that I'm right that http GET is not used, the patch filters away % ; | $ &.

Make sure your password (or username) doesn't contain any of these characters before applying the patch. The filtering is silent, you won't get any notice that an illegal characters is used, the backend just gets the password without the filtered characters, and will reject access.

Benutzeravatar
shv
Beiträge: 60
Registriert: Sa 10. Nov 2018, 17:36

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von shv »

I just tested the behavior of NAS542: V5.21(ABAG.4)B1_20200220.

Created account:
User: test
Pass: test% (no message about usage of vorbidden characters, account was nevertheless created)

Test login:
U: test P: test% (username or password is wrong)
U: test P: test (username or password is wrong)

Possibly Zyxel replaces forbidden characters with something or filters more than just one character.

Mijzelf
Beiträge: 92
Registriert: Mi 14. Nov 2018, 19:50

Re: 0day Exploit in Zyxel Network Storage Devices CVE-2020-9054

Beitrag von Mijzelf »

shv hat geschrieben:
Di 24. Mär 2020, 20:15
Possibly Zyxel replaces forbidden characters with something or filters more than just one character.
No. The problem is that the filter is only implemented on weblogin.cgi. I think that is only used when logging in on the webinterface. It's not used by samba or ssh login.
The filter is not implemented in the 'change password' webpage. So you actually changed the password to test%, and now you are not able to login because weblogin.cgi filters % and passes only 'test' to the underlying login mechanism, which doesn't match test%, and so you can't login.

In next firmware release the change password dialog will reject those characters:
https://homeforum.zyxel.com/discussion/ ... mment_8527

Antworten