Fuzzing PL/SQL

This is my presentation to the UKOUG last December on using a different method to assess whether PL/SQL code is vulnerable to attack. This method is similar to what an attacker may do

Slide 1 - Fuzzing PL/SQL

Slide 2 - Legal notice

Fuzzing PL/SQL

Published by
PeteFinnigan.com Limited
Tower Court
3 Oakdale Road
York
England, YO30 4XL

Copyright © 2025 by PeteFinnigan.com Limited

No part of this publication may be stored in a retrieval system, reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, scanning, recording, or otherwise except as permitted by local statutory law, without the prior written permission of the publisher. In particular this material may not be used to provide training of any type or method. This material may not be translated into any other language or used in any translated form to provide training. Requests for permission should be addressed to the above registered address of PeteFinnigan.com Limited in writing.

Limit of Liability / Disclaimer of warranty. This information contained in this course and this material is distributed on an “as-is” basis without warranty. Whilst every precaution has been taken in the preparation of this material, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions or guidance contained within this course.

TradeMarks. Many of the designations used by manufacturers and resellers to distinguish their products are claimed as trademarks. Linux is a trademark of Linus Torvalds, Oracle is a trademark of Oracle Corporation. All other trademarks are the property of their respective owners. All other product names or services identified throughout the course material are used in an editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this course.

Slide 3 - Background

Pete Finnigan – Background, Who Am I?

• Oracle Security specialist and researcher
• CEO and founder of PeteFinnigan.com Limited in February 2003
• Writer of the longest running Oracle security blog
• Author of the Oracle Security step-by-step guide and “Oracle Expert Practices”, “Oracle Incident Response and Forensics” books
• Oracle ACE for security
• Member of the OakTable, SYM 42
• Speaker at various conferences UKOUG, PSOUG, BlackHat, more..
• Published many times, see http://www.petefinnigan.com for links

Slide 4 - Agenda

• Attacking a database
• What is fuzzing
• Fuzzing Design
• Examples of Fuzzing
• Other types of code analysis
• Conclusions

Slide 5 - Attacking a database

Slide 6 - How to exploit a database

• Two main ways an attacker can exploit the database
• Connect – they have an account, employee, steal credentials etc
• Or exploit an application via SQL Injection or similar
• How do we stop this?
• Leave the credential based attacks for another time!!

Slide 7 - How can we fix code

• Education:
• Teach developers to write secure code
• Teach developers what insecure code looks like
• Peer code review
• Work to standards
• Automated Testing
• Use SQL and PL/SQL scripts
• Use commercial tools
• Fuzzing
• Abuse and attack your code

Slide 8 - What is Fuzzing?

Slide 9 - What is Fuzzing

• This is a technique that can find bugs and security issues automatically by feeding a program large amounts of unexpected, random or malformed input and observing behaviour
• Can be useful to find corruption, memory issues, overflows, SQL Injection

Slide 10 - Types of Fuzzing

• Black box – no knowledge of the internal system
• White box – can use code analysis to generate smart inputs (we will come back to this)
• Grey box – uses lightweight instrumentation to assess coverage (we will also come back to this)

Slide 11 - Fuzzing Tools

• There have been two known PL/SQL fuzzing tools in the past
• Joxean Koret created the first PL/SQL fuzzer in 2007 / 2008 - http://www.securityfocus.com/archive/1/453650/30/30/threaded (broken)
• Slavik Markovich enhanced this with a new PL/SQL fuzzer in 2009 - http://www.slaviks-blog.com/wp-content/uploads/2009/01/fuzzor.sql (broken)
• I did look at them both back in 2007 and 2009 but only remember high level details
• Both not available in the web archive
• We will look at doing fuzzing with PL/SQL manually to test the ideas

Slide 12 - Fuzzing can be destructive

• If we pass a parameter such as “x’ union select 1 from table where 1=0”
• Then this could be inserted by a procedure as data in one or many tables if the procedure inserts passed in data
• Before fuzz testing ensure you can “lose” the database and restore it later to a previous state

Slide 13 - Types of PL/SQL code issues

This is not definitive

Slide 14 - Code issues that can be Fuzzed

Slide 15 - The main focus for Fuzzing is injection

• In band, out of band, inference
• 1st Order , 2nd order, …
• Parameters to procedures, select into, triggers, …
• Not just SQL but SQL, PL/SQL, DDL, open interface, others…

Slide 16 - Attacks can be multi-layered

Slide 17 - Fuzzing design

Slide 18 - Types of attack for Fuzzing

• Single Quote (s)
• Double Quote (s)
• Size and type – pass string for number, string or number too long
• SQL Inject strings
• PL/SQL or C language comments
• Open Interface attacks
• File based attacks

Slide 19 - Some error codes for Fuzzing

