Hacking SQL Injection for Remote Code Execution on a LAMP Stack
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 109 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/36405 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 2330 / 109
12
19
20
23
24
29
32
33
36
51
58
60
62
66
67
68
69
70
71
77
82
84
85
88
89
92
98
99
103
104
107
00:00
InjektivitätCodeKeller <Informatik>RechenschieberComputerHackerGruppenkeimStellenringBitInjektivitätMereologieComputervirusProgrammierspracheSoftwareHackerGruppenoperationStellenringAutomatische HandlungsplanungEreignishorizontFreewareMinkowski-MetrikCode
00:50
W3C-StandardInformationCoxeter-GruppeService providerKonstantePhysikalischer EffektImplementierungEuler-WinkelMereologieComputersicherheitBenutzerbeteiligungWeb-Designer
01:29
ServerOperations ResearchSystemprogrammierungCLIDatenbankCodeDatenkompressionBitInjektivitätServerComputersicherheitFortsetzung <Mathematik>Schreiben <Datenverarbeitung>NetzbetriebssystemSoftwareentwicklerNichtlinearer Operator
02:21
PunktIdentitätsverwaltungServerCodeMereologiePhysikalisches SystemGüte der AnpassungBeobachtungsstudieClientSoftwareschwachstelleRechter WinkelBenutzerbeteiligungWeb-ApplikationInjektivität
03:09
QuellcodeCodeInjektivitätEin-AusgabeBefehl <Informatik>DatenbankInterpretiererCodeFormale SpracheNatürliche ZahlProgrammierspracheValiditätZeichenketteInjektivitätAbfrageParametersystemCASE <Informatik>Nabel <Mathematik>Ein-AusgabeFortsetzung <Mathematik>MiddlewareTLSBenutzerbeteiligungMultiplikationsoperator
04:00
Hintertür <Informatik>ServerElektronischer FingerabdruckDatenbankPhysikalischer EffektCodeDatenbankPhysikalisches SystemRechenschieberAbfrageServerEin-AusgabeSoftwareschwachstelle
04:38
ServerGeradeBrowserProgrammierumgebungSkriptspracheHyperbelverfahrenCodierungPhysikalisches SystemGraphische BenutzeroberflächeDateiformatMultiplikationsoperatorSuite <Programmpaket>
05:16
URLHIP <Kommunikationsprotokoll>SoftwaretestSkriptspracheSoftwaretestSkalarproduktParametersystemEin-AusgabeSkriptspracheDateiformatURL
05:51
Architektur <Informatik>CodeDatenbankPhysikalisches SystemServerCASE <Informatik>Kartesische KoordinatenSoftwareschwachstelleBenutzerbeteiligungWeb-ApplikationComputerarchitektur
06:28
DatenbankArchitektur <Informatik>ServerLastSummengleichungCodeDatenbankCodierungInjektivitätLastLoopAbfrageServerNichtlinearer OperatorNabel <Mathematik>PunktLastteilungCluster <Rechnernetz>DifferenteSoftwareschwachstelleBenutzerbeteiligungUnternehmensarchitekturFortsetzung <Mathematik>Netzbetriebssystem
07:24
DatenbankSoftwaretestCodeDatenbankOrdnung <Mathematik>SoftwaretestCodeZeichenketteEinfach zusammenhängender RaumInjektivitätAbfrageServerRoutingHash-AlgorithmusEin-AusgabeFortsetzung <Mathematik>PasswortLoginSoftwareschwachstelle
08:34
InjektivitätStandardabweichungMessage-PassingPhysikalisches SystemMeta-TagSoftwaretestInjektivitätFortsetzung <Mathematik>MereologieAbfrageAusnahmebehandlungSystemverwaltungFehlermeldungCoxeter-GruppeTouchscreenBenutzerbeteiligungComputeranimation
09:09
ZeichenketteCodeLeistungsbewertungBefehl <Informatik>InjektivitätTabelleSoftwaretestStichprobeVariableDateiformatGleitkommarechnungBasis <Mathematik>DatenbankZeichenketteTypentheorieInjektivitätLeistungsbewertungResultanteFortsetzung <Mathematik>PasswortDifferenteLoginWeb-Applikation
09:41
InjektivitätDatensatzOrdnung <Mathematik>SoftwaretestInjektivitätResultanteZahlenbereichFortsetzung <Mathematik>SkriptspracheTrennschärfe <Statistik>SoftwareschwachstelleURL
10:47
Data Encryption StandardInjektivitätCodeDatenbankDatensatzZeichenketteInjektivitätMultiplikationResultanteFortsetzung <Mathematik>MultiplikationsoperatorSoftwareschwachstelleExistenzsatz
11:19
Physikalisches SystemElektronischer FingerabdruckArchitektur <Informatik>ServerInjektivitätSpieltheorieAggregatzustandVersionsverwaltungDienst <Informatik>InjektivitätKeller <Informatik>Web-ApplikationAbfrageServerElektronischer FingerabdruckBenutzerbeteiligungCodeDatenbankComputerarchitekturE-MailPunktSchnittmengeMiddlewareNetzbetriebssystemDefaultPortscannerMAP
12:36
PortscannerBereichsschätzungServerElektronische UnterschriftPunktElektronischer FingerabdruckIdentifizierbarkeitBenutzerbeteiligungHochdruck
13:05
DatenbankArchitektur <Informatik>ServerFunktion <Mathematik>Elektronischer FingerabdruckTabelleZählenAbzählenGanze ZahlDatenbankServerBenutzerbeteiligungResultanteZählenAbfrageVersionsverwaltungParametersystemFortsetzung <Mathematik>Trennschärfe <Statistik>Front-End <Software>NetzbetriebssystemSoftwareentwicklerSchnittmenge
14:32
VersionsverwaltungDatenbankFilter <Stochastik>VersionsverwaltungZeiger <Informatik>PunktFortsetzung <Mathematik>Trennschärfe <Statistik>Proxy ServerBenutzerbeteiligungEinsAbfrage
15:12
Orakel <Informatik>ProgrammverifikationDatenbankZeichenketteElektronischer FingerabdruckSoftwaretestDatenbankFunktionalÄhnlichkeitsgeometrieFortsetzung <Mathematik>Trennschärfe <Statistik>Ordnung <Mathematik>SoftwaretestGeradeAbfrageVersionsverwaltungPunktFront-End <Software>ResultanteComputerunterstützte Übersetzung
15:55
MAPDatenbankSoftwaretestZeichenketteOrakel <Informatik>Elektronischer FingerabdruckAbzählenArchitektur <Informatik>PasswortNummernsystemHash-AlgorithmusInformationLoginProzess <Informatik>Operations ResearchPhysikalisches SystemProgrammverifikationZahlenbereichVersionsverwaltungFortsetzung <Mathematik>ComputerarchitekturPunktDatenbankMereologiePasswort
16:39
AbzählenCodeDatenbankDatensatzProgrammiergerätEinfach zusammenhängender RaumTabelleWurzel <Mathematik>Hash-AlgorithmusFortsetzung <Mathematik>PasswortTrennschärfe <Statistik>Web-ApplikationStellenring
17:33
ServerPasswortAdressraumDatenbankTrennschärfe <Statistik>TabelleZählenDifferenteDatenbankComputerarchitekturEinfach zusammenhängender RaumFunktionalMereologieAdressraum
18:18
TabelleFunktion <Mathematik>DatenbankInformationTabelleFortsetzung <Mathematik>Ordnung <Mathematik>Funktion <Mathematik>PunktHash-AlgorithmusPasswortLoginWeb-ApplikationZahlenbereich
19:15
PasswortHash-AlgorithmusElektronischer ProgrammführerSchnittmengeIdentitätsverwaltungInformationTabelleTrennschärfe <Statistik>LoginProgrammierumgebungHash-AlgorithmusPasswortWeb-Applikation
19:48
Hash-AlgorithmusPasswortDifferenteFunktionalVersionsverwaltungHash-AlgorithmusPasswortMultiplikationsoperatorMessage-Passing
20:33
GraphikprozessorMini-DiscRippen <Informatik>Hash-AlgorithmusPasswortKraftROM <Informatik>DatenverarbeitungssystemPaarvergleichService providerTabelleInformationBitFortsetzung <Mathematik>PasswortMAPHash-AlgorithmusRippen <Informatik>DatenbankMaschinenschreibenSchaltnetzSoftwaretestTabelleComputersicherheitMultiplikationsoperatorCracker <Computerkriminalität>
21:17
GraphikprozessorHash-AlgorithmusPasswortGraphikprozessorComputerunterstützte ÜbersetzungCodeDatenbankProgrammierumgebungInjektivitätPhysikalisches SystemServerSystemverwaltungWurzel <Mathematik>AbschattungMailing-ListeElektronische PublikationMultiplikationsoperatorBenutzerbeteiligungNetzbetriebssystemWeb-ApplikationDefaultComputerarchitekturGrenzschichtablösungBitFortsetzung <Mathematik>Softwareschwachstelle
24:01
Elektronische PublikationDatenbankForcingServerMailing-ListeKonfigurationsraumPunktResolventeElektronische PublikationMessage-PassingCOMInjektivitätResultanteTabelleAbfrageHash-AlgorithmusFortsetzung <Mathematik>Befehl <Informatik>PasswortTrennschärfe <Statistik>SoftwareschwachstelleDatenbankBitLogin
25:12
DatenbankParametersystemBefehl <Informatik>RFIDTropfenTabelleBitResultanteAbfrageTropfenDatenbankInjektivitätTabelleFortsetzung <Mathematik>
25:45
MagnettrommelspeicherTreiber <Programm>Funktion <Mathematik>CodePhysikalisches SystemTropfenAbfrageVersionsverwaltungKeller <Informatik>FunktionalMultiplikationTabelleFortsetzung <Mathematik>CodeComputerarchitekturRPCPunktNabel <Mathematik>Benutzerbeteiligung
26:29
Nabel <Mathematik>ServerBrowserInterface <Schaltung>SkriptspracheMenütechnikCodeFunktionalPhysikalisches SystemServerNabel <Mathematik>BenutzerbeteiligungInjektivitätGewicht <Ausgleichsrechnung>Schreiben <Datenverarbeitung>NetzbetriebssystemOffice-Paket
27:34
ZeichenketteBenutzerbeteiligungServerFunktion <Mathematik>GammafunktionCodeDatenbankZeichenketteVariableFunktionalServerNichtlinearer OperatorEin-AusgabeInformationsspeicherungDruckspannungElektronische PublikationKonditionszahlSchreiben <Datenverarbeitung>DefaultSoftwareentwicklerEinsSoftwaretestRPC
29:15
Funktion <Mathematik>Nabel <Mathematik>CodeInformationComputerarchitekturFunktion <Mathematik>ProgrammbibliothekBitPhysikalisches SystemServerNichtlinearer OperatorParametersystemNabel <Mathematik>WeitverkehrsnetzVererbungshierarchieBrowserRegulärer Ausdruck <Textverarbeitung>Elektronische PublikationHintertür <Informatik>MultiplikationsoperatorRechter WinkelBenutzerbeteiligung
30:21
Hintertür <Informatik>SkriptspracheFunktion <Mathematik>CodeSocial Engineering <Sicherheit>CodeFunktionalInjektivitätMultiplikationPhysikalisches SystemServerFortsetzung <Mathematik>Mailing-ListeSkriptspracheElektronische PublikationEreignishorizontMultiplikationsoperatorSoftwareschwachstelleSchreiben <Datenverarbeitung>BenutzerbeteiligungSocial Engineering <Sicherheit>Web-ApplikationPlastikkarte
31:34
Elektronische PublikationPhysikalisches SystemVerzeichnisdienstPunktCodeAbfrageElektronische PublikationRechter WinkelWeb-ApplikationDefaultBildgebendes VerfahrenPunktFortsetzung <Mathematik>SoftwareschwachstelleCachingBenutzerbeteiligung
32:13
VerzeichnisdienstElektronische PublikationProzess <Informatik>CodeDatenbankPhysikalisches SystemServerComputersicherheitPunktFortsetzung <Mathematik>Installation <Informatik>Elektronische PublikationDifferenteBenutzerbeteiligungDefaultEinsCodeRPCCoxeter-GruppeKartesische KoordinatenSchreiben <Datenverarbeitung>
32:55
Proxy ServerStichprobeDigitalfilterElektronische PublikationCodePhysikalischer EffektPhysikalisches SystemSystemverwaltungMini-DiscVariableInterpretiererRegulärer Ausdruck <Textverarbeitung>Konfiguration <Informatik>ServerSocial Engineering <Sicherheit>VerzeichnisdienstKartesische KoordinatenElektronische PublikationCodeSoftwareschwachstelleDatenbankFilter <Stochastik>BitPhysikalisches SystemServerSystemverwaltungFortsetzung <Mathematik>PlastikkarteMini-DiscLoginBenutzerbeteiligungNichtlinearer Operator
34:06
Physikalisches SystemServerElektronische PublikationBenutzerbeteiligungNetzbetriebssystemPlastikkarte
34:40
CodeOrdnung <Mathematik>SoftwaretestBitPhysikalisches SystemVerschlingungParametersystemSystemverwaltungNabel <Mathematik>Reverse EngineeringSkriptspracheElektronische PublikationBeweistheorie
35:39
Physikalisches SystemSystemaufrufNabel <Mathematik>ServerReverse EngineeringProgrammierumgebungGamecontrollerCodeGeradeMeta-TagEinfach zusammenhängender RaumGewicht <Ausgleichsrechnung>Nabel <Mathematik>Reverse EngineeringComputerunterstützte ÜbersetzungHintertür <Informatik>CodeSoftwaretestEinfach zusammenhängender RaumPhysikalisches SystemRPC
36:14
Physikalisches SystemPivot-OperationCodeProzess <Informatik>MathematikSystemprogrammierungVerzeichnisdienstInjektivitätPasswortInverser LimesServerEuler-WinkelSoftwaretestQuellcodeCodePhysikalisches SystemSoftwareschwachstelleNetzbetriebssystemGamecontrollerBitPasswortPunktMAPInjektivitätGüte der AnpassungFortsetzung <Mathematik>
37:04
InjektivitätPhysikalisches SystemSoftwareEin-AusgabeDigitalfilterTreiber <Programm>HyperbelfunktionInjektivitätPhysikalisches SystemWurzel <Mathematik>RoutingFortsetzung <Mathematik>Dienst <Informatik>DefaultCodeZeichenketteFunktionalComputersicherheitEin-AusgabeSchnitt <Mathematik>DickeSchreiben <Datenverarbeitung>Programmbibliothek
37:56
DatenbankBenutzerdefinierte FunktionNabel <Mathematik>AnalysisCodeHydrostatikQuellcodeRippen <Informatik>Physikalisches SystemBenutzerdefinierte FunktionFortsetzung <Mathematik>BimodulSchreiben <Datenverarbeitung>ComputersicherheitElektronischer ProgrammführerCodeKeller <Informatik>AnalysisBelegleserRippen <Informatik>SoftwareschwachstelleBildschirmsymbol
38:30
BildschirmsymbolBildschirmsymbolPythagoreisches ZahlentripelPackprogrammProgramm/Quellcode
Transkript: Englisch(automatisch erzeugt)
00:00
So we're going to go ahead and start the talk with Lance from 801 and with that he's going to be talking about his SQL injection. Thank you. Hello. My name is Lance. I also go by the handle Nemus. A little bit about myself. I'm part of the local Def Con group in Salt Lake City, Utah. DC801.
00:22
We hang out at the pound DC801 on free note if you want to come chat with us during the day. I also help out with the hacker space in downtown Salt Lake. I help organize and plan events and things like that. That's my hobbies during the day. I write software for payment solutions.
00:41
I code in PHP and Python mostly. I also do a little C and basically just the whole gambit of programming languages. Also if you're interested in listening to me more, I'm part of the web security warrior podcast. It's a general new podcast that we're putting together for
01:02
people who are interested in security. It's mostly focused towards web developers and focuses on introduction security related topics. All right. Quick disclaimer. I am not responsible for anything you do with what I teach you.
01:21
That's you. I am not a lawyer so I cannot tell you what is legal and what is not legal. That's what lawyers are for. Prereqs. This is a 101 talk so it's geared towards beginners but you do need to understand basic Linux operating systems, basic PHP coding techniques. Basically you
01:44
need to understand how to set up a LAMP server and get PHP working on it and write PHP code. Just a little bit. Not a lot. Just a little bit. I wrote this talk. It's geared towards beginning PHP developers so they can learn the basics of
02:00
PHP injection, SQL injection security. So if you're looking to get into coding or just want to learn more about SQL injection, you can just study up a little bit and come back to this talk. So if you don't have the prereqs, well, I'll have a lot of fun coming back to it later. So why do we
02:23
study attacks, right? You always hear the best defense is a good offense, right? But we can't attack other systems. We can't go out and defend against the world. It's basically the world against us with our code, right? We want to have our code visible and available to our users and our
02:42
clients and basically the world. That's the way web apps work for the most part, right? You set up a web application and you want as many customers as you can possibly find. But the only way you can secure it is if you study how your system is coming under attack. You're not going to be able to attack the attackers, but if you attack yourself, you'll be able to understand your
03:02
weaknesses and find good solutions to mitigate those issues. So basics of SQL injection. What causes a SQL injection? Any time you have one programming language or you have one language writing code or writing executable
03:20
instructions for another language, you're going to have an injection flaw. It's just inherent. It's the nature of the beast. In this case we're going to focus on PHP writing SQL queries, but when you have two languages, like if I had PHP writing PHP, which I'll talk about when we go over web shells, you're going to have an injection problem.
03:41
And so with that you have to validate user input and you have to make sure that you're parameterizing queries correctly. Otherwise the user is going to be able to manipulate the string that's being generated by the middleware and take advantage of the code that's being executed on the second layer. So in this scenario what I'm going to do is
04:03
I'm going to walk you through some vulnerable PHP code. I've posted the code in the slide. It's very simple, broken down. I tried to make it very concise so that you can see, oh, okay, here's where the vulnerability is, here's the input from the user and here's the system, the code being executed on the system. And you can also use it to debug
04:22
why your query is not working. But we'll start off with identifying the vulnerability, fingerprinting the server, enumerating data from the database, and then once we're finished with that we're going to explore ways of uploading code and taking advantage of the server. So this is just the basic lab setup. I'll go over this real quick. You guys can
04:44
come back to this later. I always design my talks as a lab so later if you want to come through and learn something and work through it. So we're going to use curl. Curl is just going to do our HTTP request. It's going to format it. I like command line stuff. There's also Zed and burp suite
05:02
you can use if you like a GUI system. I don't have time to go over these tools but just let you know that they're available and they do basically the same thing. We just need something to help us craft the HTTP request so that we aren't, you know, hand coding it each time. So this is my simple curl test script and what we're doing here is we're just
05:20
taking parameter from the command line and feeding it into the variable ID which is going to be passed to this git.PHP script. And see the command example there, we just do git curl 1 and then it builds the HTTP request URL. We're also going to have it do data URL encoding which is just
05:42
how we want the input formatted so that all of our attacks will be formatted correctly and we won't have issues with spacing and special characters in the URL. So when we're attacking lamp, we have to think about the architecture. Most basic lamp applications when they start
06:01
off are probably going to start off on a single system. The web application might be running on a server on one server. We might have the PHP code running on one server and then database code running on another or sometimes in most cases it will all be running on the same server. This makes it a lot easier for attacking because we know that once we've found a vulnerability we can leverage
06:23
the database or we can leverage the web server and we're working within one system. It gets more complicated when you get into like an enterprise solution. So in this point we see we have load balancers, we have a web server and we have database clusters. So if I run a SQL injection attack I might be going against the first server, the
06:41
second server, the third server and it might be cycling and I'm not going to have a way of knowing where my code's being executed. So you have to keep this in mind because you might have a vulnerability and you might be pushing code or you might be doing something to the operating system and if you're attacking the web server aspect, you're attacking the PHP code, it's going to be on one of these web
07:01
servers and you have to figure out which web server it is in the loop. The load balancer is going to send it to different servers, different databases and the web servers are going to send the different requests to different databases. So if you have a SQL injection query and you're writing uploading shells, it could be pushing the shells to each one of those databases and you have to figure out how to execute that code or those web shells on the different web
07:23
servers. So here's our test database. It's just a simple orders database with some columns. We're going to create another database with login users and put some users in there using MD5 hashes. So here's our vulnerable code.
07:41
This is a simple code. At the top I'm showing the request as the server sees it. In the middle of there we're just connecting. We're going to connect. I've designed this to be what I would interpret would be out there when people first start writing PHP code. So the easiest thing they do is connect to the MySQL database's root, probably using local host,
08:01
no password just to get it running. We have some code to check to see if the connection fails. Then we run the query and here we have the vulnerability is that we're concatenating the query string. This is what the vulnerability is. Because we're taking two strings and concatenating them and we're not filtering any of the user
08:23
input, we have just created a SQL injection problem that will allow a user to take advantage of our database which we did not attend. So how does the attacker test for the SQL injection? Before we really do anything we want to
08:40
verify that the injection actually exists. So we're going to on this presentation I'm going to focus on blind SQL. I think for the most part most web administrators have been turning off errors, error reporting, which is a good thing, but it makes SQL injection more difficult. Non-blind
09:01
injection is where you have error messages that are printed to the screen and you can use those to help you infer what you need to do to build your query. So there's three different types of SQL injection attacks and what you're going to be doing is you're going to be manipulating the strings, our numeric values or we're going to
09:21
do an evaluation. So the classic example is where you take advantage of the evaluation of a log in where the user name and password is sent to the database. If we get a result we know that that user is a valid user on our web application. So like I said we'll be doing numeric
09:41
injection. So here's our first test. What we're going to do here is we're going to pass it to my get curl script. The script is going to generate the URL that's going to pass the ID forward and we're going to do a select orders from order numbers where one and one and we get the first results. We do it again and we do one and zero. We get no
10:03
results. So what the and is doing is it's doing a binary and saying if it's one and one it's true so that's one so return the first results. If it's one and zero that's zero so look for the zero results. There's no data there. So with this we can say huh seems like there could be a possible
10:20
SQL injection vulnerability. To do further testing we do one and true. True will be evaluated as one and it with one comes back as one we get the first record. One and false. False is zero and it come back with the record. Do the same with
10:41
minus if it's minus one minus true we see the results we don't zero record. And then the dead giveaway here is if we can use multiplication against the SQL database we know that we have a numeric injection flaw. So we use our curl string we do one times three and if we get the third
11:00
record we know the vulnerability exists. So in this example I didn't have a third record. I don't have the third record displayed there so you don't see it. But if we got the first results back we know okay this probably might not be a SQL injection within this code. So now that we
11:21
verified that the injection exists what we're going to do next is we need to verify that the web application is actually running LAMP stack or whatever we need to figure out what the web application is running so that we can attack it. So what we're going to do is we're going to fingerprint the server by looking at web requests and
11:40
figuring out the architecture so that we can craft our queries. So just the easiest thing you can do is you can use curl-v and look at the headers and the headers will tell you a lot about the web application and the database. It won't tell you about the database it will tell you about the middleware and the Apache or the web application
12:02
or sorry the web server. So it will tell you the web server and possibly the middleware code that's being run. This is the default settings. These are things that you can turn off so it will make it more difficult for the attacker to guess what's going on on your architecture. But here we're just blindly telling people, hey, I'm running Apache on CentOS and I'm running PHP 5.5.17.
12:26
We can also run an N map scan, verify the operating system and the web server. We see N map is identified as Apache and CentOS. We run the dash A command and do the OS fingerprinting, Apache, CentOS. Another tool we can
12:45
use is HTTP print. It uses signatures to identify web servers. So here we run the command against our web server on port 80 and it tells us with a probability score saying 76% confidence that this is an Apache web server.
13:02
So at this point we can say with some confidence that the web server is running Apache and we know what we're going up against. So next we need to identify the database. We've identified that we're running the Linux operating system and
13:21
we're running Apache as the web server. Next we're going to do is identify what the database version is or determine if it's MySQL, Postgres, Oracle, MS SQL. You can see some weird stuff out there. For the most case if you're using PHP you can probably guess with the high probability they're
13:42
running MySQL on the back end. So to do this we're going to use a union select poisoning query. The way this works is we're going to take the original query that the developer wrote and we're going to mirror it with our own code and we're going to match those up so that the result set is returned together. So what you do is you
14:03
write a select ID and then you do union select and then you've got to figure out how many columns that are in that query so that the union will match the original query. So you just start with one and you enumerate and go two, you enumerate three, four, five and then once you get a
14:21
valid result back you can then know how many parameters there need to be in that union select so that it matches the original query's column count. So here we have our union select. I just used nulls. You could use ones. You basically want to avoid things that use special characters so that it can get past filters and other
14:44
things. That's a more complicated subject by passing web filters but just to keep in mind, you know, don't use ticks. Use, you know, pretty safe SQL queries. So here what we're doing is we're doing union select with the original query and we're going to match it up with
15:03
version so the last column there we're going to have the version and we get the database version which is 5.4, 5.540. So next what we're going to do is we're going to use the concat function in SQL which is different
15:20
between all of the different databases. And so MySQL and Oracle are similar so we need to just verify that it is a MySQL database and not an Oracle database. So here we want a union select so we do 1.1.1.1. Here I am using ticks. And then we get back here in the line
15:41
order when it merges the query AB. So we know the concat worked. We run the Oracle test. We do BB or concat. We don't get results. We return zero. So we're fairly certain that we have a MySQL database on the back end. So at this point we can Google the version
16:01
number and verify that, you know, all that version seems to correlate to MySQL. We have a good understanding of what we're up against. And now we can start pulling data from the architecture. So at this point you have a select statement and we're just going to try and get as much
16:21
data as we possibly can out of the database. If you're attacking it, an attacker might pick selective items. They might go over user names and passwords. For the most part at this point I'm going to show you how all of your data will be stolen out of your database just from this one flaw. So the
16:41
first thing we're going to do is we're going to enumerate the user database of the MySQL database, not the web application that the programmer wrote. This is the database that maintains access to the connections to the database. And so we're going to use a union select. We're
17:01
going to select user host, user password, and then we're going to know all the rest from MySQL.user. If the credentials that were originally set up on the PHP code are root, we'll have access to this database. If they secure their credentials and put a least privileged user account in the MySQL database, we won't have access to this table. But
17:22
you can see here I was able to determine that the local host connection has a user root and then there's the password hash from the database, the MySQL database. Here we can get the host name. I'm just using a union select. Here we can, so if you need to have more data in your union
17:43
select than the column count has, you can use concat to get more columns from different tables into one column and get that returned with the union. Another interesting thing is you can use the UUID function to get the MAC address. I did
18:03
verify this. I don't know if it works on all architectures. But the first part or the last part of the UUID returns the MAC address. So that might be useful for attacking other infrastructures. You can use the database command to return which database the connection is connected to. And
18:23
with this command here, you can see it gets pretty complicated. But what this does is it dumps all the tables and columns from the MySQL database that it has access to. There's more information there. And then see we have our output when we have the order details, order
18:42
number, tells us all the column names. So we can go through this and see where our interesting points of data might be. So next what we're going to do is we're going to pull all of the users from the web application. So this is usually a table called logins or users or something like that in the web application itself that's
19:01
going to contain either a clear text password or hopefully a salted hash password. But what we're going to do is we're going to pull that data and get users that we can use to log into the web application. So we do that by just doing union select and pulling that information from
19:21
this log in table that we had earlier. So now that we have hashes and we have usernames, one thing that we can do to attack this web application is crack these hashes. And before you can do that, you need to identify what these hashes are. And one tool you can use to do that
19:41
is hash ID. And hash ID is running in Python 3, so you'll need to set up a Python 3 environment to identify the hashes. So just a quick thing on password hashing. Don't use it forever. The guy who wrote it said stop using it. To
20:03
this day, I still find MD5 hashes. If you can, use password hash. It's a PHP function. The newer versions of PHP, it will be included by default. If you're running an older version, you can get PHP pass. It uses bcrypt and uses
20:22
a salted password for you. It takes all the magic and difficulty out of it. You can see here we've used the same password twice and generated a unique password each time. So if you're interested in hashing passwords or cracking, here's some information on it. You can use ‑‑ you can
20:42
reference this information. Hashcat is pretty good. John Ripper is great. Sequel map, which I'll talk about a little bit later, has a password cracker in itself. So just a quick touch on rainbow tables. Rainbow tables are like password crackers, but the hashes are stored in a database
21:02
and indexed so you're not generating a new hash each time to compare it against. So you want to use a combination of both password cracking and rainbow tables when you're testing the security of your hashes. Just a quick example. I ran my MD5s through hashcat on my GPU miner and with
21:26
four GPUs I was able to get these passwords using the rock you list within two or three minutes. All right. Now for some more interesting stuff. So we've attacked the database,
21:44
but now what we're going to do is we're going to attack the operating system of the database and we're going to do that by looking at files on that system. So going back to architecture, if the database and the web server are both sitting on the same system, you might be able to look at
22:02
the code files on the system using your SQL injection technique. So by doing this, I take a look at, I load the file and then I use a union select to push that file out and I can view, hey, here's the user name and password for
22:20
the database and I've just, you know, gotten credentials that way. So this goes back to your database or your web server set up. Your web server set up, you know, when you're, nothing's working, right? You changed to mod 777, right? Get it to work. This is why you don't want to
22:41
do that because if that's 777 and the MySQL user is the same, the MySQL user can touch that and if there's a SQL injection vulnerability, I can overwrite that, which we'll later. So this comes down to if you have a MySQL database and a web application running on the same server, you want to make
23:01
sure that the web application is not running with the same privilege as the database. You want to have them in completely separated, isolated environments. By default, CentOS and Ubuntu and all the other Linux distros appear to have that separation, but a lot of times administrators will just push everything as the root user. When you have everything
23:22
as root, then everything can touch and cross contaminate and you can modify files. So here, by default, so this is my attack against the operating system and by default I was able to pull ETSI password. It was readable with the MySQL injection as the root user on the MySQL
23:42
database and I got a list of users from the ETSI password file. Luckily I was not able to read the ETSI shadow file, which would have all the hashes for the operating system passwords. So that's at least secure and blind for me on a default configuration. But I now have user names that I can
24:04
use to brute force or attack or go against other servers. So here's a list of interesting readable files. You can get the resolve.conf, the message of the day, SSHD config and other
24:21
places or even Apache config so you can figure out how the server is configured. So at this point you'll be thinking, okay, I've got this SQL, I've got this select vulnerability and so I want to modify the database. It would be much easier to just rewrite the hash on the login table and then
24:43
login with a password that I already know. So if you have a SQL injection and you're using union select, I was not able to find a way to do an insert and update using a subquery or nesting query. What a sub and nesting query are is when you have a query inside a query where you have the where
25:03
statement that's the selecting item is the query result returned from a future query. So just a little bit more about subqueries. Like I said, I wasn't able to figure it out. So if someone can do that, I'd be really interested in seeing
25:23
your results. So Bobby drop tables, right? We cannot have a talk about SQL injection without Bobby drop tables. It's just not possible. So you're like, oh, I can modify the database just using a semicolon and then
25:42
terminating the query and running another query. Well, if the up-to-date version of my SQL I query on this version of PHP, I was not able to use query stacking. Excuse me. So no Bobby drop tables, unfortunately. There is a MySQL
26:00
multi-query that does give you this functionality, but why would you use it? I don't know. One of the problems of PHP is it lets you do all kinds of things that you probably shouldn't. Okay. Some fun stuff. So we're going to go on to remote code execution. And so at this point we've got
26:23
usernames, we've got passwords and we're going to look at a couple of scenarios on how we can attack this architecture. Web shells. Web shells are great. So what we're going to do with web shells, we're going to demonstrate how you can use PHP code to put a simple back
26:42
door that will be executed by the web server and possibly by the web server operating system. And these are web shell functions that PHP has. So this is a good idea to disable these if you don't need them. And I can guarantee that you don't need them. So we don't need execute shell execute. If
27:04
you're running shell execute, the only real example is if you're writing code for like net gear or something like that or one of those small home office networking appliances
27:20
where you have to run operating system code. And to do that you need to make sure that you're properly escaping and parameterizing your code or you're going to have injection problems. But as an attacker we can take advantage of this function to run code on the operating system. Eval. Eval. I hate eval. Don't use it. If you're a PHP coder, please do not use eval. I can't think of a reason
27:45
to do it. What eval does is it takes a string of code and executes it. So you can write PHP code that executes PHP code. I've seen some weird stuff. I've seen developers put PHP code that they pull from strings in the
28:02
database and then execute it. Don't use eval. I can't stress this enough. It's a dangerous function. Disable it. Get rid of it. One of the more hidden ones is assert. Assert does the same thing but it's used by developers to test code and make sure that operations are running correctly and their
28:22
conditions are what they expect them to be. So you've got to make sure if you're using assert that you're doing it correctly and that you're not providing user input into the assert that isn't sanitized or cleaned. We have the create function. Create function is great. Takes a string of code
28:43
and turns it into a function that you can call later. And then using dynamic variables here in PHP, we can call any function in the code. Another couple of dangerous functions is include. By default, PHP will include files remotely. So you
29:01
can store PHP code on a remote server. If you have access to the include function by a dynamic variable, you can manipulate it to actually pull code remotely. So that's a good thing to disable that functionality. So here's an example web shell. It's pretty basic. We're just going to call the system and then we're going to pass in a get
29:22
parameter called command. We call the URL via curl or just through the web browser. We pass it the command LS. We get out the output and we can see that these files, you know, shell that PHP is on that server. Then we can use a PHP
29:41
code eval to run PHP commands and then do a little bit more discrete, discrete back door by running preg replace because preg replace looks pretty benign, right? You're looking through the code. Oh, yeah, preg replace. I'm doing some operation. I can't remember. So you can sneak that
30:02
in there and it might get past a code review and you have a possible back door inside your code. I don't have time to go into super detail about web shells but there's more information on iron geek and then library of web shells is a great resource. It has all kinds of web shells for pretty much any architecture you can think of. So remote code
30:25
execution. There exists a multiple avenues of attack that we can attempt. First we're going to try and upload a PHP script by the my SQL write function. Like I said earlier, if the web server has on every variable or every file, I
30:44
can overwrite those files if the my SQL server and the web server on the same system. The other possibility is I can try and upload code using an upload feature. So if the web application itself has a file up like a picture upload, I can take advantage of that and see if I can get it to pass my
31:03
PHP code and write it to a file and then later execute it through the URL. Third is kind of a last ditch effort. It's kind of a social engineering attack. I'm going to talk about wild card poisoning. This has kind of been like a vulnerability feature that's been in Linux for a very long time. It's been on the full disclosure list. It's where I
31:24
found it. Basically it just takes advantage of the Linux star commands to run commands. It's kind of an injection attack in and of itself. So writing files. Here we're going to use the into out file, which is going to take
31:43
our PHP code and push it to slash temp. I know by default most web applications can write to slash temp, so I send it out there, see if the query runs, look at the file, see if it's actually there. Yep, it is. If I can find possible write
32:01
points, you know, a good place to look is temp, cache, images, files. All right, you know, basically just try and numerate the web application, see if you can find a place where there's weak permissions. Writable files by MySQL. So this is the default. These are the only ones of interest I
32:21
could find. So default install, it's kind of secure in the fact that the MySQL user is a different user that doesn't have permissions on the web server. Like I said again, if the web server and the database are running on the same system and they have the same permissions, then at this point I can change those files. Like I said, this is what I
32:46
talked about earlier. Here's some more detail about a Black Hat presentation that was done a couple years ago. It's got more detail on remote code execution and file writing. So application upload feature. What we're going to do
33:01
is if it's not filtered, we'll just upload a PHP file. If not, we'll try and manipulate the PHP file so that it can be uploaded. So here's some example vulnerable code. And here all it does is just take files from the user and upload them. So that's one way. There's other examples on there
33:26
you can look in and dig deeper on getting past filters and stuff like that. So if you can't write files on the web server and you can't upload files, one thing you could try is doing a wild card poisoning attack on the system.
33:46
So if the MySQL user can write files, it can write to MySQL, right? So one thing that you could do to attack the system is just fill up the operating system, fill up the disk with MySQL general logs, right? Most database
34:02
administrators, they might go in there and say the log is full and delete it. Some of them might go in there and try and be like, well, why is it so big? Well, it's so big, I don't want to work with it on the web server, so I'm going to S copy it off the system. So using wild card poisoning is basically it works like this. So we have the LS
34:22
command, the LS-L, and the LS-*. If I have a file on the operating system that's dash L and I do an LS-*, that dash L is interpreted as a command that's being passed to the LS command. So we can take advantage of that. And the
34:43
proof of concept is here on the defensive code down below. I've provided the link. And what this does is in this example is it takes advantage of S copy or no, this one takes advantage of tar that owns S copy. So the administrator might
35:02
tar up the file. Well, tar has a parameter that you can pass it that will actually execute code. So you can upload a bunch of file names, set them up correctly. This is something you want to test because the order is important, so you need to make sure that the file is in the correct order. And then when the administrator comes in to S copy out this file or
35:24
tar up this file, they're going to run this vulnerable code and you can possibly get a shell or get access to the system. And then here's the S copy example. It uses the dash O command to run a script. And so a little bit
35:42
about reverse shells. So last year I did a DEF CON talk on intro to back doors when we talked about reverse shells and net cat and stuff like that. So if you're interested, this is just a basic PHP reverse shell that's taken from pentestmonkey.net. And you can just do a PHP dash R and
36:03
it will do a reverse connection and you'll be able to get remote code execution on the system. And you just hit up a net cat listener, bam, you've got commands that you can run. All right. So what we've seen from this is that they're just a simple vulnerability. So someone just
36:22
barely learning PHP code has completely left their system unsecured. And we were able to steal a lot of data. We were able to take advantage of the operating system. We've been able to manipulate it and even possibly gain control of the system. Just a little bit of a recap. Get the
36:41
user password. So what's next? So at this point you have a pretty good understanding of SQL injection. A lot of this research has already been done and built into the SQL map tool. With this knowledge you can build better queries and run the tool better. So I encourage you guys to just get in there and play with SQL map and learn how it works.
37:05
Here's some injection resources, too, if you're interested. Another thing that you might want to research, too, is privilege escalation because by default these systems, the Apache service and the MySQL service are not running with
37:20
root privileges. So if you want to get full access and root the system, you'll need to do privilege escalation. Here's some examples of PHP secure code. If you want to write PHP secure code, filter your input. PHP has a great filter input library. Just set your variable length. So when
37:45
you're taking data in, one thing you can really do to limit the damage that someone could do is if you have a string that's not supposed to be more than nine characters, cut it off. MySQL also has user defined functions. This is
38:02
pretty cool stuff if you want to get more advanced stuff. It lets you kind of write modules and other things to take advantage of the MySQL system. Here's some security guides on how to harden your LAMP stack. And then for some code
38:20
review and analysis, here are some free tools. The rip scanner is kind of old, but it kind of gives you an insight of where you might have vulnerabilities in your PHP code. And so here's my credits. Icons were from icon archive and the background was from PPT backgrounds. Thank you.