 The following video was recorded live at the conference and produced by the Sound of Knowledge Incorporated. To welcome to the annual DEF CON connection, this meeting was held in exciting Las Vegas, Nevada from July 9th through the 11th, 1999. This is video tape number 9, Hacking Warfare 101. First off, there's my email address if anybody wants copies of these slides, just send me an email. First a usual disclaimer. And then because of my professional affiliations, my absolutely necessary disclaimer. I'm not saying God can use this information for any kind of illegal purposes. Okay, what is Oracle? Oracle is a relational database management system. Database provides a transparent interface between the storage of data and the representation of data. And Oracle is a very widely used database. It's very prevalent in the industry. What's the value of attending this presentation? One is that, like I said, Oracle is widely used. If you get some Oracle expertise, you can go out and make some money with it. And you can apply the knowledge around here for some good things. Oracle uses standard query language to get database. Here's some Oracle SQL tools. SQL is probably the most widely used. It's basically a shell to do standard query language commands. The forms is an Oracle application. The port writer is a query front end data query tool. SQL menu also is an application front end for menu applications. SQL loader will load data from system files into the database. SQL net is the TCP IP communications protocol used to communicate in client server fashion. SQL DBA is an administration tool. Here's a few other Oracle tools. Basically, these are case tools, the first two to help develop applications. And the last ones are newer reporting utility. Here's current programming languages that can be used to create batch jobs or application code for Oracle applications. Basically, it's each of these languages with a compiler that will let you embed SQL commands into that language, into that compiler. This is the way Oracle stores data in tables. Here's a sample table. These are columns, SSN, last name, first name. These are rows within the table and any single data element within a column within a row is called the record. If you're on an OS and you want to know if they have Oracle on that OS, here are some ways you can determine if Oracle is present on that system. Unix lists the processes and grep anything with ORA in it. In VS, under Interactive System Productivity Facility, there should be an Oracle option. In VMS, you list the processes and on NT, there'll be an Oracle option under programs and it will also be running as a service. In order to access the database, you have to have a few things. You have to have your path set up to where you can access the Oracle executables. You also have to be pointing to the system ID of the database. Oracle databases are named with system IDs and it's just basically a generic naming standard. You can name it DB01, DB02, DB03. You just have to be pointing to the valid database in order to access it. And you need a valid user ID with connect privileges. In order to identify valid environment variables, you could check the INI files to see what databases have been loaded on that system. And the environment variables, the path in the SID will be in those files. And in VS, it's in sys1.proclib, in VMS, INI files, and NT INI files. The types of user IDs that exist in an Oracle database. DBA, database administrator, basically can do anything they want. This is the God ID with an Oracle. A privileged user is a user that has been granted specific privileges to data elements within the database. And an unprivileged user can be a user ID that's been created but has been given no privileges that can access anything that's been granted to public. Within Oracle, some system elements and sometimes data elements are granted to public, which means any user ID can access it. So you don't need specific permissions if it's been granted to public. Oracle uses several different types of authentication options. One is authenticated by the operating system. If you have a valid user ID in the operating system, you can get into the database. Another is a standard user ID and password stored in the database. And two more X509 certificates and smart cards, which are newer options. With operating system authentication, this is probably the most widely used authentication due to lack of password management within the database. And what happens in this case is you have a valid operating system user ID and in the database you have the same ID that has a prefix of OPS dollar sign. And that's the default. It can be something different, but that's pretty much 99% of the time that's the prefix. So if you've signed on to the operating system, you type SQL plus to try and get into the SQL shell. And when it prompts you for a user ID, you just put slash and it lets you into the database. So what does that mean? If you can become a user on the operating system that has a valid database user ID and they're using OS authentication, you're in the database. No additional authentication required. If you're doing some type of penetration testing or certification and accreditation testing, you should check out some user IDs that are on the OS that look like they're Oracle application users to see if you can get to that ID and then get to the database. Another way is to look for IDs that are in the DBA group because if you can get to one of those IDs and get into the database, you're now God of the database. The user ID and password authentication. This is pretty much used for client server environments. The user IDs can be from render 30 characters. It cannot be mes, but it can be a space. Password to stored does encrypt it in the database. And basically when you log in, it will encrypt the password value that you enter and match it up against the stored value in the database. The big problem with this is that the does key to do this crypto is not well secured. So if you access that key, you can pretty much crack all the passwords in the database. User ID and password authentication. Every Oracle implementation has three default user IDs and passwords. Anytime an Oracle database is installed, these IDs and passwords exist. The first one is sys, the password is change uninstall. The second one is system, the password is manager. And like I said, if you're doing certification and accreditation testing, these are things you should try. And the third is scott, password is tiger. That's basically an unprivileged user ID, but it's always there. But if you're a security person and you're installing, or someone's installed a database, you should go change these passwords, obviously. Sys is the only ID that can start, stop, or tune the database. But system or any other ID that has the DBA row granted to it can do anything in the database except start, stop, or tune it. The X5 or 9 certificate authentication. The newest version of Oracle is Oracle 8. It's been around for about a year now. They have a separate security server that's an option with the database. And with it, you can use X5 or 9 certificates to authenticate yourself to the security server and then to the database. The smart card is the same thing. If you're doing certification and accreditation testing of a database, on most implementations, any user in the DBA group can run the SQL DBA utility and type the words connect internal and be logged in as sys. And use of the SQL DBA utility should be locked on Oracle implementations, but it's usually not. And it won't work on NT because NT handles groups differently than Unix and VMS and MVS. It doesn't recognize group privileges the same way. Okay, once you're in the database, how do you access the data? You must have specific granted access to the tables or views of the tables. Within Oracle, you can limit access to a table to certain data elements within the table through use of views. So once you're in the database, you have to have these table privileges granted to you to get to the data. Table privileges can be given on a table by table basis. Lots of tables can be grouped into what's called a row and then that row can be granted to the user. And only the owner of the table can grant access to the table. Or a user ID that has been granted access to the table by the owner with grant authority. So they can re-grant permissions once they've been granted permissions. That's not typically done. Like I said before, the access views can provide granularity of record level access. You can limit it just to specific rows or specific columns or specific records within a row, within a column. And all users and player SQL in some way to retrieve and present data. Also besides the database data being in the database, it's obviously in the OS files. And those OS files may not always be well protected. If you find the OS files and they're readable, a lot of the data will be gibberish because of the format it's starting. But there will be normal readable clear text data in those OS files. So it's not always necessary to get into the database to look at the data. All core sub-directories have names like those listed here. And like I said, access and data this way is not going to restrict you to certain rows or columns or records within the database. Here are some all core system privileges rules. You must connect to any user ID that has to log onto the database. Connect as a rule within Oracle. If you grant the resource rule to a user, that will allow them to create, manage or drop database resources such as tables within your schema, which means under their user ID. And DBA is a rule which allows users to do just about anything they want to do within the database. Within Oracle, Oracle 7 and 8 came out with some other granular rules to further limit access to system resources. So you have some granularity where you don't have to make a DBA or just a normal user. You can just give them only the privileges they need to do their job. But before Oracle 7, these were pretty much the only system rules that existed. Any and all system privileges can be granted by any user with the DBA privilege. So if you want to grant a system privilege to a user, if you're a DBA you can grant any system privilege. You cannot grant system privileges to a non-DBA with grant authority. Auditing within the database. Auditing in Oracle can be turned globally on or off by modifying the INI files for the database. This is going to require a restart to actually get the database to start or stop logging. However, DBA can turn on or off auditing within the database by issuing commands and it would not require a database restart for that change to take effect. The DBA can set granular or global auditing parameters. And basically I'm going to get into some commands later that specify the different types of auditing that a DBA can do within the database. All audit records are sent to the sys.aud$sign system table. Any DBA can access those audit records not through querying the table itself but through querying views that have been created to point to that table. The sysaud$ table must be backed up to regular tables and cleared periodically. And the reason why is right here. If the sysaud$ table grows to 50,000 records, the database basically stops running. And if you audit every successful read of an Oracle table, you're going to reach that limit pretty fast. Oracle password management. Other than the fact that you have to have a password to access the database, all Oracle versions prior to version 8 have no password management features. What does that mean? That means that a user can establish a password of a space, a run, or an A, or anything. They can establish passwords that match their names or user IDs. Passwords will never expire and accounts will never be locked within any version of Oracle prior to 8. Most people are still on 7 or lower. Some people have moved to 8, but there's been some instability within version 8 that's kept some people from moving there. Exceptions to that prior slide. If you're trying to connect to the database after three unsuccessful login attempts, the SQL plus session or login session will be terminated. However, you can restart that session thousands and thousands of times and let user ID will never be locked. It's just a lockout on invalid passwords within the logon form. These two companies Mer systems and Blain Tree offer third party password management software for Oracle version 7 and 8. And Oracle 8 finally puts some password management into the database. Mainly because people like me bitched enough of them to do it. If you're looking in an ORS and you want to know if Blain Tree or more is being used to do password management within an Oracle database, version 7 or 8, they have SysOS IDs, the Blain Tree user ID on the ORS with the SQL CQR. I don't know what the more user ID is, but I'm sure it can be found on more's website. You can call them up, ask them whatever, some information about their product. And within Oracle 8 password management parameters can be set by any DBA. And if you list the default profile and the Oracle database, it'll show the password management parameters that exist under Oracle 8. Which can be turned on or off or set to different parameters or levels. Oracle TCP IP Sessions. The SQL NAT protocol is used to remotely connect to the Oracle database. Multiple database instances will usually run on a single server and each instance will require its own listener or port. So basically you can have three or four or five database instances running on an operating system. And you just have to have separate listeners for the SQL NAT connection to connect to. And Oracle Server listeners usually run in this port range, 1500 to 1599. In order to encrypt SQL NAT sessions, there was a product called Secure Network Services. Now it's called Advanced Networking Option. And sometimes it's used, sometimes it's not. Crypto strength of AMO is pretty good, but there are some flaws in the key exchange protocol. And basically if you want to know what they are, you probably have to do a source code review and sign a non-disclosure agreement like I have. And you'll be able to pick out that stuff. And AMO encryption can be mandated or it can be optional. So the server can say every TCP IP SQL NAT session is encrypted or you can encrypt if the client wants to or not. Here are some useful SQL statements. Grant connect to user ID being any user ID you want to name, identified by password being any password you want to name. That will create a new user within the Oracle database. If you want to change the user's password, you can use that second command. And basically all the information here, I gave this presentation to a guy that had to do some certification testing. And he took this presentation and went at this database. He knew nothing about it. He didn't know anything about Oracle and he was able to get into the database lots of different ways and do lots of different things once he got there. You can grant the DBA rule to a user ID if you are DBA or if you're in the system account or sys account within the database. And you can drop user IDs by drop user ID cascade. The cascade is an option and it will drop all the tables created by a user when you delete the user ID. If you don't use cascade, the user ID goes away but the tables still exist. You can look at all user IDs and passwords in the database by issuing the top command. You have to be a DBA to access any DBA table. And basically that's any table that starts with the name sys.dba something. Only DBAs can query those tables. There are also some tables within Oracle that start with the word ALL. Any user ID on the system can query those tables. So any user could look at all the user IDs on the system by selecting user name from all users. That table all users does not have the password stored in it so you would not get the encrypted passwords. Select asterisk from profile default. If you're in Oracle 8 and you want to see what the password management settings are, that's the command to do it. And if you wanted to change the default profile, you could do a command like alter profile default invalid logins unlimited. So then there will be no lock. What's that? Do you have to be a DBA to do that? Yes. In order to change that default profile you do have to be a DBA. But there's plenty of ways to become a DBA. If you grant ALL on any table to a user ID, basically it's going to give you a whole list of permissions on that table. Like select, which means read, insert into the table, modify the table, delete records out of the table, and a few others like create indexes on the table and links on the table. You can grant specific privileges. So if you want to just grant read access to a user ID, you can do grant select on the table to the user ID. And that user ID would only be able to read that table. And you can revoke everything on the table from a user ID. You want to take away access on a specific table or object. If you want to create a row, basically it's just create row and row name. And drop a row, or delete a row, drop a row, row name. And if you want to add a bunch of table permissions to a row, you basically grant those table permissions to that row. And then the second and last command, you can grant that row to a user. Prior to version 7, there were no rows, so it's a security administrator job that's really hard because you had to grant specific table privileges to every user ID on the system. And with Oracle 7 and 8, you can just grant it to a single row and grant that row to every user that needs it. And the last command is to take a row away from the user ID. The granular auditing options are alluded to here. You can turn on auditing for any successful login by using the top command. You can turn on auditing for any unsuccessful login by using the second command. And you can audit specific privileges, say anytime someone updates a table, you can audit just that updates on default, like any table on the system. If you issue that command, any table that gets updated will cut an audit record. Or you can do it on a specific table. This first option is showing how to do it on a specific table instead of every table by default. You can turn off auditing by just doing no audit all on a table. So any access to that table at all would not be auditing if that statement was issued. And no audit all will turn off all statement auditing. Basically any SQL statements that are issued will not be audited. And no audit all privileges would turn off auditing for any system privilege that was executed. No audit all on default will turn off all default audits. If you want to turn on auditing for a specific user, you do audit session by the user ID. And if you want to turn off auditing for a specific user, you just issue no audit session by that user ID. So if you were doing something in the database and you didn't want to be audited, and you could issue that command, you would not be auditing. And delete asterisk from the CISA dollar table will delete all audit records. This first statement say you're querying a database that has a bunch of credit card numbers. This would show you how to possibly retrieve some of those credit card numbers. Or a database that had some other data. The second statement has a wild card F name like Liz percent sound. Basically you can put a percent sound before or after any string. And that will give you any option like Liz or Lizzie or anything that came after Liz basically. If you wanted to see all the tables in the database, you could select owner and table name from sysdba tables. If you wanted to list all columns within a table, you would do a describe on that table. And if you want to list audit records, here's one of the audit views of the CISA dollar table that can be queried to look at all audit records for a specific user. Here's some of the useful security tables within an Oracle database. The first one is stores all users and passwords in that table. The second one any table privileges that have been granted to anyone would be stored in that second one. The third one any system privileges that have been granted to any user would be stored in the third. Any profiles that have been created and granted to specific users will be in sysdba profile table. Any rows that have been created will be in the dba rows table. Any row privileges who they've been granted to will be in the dba row profiles. And audit records will be under the view of the dba audit trail table. And the sysdba dollar table is the actual audit table. It kind of went quick, but that's it. If anybody has any questions, now is the time. Yes. I'm a newbie when it comes to Oracle, but I'm going to put me on a server on keys 400. There's more than anything like a rollback file. And if it does, and thinking about OS tags on files, if there's any way to take for instance a rollback file for OS type files, you can put them off and set them up in a clean environment to inspect. Okay, within the Oracle there are rollback segments. So if you're doing a lot of changes within the database and something happens, it crashes, you can rollback to some certain period in time. You want to know if you can offload those rollback segments? Yeah, yeah, basically you can structure, you can separate some of those things like the rollback segments on different disks on an OS. So if you have a disk crash on a disk that has part of the database, it's not necessarily going to affect where you have stuff like rollback segments if you have it on a different disk. So you can separate those things. As far as putting them on another OS, I'm pretty sure you can do that. Let's do an export. Okay, yeah, I mean I'm not a DBA so those functions are kind of outside of my realm. I do know that if you're issuing a bunch of SQL statements and you're not committing those statements to the database periodically, you'll overflow the rollback segments and the database will run to a halt. So if you're issuing a thousand create user commands and you're not committing those commands every 50 user IDs or something, you'll overflow the rollback segments and the system will halt. Yes? On operation authenticated accounts, does it still let you enter a password? Is it possible to authenticate using that password or what is the operating system? If you're using OS authentication and a user ID has already logged into the OS, it doesn't matter what the ID in the database has as a password. If it's set up to use OS authentication and the ID exists that matches the OS ID and has an ops-dollar prefix, they'll log in. If you want them to have to log into the database, don't use the OS authentication. They'll log into the OS but if you create an ID for them in the database, don't prefix it with the ops-dollar and when they connect, they'll have to supply the user ID and password. So if they've got an ops-dollar prefix, for example, if they're going to sequence that to the OS authentication, they'll go into the database, they'll go into the database and they'll have to log in. Right. If you don't sequence that, that's not OS authentication because you're client-server mode. You're not logged into the OS. And the ID can exist just as a regular user ID with a password or it can be ops-dollar user ID with a password. You'll have to type ops-dollar user ID in the password if you're coming in over sequence that because you haven't authenticated to the OS. Yes. I've seen some of it, you know, some sales pitch stuff. Do you have any specific questions about it? I don't know. There's problems with that. One of them is to use a global user ID to access the database and it's doing all the ID mappings at the web server. I personally have a little heartache with that but haven't filled with it much. Oh, yes. It's viewvandal at exploit.com. The O in exploit is a zero. Yes. It does encrypt it. An offline tool to list the... Yeah, I mean basically if you can access the OS data files from the OS you'll see those encrypted passwords there. Okay. Yes. Right. This is just to start. He's asking if it's possible to start the secret met listener on a privileged part like less than 10, 20, 30, you're asking. If that port's not being used by another service, yes, you can specify the listener to use one of those privileged ports if it's not being used. Yes. Oh, yeah. I mean those commands I was issuing. If you want to delete audit records for a specific ID you can do that. If you want to delete audit records on a specific table like anybody that's accessed a specific table you can do that. Basically you just delete staff from the CISR dollar table where some condition is met, whatever condition you need to meet. Does that answer what I mean? Yeah. Okay. Yes. Well, you can, but typically it's a date-based thing where you offload all the, you know, if you're going to be making audit backups you'd probably want to store them by some weekly parameter or monthly parameter or daily parameter. So you'd have to have your script set up to offload just that week's data and then a script that would delete just that week's data. So, you know, you can code that. So yes, you can automate it. You could, not in the database itself, I mean there's nothing to trigger that. You could set up something in like Kwan to go check it and, you know, if you can select count from the table and it'll give you how many records, how many rows are in that CISR dollar table and based on some output condition that if it's greater than whatever 40,000 then you can, you know, kick off whatever you need to to clear it out. Yeah. Yes. Have I tested any vulnerabilities with the SQLNet protocol? As far as like man in the middle attack or I'm getting a key, a crypto key for the session, yeah. But, I mean, as far as anything else, you know, it's either encrypted or it's not. As far as connecting to the database with SQLNet, you know, you have to have a valid ID once you get there. I haven't found a way to like exploit that to get in otherwise. Yes. I don't think so. I don't think anybody can drop a DBA table. But I haven't actually tried that. That's a good little test. Yes. Oh, no. Any statements like if you're inserting data into a table, you're inserting some row into a table and you have insert this row, insert this row, insert this row. You can insert to any table you have access to. Yeah. I mean, basically, if you have access to do some type of command that's going to alter any kind of data, whether it's creating users or inserting data or deleting data, whatever you have access to do, if you do too many of them without committing them, you will overflow that row back segment. I mean, what I usually do is do a commit like every 50 and no more than 100 statements. I don't know exactly at which point it breaks. It probably depends on the complexity of the SQL command you're issuing. But I never go over 100 SQL statements without issuing a commit unless I want to break it. Yes. It's just something that Oracle overlooked. I mean, they do have the ability to does encrypt the passwords, but they didn't really take good consideration in how they were going to protect that does key. Can they fix that? Yeah. Is it fixed right now? No. How is it affected? How is it protected? Basically, it's not. Basically, there's a few ways you can find out. You can fool around with it and find it yourself. You can do a source code review and sign a non-disclosure statement like I did, which is why I'm not disclosing it right now. And you'll find it. Or you can get me drunk and maybe I'll tell you later. So, yes. Well, usually if you're using OS authentication, if you're setting up a bunch of application users, they'd normally be part of some application group. But it's not necessary for them to be in a specific group at the OS if you're using. Right. With the exception of if they're in the DBA group and they run the SQL DBA utility, that's the only time it'll actually check what the group is. Yes. I have a few questions. The first question is, what's the most secret it goes? Is there a way to lock it in so it's a web server to work with it? No. But you can only execute it through procedures on the local database, so you can lock it in online. It's a good process. But the second thing is, can you not really build an application proxy that will work with SQL DBA? If you only want them to execute stored procedures, you can set up profiles for a user within the database that can limit what they can do. You can basically say they can't issue this command, this command, this command, or any command except this one. So yeah, you can do some stuff to limit what they can execute over a SQL node connection. The second part of that was... Application Proxies. Most of the proxies, if you're talking about firewall proxies, are like generic proxies. They're not really doing any command filtering within the proxy. It's just some proxy to get them through the firewall and handle the SQL node traffic. But to me, a generic proxy is not really a proxy. A proxy is going to limit what you can actually do while you're using that. This guy is saying Sidewinder. I don't know what it limits you. What is it limiting? What is it stopping you from doing? Most of the names at a time, they do it right. That's the fairness you think about. It's going to be a hassle of finding it. It's supposed to be fixed first and foremost. Yeah, well, most of the ones I've seen were generic, but... No, I'm talking about the proxy, just to point out that the generic proxies is not really doing this. Anyone's not going to be a new one yet but you can get a new one and you can get a new one. Right, well, it does that on NT. The SQL node implementation on NT uses a wide range of ports, which is really F'd up if you're some kind of security administrator. On the Unix, it doesn't do that. The listener listens on this port and this port only. If you run an NT and trying to do SQLnet, you could have a situation where you can't use proxies, because of the wide range of ports, and the proxy's not going to handle that. You would get that the port is open. If you were port scanning, would you know if the port was being used? You would just get an open port and not use any kind of... Depending on the kind of scan you were doing, yes, it was... If you were not going to do SQLnet, why would you choose the wide-stranded and internal listening system because it's not the protocol itself? What you probably want to be doing is connecting SQL plus over SQLnet to see if you get a username, login prompt. Yes. Do you have any possible way to exploit the database? What's the way to get operating system show access? If you're in a SQLnet session, if you host out, you host out back to your client, you don't host out to the OS. I haven't tried that, so I don't know. Yes. I've seen it, but I haven't played with it. I don't know. One more question? One more question? Thank you all for coming.