Client Side Attacks – Not A New Phenomena
Bob’s been around the block a few times. He’s seen it all and the resurgence in client side attacks comes as no surprise. Attacking the client and person sitting in the chair are a time honoured way of rooting boxes. And it’s not just browsers and Adobe products that are susceptible. So here is a tale from long ago which goes to show why you shouldn’t taunt Bob unless you don’t mind having it handed to you on a plate.
The Bet
“My machine is hacker proof!” beamed Dominic, brimming with pride that he had connected his Debian box to his home DSL line. “I’ve applied all of the patches and no one is getting in.” Bob of course takes this as a direct challenge and soon a wager is set up that Bob cannot hack said server. Bob had a wider view of information security and finding remote exploits for a patched server wasn’t high on his list of how to crack this nut. Sure enough a few days later Dominic confronts Bob with a flushed face with anger. “My web server has been defaced! How did you get in?” he cried.
Always practice safe X
Instead of going straight for the server Bob concentrated on attacking the client side of remote access, which he knew would be weaker and easier to exploit. Both Bob and Dom were Unix administrators for a large firm and to display graphical programs like xterm on their workstations they used an X server for windows. X does provide a means of limiting which clients can access; of course real men tunnel X over ssh. Lazy administrators won’t and will simply permit any client to access the server. Displaying arbitrary crap on someone’s screen does provide some amusement but the sinister and often overlooked consequence of a permissive X servers is that it allows keystroke logging. All Bob has to do was connect to Dom’s workstation and wait for him to log into his server.
Shared servers are evil, no?
Dominic of course cried foul. The wager was clearly not won since Bob hadn’t “hacked” his server and the challenge still stood. So Bob tried again. One short shell script later and Bob had a trojan ssh command which he placed in Dominic’s PATH on shared server which he used to access his Debian server. When run it paused for a second, prompted for an SSH password, paused once more and started the real ssh client with the same parameters it had been passed. As well as writing the password to a file it deleted the trojan script and fixed the PATH variable in Dom’d .bashrc to cover it’s tracks. Most people won’t question why they’ve been prompted for a password twice since entering a typo is so common. The same defacement occurred and Dom’s pride was hurt all over again. Bob really, really hoped that Dominic had learned some valuable lessons in operational security, but then Bob is an optimist.
The moral of this tale?
What are you going to take home from this? Pride comes before a fall? Don’t tease the tiger? How about be nice and don’t harass your colleagues by hacking their server even if they challenge you to? What happened here was basically a pen test where the rules of engagement were not agreed upon from the start. The client called out the tester because they used dirty tricks to get to the prize. Noses can easily get put out of joint if you try to be clever or brag about your conquests, but isn’t that part of the fun of being Bob?
Categorised as: Stories