lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 31 Aug 2020 14:58:44 -0500
From: Ryan Delaney <>
Subject: [FD] Sagemcom router insecure deserialization > privilege escalation

# Exploit Title: Sagemcom router insecure deserialization > privilege
# Date: 08-31-2020
# Exploit Author: Ryan Delaney
# Author Contact: ryan.delaney () owasp org
# Author LinkedIn:
# Vendor Homepage:
# Software Link: N/A (F@ST 5280 firmware not published)
# Version: F@ST 5280 router, F/W 1.150.61, possibly others
# Tested on: F@ST 5280 router, F/W 1.150.61
# CVE: CVE-2020-24034

1. Description

Sagemcom F@ST 5280 routers using firmware version 1.150.61,
and possibly others, have an insecure deserialization vulnerability
that allows any authenticated user to perform a privilege escalation
to any other user. By making a request with valid sess_id, nonce,
and ha1 values inside of the serialized session cookie, an attacker may
alter the user value inside of this cookie, and assume the role and
permissions of the user specified. By assuming the role of the user
'internal', which is inaccessible to end users by default, the attacker
gains the permissions of the 'internal' account, which includes the
ability to flash custom firmware to the router, allowing the attacker
to achieve a complete compromise.

Note that the 'internal' account is disabled and hidden by default, and the
primary administrative account ('admin'), lacks the permission to
flash custom firmware to the device, meaning that an attacker
exploiting this vulnerability obtains access exceeding that of
the legitimate, authorized system administrator.

2. Proof of Concept

Log in as a valid user (default is admin:admin). Retrieve the 'session'
cookie. Simply change the only occurrence of the string "admin" within
the cookie to "internal", and make a new request with this modified cookie.
If you decode the cookie, you will note this is the 4th key value pair
inside of the cookie, where the key is "user", and the value is "admin".

3. Solution

This vulnerability is only exploitable with a valid existing session.
Changing the administrative password to a strong, non-default value,
and ensuring that TLS certificate has the correct fingerprint will
help prevent attackers from obtaining a valid existing session.


Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists