Chapter 15: Sybase: Moving Further into the Network

This chapter is largely focused on attack, and covers the techniques the attacker can use to move deeper into the network, having compromised the Sybase server. It also covers a few obvious techniques for ensuring that access to a Sybase server is retained once it has been gained , via the insertion of simple backdoors and similar.

Accessing the Network

An attacker wishing to access external database servers from within Sybase has several options. First, as you saw in a previous chapter, you could just use JSQL to write a client for the desired protocol yourself. This is the most flexible approach, but probably not the easiest to use.

Sybase allows you to run queries on remote servers via a number of system stored procedures. You can add servers via the sp_addserver stored procedure, and configure them via sp_serveroption. Once the method that will be used to access the remote server has been specified, you can use a variety of commands ”create proxy_table, create existing table, create existing procedure, and so on ”to access data and execute procedures on the remote host. The disadvantage of using this technique to connect to other databases is that it requires sa_role or sso_role privileges. One significant advantage is that Sybase allows you to connect to other database systems, for example, IBM DB2.

Another method, again covered briefly in the previous chapter, is to use Sybase to proxy TCP connections and traffic for you, using JSQL to perform the network interaction. In this scenario, attackers would be able to use their own client software (for example, their DB2 client) to connect to a server within the Sybase server's network. The downside of this approach is that it can be somewhat unreliable; JSQL support for TCP is a little limited and not terribly friendly.