How to secure the default apache karaf installation

1
votes

Following Christian Schneider's blog post, How to hack into any default apache karaf installation, I checked to see if my default Karaf installation (4.0.5) is insecure:

Some simple steps to check if your karaf installations is open.

  • Check the "etc/org.apache.karaf.shell.cfg" for the attribute sshPort. Note this port number. By default it is 8101
  • Do "ssh -p 8101 karaf@localhost". Like expected it will ask for a password. This may also be dangerous if you do not change the default password but is quite obvious.
  • Now just do bin/client -a 8101. You will get a shell without supplying a password. If this works then your server is vulnerable

As expected. It is vulnerable. So I tried to secure it following the instructions as described:

How to secure your server?

  • Simply remove the public key of the karaf user in the "etc/keys.properties". Unfortunately this will stop the bin/client command from working.
  • Also make sure you change the password of the karaf user in "etc/users.properties".

I shut down the Karaf server using the halt command. Then I changed the karaf password in etc/users.properties and deleted the file etc/keys.properties. Then I started the server again with bin/karaf. Then in a new terminal I tested to see if the installation was secure by trying to ssh into the server. I validated that ssh login now requires the newly configured password. Finally, I tried using the bin/client -a 8101 command.

At this point, as explained in the blog post, I expected the command to fail:

Unfortunately this will stop the bin/client command from working.

I noticed after running bin/client -a 8101 there is a new file etc/host.key that either bin/client or the container itself auto generated. Rather than failing the command succeeded and I was presented with the Karaf console.

Does this means the container is still vulnerable to this attack vector?

1
securityssh-keysapache-karaf
I noticed a down-vote with a vote to close this question. Please explain the purpose for the down-vote in a comment. - axiopisty
Not the one who down-voted you, but I think you mean to ask: "How to secure... instead of how to hack...? - Makketronix
best to ask on the Karaf mailinglist, I'm sure you'll get a much more detailed answer there ... - Achim Nierbeck

1 Answers

0
votes

No.

The modifications described in the OP (changing the default password in etc/users.properties and deleting etc/keys.properties) secures the container from that specific attack vector.

According to the discussion on the Karaf users mailing list concerning this stack overflow question:

By default bin/client tries (in this order) to use:

  1. etc/keys.properties

  2. etc/users.properties

  3. karaf/karaf

  4. -u to prompt for the password

bin/client is an SSH client (written in Java). The host.key is the same file as for SSH and containing the trusted hosts (you also have .sshkaraf/known_hosts for that).

The section quoted from the blog in the OP is out dated:

Unfortunately this will stop the bin/client command from working.