Hacking .NET(C#) Application: Building and Breaking Layered Defense
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 | 163 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen 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 und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/50195 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201581 / 163
6
13
16
17
18
19
20
21
22
25
28
29
30
31
40
41
44
45
49
51
52
53
54
55
57
58
60
61
71
74
75
76
78
84
85
91
92
93
94
95
96
98
99
100
105
106
107
112
115
116
117
118
122
123
124
125
127
128
129
130
131
132
133
135
136
142
144
150
151
153
155
156
157
159
160
00:00
Gewicht <Ausgleichsrechnung>Gebäude <Mathematik>SoftwareentwicklerComputersicherheitSoftwareSprachsyntheseSystemprogrammierungUnternehmensarchitekturAutomatische HandlungsplanungDigitalsignalFokalpunktKryptologieSchlüsselverwaltungDemo <Programm>DatenkompressionServerWidgetComputersicherheitKartesische KoordinatenExploitMultiplikationsoperatorReverse EngineeringDemoszene <Programmierung>MalwareComputervirusDemo <Programm>SchlüsselverwaltungDatenbankPhysikalisches SystemServerProdukt <Mathematik>FokalpunktBitrateImplementierungAuthentifikationGewicht <Ausgleichsrechnung>DatenkompressionTwitter <Softwareplattform>Gebäude <Mathematik>WellenpaketSprachsyntheseBitKlasse <Mathematik>HalbleiterspeicherBildschirmfensterBenutzerbeteiligungMechanismus-Design-TheorieDifferenteSoftwareschwachstelleZahlenbereichMusterspracheEchtzeitsystemVerschlingungPatch <Software>AdserverUnternehmensarchitekturSoftwareentwicklerSoftwareAnalysisKryptologieDatenfeldÜberlagerung <Mathematik>Pivot-OperationGenerizitätZeitzoneGrundraumInternetworkingGüte der AnpassungVerband <Mathematik>Software Development KitComputeranimation
06:33
TrägheitsmomentBoolesche AlgebraZeiger <Informatik>SystemaufrufMIDI <Musikelektronik>COMKartesische KoordinatenDatenfeldWeb SiteKategorie <Mathematik>Objekt <Kategorie>Konstruktor <Informatik>Single Sign-OnOrdnung <Mathematik>BildschirmfensterParametersystemAusnahmebehandlungFunktionalHalbleiterspeicherTexteditorSichtenkonzeptPunktWellenpaketWurm <Informatik>Elektronischer FingerabdruckInjektivitätMechanismus-Design-TheorieProzess <Informatik>Physikalisches SystemDemoszene <Programmierung>InformationSpiegelung <Mathematik>MatchingInstantiierungSpeicherverwaltungSoftwareFramework <Informatik>MultiplikationsoperatorUnternehmensarchitekturMAPFundamentalsatz der AlgebraVariableDatenstrukturKlasse <Mathematik>UmwandlungsenthalpieZeiger <Informatik>TabelleSoftwareentwicklerTypentheorieEchtzeitsystemLaufzeitfehlerKontrollstrukturDienst <Informatik>URLQuick-SortPasswortBitrateFolge <Mathematik>Überlagerung <Mathematik>PlastikkarteSpeicherabzugKette <Mathematik>Message-PassingHackerAuthentifikationQuaderGruppenoperationPivot-OperationRPCGewicht <Ausgleichsrechnung>Grundsätze ordnungsmäßiger DatenverarbeitungDemo <Programm>SystemaufrufMicrosoft dot net
12:54
ComputersicherheitBitrateSoftwaretestPunktExogene VariableRechenwerkGrenzschichtablösungDatenverwaltungServerDienst <Informatik>DistributionenraumSchlüsselverwaltungRohdatenKlasse <Mathematik>EchtzeitsystemObjekt <Kategorie>ChiffrierungNeuroinformatikInformationProgrammierumgebungGatewayDatensatzServerMultiplikationsoperatorUnternehmensarchitekturSoftwareentwicklerDienst <Informatik>BelegleserDatenbankKomponententestPunktMusterspracheFokalpunktSchlüsselverwaltungVektorraumGewicht <Ausgleichsrechnung>MAPInformationsspeicherungHackerSystemverwaltungGemeinsamer SpeicherDefaultExogene VariableComputersicherheitRechenwerkLoginInjektivitätSoftwaretestPhysikalisches SystemAutorisierungPivot-OperationBenutzerbeteiligungFirewallSoftwareExistenzsatzNormalvektorRechter WinkelProdukt <Mathematik>ProgrammierparadigmaStandardabweichungDistributionenraumDatenverwaltungTypentheorieProtokoll <Datenverarbeitungssystem>BildschirmfensterAnalogieschlussSpiegelung <Mathematik>HalbleiterspeicherKartesische KoordinatenFestplatteWeb-DesignerMaschinenspracheDatenmissbrauchPatch <Software>Fortsetzung <Mathematik>TeilbarkeitAnalytische MengeGamecontrollerDatenflussDifferenteOffene MengePortal <Internet>FlächeninhaltEreignishorizontProzess <Informatik>Automatische HandlungsplanungDreiecksfreier GraphGruppenoperationSkriptspracheComputeranimation
20:14
GatewayComputersicherheitAnalysisExogene VariableSoftwaretestTime line <Programm>Wiederherstellung <Informatik>SystemprogrammierungWärmeausdehnungPunktKommensurabilitätKonvexe HülleRechenwerkHash-AlgorithmusInjektivitätQuellcodePunktGewicht <Ausgleichsrechnung>SprachsyntheseSystemplattformSyntaktische AnalyseHalbleiterspeicherPhysikalisches SystemMultiplikationsoperatorGamecontrollerAutomatische HandlungsplanungPlastikkarteServerUnternehmensarchitekturDatenbankAnalysisComputersicherheitKartesische KoordinatenElektronischer FingerabdruckLaufzeitfehlerSystemprogrammAppletInformationDatenflussProdukt <Mathematik>DifferenteKonstruktor <Informatik>ProgrammierumgebungTypentheorieSpannweite <Stochastik>HD-DVDMAPProgrammierungDatenstrukturHackerCodeStabNeuroinformatikEinfach zusammenhängender RaumAnalytische MengeAuthentifikationBildschirmfensterQuaderVirtuelle MaschineDichte <Stochastik>BenutzerbeteiligungSpeicherverwaltungSoftwaretestObjekt <Kategorie>Erweiterte Realität <Informatik>FirewallGüte der AnpassungVerknüpfungsgliedEreignishorizontSoftwareGatewayExogene VariableWiederherstellung <Informatik>ZahlenbereichKategorie <Mathematik>Sampler <Musikinstrument>Patch <Software>Reelle ZahlZentrische StreckungNormalvektorBitFortsetzung <Mathematik>Textur-MappingTexteditorLoginGradientGenerator <Informatik>KorrelationsfunktionComputeranimation
27:21
ComputersicherheitAdvanced Encryption StandardHash-AlgorithmusChiffrierungPasswortInformationsspeicherungKryptologieFunktion <Mathematik>WechselsprungEin-AusgabeServerCodeAbstrakte ZustandsmaschineChiffrierungPasswortInformationsspeicherungKartesische KoordinatenDifferenteDatenbankKryptologieHackerComputersicherheitObjekt <Kategorie>InformationDatenstrukturBitCompilerQuick-SortPhysikalisches SystemUnternehmensarchitekturSchlüsselverwaltungHash-AlgorithmusAbstimmung <Frequenz>PunktKontextbezogenes SystemCASE <Informatik>KorrelationsfunktionInternetworkingProzess <Informatik>TabelleEin-AusgabeAlgorithmusFunktion <Mathematik>Computeranimation
29:20
SystemprogrammBefehlsprozessorPunktMultiplikationsoperatorLaufzeitfehlerMAPGewicht <Ausgleichsrechnung>KontrollstrukturSoftwareentwicklerObjekt <Kategorie>MaschinenspracheComputersicherheitDatenstrukturHalbleiterspeicherUnternehmensarchitekturDemo <Programm>Grundsätze ordnungsmäßiger DatenverarbeitungKartesische KoordinatenGüte der AnpassungSchlüsselverwaltungZahlenbereichQuaderIsing-ModellSkriptspracheSystemverwaltungLeistung <Physik>ExploitFormale SpracheGamecontrollerSpiegelung <Mathematik>Spannweite <Stochastik>Prozess <Informatik>Virtuelle MaschineCASE <Informatik>GeradeQuick-SortBitrateCodeAlgorithmische ProgrammierspracheSprachsyntheseLochkarteKontextbezogenes SystemInjektivitätComputeranimation
32:12
Abstrakte ZustandsmaschineCodeInnerer PunktGatewayLastSummengleichungCodeMathematikLaufzeitfehlerJust-in-Time-CompilerFunktionalSpannweite <Stochastik>HalbleiterspeicherVirtuelle MaschineMaschinenspracheLastteilungQuaderFirmwareDatenbankMusterspracheServerPhysikalisches SystemComputersicherheitUnternehmensarchitekturRohdatenSchlüsselverwaltungKalkülSoftwareentwicklerGrundsätze ordnungsmäßiger DatenverarbeitungKartesische KoordinatenSpeicherabzugPunktMultiplikationsoperatorTelekommunikationGewicht <Ausgleichsrechnung>Rechter WinkelNeuroinformatikTangente <Mathematik>BildschirmfensterFinitismusBenutzerbeteiligungWeb ServicesMehrrechnersystemLeistung <Physik>UmwandlungsenthalpieCompilerMaschinenschreibenSprachsyntheseGatewayDienst <Informatik>Offene MengeComputeranimation
35:12
ImplementierungFramework <Informatik>StandardabweichungSoftwareProgrammierumgebungServerVisuelles SystemRechnernetzSystemprogrammierungDatenbankSoftwareschwachstelleCodeKanal <Bildverarbeitung>ComputersicherheitVerschlingungNotebook-ComputerFlächeninhaltMailboxPatch <Software>SoftwareschwachstelleProzess <Informatik>Honeywell-HoldingCodeServerMomentenproblemReverse EngineeringBildschirmfensterDatenbankDienst <Informatik>GruppenoperationGatewayFortsetzung <Mathematik>TelekommunikationBildschirmmaskeFlächeninhaltSoftwareComputeranimation
36:09
VerknüpfungsgliedDienst <Informatik>EinsComputersicherheitZustandsdichteSoftwaretestRechenwerkInformationsspeicherungPasswortKonsistenz <Informatik>Wiederherstellung <Informatik>UnternehmensarchitekturAutomatische HandlungsplanungInformation-Retrieval-SystemPRINCE2COMSoftwareentwicklerDemo <Programm>DifferenteBenutzerbeteiligungAuthentifikationTelekommunikationProzess <Informatik>Leistung <Physik>ProgrammierparadigmaSoftwareentwicklerMusterspracheUnternehmensarchitekturPunktWeb logComputersicherheitKartesische KoordinatenDienst <Informatik>CodeInformationsspeicherungPasswortRechenwerkWorkstation <Musikinstrument>EntwurfsmusterServerAutorisierungWeb-DesignerDoS-AttackeHackerGruppenoperationGeradeZahlenbereichSoftwareDatenbankGatewaySpieltheorieComputerunterstützte ÜbersetzungGanze FunktionQuick-SortMechanismus-Design-TheorieInjektivitätPhysikalisches SystemKryptologieExogene VariableValiditätOffice-PaketIndexberechnungGefangenendilemmaSoftwareschwachstelleSichtenkonzeptVerknüpfungsgliedEreignishorizontMultiplikationsoperatorFortsetzung <Mathematik>KomponententestDigitales ZertifikatProdukt <Mathematik>EinsSprachsyntheseWiederherstellung <Informatik>IntegralGüte der AnpassungStrömungsrichtungWort <Informatik>Computeranimation
40:56
Softwareentwickler
Transkript: Englisch(automatisch erzeugt)
00:01
Cool. Well, hello. It's nice to be in NDC and see you guys. How many of you have seen any of my talks at the previous NDCs or other conferences? Okay, cool. Well, we're going to be covering something different this time.
00:22
Typically, we talk about application security as it pertains to reverse engineering and malware and exploits that applications can suffer at the hands of bad people. And the tools we put out facilitate this. This time
00:45
we're going to be focusing on assuming that something has been deployed into the wild. You're doing a web server. You're doing whatever it is that your business does. How do you defend it? How do you go about stopping someone with an
01:02
intense amount of skill from intruding in to your application and doing incredibly bad things to your enterprise? So this is hacking .NET applications, building and breaking layered defense. Just as a preface, layered defense is the pattern that wins in secure design principles. The anti-pattern
01:22
is crunchy on the outside, soft on the inside. Your enterprise has a good perimeter, but once you breach the perimeter, it's a free reign. And most companies, most products are crunchy on the outside and juicy on the inside. I'm John McCoy. I'm Topher Timson. And this is security for
01:42
the developer. When you're tasked with building a secure product or just a product, we're going to be looking at building and breaking layered defenses. Whether you're mobile, building for the internet, or desktop developer, this should apply as a generic engineering principle. This speech we're going to
02:03
cover layered defense, attack techniques, and software security in the general sense. Digital Bodyguard, we do training, advising, implementation support. We focus on enterprise systems, design and defensible patterns, infrastructure, and
02:21
deployment. And then I'm Topher Timson. I'm currently a security researcher. I'm a security researcher in the United States for universities, so I've been working for the past two years on doing .NET memory hijacking techniques. I see a couple of you were at our hacking class yesterday, so that's good. And then I also do a little bit of security training on the side and then arbitrary Twitter link. And what is security? And let's focus on
02:47
segmentation. That's the key focus of this entire speech, segmenting each of your systems from other systems and not trusting any one of them. We're going to be looking at something like your authentication or your crypto
03:03
server and you have a database. How do you build these two systems, interconnect them without either one of them trusting the other? You want to assume that every system is compromised and defending itself from every other system. And this leads to layered defense. As they breach one layer, they fall through and come to the next layer. So your product has a database,
03:24
detect when I attack you, and defend against my attacks. And if I do actually have the keys, if I do successfully breach your enterprise, maybe I take over your AD server first before I come to your servers, how do you reject me from your servers if I do have the proper keys? And you have the world, it
03:42
comes into your server, it hits you, and you serve data. That's the premise of most applications. When you have the web coming to your server, typically you're 95% vulnerable. I'm always going to get into your web server. You have to have a number of people coming into your web server doing arbitrary
04:01
traffic and then this arbitrary traffic flows through your enterprise. This is the same as airport security. When you have a number of people getting on an airplane and you have one bad actor, it turns out when we do security analysis in the US on airport security, it's 95% vulnerable. And security works in
04:22
different ways. What does work for airports is a steel bar. A steel bar that stops people from going through a door. And there are some security mechanisms that this steel bar, or as we term it, a ballistic protection secure access emergency ingress and egress decompression release system, or a steel bar. And this costs $10,000 with a 95% success rate. And that's what we're
04:48
looking at. How do we get from these scanning systems that provide all of this ability to considering that your web server, you have a patching window. It takes you time before you can use the new Microsoft patch. In that time I
05:02
can reverse, a number of people reverse engineer that patch and make it a weapon so I can deploy it against you. So you have your patching window, you have O days against your server, you have weak authentication, application updates on there, and it goes on. Weak IT, side systems, broken kyptology, and by the end of the day I'm going to be able to take your web server. With
05:23
enough time, with enough resources, with enough tries, I'll be able to take your web server. And when we run these basic attacks, this is the premise. You have your users logging in and you have your crypto keys coming out to your
05:40
users. Your users are able to gain access to your database. This is the anti-pattern that I see all over industry and that I'm trying to push giving patterns to defend against. Let's switch over demos to a hands-on weaponization run and we'll look at what happens. I find an O day, I find a
06:02
reach, and we don't have advanced technology that allows for all of the fancy things that you might find in industry, so we're going to manually switch over real quick and do some demos. We're able to, once intruded into
06:23
your system through a number of exploits, pivot around your applications in real time in memory to take them over. And what does that in the field look like? What does it look like to intrude from one application to another? So
06:40
you're building some sort of application, you're trying to make it secure, you're doing things like allowing users to authenticate into it to perform whatever actions. This is pretty much consistent across the enterprise. However, what you can do is you can launch an attack once you're on a physical box on any application you want that's running in the .NET framework. So in this example
07:01
I'm going to show you how easy it is to bypass authentication and steal some information about a user on a common fingerprint reader software, which is commonly used to authenticate with single sign-on, unlike Windows applications, etc. And you can take this in place of your authentication service or any of your mechanisms that are validating users. So what I'm going
07:24
to first do is I fired up the software. I'm going to use Gray Dragon, which is just a remote DLL injector. So if you're not familiar with DLL injection, it essentially means I'm going to forcibly load a new DLL in my target application. So I'll just drag these crosshairs, it'll fire on to this fingerprint reader. I'll select my payload, which is going to be Gray
07:44
Frost. If you were at our training course yesterday you know what these mean and I'm happy to talk about what they are afterwards. Essentially what it's going to do is Gray Frost is the DLL. It's a C++ loader, so it'll go through and it's going to attack the 4.0 CLR that this application is running. So I'll inject into this application and now a new GUI Gray
08:03
Storm is up, which is a memory reconnaissance tool. So through this I'm able to go through everything in my target application, look at its classes, look at its methods, look at its resources, etc. What I want to be able to do with this software once it's there is get something special from it. And
08:21
what's special about this specific application is once you're authenticated into it, it saves your Windows password in plain text in an object. How do we get objects, you're asking? Well it turns out that all .NET objects are stored on something called the managed heap. While we asked yesterday, three of the .NET developers in the room actually knew what that was. So essentially what it is is it's a heap that all objects that are
08:43
instantiated at runtime go into, and each object points to an object instance. And from that you can get things like fields and properties using reflection. You also get a pointer to the method table which gives you all instance methods. So unlike people seem to think with the .NET framework, there's actually a plethora of pointers spread out throughout it. So
09:03
we're able to go through with reflection, create an object, and then figure some things about it. So I'm going to go to the qlclr assembly, which is going to contain the specific class that I want to target. The specific class that I want to target is qlclr.user, and then through reflection I'm going to actually go and find its void constructor, and that is
09:23
somewhere here. So this constructor, I don't know if you can see it, I'll magnify it for you, is going to take two complex types. So it's taking some sort of passport object and then an infra-native object. However, using reflection it doesn't really matter what that thing takes in because we can just pass null arguments. The point of this isn't to actually use this
09:42
object, it's to learn something about it and be able to learn the location of managed heap in memory because the dotnet framework is not going to give it to us pure. So I'll come over here to this method editor functionality of GrayStorm, and I'm just going to add two arguments in order to call that constructor, and then I'll call that constructor. So now I have access to an
10:01
object that I've created at runtime, and you can see that it has properties on the side here, it has fields, and it has instance methods. However, what I want to do with this is I want to be able to get all other objects on the managed heap that match this object. So I'll go through and get all objects and debugging information spits out. Oh, that's awesome.
10:22
Live on the edge, right? Living on the edge. I'll just run through that really fast. And this is what happens behind the scenes when someone does get an ODA to run on your system. They pivot around your processes, pivot into a process, move through your memory structure, access variables, and attack it at the core fundamental level. And this is, as developers, what we don't
10:43
typically consider someone might do to us on a weekend. And with these tools, this is a kind of attack that you certainly can pull off from beginning to end in a weekend quite easily, if not a couple of hours, if you're highly skilled. So now over here, because the application shows not to crash this time, I didn't pray to the demo gods hard enough apparently
11:03
last night, you'll see that it has things like fields and properties. Okay, it didn't find the right one. So what happens is I actually haven't authenticated yet with this application. So let me try one more time. The demo gods are not happy. So there's QLCLR user. I'll get all objects. So now it's
11:26
found them. And now look, I have a proper one. So what it has is you can see that it has a field called SystemString.WindowsPassword. However, it's currently not set to anything because I actually haven't yet authenticated with this application. So what I did is I set a
11:44
bunch of breakpoints and started reverse engineering this application, and I realized that in order for this object to be on the managed heap, you have to log into the application. So if you do something like swipe your finger or enter your Windows password, that object is now on the managed heap. So when I go back and get all objects once again of that specific type, you
12:09
should see some magic. And there it is. NDC Oslo 2015 is the password on
12:29
this application that I authenticated with. So now this opens up a whole new level of attack chains once you're dealing with authentication and how not to do it. By simply putting something in an object in plain text that exposes
12:41
your password after it's been cryptographically hashed, somebody can come into your application and now take advantage of the managed heap at runtime and see what objects are instantiated on your target application. And this is typically what we're covering in the attacking hacking sequences. Giving the ability to quickly move around applications, raw in-memory access objects,
13:05
and move around the class structure, the object structure, in real time without reflection at the pure assembly level. And that was pulling an object out of the pure memory area, not going through reflection but the pure memory of .NET, the raw actual machine code of .NET. And that's what you're
13:23
going up against when you're talking about an attacker. You're looking at someone that has an immense amount of skill and focus in a very specific area and they're breaching your server typically for either fun or gain. Let's take this back to the analogy of you can do body scanners for $200,000 or
13:42
you can do a steel bar for $10,000. If you get into industry you're gonna have people offering your company $200,000 scanners and IPS gateways and they're gonna stop all of these threats. And in the real world they don't actually stand up. It stands up for a half hour, a couple of hours until you know what it is and what works around it or how it works.
14:04
And that's where we come to how do you actually roll this in? How do you roll this into your development cycle? What does it actually look like? I'm gonna run you through security stories, security unit tests, security defensible points in your architecture and your process, response plans, and security
14:21
test and deployment. And this is actually fairly easy. I'm trying to show that if you plan this in, if you think about it just a couple of hours at the beginning of your process, you can identify holes and you can actually get ahead of it and it really doesn't cost a lot of time. It's not as
14:40
hard as it sounds. I'm trying to make this sound fun and easy, I really am. Data protection at the end. Let's go through a security story. I want to separate the concerns of who manages the data. We're a health care company. We're taking in health records and at the edge of our gateways we're taking in
15:00
user confidential information. And let's run through this security story. I have a computer on the edge of our network. I encrypt the data, not when they send it up to the server but before they send it up to the server. And this is highly important for point-to-point encryption. When this travels over the network, when it travels up to the gateway, when it travels through SSL, if
15:23
you break the transport protocol, there's crypto inside of it that isn't on the server. So if someone is able to compromise the server, take it over, all they see flowing through is encrypted data. We put this in the database. I'm going to advocate that we don't decrypt it and store it in the database and store it encrypted at rest. We leave it encrypted in the
15:41
database at rest, however the database is storing it. We don't decrypt it there. The database in fact does not have the keys to decrypt it. I'm proposing a pattern of design that has a database full of encryption. That's all this in. It's a document level database full of encryption. If you took this and walked right out with it, there would just be encrypted data. There are no
16:04
keys, there are no attack vectors on it because it's simply encrypted data. It's much like finding a fully encrypted hard drive. You just have a big blob of highly encrypted protected data. And we have key servers and databases in this pattern that I'm advocating. Where a key server is responsible for the
16:22
distribution and key management and policy of who receives these keys, and the database is only regarding availability and performance. It's not caring about necessarily who has access to the data. It's primary responsibility is only availability and performance. Of course we put in security access and all that, but the default of a database should be locked.
16:45
When you have a database it defaults open. SQL was never meant to be secure. SQL is meant to give information, not destroy information. Our key server has given our user a key, our database shares encrypted data to a consumer of
17:03
the medical records, and only at the edge node does it ever become unencrypted. So all the way through the network I can show it was encrypted. None of my sys admins could have attacked your data, stolen your data, exfiltrated your data. That only at the edge node is it ever decrypted. And this is an easy pattern that once you consider it will give you an immense amount of
17:23
security. And then you layer security on top of this, but at the end of the day at the most basic level the data transitioning through our enterprise was always encrypted. Let's look just at another security story. And much like you might look at a user story, let's talk about a hacker using our
17:40
enterprise. We plan for and we hope for good users, but let's plan for and in a way hope for in a hacker using our system. He comes through our web portal, he pivots through our server, pivots around our enterprise, through our auth server, and then comes in through a point-to-sale back-end system with a weaker security going to the database. We can consider this from the
18:06
signer application for this event. And that's just a story. We can codify unit tests. A unit test, everyone knows of SQL injection, whether you're desktop or web developer hopefully. When you have SQL injection coming in and it
18:21
travels to your databases, we can develop a security unit test just like a unit test to validate this. When the attacker sends SQL to the database, the security unit test fails when the SQL makes it to the database. It succeeds the unit test is successful if the SQL is instead detected, sent to a honeypot,
18:41
sent to a login server, and not propagated to the database. Much as you would write a unit test for does it store the correct information, you write a unit test for SQL injection. And we can use in unit, we can use our standard paradigm of production. This sits right on top of our normal application development. Quickly going to run through defendable points. We want
19:02
to defend our database. When they come in to hack it, they find a protected layer that that database goes from being a SQL to a data access defense layer. That defendable layer is actually a soap and rest that's protecting our database. That its sole purpose for existence is to defend
19:22
that database. It does logging, it does repelling the attack, detecting the attack. We can put a firewall in front of this rest service and say we want it to talk to the server. And the server should come in on port X and it should be on IPY or TCP. And we can put a firewall between the server
19:41
and this computer. And this is critical for stopping the patching window. That maybe you find a certain protocol that the server is vulnerable to. And instead of being vulnerable to it, we have a server that's protected by a firewall with just one port, with just TCP, with just one service, with just rest. And it's highly defendable as opposed
20:03
to SQL or a web server, which is vast amounts of traffic. You're talking about one type of traffic in a very controlled environment. We can scale out our service into logging, detection, honeypot, build a defensible infrastructure just around this one database. We can shard out the database into different types of data and we can do different flow
20:23
control analytics on different databases. And this gives a scalable and defendable system. I highly advocate that when you're laying out your application design, you incorporate that you're going to have these connection points. That these connection points are going to be
20:40
hard and that you and your UML can define what port should talk to what computers and this can be codified by the IT staff on deployment. So let's do a quick security analysis. Even though we never want to lose our payment gateway, let's just for a few minutes consider what happens if it does. If the hacker comes in through our firewall, goes through our data access layer and actually makes it
21:03
to our database, we can just throw out some numbers. What does our credit card processing database look like? How much is its value? What happens if they actually take it over and are able to take control from us, our own database? And we don't have to worry about it, but we can just plan for it. What is our
21:26
system down? In one day, can we bring up a replacement? In a week, can we harden against that attack? And in a month, can we deploy this hardening to our entire enterprise so when they attack another server and another server, we can resist their attack? And this is where it turns into our response plan.
21:42
We can plan ahead from an event that we don't want to happen and at least consider it for a few minutes. And then we can say, well, in X amount of time, good or bad, this is what we're looking at, to recover our credit card database. And we stood up a firewall in front of it and we're starting to harden it. And then we're starting to harden our other
22:01
database servers and we're starting to deploy this augmentation to the rest of our enterprise. And this can be our plan moving forward. And this can be applied to most any problem. We finally get to testing and deployment. And you should work out like it's real. You should pretend like you're really going up against an adversary. You can have someone log in and come through your POS system with
22:24
proper keys and try and have them attack your database and see if they can make it. You can have one of your other team members fire SQL injection. You can have one of your team members come into your rest server and just spend 20 minutes trying to DDoS it or just however you want to attack it. And this little bit, 15 minutes, offers
22:45
someone a prize if they're able to get past it. If you're able to get in, you get $500. You get a Tesla, whatever your Norway prizes are. Because if you're working out like it's real, if they're able to take control of your credit card database, you want to know that. If some
23:01
junior analyst on your team can take control of your database without any advanced skill, when you come up against a real hardened attacker, you're going to lose your database. And that's probably worth it to know. And you can plan. Plan for this event. And you might lose. You might lose the first time and the second time. And this is good. It's better to lose a fight against your
23:22
junior analyst. And it's better to lose in a safe environment than it is to lose in an unsafe environment, of course. And without this trial and being willing to accept that maybe our system isn't as robust or secure as we might want, we can move forward past that. So let's look at some basic memory attacks of
23:43
Graywolf. And we're going to look at what it takes to open up an application and find a vulnerable point. So what does it look like to open up an application and just move around it in a couple of minutes? This is literally
24:01
what I did in a few minutes just before this speech. I drag in here. In Graywolf, the tool he showed was an in-memory attack. Graywolf is an on-disk IL parsing editor. It's not a decompiler. It's an editor. Anyways, I dragged in here JetBrains platform shell. And in a
24:22
couple of minutes, I was able to find JetBrains application defines static constructor. And so in a couple of minutes, I was able to tunnel into this JetBrains product and see, oh, there's a license seed. There's an
24:41
update seed. There's an update security key. And this is in a couple of minutes. You can quickly jump in, find that one weak point, and move through the application to a devastating attack. I can come through and see how they're laying out. So when I breach your server or someone breaches your server, they're going to move around it like, I don't know what this
25:02
is. What's this? It's upgrade. That's interesting. Here's a constructor. And I can move around this application like it was my own source code. I can make modifications and other speeches and online. There's a lot of our information about how do you go in
25:22
and modify an application. But it's fundamentally true that any application has all of the commands inside of it to run that application. That source code is commands. There's hopefully a one-to-one correlation between the code you type in and what comes out. And so there's a one-to-one correlation between what came out and what you typed in, whether it's C++, Java. Any application,
25:44
any platform, hopefully has a one-to-one correlation. And utilizing a utility like Graywolf to actually decompile the IL code on your .NET application allows more sophisticated runtime attacks. If I had just started going after a fingerprint reader software in memory without knowing
26:02
anything about the high level control flow, I wouldn't have been successful. By utilizing a utility like this and being able to parse through the structure of the program at a higher level while it's on disk opens up a wide range of possible attacks that you can carry out. This is why it's so important that when you're developing software to make it secure at the initial
26:23
point because you don't want to be releasing patches or agile developing the thing as you go along and not have it secure out of the gate. Because people like us can go through, read your source code, even if it's not openly available utilizing decompilers and attack them at runtime and look at all objects on your
26:41
managed heap. And this turns into the persistent attack. When I breach, maybe I don't come through your web server. Maybe I send your HR a packed PDF. And when they open the PDF, I'm able to get a couple of machines. I'm able to get on a Windows box. Once I get on a Windows box, there's authentication
27:02
hashes and I'm able to reuse these hashes and slowly pivot around your enterprise. And as I learn more and more about your enterprise, about your software, about your architecture, the threat grows. And if you can detect me at the earlier stages, you can repel me. But if you can't detect me, then there's really no repelling me. And so just to cover a little bit of basic
27:31
information that there's a huge difference between encrypting and hashing. And this is just some of the basic information that like when a security person comes in, they look at your application to be
27:41
concerning of when you do have a hacker come in and they do make it to your database and they're able to gain access to it. Are they looking at your password storage with cryptology or hashing? And we all know that, hopefully, if anyone doesn't, raise your hand and be embarrassed of the difference between storing your passwords with
28:02
encryption and hashing. And encryption gives us the ability to do it one way and undo it the other way. Hashing gives us the ability to theoretically one way encrypt it. This is fundamentally untrue. Hashing is reversible. There are ways to try and disguise how hashing is
28:23
reversible. And there are ways to make millions of possible inputs that could have led to that output. But typical hashing is not. You can look up rainbow tables and you can make it computationally hard. But typically, hashing is a reversible process for a hacker, not for a developer. And if you ask the
28:41
internet, hashing is a one way algorithm. But for a security person, there's a one to one correlation between the hash that went in and the hash that came out in most all cases. There are some advanced techniques to prevent that. And so we can look at some, can we get another context
29:01
switch? So when we are looking at attacking an enterprise, we're looking at the vulnerable points. When we're looking at defending an enterprise, we're looking at defending the vulnerable points. Yeah, so what you're able to do once you have gone onto a system as an attacker
29:22
and you've gone through using some sort of decompiler and you've learned the structure of a target application that you're trying to attack, it makes it a lot easier. If you're in the enterprise and you're developing something that's maybe utilizing keys, you can go through, find the objects that contain those keys, look at what the keys may be, look at what salt's being used, and then through reflection, actually go
29:42
through and change those things. What you can also do in an application once you're inside of it is actually mess with the control flow at the assembly level. With .NET in particular, as we know, when you compile it, it actually produces an IL code, or intermediate level language, which then at runtime gets just in time compiled to the actual machine code that
30:03
the CPU is going to run. So if you go into a utility like PowerShell ISE, which is just an IDE essentially for PowerShell developers, and you inject something, you inject gray frost into it once again. And how many of you have ever seen PowerShell ISE? Good? Oh, nice. So you
30:26
might appreciate that if someone, there's a lot of exploits to move between boxes, and this is a defensive speech, but if someone did make it onto your box, this is an attack that would be easily executable and deployable against it. And
30:44
the demo gods are super unhappy this afternoon. So typically when you're going up against an application, you're targeting its memory structure, its key value points. When you're attacking people, you're attacking the process, procedure, and the power that the user has over the enterprise. In this case, the ability to modify
31:03
a sysadmin's scripts as they're running it, or... That's the wrong assumption. At this point, the
31:22
developer of ISE for PowerShell is not responsible for securing this. You should consider the box lost. There is a number of, is it right, 32-bit, 64? Yep. This is a good example of awesome security that a developer has put on their target application, which you
31:41
should do to prevent DLL injection, because OK. Well, we will context switch back. All right. You want to describe the punch line? Go through the whole process, and in your minds, visualize,
32:00
because it's... Yes. So what you can do is you can essentially go through, if the demo gods were happy this afternoon, I apologize sincerely, but you can go through with the target application, piece through its structure in memory. So you go from that IL code down to actual raw runnable machine code, and through the just-in-time compilation process, as it turns out, Microsoft
32:21
chooses to leave the memory in that range readable, writable, and executable. Bad. But essentially, because of that core functionality in the just-in-time compiler, you can go through at runtime and change machine code for a specific method. So what I was going to show you is how easy that is to do with an application like Windows PowerShell, and I was going to do some cute little trickery to
32:42
manipulate that, but demo gods. And maybe if we have a couple of minutes, we'll pop a calc or some base demonstration. So we're able to go underneath .NET with these tools and techniques, and actually affect the raw machine code of a function post-jit. And this is something that a normal .NET developer does not
33:02
do, does not consider, nor should. But if we get on your system, we are able to do basically anything, and no, you can't get us off. You should consider the system lost. If a system is infected, burn it, and replace it, and move on. And anyways, defensive patterns. You're looking at replace your outer gateway
33:21
rapidly. We intruded into it, and we were able to reconfigure the memory. There is no unconfiguring the memory. You replace it. You maybe even assume that we were able to reflash the firmware on it, and you sell the box on eBay, or destroy it, I guess, depending on how paranoid you are, and you grind it up.
33:41
Anyways, give no rights or keys access to the exterior gateway. The first computer that someone comes to in your enterprise should have no rights over your enterprise, no access over your enterprise, and a confined communication channel. If you assume that I'm going to take over the first box that I touch, which you should, or any security professional,
34:03
you should consider that once I touch that box, you should be concerned with detecting me. You will never be able to resist the intrusion, but hopefully you can detect the intrusion. If you can detect the intrusion, you can respond. If you can't detect the intrusion, then I have an unlimited amount of time to make that happen. And load balancing and
34:21
segmentation, we're all used to robust scalable systems, and this is what we get with being able to quickly burn down and rebuild a system. So when you have your external system, which I just call IO, coming to your POS, that's the first system that I hit. When your point of sale system communicates to your database, it's over
34:42
encrypted SOAP and REST services. And when your web server talks to the database, it's over encrypted REST and SOAP services. If your web server, A, has a database on it, B, talks directly to the database, once I take over your web server, even if you have detection, you have a finite window of time that I can operate in to try and pivot to your database server. And databases were
35:01
not meant to be secure. And so I just want to take a quick tangent on something that I was going to leave out of this speech, that here's a company that's purely concerned with security, Honeywell. They build a lot of the airplane defenses
35:21
and all of that. And when you go to Honeywell, you look on their job search area, and you look, oh, they're looking for REST and SOAP, and they're looking for someone that has SQL Server 2005. So when I'm touching their external gateway, I'm looking at, OK, I'm going to prep all of the weapons that I'm going
35:40
to use against this group, that I'm going to go over and I'm going to look for code execution vulnerabilities. And I'm going to look for patches that were done. And then I'm going to find the reverse engineer of those patches. So when I finally do make it through, all I need is a 30-second window to pivot. Once I can touch their database, I can get in it if there's a patch window. And if there's not that, then I
36:00
can look at what kind of networking they were using. And I can prep and have a lot of tools and weapons ready for that moment when I finally do make it past their exterior gateway to their database, and I can talk directly to their database. That's why you should have a SOAP and REST service always, and you should have a service and never let any user ever touch your database.
36:21
It should be a segmented network with no form of communication. There shouldn't be AD. There shouldn't be a workaround. You should segment it. So you have an authentication server for your web server. Let's have a different authentication server for our service and our POS. So when I do breach your web server, if I do take over the auth server, I'm only
36:41
taking over the auth server for your web layer, not your POS, not your service layer. You can have as many authorization servers and segmented servers. So our exterior is a hardened guard station. Our web layer, it's just a guard that lets everyone through. Between our POS and our database is a checkpoint where we can
37:01
validate and try to detect maloccurrences, and we can try and defend this architecture with a number of layers that, when you go through the front gate, millions of people go through. The guard station is built to be resisted and detected. The guard checkpoint is built to see anonymous traffic and be able to try and understand whether it's good
37:21
or bad. Someone has assumingly broken through our service, and they're attacking our database, the checkpoint can try and understand that this is occurring and be another line of defense just on the network layer, and a response team to take action when we do have a breach. And when we have this authentication, when we have this segmentation, when the
37:41
hacker comes in, he comes in through a guard post, and he comes in, he takes the authentication server, he takes the service, he comes through a hardened checkpoint, he makes it over to the database, and he makes it through the auth server. And we can just, for five minutes, talk through how do we respond to this, how do we respond if he gets the crypto from our auth service, comes
38:01
back in through a point of sale system. And not that it'll happen, but what do we think about it? Is it earth-shattering, is that the end of the enterprise, or is it we can recover from this? And you know, it's a bad thing, because we can talk about protection from denial of service unit testing, SQL injection unit testing,
38:21
password storage validation, authentication recovery, communication integrity, we can we can talk about all of these things. And that's what we do. And this isn't just talking about building your enterprise, it's also what you do once it's built. You can go through the proper mechanisms of actually building up
38:41
everything to have SOAP, REST, a secured database, a secured network, but if you're not writing the code yourself and using some sort of vendor, you need to be sure that you're always updating that vendor service, and whether or not that vendor is currently susceptible to attacks. The whole entire attacker and defender game is more or less a cat and mouse game. So like the
39:00
attacker comes in, they write a book about how to attack something, or a blog post, or an exploit, and they own whatever it happens to be. Then somebody else comes along and protects that thing. They defend it, they update the software, etc. If you leave any point of your enterprise vulnerable, somebody that wants you bad enough and is motivated by money, greed, and power, they're gonna
39:21
get in, because it's the defender's dilemma. There's a thousand ways that they could get in, they only need the one. And so when you do assume they are going to breach your exterior enterprise, you can have an authentication service that's segmented off protected. There's another enterprise within the enterprise, and there's two enterprises within that,
39:40
and each one is defended against the other ones. And that's what we do. We look at companies, and we look at products, and we try and advise. And I'm trying to bring some of this back in and start codifying it into principles and patterns that can be at least considered by the development community, because typically as web developers we have
40:01
certificate, we have a couple of SQL cleaning, and we have some of these paradigms. But as desktop developers, we don't even have that. As desktop developers, it's in our enterprise, and it ships, and we're happy. And as more and more the power of applications is growing, hopefully more and more we'll consider this security.
40:20
So I'm Digital Bodyguard. I'm still Topher Timson. Yup, we're still us. So thank you for coming, and after the speech, if you want to see some of these advanced demos that will work after the speech, we'll show you that. consider the security, and hopefully this has been helpful in developing more secure design pattern applications. Thank you.
40:48
You guys want to talk about, feel free to come up. We're really friendly people. Good job.