Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86373430

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

There is no check for name field in metadata.gz. By assigning a maliciously crafted string like ../../../../../any/where to the field, an attacker can create an arbitrary file out of the directory of the gem, or even replace an existing file with a malicious file.

Proof of Concept 1: Create a file anywhere

This PoC attempts to create a file /tmp/malicious-0/BOOOOM.

1) Download the attached file malicious.gem.
2) Run gem install malicious.gem --no-doc.
3) /tmp/malicious-0/BOOOOM should be created.

malicious.gem assigns ../../../../../../../../../../tmp/malicious as name field. This attack is relatively weak since the path must include a directory named <name>-<version>, such as malicious-0. Still, there are many chances that cause a catastrophe. For example, think of replacing a file in /etc/dbus-1/.

Proof of Concept 2: Replace rackup command

This PoC attempts to replace gems/rack-2.0.3/bin/rackup with a malicious file.

1) Download the attached file replace-rackup.gem.
2) Run gem install rack -v 2.0.3.
3) Run gem install replace-rackup.gem --no-doc.
4) Run rackup. It will emit just BOOOOM!.

replace-rackup.gem assigns ../gems/rack as name field, and contains a malicious file bin/rackup. This is really exploitable for attackers.

Note

For how to create the malicious gems, see the attached file src.tar.gz.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42611.zip