Spoofing a Spectrum Protect server

[Trident]

Hi,

Possible to spoof a tsm server?

In an enviromnet with tsm server TSMA on ip 1.2.3.4, and a client runs happily here. Then a bad dude sets up a new tsm server with the same servername but on ip 7.8.9.10. He has access to the client, and creates an identical node with the same password on the new server. Lastly he creates a entry in the local host file and redirect DNS for TSMA to the new IP 7.8.9.10, and restarts the scheduler.

Is there a mechanisme that will detect this on the client side? OR will it send data as usual?

Does anyone know what happens during a tsm login session. I know you need node_name and password, but in the stored registry key, does it also verify the actual server?

I know that SSL can be used to prevent this, but is there a build in check too?

-= Trident =-

 

[moon-buddy]

Trident,

I like your scenario but will that happen? Most likely not.

Building a TSM server inside one's network is not a trivial task - it requires group effort:

- DNS changes
- IP address allocation
- cabling
- etc

Putting a spoofing TSM server on a network is not easy, and most likely next to impossible.

Now for the question: what local mechanism can you use? Password access prompt maybe the way to go plus hard coding the TSM IP address instead of using the DNS name.

What you should really be afraid of is Ransomware: the virus/worm is passed on from the node to the TSM server.

 

[Trident]

Security audit can reveal the most amazing theories

I know all parts must be lined up (access/nodename/password/....)
And as long as you can modify the local /etc/hosts file, then server can be located 'anywhere'.

I was hoping the server guid or a smiliar values was part of the nodename/password cookie. If all three does not match, then notify user.

 

[marclant]

You can actually test that if you create another TSM Server instance elsewhere temporarily.

 

[moon-buddy]

I have actually tested this - the nodes connected and ran backups to the new TSM server even if the new TSM Server is on 7.1.7 while the old one was on 6.3.5.1. The DNS entry of the new server=DNS entry of the old server after the switch. Of course, a full backup of all systems ran. Also, all nodes were registered first on the new TSM server and all backup schedules setup.

The settings to note on the client side:

- passwordaccess=generate
- tcpserveraddress=<dns_name_of_TSM_server>

Even if the TSM Server is set to "closed registration", it would not matter.

 

[Trident]

Hi,

A small follow up. A pmr has been opened about this. 31891,001,806

-= Trident =-

 

[marclant]

Check this:

 

[marclant]

He has access to the client,

So the "bad dude" has physical access to the building.

creates an identical node with the same password on the new server.

That same "bad dude" must also already know the node password in order to be able create a node with the same password.

Conclusion:
That "bad dude" can only be one of your co-workers.

 

[Trident]

Hi,

In the enviroment where this was evaluated, it can not happen, unless you control all aspects of network, hosts, firewalls, usermanagement etc... But, the role of a security auditer does not take the entire picture into concideration. They look into one part at the time, and ask questions. And, that was the question that I got. Is it possible to connect to another tsm server without the client knowing about it?

An the answer to this is yes. The client does not verify the server with anything else than nodename and password.

In this case we can work happily with this missing feature of verification. But, I can see the requirement for a better client-server authentication and verification. How many people uses a random password for each client registration? How many do change the node password every day/week/month? Do clients have full access to internet, or is all traffic firewalled both directions?

Security becomes more and more detailed, and Spectrum Protect needs to have focus on this too.

-= Trident =-

 

[hogmaster]

Hi.
use SSL. availabel since 5.5
http://www.ibm.com/support/knowledg...e.hv/t_ve_hv_cfg_mountgui_secure_ss_cert.html
/hogmaster

 

[Trident]

Hi.
use SSL. availabel since 5.5
http://www.ibm.com/support/knowledg...e.hv/t_ve_hv_cfg_mountgui_secure_ss_cert.html
/hogmaster

When I think about it,I am not sure that SSL will help out. In this case, we assume that a evil person has access. An import of the 'spoofed' tsm server public key is not that hard. Not sure how the login part with SSL works. Is it per node_name, or per node. My guess is that even with a valid node_name and password (and the imported public key from a spoofed server), the node will be able to connect to the wrong server.

Wrt the pmr, logs has been sendt to IBM, so I am awaitng their respons.

-= Trident =-

 

[hogmaster]

Hi.
You ned the private key from the tsm server, this key must be copied to the "bad" tsm server.
So keep your tsm server secure, and a password on the keystore. If you also add the dnsname and ip adresses of the server to the private key it is even harder to move it to rouge tsm server and get it to work.

During a "normal" login the client will login to the server by using its password and id, the server will repsond with its "tsm server name", the client wil verify if this matches the stored value before proceeding.

 

[Trident]

Hi,

I have just tested. Got two tsm servers A & B. Both with SSL enabled on port 1510.

Imported SSL public key from both servers to the client. Logon with dsmc to server A with node and password

Exported reg key for:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\TEST1\A]
"Password"=hex:03,5d,88,7b,32,e8,0a

And imported it for server B with these settings.

[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\TEST1\B]
"Password"=hex:03,5d,88,7b,32,e8,0a

As you can see, the password hex key is the same.

Once this is in, I can connect to B without any verification other than node_name password combo. Even with SSL enabled. SSL is only for trafic, and is not used for authentication purposes. It will need a valid public key, which you have since you have configured it.

And i agree that this is a very special case. And the probability for this to happen is close to zero.

-= Trident =-