SDL Episode56

From Paul's Security Weekly
Jump to: navigation, search

Secure Digital Life #56

Recorded on March 13, 2018 at G-Unit Studios in Rhode Island!

Episode Audio

Coming soon!

Announcements:

  • Infosecworld -- Next week! I will be in Orlando with the whole PSW crew so be sure and come by and meet up with us at the booth or con Paul into buying you a drink.
  • BSIDES Orlando Shootout at Full Sail Live on 7 - April. You really need to get to this. Check out bsidesorlando2018.eventbrite.com and bsidesoirlando.org. Students are free with your ID. Labs, speakers, challenges. What's not to like.
  • RSA -- I will be speaking at RSA 2018 in San Francisco on the 18th of April so be sure and come by. I will be there shooting SDL on Tuesday at the NetSparker booth so if you want to see the show live, now's your chance. I am speaking at 8 am on the 18th but the show will be there on the 17th at the Marriott Marquis.

Hosts

  • Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  • Russell Beauchemin
    Cybersecurity & Network Security Program Advisor and Director of Instructional Support & Learning Innovation at Roger Williams University.
  • Topic: SQL Injection

    • SQL Injection -- This won't hurt a bit.
    • What is SQL to start with? -- This is a scripting language used to manage SQL (get it) databases. Most relational databases from the last 20 years uses this language to write queries, create tables, etc. MySQL, SQL Server, you name it, they are all based in SQL.
    • So, what is a database anyway? -- Well, a relational database uses tables which have a common theme to store data. Each table has a theme and some sort of key. A key can be one of may types of things but is often a unique (at least in that table) identifier of that data record.
    • Tables are joined together to seek information by using tables made up of keys which link the two tables together.
    • Example: A table of names and addresses has Doug White | Studio G in two fields. The key is the name or the address. Now, I could link the names table (which has all sorts of information about Doug) using the name or the address field which has all sorts of information about Studio G together and by doing that query, I can find out the phone number of Studio G by using Doug White as the search. That would link at least three tables together and maybe more.


    • Relational databases rely on these types of key tables to allow for gathering all sorts of information from a wide range of tables.
    • So, the problem is, what if I can use logic to outmaneuver security?



    • Example 2: One table has users and a user id (so like 1|Doug) and another table has passwords of users also based on user id (1|mrfufu)
    • So in normal operations, when you try to login to a website it says:
    1. Uname:
    2. pword:


    • you type Doug into one field and mrfufu in the second. The database a logic query to see i
    • Doug == 1 (uname table), look up 1 in pword table (== mrfufu); pword == mrfufu, return true.
    • So, when that true value is returned, you are allowed to login to the system.
    • This led to a wide variety of attacks categorized as SQL Injection attacks
    1. Attack 1) In this type of attack, what happens is, instead of a password in that field you could put something like: 1=1 This created a true situation by default and pushed the value true all the way through and let you login as Doug regardless. With a little social engineering, we may be able to find the head of IT or the VP of Database Operations or how about the VP of Finance. Who knows what exciting things they may have access to in the database system. The more rights and privileges the better. I could literally logon as CEO and just SELECT * FROM * type commands to see all the tables and even DROP TABLE Employees; and suddenly fun ensues.
    1. Attack 2) In this type of web based attack, embedding a 1=1 type logic bomb into a search, may allow you to escalate beyond your privileges. So, say, you are on SWA looking at your upcoming flight and it says which record number you put 1=1 into the query and push a true into the query. This could cause it to reveal all the data for ALL the flights for ALL the customers and any other information (like their names, passport numbers, etc.) on the screen instead of just the ones for Doug.
    1. Attack 3) Suppose you go to Bank of Hooha and are faced with a login screen. An SQL injection attack can be used to do something like INSERT INTO users(username.userid) VALUES ("iAmOz";"blank");
    • Now, I have a user in the system and can login. This type of attack can also push permissions in the database or into the system overall.
    • So, basically you have the ability to both reveal data from other table by injecting joins, selects and so forth with escalated privileges.
    • What do do?
    1. Ensure you vulnerability scan with tools which can assess these weaknesses.
    2. Don't rely totally on automated pen tests since they can miss key exploits
    3. Use firewalls which prevent certain types of access (although that won't help with tcp/80 access)
    4. Patch your SQL products
    5. IDS/IPS can also detect packets with attempts like this so you can blacklist attackers
    6. More advanced firewalls can look for these types of attacks (application layer firewalls)

    Next week: A visit to a con.