Replace expert password on SMB Appliance

[KennyManrique]

Hi everyone,

Some time ago a customer requested changes at expert level for compliance purposes. The thing was that since the locally managed SMB device (1140) was inherited from another administrator, the expert password was unknown. Tried a ton of usual passwords for the organization, none of them worked.

After a fast search on SK, I landed on sk106025 and read the following statement:

That was a little bit dissapointing, because I still was able to access as web gui admin and perform many administrator operations. So I decided to find a way to gain expert access without having to factory default the device and reconfigure all parameters from scratch (maybe my lazziness was the main cause of this haha).

So, moving on. On Web GUI, I generated a backup as usual. This is so important since all the required configurations are contained on this file. Also previous experience from backup restore on different smb hardware, reminded me that all the time expert password was replaced for the one contained on backup.

Opening the backup I found the following files:

According to sk106025 expert_pass_ file contains the MD5 expert password hash, as expert it can be deleted so the system will ask again for a new password. Also there is the shadow file, that contains MD5 hashed credentials for all users; the web admin among of them (notice the last line was added by me to explain the segments):

One interesting fact when extracted the ZIP backup on a Windows computer was the following message:

I opened the ZIP file as text to verify, and found the following:

Some metadata is added to the ZIP file, I presume that is to identify the device and proceed with restore. Because of this, I needed to undrestand how backups are generated. I can't only modify the contents under windows since the metadata will be missing after recompression.

After some digging on Internet, I found a 2016 blog entry by John Fleming where he does a great analysis of backup routine using strace. This gave me the necessary flags to recreate the file using any linux distro with ZIP support. So started a live usb image of Parrot linux (you can use whatever you want). The first thing I did was to check the comment for the previously generated backup and found that not all data is added as comment:

At backup creation, this comment is generated by /pfrm2.0/bin/backup_settings.sh execution, adding the relevant info for the appliance:

So copied the backup to a new directory and unzipped:

Once all files were extraced, procedeed to edit expert_pass_ file using vim. The unknown expert password hashed data was located here, I replaced it with the information of web gui admin from shadow file (only $1$SALT$HASH is needed):

Zipped a new file named backup.zip using the flags -ry (recursive - include sym links only where is necessary) and -z at the end to add the same comment extracted some steps ago:

The new generated ZIP backup contains almost exactly the same information at the end of the payload. Using echo, I added the final information (maybe this step is not necessary, I didn't test the restore up to this point) EDIT: After downloading a backup through SCP noticed this information doesn't exists; it's only added when the backup is obtained through a web browser. Used -n flag to avoid a line jump at the end, so it matches the original format:

Changed the name back to original to match the CP format:

Finally changed file permissions as the original backup (777):

Backup was uploaded and restored to appliance sucessfully:

Finally I got expert access with same password as web gui admin user:

All configurations (policy, vpn, filtering, etc) worked perfectly!!!

[G_W_Albrecht]

Yeah ! That is the spirit i love 😎 !!!

[KennyManrique]

😄😄

It should work up to R77.20.XX versions. Still not tried on R80.20.XX since I don't have the hardware.

[G_W_Albrecht]

It seems that the file structure is identical and we have expert_pass_ here also:

So it should work for R80.20.xx also...

[KennyManrique]

It's good to know! 😃

[HristoGrigorov]

Excellent hack I must say. Thanx for sharing it.

However, I find this as a potential security issue. Tampering with backup files for security devices should not be possible. They must at least be signed. Something CheckPoint should think about...

[KennyManrique]

That's right, it can be considered as security issue because the modification of sensitive information. Maybe administrators should document the SHA2 hash of the file itself after the backup generation and manually verify at restore that is not a modified file. This until CP propose new backup procedures to avoid tampering.

Luckily for my case, there was no other checks than zip's comment. 

[PhoneBoy]

Impressed you worked that out.
Thanks for sharing!

[KennyManrique]

You're welcome!

[John_Fleming]

w00t! I remember finding backup info in the comments and thinking that was an interesting abuse of comments. 

[KennyManrique]

It was there for a reason haha! On my very first test, without comments, the file was recognized as "Invalid backup".

BTW, thank you for the blog post!