• ORA-01756 – Quoted string not properly terminated
• ORA-01790 – Data types do not match
• ORA-01789 – Miss-match in number of columns
• ORA-00972 – Input too long
• ORA-00942 – table or view does not exist
• ORA-01031 – security error
• ORA-00928 – missing SELECT keyword
• ORA-00923 – missing FROM keyword
• ORA-00904 – Invalid identifier
• ORA-00933 – missing expression
• ORA-00907 – missing right parenthesis
• ORA-00911 – invalid character
• ORA-00924 – missing BY keyword – in group, order, connect
• ORA-00900 – Invalid SQL Statement
• ORA-01741 – illegal zero length identifier

Slide 20 - Paths to code

• This is the problem that could to be solved by grey-box and white-box ideas but is not solved at all by black-box testing
• If a procedure accepts two parameters and one being set to ‘N’ or ‘Y’ causes different paths through the code for a second parameter to be used then simply passing random data in parameter 1 will always go through one path and not the other
• To properly test code by fuzzing we would need “flow analysis”

Slide 21 - A simple Fuzzor design - Version 1.0

• Just test parameters to procedures
• Start with partial testing
• in a sense only blindly find parameters and send attacks
• List all PL/SQL procedures with CHAR, VARCHAR and other text parameters
• List procedures
• List parameters
• Build a list of attacks
• Execute each procedure for each attack string in a loop
• Report any errors located
• Assess results

Slide 22 - Future improvements - Version 2.0

• Identify triggers
• Insert data (attacks) to be picked up by triggers
• Identify “select into” clauses
• Insert data (attacks) to be picked up by select statements
• Extend to test file based attacks
• Extend to exploit exceptions
• Extend to exploit ref cursors
• More…

Slide 23 - Examples of Fuzzing

Slide 24 - Example Procedures

• SIMPLE – cannot be attacked – The control
• CUSTA – can be SQL Injected
• OPENI – Open interface can be exploited

Slide 25 - Test Frame Work

• Change the variable lv_in to pass different attacks
• Change the function / procedure calls to test other calls and parameters

Slide 26 - Single quotes

• Cannot assign one single quote as the variable MUST be between 2 single quotes
• Three quotes lv_in:=‘’’ – compile error not run error
• Four quotes lv_in:=‘’’’ – i.e. one single quote – shows probable injection possible
• Five quotes lv_in:=‘’’’’ – compile error
• Six quotes lv_in:=‘’’’’’ – i.e. 2 single quote, empty string gives ORA-00900 in openi()

Slide 27 - Double quotes

• Single double quote - Can identify the open interface
• Double double quote – same error

Slide 28 - Long strings

• The variable is 2000 in custa() and 32767 in openi()
• Could do similar with too big numbers

Slide 29 - Comments

Slide 30 - Simple SQL Injection

• The first example fails because the rest of the statement is added to ours
• Both cases fail in openi() because it is not a complete statement

Slide 31 - More SQL Injection

• Too many columns
• Code correct but no permissions
• Open Interface suceeded

Slide 32 - Other types of code analysis

Slide 33 - Simple code analyser scripts

Slide 34 - Manual PL/SQL code analysis

• It is a manual process
• First locate all public PL/SQL functions and procedures
• i.e. they can be reached in an attack
• Then locate the procedures that have CHAR / VARCHAR parameters for those public functions and procedures
• Review potential attacks located and
• Check source code for path to a parameter for a public procedure

Slide 35 - Code analyser

Clearly will find more things as code is analysed

Slide 36 - Fuzzing is limited

• Only tests limited things such as SQL, PL/SQL, DDL etc Injection
• Could be changed to test other things such as directory access to pass in dummy folders, file names etc
• Cannot cover code easily without knowledge of the code and complex path / flow analysis
• If a tool is written to do flow analysis then why not just do code analysis?
• Good as a simple black-box brute force tester

Slide 37 - What use is a Fuzzor

• Attackers do not use professional code analysers unless they can get the source code – maybe the application is public like Wordpress
• Attackers do not use simple scripts like mine to analyse the code unless again they have access to the code
• Attackers use brute force techniques as they have no other options when code is not available
• Usually this could be in the form of tools like sqlmap or BurpSuite that target web sites / apps and try and drill into SQL in some cases
• An attacker might enter random rubbish into form fields or web page fields manually and watch the error messages
• By using a simple fuzzor at the database level we replicate what attackers do first

Slide 38 - Conclusions

• Fuzzing is not a replacement for education, code standards and review
• Fuzzing has severe limits
• Can only really test injection and open interfaces
• Fuzzing needs pre-analysis to be useful
• If we need proper analysis for other types of issue then why not for injection also
• Fuzzing simulates an attacker
• The results need manual analysis and review of code

Slide 39 - Questions

Slide 40 - Fuzzing PL/SQL