[00:01.630 --> 00:02.730] All right. [00:02.950 --> 00:03.710] Good evening, everyone. [00:03.950 --> 00:05.710] Thanks for taking it to 11. [00:05.950 --> 00:07.090] It's pretty late at night. [00:07.690 --> 00:13.170] I guess tonight I'm doing a talk covering the planning, execution, and mitigation of backdoor attacks. [00:14.150 --> 00:16.850] First, I'd like to thank HOPE for, I guess, having me speak. [00:17.130 --> 00:19.130] It's actually my first talk here. [00:19.690 --> 00:27.370] It's good to be around a good bunch of developers who are doing good things in the information security community, building things. [00:28.310 --> 00:33.310] I mostly do, like, attack work for defense. [00:33.610 --> 00:38.970] But it's nice seeing the people that build things, talking to them, and conversing with them. [00:40.170 --> 00:41.610] Yeah, so far it's been unique. [00:42.090 --> 00:45.050] So this talk, it's primarily offense stuff. [00:45.330 --> 00:51.150] But that's okay, because a lot of people here are developers or they're interested in the community. [00:52.310 --> 00:56.170] And a lot of this stuff pertains to you, because you may be in a targeted demographic. [00:56.170 --> 00:59.890] You may be executing bad code that you don't know about. [01:00.090 --> 01:05.750] And it's just good to know what's out there and what things are being done. [01:06.830 --> 01:10.130] So backdoor attacks that target early in the supply chain. [01:10.290 --> 01:13.550] That's what most people think about with backdoor attacks. [01:13.690 --> 01:14.930] Like, oh, Tor is compromised. [01:14.930 --> 01:16.070] It's backdoored. [01:16.390 --> 01:18.890] Or this full-disk encryption is backdoored. [01:19.070 --> 01:24.290] Those are all attacks early in the supply chain where it's hitting things in the development cycle. [01:24.290 --> 01:28.250] And that's not necessarily all of the attacks that would happen. [01:28.450 --> 01:38.450] It might be more feasible to do things in the deployments or later on when things are being used or already implemented on a server. [01:38.630 --> 01:40.930] Like, you have some PHP scripts on a server. [01:41.110 --> 01:46.630] It could be an attacker just doing some post-exploitation and backdooring those applications. [01:55.540 --> 01:58.400] Looks like I'm having a little technical trouble right here. [01:58.600 --> 01:59.160] Okay, there we go. [01:59.640 --> 02:00.940] So a little about me. [02:01.580 --> 02:03.920] Spent some time in the active reserves. [02:04.480 --> 02:05.640] Deployed to Afghanistan. [02:05.640 --> 02:12.700] I guess an interesting fact about me is I worked with Bo Bergdale's unit. [02:13.000 --> 02:18.020] If you're not familiar with him, he's the missing in action Afghanistan soldier. [02:18.340 --> 02:20.820] There is a huge national ordeal about him. [02:21.360 --> 02:24.700] Some people said he was AWOL deserter, things like that. [02:25.020 --> 02:28.000] Michael Hastings from Rolling Stones did an article about him. [02:28.460 --> 02:34.840] And I was also involved during his recovery efforts and was one of the first units on the ground during that point. [02:35.680 --> 02:38.600] So lately, I've been employed as a red team lead. [02:38.840 --> 02:42.380] Primarily do operations against research and development environments. [02:42.700 --> 02:46.580] So I'm quite familiar with how some DevOps goes. [02:46.880 --> 02:50.080] Not necessarily things in like the public open-source community. [02:50.340 --> 02:52.860] But I do know some R&D type environments. [02:55.980 --> 03:01.520] Just as a mandatory disclaimer, I'm not representing any organization here. [03:01.520 --> 03:11.860] All this information should be used for defense and to design some best practices for your dev environments or personal use for applications. [03:12.600 --> 03:14.920] That being said, don't watch my application. [03:15.300 --> 03:25.440] Don't send pull requests for WordPress with like 5,000 line PHP web shells to the WordPress repository, which someone has done a couple years ago. [03:25.440 --> 03:27.880] That type of stuff is pretty obvious. [03:32.850 --> 03:36.990] So next up, we're going to move to the agenda as soon as this slide loads. [03:37.690 --> 03:38.610] Okay, there we go. [03:39.030 --> 03:42.770] So what we're going to be talking about is the introduction. [03:43.670 --> 03:47.250] There's basically a reason why backdoor attacks are successful and worthwhile. [03:47.610 --> 03:49.610] And we'll examine why those conditions exist. [03:50.470 --> 03:56.670] We'll also go over a situation report covering some of the recent events that have happened. [03:57.370 --> 04:02.090] 2016 has been really a fascinating year as far as attacks have happened. [04:02.690 --> 04:18.490] If you think of like default passwords as the 90s, SQL injections for like the 2000s, and maybe social engineering for the past decade, I kind of think the 2020s will be purposefully designed and inserted malicious code into applications. [04:18.490 --> 04:26.170] It's just because the security environment is getting so much more difficult to find bugs. [04:26.510 --> 04:28.850] Like you need to be extremely brilliant. [04:29.090 --> 04:34.530] Like in the early 2000s or 90s, buffer overflow is really rudimentary. [04:34.870 --> 04:37.010] Now there's so many protections in place. [04:37.490 --> 04:41.730] It's a nightmare trying to do exploit development on that. [04:43.890 --> 04:46.750] So we'll go over the conceptualization of an attack. [04:47.370 --> 04:50.930] Most likely steps the adversary takes while they do these attacks. [04:51.890 --> 04:55.590] Lots of businesses and organizations develop their own attack methodologies. [04:55.950 --> 04:57.790] Lots of it's like copyrighted, stuff like that. [04:58.630 --> 05:01.190] What I'm going to show you is something I came up on my own. [05:01.470 --> 05:03.830] It's really code-centric. [05:03.830 --> 05:11.090] If you kind of think of attack surface, people really describe it as like, okay, it's just whatever ports you have open. [05:11.970 --> 05:14.410] Run an M-app scan, that's your attack surface. [05:14.910 --> 05:16.930] And really it's not that. [05:17.110 --> 05:20.750] It's the attack surface is which code base you can interact with. [05:21.130 --> 05:28.970] And that's generally with a physical, social, or networking traversal method. [05:30.730 --> 05:35.510] So I'm also going to cover some code snippets in the surreptitious code section. [05:35.770 --> 05:38.030] Don't worry, nothing's too technical. [05:39.330 --> 05:40.370] Nothing's too crazy. [05:40.770 --> 05:48.910] I'm just adding the code snippets for basically visual aid and for those who can look at it and maybe understand it just a little bit more. [05:50.770 --> 05:57.170] So surreptitious code, I'm talking about like code that you don't want to be found. [05:57.170 --> 06:03.190] There's a lot of backdoors that are kind of like known, like some of the NIST standards that have come across. [06:03.410 --> 06:05.490] We're like, oh, this is a definite backdoor. [06:05.650 --> 06:06.330] We know this is. [06:06.630 --> 06:08.750] That's not necessarily surreptitious code. [06:09.330 --> 06:14.910] Surreptitious code is backdoors that you don't want anyone to know that's there. [06:15.130 --> 06:20.430] So as far as like NIST standards and things like that, I wouldn't consider that surreptitious code. [06:24.610 --> 06:27.510] So perimeter-based security isn't what it used to be. [06:28.010 --> 06:31.670] I'll be covering that in the next slide as soon as it loads. [06:31.930 --> 06:31.990] Okay. [06:32.610 --> 06:35.530] So perimeter-based security, it's pretty obsolete. [06:35.770 --> 06:37.580] If you kind of look at the picture, you can see... [06:38.270 --> 06:40.770] Think of this as just basically web traffic nowadays. [06:41.090 --> 06:42.830] You know the traffic's crossing the wire. [06:43.110 --> 07:00.150] But with encryption so pervasive, which isn't a bad thing, it's hard to determine what's actually in those containers, what that traffic is, without really doing things that are computationally intensive and a lot of manual work. [07:01.070 --> 07:04.810] So I want you to think about all the ways that data can enter a network. [07:05.450 --> 07:08.770] It can cross over the wire, encrypted, unencrypted. [07:09.270 --> 07:12.150] It can become preinstalled on hardware. [07:12.610 --> 07:14.770] It could be brought on-premise by a person. [07:14.770 --> 07:19.070] How much of that data is actually inspected to be safe? [07:19.790 --> 07:27.150] The ongoing trends towards encrypting all traffic makes inspection of data in transit extremely difficult. [07:27.490 --> 07:34.630] The exact very mechanisms in place to encrypt data in transit and on the wire, these things are designed to protect people and organizations. [07:35.030 --> 07:45.170] But it's also a double-edged sword where attackers are like, ha-ha, now you can't see any of this malicious traffic I'm sending to you and I'm also going to ex-fill all your data. [07:45.990 --> 07:50.370] Nowadays, we have... everyone has super-fast high-speed connections. [07:50.950 --> 07:57.190] Like, ten years ago or in the 90s, 56K modem was, like, pretty widespread. [07:57.490 --> 07:59.950] DSL, ISDN, really things that are really slow. [08:00.070 --> 08:04.370] Nowadays, it's... you can ex-fill gigabytes of data within minutes. [08:04.370 --> 08:09.490] And that's... that really creates a huge liability for trying to defend networks. [08:27.750 --> 08:31.030] I'm running a VM, so it's... it's a little slow. [08:33.350 --> 08:36.590] Okay, so... applications share common dependencies. [08:38.370 --> 08:40.630] Developers don't really like to rewrite code. [08:40.810 --> 08:43.530] So what ends up happening is the application... [08:43.530 --> 08:46.270] library ecosystem isn't very diverse. [08:46.810 --> 08:49.130] Everybody's using the same libraries for everything. [08:50.430 --> 08:51.890] There's plenty of examples. [08:52.170 --> 09:00.210] The image is actually an animal ecosystem, but it's pretty much the same concept where people develop core applications. [09:00.350 --> 09:02.230] Those trickle down to everything. [09:02.830 --> 09:11.210] And then there's the same vulnerabilities, the same issues, the same code base, getting widespread into each application. [09:12.650 --> 09:26.510] So that being said, applications, since it's such a huge, like, haystack, they're one of the easiest ways to smuggle code into an organization and have that executed on that organization. [09:37.340 --> 09:51.740] So... yeah, earlier on in the year, there was, like, the whole left pad debacle where the guy was... there was, like, a copyright claim, and NPM took down his code for that specific repository. [09:52.120 --> 09:55.190] So he was just, like, FU NPM, I'm taking everything down. [09:55.500 --> 09:59.040] So he took down an application called left pad. [09:59.380 --> 10:04.080] It's like... it's a library or 48 lines of code. [10:06.580 --> 10:09.080] That being said, it's like 48 lines of code. [10:09.080 --> 10:19.710] It's... I'm not saying, like, developers are lazy or anything, but it's... the libraries, like, trickle down everywhere, where, okay, I'm not even going to write 48 lines of code. [10:19.810 --> 10:22.020] I'm just going to import it, and I'm going to be done with it. [10:22.260 --> 10:23.580] And that's not a bad thing. [10:23.740 --> 10:27.830] It's... everyone has business requirements or they need to make things with a timeline. [10:28.500 --> 10:31.900] It's just not realistic to build things from scratch. [10:32.810 --> 10:38.760] But as you can see, huge amount of downloads just in the past month alone, almost half a million. [10:39.600 --> 10:41.330] A really simple application. [10:41.810 --> 10:50.570] And this thing definitely probably goes on to banking systems, other critical systems, and who knows what could... [10:50.570 --> 10:52.260] what could happen if someone backdoored that. [10:52.600 --> 10:59.660] I don't think it's necessarily worth a lot for a malicious actor, just because it's so widely used. [10:59.760 --> 11:01.160] There's only 48 lines of code. [11:01.380 --> 11:03.040] So it's like, where are you going to hide the backdoor? [11:04.460 --> 11:11.500] But there may be similar applications where, hey, it's... this library is being used in everything. [11:12.120 --> 11:17.780] I could possibly blackmail the author, or I could pay them off, or something can happen. [11:19.080 --> 11:21.500] And that could be a risk for an organization. [11:30.820 --> 11:33.790] Okay, so just to recap the conditions. [11:35.000 --> 11:37.640] Basically, nowadays, network IDS, useless. [11:40.100 --> 11:44.680] And that's... I don't think any attackers are like, oh, my God, that IDS is in the way. [11:44.900 --> 11:45.790] I'm so scared. [11:46.440 --> 11:48.240] Nowadays, everyone's just like, okay, whatever. [11:48.400 --> 11:54.460] I'll just use a VPS somewhere at a major thing, and encrypt all my traffic. [11:54.460 --> 11:56.640] It's just going to look like plain HTTPS. [11:57.860 --> 11:59.200] Okay, I got no problems. [12:00.620 --> 12:04.440] So another condition is we have common dependencies across applications. [12:04.900 --> 12:08.380] So basically, everything is from the same bloodline. [12:09.180 --> 12:10.300] Haystacks of code. [12:10.740 --> 12:13.270] Basically, not enough people auditing it. [12:13.660 --> 12:15.060] A lot of things are closed source. [12:16.300 --> 12:19.040] And that's where some binary attacks can take place. [12:19.300 --> 12:20.800] But it's just so much code. [12:20.920 --> 12:21.820] Everyone's writing code. [12:22.100 --> 12:23.460] Everyone's writing a plug-in. [12:23.460 --> 12:28.920] Grandma has, like, toolbars covering 50% of the browser window. [12:29.600 --> 12:31.540] Who knows where all that code's coming from? [12:33.510 --> 12:37.080] So what all this leads up to is essentially supply chain attacks. [12:37.300 --> 12:40.200] And that's what the backdoor certifications code is. [12:40.400 --> 12:49.030] It's... you're doing a supply chain attack where you're trying to insert your code somewhere in the cycle before it gets executed. [12:49.030 --> 12:52.080] And that cycle could be while it's in the development process. [12:52.080 --> 12:54.560] It could be while it's hosted on a web server. [12:54.800 --> 12:57.800] It could be while it's being transmitted on the wire. [12:58.040 --> 13:03.860] Or it could be after the fact while it's installed on the computer and being ran. [13:25.390 --> 13:27.630] So I just wanted to add... [13:34.420 --> 13:37.620] A lot of times, code will be, like, reverse engineered. [13:38.420 --> 13:40.920] And then redeployed into the supply chain. [13:40.920 --> 13:45.560] A lot of instances could be, like, binary applications. [13:46.320 --> 13:53.720] Specific, like, I guess, foreign terrorist organizations out there might have, like, encrypted messenger applications. [13:54.040 --> 13:56.140] So some of these things could be reverse engineered. [13:56.880 --> 13:59.600] The public key encryption could be broken. [13:59.820 --> 14:03.080] And you can do this just through binary disassembly. [14:03.240 --> 14:09.080] Just say, if it's using public key encryption, you just force it to use a low exponent or something like that. [14:09.080 --> 14:12.820] And then that makes it very easy to decrypt those messages. [14:13.640 --> 14:16.040] And so what happens is that'll happen. [14:16.320 --> 14:23.240] It'll be reinserted into the supply chain, whether that's forums, communication channels, other things like that. [14:28.020 --> 14:29.460] So who's doing it? [14:29.580 --> 14:32.360] So basically, it's a who's who, everybody. [14:32.840 --> 14:42.040] Nation states, proxies, a lot of people claim there's, like, a differentiation between, like, the proxies and the nation states. [14:42.240 --> 14:45.980] But it's hard to discern if there really is a difference. [14:50.630 --> 14:52.030] Organized cyber criminal elements. [14:52.030 --> 15:00.650] There's been a lot of examples where banking Trojans have been added into massively deployed applications. [15:00.910 --> 15:02.110] And we'll cover that later on. [15:02.610 --> 15:04.550] And then, I guess, some independent actors. [15:04.950 --> 15:10.150] A good example would be when Facebook was compromised earlier this year. [15:11.030 --> 15:15.250] It was actually during post-exploitation the attacker added the backdoor. [15:15.610 --> 15:21.530] But all they did was they compromised a device on Facebook's network perimeter. [15:21.790 --> 15:25.510] They edited a PHP login script. [15:25.650 --> 15:30.790] And then they had that login script direct all the user credentials to an attacker-controlled box. [15:30.790 --> 15:37.650] And that's a good example of, like, surreptitious code where it's deployed late in the supply chain. [15:37.650 --> 15:41.070] And then it's also doing something without the organization knowing. [15:41.370 --> 15:46.650] So, backdoor attacks aren't always at the developer stage. [15:57.990 --> 16:07.440] So, in the beginning of this year, the cryptocurrency exchange, Krypsy, had basically a $5.7 million worth of cryptocurrency stolen. [16:08.220 --> 16:12.670] The root cause analysis showed that a backdoored altcoin client was to blame. [16:13.860 --> 16:17.940] Krypsy basically runs, like, a bajillion altcoins, if you're not familiar with it. [16:19.140 --> 16:21.820] Like, I guess, the owner of it will run anything. [16:22.100 --> 16:23.360] Like, anything and everything. [16:23.880 --> 16:28.560] So, I guess, when the attacker did their analysis, they were like, okay, this exchange runs everything. [16:30.180 --> 16:32.860] Then he's like, okay, I'm going to buy one of these altcoins. [16:32.940 --> 16:37.420] I think he paid, like, $7,000 for ownership rights and developer rights. [16:37.420 --> 16:38.380] For the altcoin. [16:39.790 --> 16:47.060] He added a, basically, a fully functional low-level, like, script kitty IRC backdoor to the source code. [16:47.880 --> 16:51.030] And then, eventually, that's, you know, that hit the supply chain. [16:51.920 --> 16:52.960] Krypsy updated it. [16:53.170 --> 16:59.540] And then, bam, $5.7 million of cryptocurrency was stolen from the exchange. [16:59.540 --> 17:05.380] And I really like this as an example of, like, an attack that can happen on a business. [17:05.560 --> 17:07.530] Because that's definitely a business. [17:07.740 --> 17:09.300] The attacker is financially motivated. [17:10.720 --> 17:11.980] There was a goal in mind. [17:12.340 --> 17:15.800] It was actually, I think, a pretty genius plan. [17:15.940 --> 17:21.820] Because most people, when they think of attacks, they think, okay, I'm going to run up Nmap. [17:21.820 --> 17:23.320] I'm going to run Metasploit. [17:23.600 --> 17:25.860] Or I'm going to do some spear phishing or phishing. [17:26.540 --> 17:32.100] But for, like, a cryptocurrency exchange, their level of security is probably... [17:32.840 --> 17:44.700] Even though they were hit by a backdoor, they have a level of sophistication that they're probably resistant to phishing, spear phishing, and other attacks like that. [17:44.700 --> 17:47.080] So I thought that was... [17:47.080 --> 17:53.140] Not that I support it, but some good strategization by the attacker in that instance. [18:03.090 --> 18:08.610] Okay, so this is a commit message for someone patched the U.S. [18:08.770 --> 18:12.190] Federal Information Processing Standard encryption in SOCAT. [18:13.190 --> 18:19.490] The guy was actually, I believe it was like a Chinese person, patching U.S. [18:19.610 --> 18:21.750] Federal real encryption standard in an application. [18:22.990 --> 18:24.070] A little... [18:24.070 --> 18:26.670] Makes you a little, like, what's going on here? [18:27.810 --> 18:30.030] So we'll cover the bad prime later on. [18:30.690 --> 18:36.490] The bad prime is like a good example of bad code that was inserted into a mainstream application. [18:37.530 --> 18:49.590] But the guy, what he did was he submitted a patch, a quote-unquote patch, with a bad Diffie-Hellman in prime to a developer of SOCAT. [18:50.130 --> 18:53.250] And the developer was social engineered, I guess. [18:53.450 --> 18:56.830] And he was like, okay, I'll commit this for you and I'll merge it. [18:57.050 --> 18:59.150] And then it eventually was merged. [18:59.870 --> 19:06.810] So who knows who was listening in on federal information processing standard encryption during that time. [19:08.550 --> 19:13.370] And this one's interesting because there's a social engineering factor as well. [19:14.010 --> 19:16.810] All the communications, it's the public. [19:17.130 --> 19:18.930] They were made through a mailing list. [19:19.150 --> 19:20.430] So anyone can read it. [19:21.190 --> 19:28.730] Well, what's interesting is like the guy who actually submitted the patch is still employed at his company that he works for. [19:28.890 --> 19:30.110] And everything's like hunky-dory. [19:30.410 --> 19:33.390] And, you know, he's submitting pretty known backdoors. [19:33.790 --> 19:35.510] So that's interesting. [19:38.650 --> 19:39.250] Yeah. [19:48.230 --> 19:54.730] Okay, so here's basically like a cyber criminal group example. [19:55.140 --> 19:58.080] So Amy Admin, never actually used it before. [19:58.340 --> 20:00.360] But it's a remote access tool. [20:00.940 --> 20:07.140] Basically, the actors compromised the distribution server for it. [20:07.520 --> 20:09.140] They backdoored the code. [20:09.470 --> 20:12.490] Added their own remote access tool. [20:13.290 --> 20:14.710] So now you have two. [20:14.880 --> 20:15.340] Two and one. [20:16.100 --> 20:17.420] That's not a bad deal. [20:17.970 --> 20:19.520] And then they're distributing it. [20:20.540 --> 20:22.660] And things like these aren't uncommon. [20:23.140 --> 20:25.210] A lot of them aren't well executed. [20:25.580 --> 20:34.420] There's like the CentOS example where I guess an attacker tried to add an IRC Trojan into the CentOS image. [20:35.020 --> 20:39.960] Pretty much like immediately people are like, okay, the hashes aren't adding up. [20:40.400 --> 20:41.400] This is backdoored. [20:41.560 --> 20:44.800] And then that failed pretty miserably. [20:47.300 --> 20:54.180] And this is like an example of an attack during the, I guess, distribution phase of the supply chain cycle. [20:56.280 --> 20:59.760] Okay, so really interesting to me. [20:59.760 --> 21:04.200] I like to follow all the Daesh activities and things like that. [21:04.380 --> 21:05.380] Ghost security group. [21:06.580 --> 21:13.540] This is just an article saying ISIS forums are worried hackers are targeting their Android downloads. [21:14.840 --> 21:17.200] And there's kind of been some buzz about it. [21:17.360 --> 21:18.920] Like APKs have been backdoored. [21:20.400 --> 21:24.280] Other purposeful applications thrown into the supply chain. [21:25.300 --> 21:26.470] And things like that. [21:26.470 --> 21:31.400] I guess the intelligence gathering function of backdoored code. [21:31.540 --> 21:32.700] It's pretty tremendous. [21:33.140 --> 21:37.100] It's really easy to retrofit a binary with your own code. [21:37.340 --> 21:40.040] And then you just pop it somewhere on the supply chain. [21:40.490 --> 21:41.820] And basically you just wait. [21:47.010 --> 21:51.130] And I talked about earlier about even like... [21:51.130 --> 21:53.290] Everything doesn't even have to add a virus. [21:53.450 --> 21:56.410] It could just break functionality like for encryption. [21:56.410 --> 21:58.970] Just let's break the encryption in the binary. [21:59.230 --> 22:01.810] And no one will really be none the wiser. [22:04.290 --> 22:09.850] So that being said, if you're using like encryption applications, make sure you get it from a trusted source. [22:10.170 --> 22:16.330] Make sure there's good encryption on the wire while you're downloading it. [22:17.530 --> 22:24.690] So, yeah, we're moving on to the next portion of the presentation, which is conceptualizing an attack. [22:26.870 --> 22:29.330] There's various methodologies, like I said earlier. [22:29.610 --> 22:35.190] What I'm going to cover is something that I personally, I guess, developed. [22:35.490 --> 22:43.590] But it's basically a mix of like a code-centric targeting path and also like some military best practices. [22:44.210 --> 22:49.150] But if you kind of look at the visualization, it's attacks just don't happen. [22:49.430 --> 22:52.110] There's steps to get to the final end results. [22:52.290 --> 22:57.090] And like in Brazilian Jiu-Jitsu, you have to follow through everything to get there. [23:08.680 --> 23:12.780] So, this is the methodology, basically, I invented. [23:13.860 --> 23:15.160] Really hard to read. [23:15.440 --> 23:17.500] But I'll just speak it. [23:18.000 --> 23:23.260] So, basically, you have three concurrent phases. [23:24.580 --> 23:29.960] Your mission analysis is your phase that you're doing continuously through the cycle. [23:30.380 --> 23:33.020] Next up, you're doing your code target selection. [23:33.280 --> 23:35.400] And then lastly, it's your execution. [23:36.140 --> 23:41.020] So, your mission analysis, you're covering, like, what is your objective? [23:41.460 --> 23:46.740] When people, a lot of people think of hacking as like, okay, I'm just going to pop every single machine on this network. [23:47.020 --> 23:49.000] I'm going to own everything. [23:50.020 --> 23:53.260] That's really not necessary. [23:54.680 --> 23:57.540] A lot of times, you just got to figure out what your objective is. [23:57.740 --> 24:09.760] If it's, you want to, if an attacker wants to know the communications going on, you don't need full system control of that machine, you just need to maybe break the encryption. [24:11.500 --> 24:14.060] Next up, there's, I guess, the threat model. [24:14.640 --> 24:19.400] And this is going to show, I'm going to show you something like a code-centric threat model. [24:20.260 --> 24:27.100] And then there's also code-based recon, which is like, okay, what organization, what code does this organization run? [24:27.320 --> 24:29.120] What can I throw in their supply chain? [24:30.120 --> 24:31.680] And what would be interesting to them? [24:32.300 --> 24:34.760] So, next up is your code target selection. [24:34.760 --> 24:39.040] So, you got to pick somewhere to put the backdoor. [24:39.720 --> 24:43.480] Which application, which library, what it is. [24:43.640 --> 24:44.600] And that's what that covers. [24:44.980 --> 24:47.340] Next up is your backdoor selection. [24:48.320 --> 24:55.520] So, like I said earlier, it's, you don't need to throw full in system, remote system administration fools in there. [24:55.700 --> 24:58.880] You can just do certain functions and that work works. [24:59.240 --> 25:00.600] And then lastly, development. [25:00.600 --> 25:05.060] And then the third phase execution, I'm not really going to cover it during the presentation. [25:05.340 --> 25:11.600] But that's testing review deployment, which is a huge portion of the life cycle. [25:11.680 --> 25:16.040] Because you want to make sure everything's good to go before you deploy it. [25:24.910 --> 25:25.430] Okay. [25:25.590 --> 25:28.490] So, how does an attacker develop an objective? [25:29.210 --> 25:33.690] Objectives are rarely set just upon systems without an end result. [25:34.030 --> 25:35.730] There's always an end goal in mind. [25:35.730 --> 25:38.130] Attackers can be financially motivated. [25:38.630 --> 25:44.970] Most of these attackers consist of organized cyber criminal elements out to get your money. [25:45.250 --> 25:47.370] There's other attackers that are information driven. [25:48.670 --> 25:52.830] But there's also attackers that are looking for, I guess, physical effects. [25:53.390 --> 26:00.610] And some systems, like industrial control systems, have real world impacts if those are compromised. [26:01.230 --> 26:14.690] But to add to the physical effects, there's also psychological factors where if things are compromised or people suspect that code is compromised, they're not going to be willing to use it. [26:15.110 --> 26:16.510] Like, if you look at... [26:16.510 --> 26:26.610] There's been, like, articles where Daesh people are really hesitant to use Tor, things like that, just because they consider it compromised. [26:26.610 --> 26:33.450] So there is, like, psychological impacts of backdoors and things like that. [26:33.710 --> 26:36.510] And then, of course, can't forget the lulz. [26:36.770 --> 26:38.630] A lot of people do that for that. [26:39.050 --> 26:39.290] So... [26:51.110 --> 26:51.630] Okay. [26:51.750 --> 26:55.730] So, basically, this is my code-centric threat model. [26:55.730 --> 26:58.770] It's zero-day information just for you. [27:00.390 --> 27:01.110] It's... [27:01.110 --> 27:07.290] Basically, what this diagram means is interactable code base is an attack surface. [27:07.610 --> 27:08.050] So... [27:08.730 --> 27:11.110] If you really think about it, it's... [27:11.730 --> 27:13.990] Code base is what matters. [27:14.390 --> 27:15.750] And the people... [27:15.750 --> 27:19.730] The way people access it is through social, physical, or network means. [27:21.090 --> 27:28.310] So even, like, a web application that's running on a web server, all... [27:28.310 --> 27:31.730] The attack surface is what you can interact with. [27:32.030 --> 27:33.110] So it's... [27:33.110 --> 27:40.670] If there's fields in there that you can interact with, or other things, it's just not network ports, which... [27:40.670 --> 27:44.170] That's typically what people think of as attack surface. [27:46.750 --> 27:47.310] And... [27:47.310 --> 27:52.310] By doing these supply chain attacks, you can directly interact with the code base without... [27:53.390 --> 27:56.410] Bothering with network, or social, or physical aspects. [28:06.740 --> 28:07.300] So... [28:07.300 --> 28:08.220] Code base recon. [28:08.680 --> 28:09.240] So... [28:09.240 --> 28:12.080] Basically, what an attacker wants... needs to do is... [28:12.080 --> 28:19.820] They need to figure out what software is being used by, I guess, a group, organization, targeted demographic, whatever it is. [28:20.740 --> 28:27.560] They should figure out what software they're interested in, because they can always develop that, and then throw it in the supply chain somehow. [28:29.760 --> 28:30.720] And there's... [28:31.280 --> 28:34.680] I guess a good example of that would be, like... [28:36.120 --> 28:36.600] Cripsy. [28:36.900 --> 28:40.160] Like, you could always invent a new altcoin, and then just give it to them. [28:40.420 --> 28:40.900] And then... [28:41.360 --> 28:42.860] Because you know they're interested in it. [28:43.960 --> 28:45.740] And then also library dependencies. [28:45.740 --> 28:54.940] So you can figure out what library dependencies are through reversing a lot of things that are public-facing are interpreted code. [28:55.100 --> 28:59.420] So it's really not that difficult to figure out what libraries are running. [29:15.240 --> 29:15.880] So... [29:15.880 --> 29:19.320] Conceptualizing an attack for target code selection. [29:20.640 --> 29:28.320] So this diagram basically shows what criteria you want for good target code selection. [29:28.320 --> 29:31.200] You want something that's to be less audited. [29:31.420 --> 29:34.480] You want something to maintain target discretion. [29:34.480 --> 29:40.860] That way it's not easily identified quickly, because the goal is surreptitious code. [29:40.860 --> 29:42.020] It's not... [29:42.720 --> 29:47.660] To deploy widely known backdoors, because that's probably a different mechanism. [29:48.140 --> 29:48.780] And... [29:48.780 --> 29:50.020] I mean... [29:50.020 --> 29:54.460] Everyone knows there's been instances where widely known backdoors have been produced. [29:54.780 --> 29:58.320] And even implemented in systems while they're known they're backdoors. [29:59.740 --> 30:05.720] And then I guess the deployment location, which just basically means where in the supply chain you're going to toss it in. [30:05.720 --> 30:10.620] And then ease is also a factor that you want to look at. [30:20.680 --> 30:21.180] So... [30:21.180 --> 30:22.320] Your backdoor selection. [30:22.480 --> 30:23.440] What you want to do. [30:24.640 --> 30:25.140] So... [30:25.140 --> 30:29.360] When you're at your backdoor, you want to figure out what the objective is in mind. [30:30.580 --> 30:33.540] You don't want to just compromise everything for no reason. [30:33.700 --> 30:35.380] You want it to have a specific function. [30:35.660 --> 30:40.960] The most minimal function probably, because it's less code. [30:41.160 --> 30:41.640] It's less... [30:41.640 --> 30:42.280] Harder to be found. [30:43.140 --> 30:46.100] You want to limit collateral damage, because you don't want... [30:47.660 --> 30:53.300] If you do more damage, or it's more widespread than it needs to be, it's more easily found. [30:53.640 --> 30:55.920] So a lot of these attacks will be very specific. [30:56.280 --> 30:56.720] Like... [30:56.720 --> 30:59.100] Again, I can bring up the Cripsy one where it's... [30:59.100 --> 31:03.220] They didn't target Bitcoin or Litecoin or a huge thing. [31:03.320 --> 31:05.720] They targeted very small altcoin. [31:06.200 --> 31:10.280] But they knew the target was running it, and that was successful for them. [31:18.740 --> 31:21.140] So, where do these... [31:21.140 --> 31:24.620] Where to throw your malicious code in the supply chain? [31:24.820 --> 31:29.540] So there's forums, chat rooms, IRC, telegraph, websites. [31:30.060 --> 31:39.340] Websites are particular because that's generally the primary method to distribute software in a lot of cases. [31:39.340 --> 31:49.620] Share drives, if you're in the post-exploitation phase, you can always find some binary in a corporate share drive. [31:50.680 --> 31:53.140] Retrofit it with your malicious code. [31:53.320 --> 31:55.080] Leave it there, and then you just wait. [31:55.860 --> 31:59.180] Gold-billed images, that's probably a huge concern. [31:59.900 --> 32:11.480] I think there's been examples where 3D printers, they've had their gold images compromised, and there's been, like, malware on them. [32:12.340 --> 32:16.380] And that's been, like, tied to, like, espionage acts and things like that. [32:18.040 --> 32:25.760] Vendors, that ties with the gold, build images, and then if you're really crazy and reckless, attempt merge to main branch. [32:27.120 --> 32:29.780] That usually doesn't go well for attackers, I think. [32:35.360 --> 32:39.960] Okay, so we're moving to our surreptitious code section. [32:39.960 --> 32:42.960] So, the visual is just a book. [32:43.560 --> 32:44.560] It's cut out. [32:44.720 --> 32:46.360] There's bugling cigarettes in there. [32:46.560 --> 32:50.520] It's basically the same concept for code in binary as you... [32:50.520 --> 32:55.420] You want to smuggle your code into what looks like a normal application. [33:04.050 --> 33:06.380] So, generally, there's two methods. [33:06.720 --> 33:08.640] I mean, you have source and binary. [33:09.100 --> 33:14.560] I'm going to lump in some compiler-centric methods into source, just to keep it simple. [33:16.460 --> 33:22.340] So, next up, we're going to look at the Diffie-Hellman prime that was submitted for SOCAT. [33:22.660 --> 33:25.100] That's the git differential. [33:25.720 --> 33:36.950] So, what the code author did was they said the Diffie-Hellman 512 bits prime was broken. [33:37.240 --> 33:43.580] So, he submitted a 1,024-bit one, and then it was actually not prime. [33:43.580 --> 33:47.080] But if you look at it without actually... [33:47.080 --> 33:51.060] The only way you could figure that was a backdoor is if you actually do the math. [33:51.460 --> 33:57.190] And that's a lot of typing in or that's work. [33:57.340 --> 33:59.620] You just can't look at it and know that it's a backdoor. [33:59.620 --> 34:06.340] So, faulty code is one of the main primary means to add a backdoor. [34:06.600 --> 34:11.640] And it's especially useful because it's really plausibly deniable. [34:11.930 --> 34:14.520] So, you can add a bad prime. [34:14.520 --> 34:17.400] You could do a function that's not memory safe. [34:17.840 --> 34:21.820] You can do quite a bit of things with faulty code. [34:21.960 --> 34:25.520] And you can just pretend you're a bad programmer. [34:30.140 --> 34:32.400] Next up, I think, was pretty interesting. [34:32.600 --> 34:35.280] This is actually from a capture the flag event. [34:35.460 --> 34:37.660] It's hack lose 2014. [34:37.660 --> 34:38.780] It's one of their challenges. [34:39.680 --> 34:43.740] But some languages allow Unicode variables. [34:44.560 --> 34:45.900] Python 3 does. [34:46.120 --> 34:47.260] I think JavaScript does. [34:47.420 --> 34:48.620] A bunch of other ones. [34:48.920 --> 34:54.040] But if you look at the function, it looks fairly normal. [34:54.220 --> 35:00.540] But I have the E and Hmax secret in the third line. [35:01.240 --> 35:03.860] That's black because that's actually a Unicode character. [35:03.860 --> 35:09.940] So, in this function, the Hmax secret actually remains blank during this whole time. [35:10.120 --> 35:12.520] So, it's just... it's bad crypto. [35:12.760 --> 35:13.740] It's not going to encrypt. [35:14.820 --> 35:20.500] And if your editor is not configured correctly, you probably won't figure it out. [35:22.180 --> 35:26.260] And it's definitely a novel and, I guess, unique path. [35:26.940 --> 35:32.100] Especially since Unicode really hasn't been widely accepted for too long. [35:32.100 --> 35:38.240] So, I think this could be possibly... there could be more instances of this in the wild. [35:47.390 --> 35:50.190] Web application JavaScript is really interesting. [35:51.550 --> 35:58.490] Just because you can add event listeners basically anywhere. [35:58.730 --> 36:03.510] A lot of web applications just include whatever script. [36:03.810 --> 36:05.090] And it's like all over the place. [36:05.090 --> 36:10.050] So, all you have to do is add an event listener somewhere in one of those scripts. [36:11.510 --> 36:14.310] Excuse the bad word wrapping on the image. [36:14.610 --> 36:20.790] But this is just basically a function that monitors for the submission of a form. [36:21.030 --> 36:26.010] And then when it's submitted, it sends the login credentials to a malicious server. [36:27.430 --> 36:32.850] And this is also a good example of... a lot of people think of like, oh, cross-site scripting. [36:32.910 --> 36:33.950] That's a joke. [36:34.690 --> 36:35.930] That's not even relevant. [36:36.590 --> 36:38.610] Nobody can do anything with cross-site scripting. [36:38.690 --> 36:44.870] But if you were to throw one of these into something that's cross-site scripting susceptible. [36:44.870 --> 36:50.030] And now you're just... you basically backdoored the login form. [36:51.130 --> 36:53.250] And that's pretty easy. [36:53.610 --> 36:57.670] Yeah, cross-site scripting, I guess it's... as long as it's persistent. [36:58.190 --> 37:01.390] That's a good example of backdoor attacks. [37:02.070 --> 37:04.150] And it's on the supply chain. [37:04.290 --> 37:06.670] It's while the application is already being used. [37:18.660 --> 37:22.500] Okay, so another example that happened recently, I guess. [37:23.740 --> 37:26.580] The vendor claims it wasn't a backdoor issue. [37:26.580 --> 37:31.560] It was a management authentication issue with a hard-coded login. [37:32.040 --> 37:35.940] And this was like, I guess, a severe... [37:37.940 --> 37:41.000] To me, in my mind, it's a no-brainer that it's a backdoor. [37:41.180 --> 37:42.260] It's a hard-coded credential. [37:42.260 --> 37:45.700] But the vendor has the nerve to say, oh, no, it's not a backdoor. [37:45.700 --> 37:48.880] It's a management authentication issue. [37:49.420 --> 37:50.820] Everything is good here. [37:51.000 --> 37:51.580] No worries. [37:53.360 --> 37:55.920] And this one, I think, was longstanding for a while. [37:56.900 --> 38:10.500] It's interesting because the operating system it was on, it was something... it was on something called, I think, the Evaluation Assurance List, which is a list of software that's reviewed for security functionality. [38:11.400 --> 38:15.460] And it's almost... it almost seems like that's like a hit list. [38:15.460 --> 38:22.280] Because there's so many applications on there that security researchers just have gone after and have found backdoors. [38:22.640 --> 38:28.040] They've found really bad remote code execution bugs and all kinds of crazy things. [38:28.460 --> 38:36.320] But, yeah, just because someone says... puts a stamp on it and says it's certified doesn't mean it's necessarily good to go. [38:45.990 --> 38:51.110] So, another good example, this is just like a backdoor interpreted language. [38:51.450 --> 38:54.130] This is source code for fabricator. [38:54.350 --> 38:59.950] Fabricator is like a... it's like an add-on to Git. [39:00.130 --> 39:06.490] It's a versioning control system where you can communicate, you can track changes, do differentials, things like that. [39:07.370 --> 39:16.130] This is basically just a one-liner you add to the login function that sends the user credentials to a malicious server. [39:16.390 --> 39:28.950] And this is the type of thing that's very typical to see during like a post-exploitation phase, where the attacker wants to gain more credentials and get more widespread access to the network. [39:39.370 --> 39:40.990] So, compiler-centric. [39:41.270 --> 39:43.690] Xcode Ghost is a great example. [39:44.070 --> 39:49.550] I think there are some estimates like 500 million people were impacted by this. [39:49.690 --> 39:51.390] I can't even imagine that many people. [39:51.550 --> 39:52.430] That's like huge. [39:53.190 --> 40:01.810] But what Xcode Ghost was, was a... the iOS developer package was backdoored. [40:02.790 --> 40:05.070] And it was hosted on Chinese servers. [40:05.850 --> 40:13.570] And the reason why Chinese developers don't get it, get it from the official repositories, was because of latency and speed issues downloading it. [40:13.750 --> 40:18.550] So, they'd all grab it from all these Chinese distribution servers and it was backdoored. [40:19.470 --> 40:23.790] Ending up, I guess, compromising, infecting 500 million users. [40:24.350 --> 40:26.470] These phones, I'm sure, have been everywhere. [40:26.910 --> 40:28.510] Every organization you can imagine. [40:29.270 --> 40:33.050] The actors that did it, I guess, were cyber criminal, financially motivated. [40:33.050 --> 40:36.510] But something like that, that's... [40:37.590 --> 40:40.630] If someone, like, just financially motivated could do that. [40:40.810 --> 40:48.510] Someone, like, with different motivations that are more, I guess, sinister or malicious, could definitely execute something like that. [40:48.670 --> 40:52.250] And it would be... there would be grave effects. [40:52.410 --> 41:01.990] Like, what if they just set the iPhone clock to the year 1960 and it bricked everybody's phone irrevocably or something. [41:03.390 --> 41:05.130] So, that's a good example. [41:05.830 --> 41:11.190] I guess, Yan Zhu did some security research with JavaScript minification bugs. [41:11.550 --> 41:22.530] And that's really novel and unique because some of the minifiers have logic issues where they don't do comparison operators correctly. [41:23.770 --> 41:25.830] Like, multiple comparison operators. [41:26.330 --> 41:29.310] And that leads to some potential backdoors. [41:29.610 --> 41:31.650] But if you look at the source, it's not there. [41:31.850 --> 41:36.050] It's only when it's minified do the backdoors get added. [41:37.310 --> 41:43.410] And there's some other compiler bugs out there, too, that results in, like, some memory unsafe things. [41:44.470 --> 41:46.130] It's a huge field to look into. [41:57.130 --> 41:59.890] So, we're gonna transition to binary. [42:00.140 --> 42:02.250] You actually don't need to read anything on that image. [42:02.390 --> 42:04.690] It's just a control flow graph. [42:05.460 --> 42:08.480] One of the easiest things to do is to just... [42:09.080 --> 42:12.120] to modify the control flow of a binary application. [42:14.080 --> 42:17.210] And this is not something that's new or anything like that. [42:17.210 --> 42:22.910] Like, Crackers use this to bypass, like, windows and things like that. [42:23.190 --> 42:25.390] Or, like, serial windows, things like that. [42:25.560 --> 42:31.670] But, with control flow redirection, you can maybe bypass an encryption subroutine. [42:31.950 --> 42:35.790] So, it's directly sent to the WebSocket or something like that. [42:36.950 --> 42:39.210] And this is something that's... [42:39.210 --> 42:43.080] It's not gonna set off antivirus alarms just because it's... [42:43.080 --> 42:46.270] You're just having the function return somewhere else. [42:46.270 --> 42:53.690] You could also bypass pseudo-random C generators, things like that, just by altering the control flow. [43:01.980 --> 43:05.780] So, next up in binary, surreptitious code. [43:05.980 --> 43:07.220] You have data replacement. [43:07.920 --> 43:10.520] Basically, any hard-coded variables are game. [43:11.280 --> 43:13.600] URLs can lead to cross-site scripting attacks. [43:14.220 --> 43:19.640] If you edit the auto-update URL, potentially, you can do auto-update attacks. [43:19.960 --> 43:31.900] And then, basically, you could feed just a particular binary to a certain person or a certain IP range or a certain criteria that are met. [43:32.140 --> 43:37.560] And then, obviously, you can change any encryption keys that are hard-coded in the application. [43:46.140 --> 43:48.980] Malicious stubs, that's probably the easiest thing. [43:49.180 --> 43:51.600] That's, like, how Trojans spread for the most part. [43:51.800 --> 43:52.640] They just... [43:53.440 --> 43:55.320] Fundamentally, how it works is... [43:57.020 --> 44:01.260] There's, like, a Windows 32 native executable application. [44:02.280 --> 44:05.460] The bad code will say, execute me first. [44:05.900 --> 44:06.980] And then, it'll get executed. [44:07.200 --> 44:10.440] And then, once it's done executing, it'll just say, return to the normal code. [44:10.620 --> 44:13.800] And that's, essentially, what a malicious stub is. [44:14.020 --> 44:17.100] Really easy to add to native binaries. [44:17.660 --> 44:22.060] Really easy to obscure and bypass antivirus detection with that. [44:29.630 --> 44:32.470] So, some excellent reverse engineering tools. [44:33.830 --> 44:35.270] .NET, Dnspy. [44:35.270 --> 44:38.090] I can't speak enough good about it. [44:38.270 --> 44:38.730] It's great. [44:39.170 --> 44:45.110] If you've never decompiled .NET before, it's like reading the original source code. [44:45.430 --> 44:46.490] But probably cleaner. [44:48.610 --> 44:49.690] It's amazing. [44:52.190 --> 44:53.390] .NET, it's... [44:53.390 --> 44:56.350] I guess it's considered a compiler-interpreted language. [44:56.730 --> 45:03.550] Where it's not fully interpreted, but it's not fully native code either. [45:03.550 --> 45:08.850] But the CIL makes it just incredible to decompile. [45:09.150 --> 45:10.430] And it's amazing. [45:10.610 --> 45:20.190] There are some, like, I guess, obscuration applications out there that try to make it harder to reverse engineer. [45:20.470 --> 45:21.930] But those are all defeatable. [45:22.730 --> 45:23.910] Native Windows 32. [45:24.250 --> 45:25.170] Immunity debugger. [45:25.170 --> 45:26.950] It's probably one of the best things. [45:27.110 --> 45:27.630] Or IDAPRO. [45:28.030 --> 45:30.730] But not everyone has thousands of dollars to spend on it. [45:31.730 --> 45:32.090] Java. [45:33.470 --> 45:34.970] Another interpreted language. [45:37.350 --> 45:38.710] Decompiling, that's also good. [45:39.070 --> 45:42.930] Probably not as good as .NET, but it's still really easy to read. [45:43.970 --> 45:46.530] Procyon's one of the tools that I like to use. [45:46.530 --> 45:48.470] And then, I guess, Hopper. [45:48.950 --> 45:50.110] That's a great tool. [45:50.490 --> 45:53.610] Basically, decompiles or disassembles everything. [45:53.870 --> 45:56.270] Tries to decompile things into pseudocode. [45:56.390 --> 45:57.090] Doesn't always work. [45:57.250 --> 45:58.850] But it's still a great tool. [45:59.050 --> 46:02.790] Well worth the, like, the $70 I spent on it. [46:06.410 --> 46:08.910] So, we'll move to, I guess, mitigation. [46:09.390 --> 46:12.170] We can talk about what developers can do first. [46:13.230 --> 46:16.990] Version control policies are probably one of the most effective means. [46:16.990 --> 46:22.770] If you're using Git, if you're using Fabricator, if you're using some kind of version control system. [46:23.010 --> 46:24.610] And you're actually looking at your code. [46:26.990 --> 46:28.010] That's very helpful. [46:28.270 --> 46:37.070] I know a lot of organizations out there probably aren't as, I guess, clean as the open-source community as far as source code. [46:38.070 --> 46:39.890] Because I've seen some messy code. [46:40.090 --> 46:42.070] But version control definitely helps. [46:42.210 --> 46:43.210] Writing clean code helps. [46:44.610 --> 46:47.450] As far as, you know, limiting library dependencies. [46:47.990 --> 46:51.910] When you increase your library dependencies, you're increasing your attack surface. [46:52.450 --> 46:56.090] Which, that can have some risk factors included. [46:57.110 --> 46:58.150] Anti-debugging. [46:58.870 --> 47:00.710] Some people have some gripes about it. [47:00.850 --> 47:02.570] They're like, code is free. [47:05.190 --> 47:06.150] Things like that. [47:06.150 --> 47:10.210] But for binaries, you can do... [47:10.210 --> 47:15.210] I think everyone should probably add some functionality for anti-debugging in binaries. [47:15.450 --> 47:16.830] Even if your source code is available. [47:17.730 --> 47:19.930] But some people want their code transparent. [47:20.210 --> 47:20.910] But it's... [47:20.910 --> 47:24.110] I guess it's whatever your philosophy is with that. [47:25.450 --> 47:28.150] And then, last but not least, audit other people's code. [47:29.310 --> 47:33.650] Things are found all of the time with auditing. [47:34.770 --> 47:36.030] So, it's... [47:36.030 --> 47:37.850] There's never enough eyes looking at code. [47:39.070 --> 47:41.030] And you never know what you can find out there. [47:50.610 --> 47:53.250] So, for mitigation for system administrations. [47:54.410 --> 47:54.970] Containerization. [47:55.230 --> 47:56.650] It's a fairly new thing. [47:58.050 --> 48:00.710] And that does some awesome things. [48:00.710 --> 48:02.730] It's basically compartmentalization. [48:03.470 --> 48:09.730] If the altcoin client for Cripsy was containerized, they probably wouldn't have stolen $5.7 million. [48:10.410 --> 48:14.970] It's not really a huge task to containerize things. [48:15.370 --> 48:22.350] Especially on mission critical, hugely valuable systems. [48:22.870 --> 48:24.890] Do some file integrity checking. [48:24.890 --> 48:29.210] Especially on any interpreted language. [48:29.510 --> 48:32.510] Or anything that handles login requests. [48:33.630 --> 48:34.910] Just because... [48:34.910 --> 48:36.790] Especially if it's an interpreted language. [48:36.990 --> 48:38.470] You can always add a one-liner. [48:38.610 --> 48:40.810] Redirect that user credential somewhere else. [48:41.010 --> 48:41.850] And then, now you have it. [48:42.890 --> 48:45.050] Hashing and whitelisting. [48:45.170 --> 48:46.250] Go along with that. [48:56.330 --> 48:57.610] So, for users. [48:57.910 --> 49:00.070] I guess, stop downloading stuff. [49:03.330 --> 49:07.210] There's probably some of you out there that work in, like, corporate environments. [49:07.210 --> 49:08.990] And they see the things users download. [49:09.190 --> 49:10.910] It's, like, incredible. [49:11.070 --> 49:14.030] They'll go out of their way to download the malicious application. [49:14.630 --> 49:17.210] And it's just incredible what they download. [49:18.210 --> 49:20.130] And beware of waterholes. [49:20.210 --> 49:23.790] Especially if you're in a certain subgroup. [49:23.890 --> 49:25.330] Or if you're in a certain demographic. [49:25.330 --> 49:28.310] And you frequent that watering hole. [49:29.550 --> 49:31.670] The first thing to do is to realize. [49:31.930 --> 49:33.630] This could be a possible waterhole. [49:34.690 --> 49:37.470] I really need to be careful with any of the binaries. [49:37.770 --> 49:40.910] Or things that I could get from the source. [49:41.790 --> 49:43.090] Always check file hashes. [49:43.230 --> 49:43.950] It's a pain. [49:45.270 --> 49:46.850] I know I don't do it all the time. [49:47.030 --> 49:47.810] I'm sometimes guilty. [49:48.590 --> 49:50.190] But checking file hashes. [49:52.090 --> 49:53.510] It's not a bad thing. [49:53.510 --> 49:55.250] Most people will think you're paranoid. [49:55.510 --> 49:58.130] But it's reasonable. [49:59.330 --> 49:59.470] So, yeah. [49:59.590 --> 50:00.970] Download only from trusted sites. [50:02.790 --> 50:04.970] And don't rely on antivirus. [50:05.270 --> 50:07.250] It's really easy to bypass. [50:08.130 --> 50:13.170] It doesn't detect any backdoors that just break functionality. [50:13.710 --> 50:17.350] Nine out of ten times an attacker can easily bypass antivirus. [50:17.490 --> 50:19.570] And it's not really that useful. [50:21.290 --> 50:23.570] So, I guess that concludes my talk. [50:23.790 --> 50:26.730] I think I have a couple of minutes for questions if anyone has any. [50:29.250 --> 50:29.890] Go. [50:35.810 --> 50:44.970] So, your Xcode goes to vulnerabilities particularly concerning because our board support packages for every piece of hardware comes out of China. [50:45.410 --> 50:45.750] Wow. [50:45.750 --> 50:47.190] So, and that's code. [50:47.430 --> 50:48.710] In many cases it's binaries. [50:49.010 --> 50:54.670] And you don't usually have access to the source code because the vendor won't take the time to mainline it or upstream the code. [50:56.030 --> 51:01.450] Do you know of any mitigations, possibilities we have there other than vendor-vendor relations? [51:04.590 --> 51:15.850] As far as I guess mitigations where you're provided with bad code, really the only thing you can do is disassemble it, which that's not necessarily feasible. [51:16.750 --> 51:22.130] So, unfortunately I don't really know if there are many mitigations in place. [51:24.150 --> 51:27.230] I guess that's a reason we should all insist on open-source packages. [51:27.930 --> 51:28.210] Definitely. [51:28.510 --> 51:28.590] Yeah. [51:28.870 --> 51:30.230] Open-source so you can read the source. [51:31.910 --> 51:38.430] Proprietary code, it's much easier to hide backdoors into it because the only way to review it is the assembly. [51:40.730 --> 51:41.210] Go. [51:43.270 --> 51:46.890] Reinstall, try to isolate, also do the practice uninstall. [51:49.210 --> 51:50.310] That could work. [51:52.750 --> 52:01.890] It's, yeah, it's, if you're to do that I would recommend using a virtual machine and just doing a snapshot back in time. [52:03.210 --> 52:07.690] After you have the code executed you really don't know what's on your system after that. [52:11.050 --> 52:16.010] One example you didn't bring up, the Apple SSL bug with the go-to-fail, go-to-fail. [52:17.430 --> 52:22.370] I don't think, I don't remember if they ever acknowledged that that was a code injection. [52:22.710 --> 52:23.270] Do you have any thoughts? [52:23.710 --> 52:25.630] I'm not too familiar with that one. [52:25.850 --> 52:26.590] I'm sorry. [52:27.570 --> 52:35.870] One of my favorite examples of compiler-centric surreptitious code is Ken Thompson's, Ken Thompson's reflections on trusting trust. [52:36.030 --> 52:36.970] Are you familiar with that? [52:37.370 --> 52:37.770] Yeah. [52:38.050 --> 52:39.630] From the early, the 70s. [52:39.730 --> 52:39.950] Correct. [52:40.070 --> 52:41.570] It's something I could still apply today. [52:41.870 --> 52:50.490] I was curious if, and in many other ways, not just compilers, do you know of any other attacks that were similar to that nature? [52:50.570 --> 52:52.030] His was more kind of just academic. [52:52.410 --> 52:52.470] Correct. [52:52.470 --> 52:54.010] It came clean about it decades later. [52:54.190 --> 52:57.250] His one was the, I think, SSH backdoor, right? [52:57.250 --> 52:57.930] And that... [52:57.930 --> 53:04.110] His was the compiler that built login that stuck in imaginary code that allowed for a backdoor password. [53:04.410 --> 53:11.450] And then he then built, modified the compiler source, not to detect that it was building login, but to detect that it was building the compiler. [53:11.790 --> 53:16.150] And then put imaginary code in the resulting compiler that would detect login. [53:16.310 --> 53:24.490] It was this very indirect approach that if you suspect your compiler, you just rebuild your compiler, but you would still end up with the screwed up login. [53:24.930 --> 53:25.270] Right. [53:26.270 --> 53:37.330] Yeah, I think most of that stuff, quite honestly, is like out of my league, especially with a double compilation using two different compilers. [53:37.510 --> 53:38.610] It's pretty well established. [53:39.010 --> 53:39.470] What's that? [53:39.770 --> 53:43.530] There's a technique where you can guard against that with two different compilers. [53:43.890 --> 53:45.230] It's in the literature. [53:45.770 --> 53:49.910] Yeah, there's other things you can do, though, with package managers and other things like that. [53:53.810 --> 53:55.310] All right, any other questions? [53:58.850 --> 54:00.790] Are you going to share your slide then? [54:01.730 --> 54:04.090] Yeah, I can throw it on Twitter. [54:04.550 --> 54:05.450] I'll throw a link on Twitter. [54:05.590 --> 54:05.810] Does that work? [54:06.610 --> 54:07.750] PDF good for everybody? [54:11.550 --> 54:14.630] Okay, it won't be backdoored. [54:15.130 --> 54:15.970] I promise, Scout's honor. [54:17.930 --> 54:18.490] Go ahead. [54:22.080 --> 54:23.560] Yes, Cripsy is dead. [54:23.780 --> 54:26.460] That was, I guess, the attack that killed Cripsy. [54:28.940 --> 54:30.880] Yeah, so be careful out there. [54:32.040 --> 54:32.520] Yeah. [54:35.160 --> 54:36.020] Yeah, okay. [54:36.260 --> 54:39.100] Well, thanks, everybody, and be safe out there. [54:39.100 --> 54:39.220] Alright. [54:39.480 --> 54:39.600] That's okay. [54:39.840 --> 54:39.880] Thank you.