[00:00.000 --> 00:01.400] ...cookie and PHP session. [00:01.540 --> 00:02.740] It's kind of magic for developers. [00:02.900 --> 00:03.400] It just happens. [00:03.600 --> 00:05.280] You make a couple function calls. [00:05.400 --> 00:06.820] The cookies are handled automatically. [00:07.140 --> 00:08.180] It's really easy. [00:08.540 --> 00:09.760] It's good for developers. [00:10.600 --> 00:16.820] So, the HTTP cookie will have a session ID put into it set by the login code. [00:17.280 --> 00:25.700] Naturally, if we have users logging into a web application to access a members-only area, they also need to be able to log out when they feel like it on request. [00:25.700 --> 00:32.660] So, traditionally, you'd have something like this URL at the bottom here, a logout.php script. [00:34.900 --> 00:50.240] And when that script gets accessed by a get request from an authenticated member, we'll expire the cookie and the session server side, do whatever cleanup you have to do in terms of marking down when the user last logged in, the duration of their login, [00:50.540 --> 00:51.720] anything like that. [00:52.680 --> 00:56.720] So, it's not immediately apparent that there's any kind of a problem with this. [00:56.840 --> 00:59.300] It all sounds like pretty typical stuff. [00:59.940 --> 01:05.900] It's only when you start thinking about users and malicious users that you start to see the problem. [01:06.080 --> 01:10.320] So, it's kind of a tale of two users, Alice and Mallory, the malicious user. [01:10.760 --> 01:13.440] So, Mallory's gonna come onto this community website. [01:13.700 --> 01:15.420] Maybe they can sign up for an account themselves. [01:15.700 --> 01:18.160] And they'll go into part of this members-only section. [01:18.480 --> 01:21.840] And they'll post one of these images down at the bottom. [01:22.300 --> 01:28.660] So, if it's one of these sites that's allowing raw HTML access, maybe they'll just stick in a DIMG tag there. [01:29.240 --> 01:33.900] Otherwise, if it's some kind of BB code markup, you know, they can do the same thing down at the bottom. [01:33.900 --> 01:40.320] So, the interesting thing to note is that the source of the image, it's not a JPEG or a GIF or anything. [01:40.760 --> 01:45.200] And you'd think that it's kind of absurd to be pointing an image at a PHP script. [01:45.420 --> 01:51.740] But as far as the browser's concerned, if that PHP script generates a binary image, that's totally fine. [01:52.020 --> 01:53.660] So, it's really not strange. [01:54.040 --> 01:56.120] Just perhaps not what you're used to. [01:58.280 --> 02:00.420] So, where does the trouble start then? [02:01.040 --> 02:06.460] Well, when Alice then logs into the community site, you know, the standard login procedure happens. [02:06.800 --> 02:09.940] She has her session ID stored in the cookie from community.com. [02:10.060 --> 02:11.200] She's now logged in. [02:11.620 --> 02:22.700] So, maybe through some kind of social engineering or just luck, maybe the title of the post was especially intriguing, Alice will browse to Mallory's crafted post. [02:22.700 --> 02:31.280] So, at that point, the HTML content's being pulled down to Alice's browser, the image tag starts to be processed, and the image has to be fetched. [02:31.420 --> 02:35.220] So, this git request is sent out to get the source of the image. [02:35.380 --> 02:38.420] In this case, it's this logout.php script. [02:38.760 --> 02:45.000] So, to acquire the image data, Alice's browser makes a git request to logout.php. [02:45.000 --> 02:49.620] And the cookie that has the session ID is sent along for the ride. [02:49.840 --> 02:51.080] That's the important bit. [02:51.460 --> 02:52.920] And, I mean, why wouldn't it be? [02:53.160 --> 02:58.380] You're requesting something from community.com, and that's what the session cookie was set for. [02:58.620 --> 03:01.880] All of your requests to community.com will include this cookie. [03:01.880 --> 03:11.520] So, then, the logout script doing its job, it gets the git request from a logged in user with a valid session ID, and it dutifully gives Alice the boot. [03:14.540 --> 03:22.460] So, being a developer myself, I've kind of abused a sequence diagram here to kind of give an idea of what the kind of flow going on here is. [03:23.660 --> 03:27.600] So, the first part, we've got this attacker logging into community.com. [03:27.700 --> 03:29.600] So, they post their log in details. [03:29.860 --> 03:30.800] They either succeed or fail. [03:30.960 --> 03:31.920] You know, they've got a valid account. [03:32.060 --> 03:32.920] We'll assume they've succeeded. [03:33.180 --> 03:35.620] So, next, they'll post this malicious content. [03:38.060 --> 03:44.040] Following up, the victim logs into the website, posting their log in details, getting the session cookie set. [03:44.840 --> 03:49.580] They fetch the page content from the malicious post, the malicious XML there. [03:50.540 --> 03:56.440] And then, when it gets processed, you know, there's gonna be a whole bunch of these git requests for all the resources that are on that page. [03:56.620 --> 04:01.500] You know, potentially a header JPEG, likely some kind of JavaScript include. [04:01.840 --> 04:04.600] But the one that's important is that git logout.php. [04:05.280 --> 04:16.180] Because when that happens, you've essentially performed a pretty brute denial of service attack, in the sense that anybody that browses to this one section of the community website is gonna immediately be kicked off. [04:16.180 --> 04:19.800] And the next request they make to the community website is gonna tell them to log back in. [04:20.240 --> 04:23.840] Mostly a nuisance, but still has implications. [04:25.040 --> 04:27.740] So, like I said, it's mostly a nuisance. [04:27.980 --> 04:33.640] And this is kind of where most developers, if they know about CSERF, will probably stop with their understanding of it. [04:34.080 --> 04:40.500] And it's kind of misleading because it's a purposefully toy example to kind of lead into the discussion. [04:41.780 --> 04:46.240] You'll have to suffer my bad puns, but it's bad form to log out with a git request. [04:46.340 --> 04:52.420] If you're a developer, you should know this, that by the HTTP specs, git should be idempotent. [04:52.520 --> 04:59.420] Which means, essentially, you shouldn't be performing any actions that have side effects when you get a git request, such as logging the user out. [04:59.580 --> 05:03.700] You should always be using post requests for that, otherwise it's kind of bad form. [05:03.800 --> 05:07.740] Nothing explicitly illegal, but it's recommended you shouldn't be doing that. [05:07.740 --> 05:16.300] So, this example is kind of misleading because it might give you the impression that CSERF relies on the ability to post content to a target site. [05:16.400 --> 05:21.640] Such as in this case, we logged onto this community page, and Mallory was able to post an image tag. [05:22.060 --> 05:22.980] That's not required. [05:23.440 --> 05:27.380] It's not specific to image tags itself, like that bug track posting. [05:27.680 --> 05:29.860] You can do it with a whole bunch of tags, really. [05:30.180 --> 05:33.800] And it's also not specific to git-based forms. [05:33.800 --> 05:45.440] So, even if you are following proper standard recommendations, and not performing actions with side effects in your forms, you're still potentially vulnerable to this CSERF attack. [05:46.580 --> 05:48.860] So, if we go into that for a little bit more detail. [05:49.880 --> 05:52.260] The content creation rights requirement. [05:52.260 --> 05:58.120] You don't need to be able to put any tags on the site that you're trying to attack with this CSERF request. [05:58.920 --> 06:03.400] That's where that cross-site aspect of cross-site request forgery comes from, really. [06:04.260 --> 06:06.600] Again, it's not particular to image tags. [06:06.760 --> 06:14.540] When you start thinking about it, all of these resources that your browser has to acquire from a website, these are all invoking requests automatically. [06:14.540 --> 06:17.740] You never have to sit there and approve to have an image loaded. [06:17.880 --> 06:18.620] It just happens. [06:18.760 --> 06:20.480] These requests get fired off. [06:20.480 --> 06:22.140] So, that's important to note. [06:22.300 --> 06:28.680] That you can really, really easily cause requests to happen with a specific source destination. [06:29.600 --> 06:33.260] And then again, it's further not limited to git method forms. [06:33.520 --> 06:35.640] You can either social engineer a form post. [06:35.760 --> 06:37.320] You know, boobs on the other side. [06:37.460 --> 06:38.100] Just click OK. [06:38.620 --> 06:41.540] Or you can use JavaScript to submit one automatically. [06:41.800 --> 06:45.620] And most people, if not everyone really, kind of has JavaScript enabled automatically. [06:45.620 --> 06:50.580] So, if you submit the form through JavaScript, they don't have much of a chance to do anything about it. [06:54.750 --> 06:59.970] So, when you start to take those things into effect, you kind of get more of a complex attack flow. [07:00.270 --> 07:03.330] So, now you can see we've got an attacker on the left. [07:03.510 --> 07:05.970] But we also have an attacker site all the way on the right. [07:06.590 --> 07:18.810] So, what happens is, once the victim's logged in as before, sent their post details, you're trying to time this so you're using it with an authenticated user, the attacker will send some kind of luring link. [07:18.970 --> 07:21.510] Again, trying to convince somebody to go somewhere. [07:21.730 --> 07:24.510] So, it's a little bit of a social engineering point at this part. [07:24.790 --> 07:28.730] They've sent this luring link pointing back to their attacking site. [07:29.150 --> 07:33.550] So, you'll send some kind of a message to this user saying, you know, cool stuff's here. [07:33.710 --> 07:34.710] Just come check it out. [07:36.710 --> 07:42.810] So, next, this logged in victim will browse to this attacking site that's been sent to them through this lure. [07:43.470 --> 07:46.870] And they'll fetch some page content from the attacking site. [07:46.870 --> 07:53.830] So, the target site, community.com or whatever it happens to be, has had really no implications in this flow so far. [07:55.790 --> 08:00.650] So, again, we get down to the bottom here and you can see the arrows cross over target site for most of them. [08:00.810 --> 08:09.090] As the XHTML that the victim has pulled down from the attacker site starts to get processed, you'll see a whole bunch of get requests again. [08:09.370 --> 08:14.350] Probably things that are on the attacker site, you know, the style sheets, the JavaScript includes. [08:14.750 --> 08:21.330] But there will be one particular request, or several really, that are being sent to the target site. [08:21.490 --> 08:37.830] So, again, since you control the destination of some of these resources and requests and you can use JavaScript to post automatically, the cookie that the user has gets sent to the target site even though it's being forced from content requested from the attacker site. [08:39.330 --> 08:44.290] So, I promised that we'd kind of learn some of these techniques through social network exploitation. [08:44.490 --> 08:46.690] So, we'll kind of talk about that now. [08:48.270 --> 08:50.150] So, what is vampire freaks? [08:50.290 --> 08:52.990] Because I assume most people probably haven't heard of it. [08:53.150 --> 08:56.510] If I can summarize it in about one word, I'd probably call it goth book. [08:58.090 --> 09:06.310] It's kind of this bizarre combination of MySpace and Facebook aimed at, like, the industrial, goth kind of underground culture. [09:06.590 --> 09:07.470] So, it's a little bit smaller. [09:07.730 --> 09:10.330] Well, compared to Facebook or MySpace, it's a lot smaller. [09:10.470 --> 09:12.390] But it's still a pretty sizeable site. [09:12.530 --> 09:16.510] We've got around a million members and around 3,000 online at any given time. [09:17.390 --> 09:23.110] Social networks in particular are appealing because just the nature of them makes them easy to attack. [09:23.930 --> 09:29.110] You've got it designed to be easy to embed content, especially vampire freaks. [09:29.110 --> 09:42.130] I recommend that if you enjoy your eyesight or, you know, have standards about what websites should look like, don't go there because it's similar to MySpace in that you get all these, like, meaty files embedded in things and flashing under construction GIFs. [09:42.270 --> 09:44.530] It's kind of like a time machine back to GeoCities, really. [09:46.510 --> 09:49.710] So, because it's easy to embed content, that just works in our favor. [09:49.910 --> 09:51.690] Images, CSS, HTML. [09:52.390 --> 09:58.630] Vampire freaks in particular, they haven't done a whole lot other than blacklisting in terms of trying to limit what kind of content you can post. [09:58.870 --> 10:00.490] You have CSS control. [10:00.730 --> 10:01.850] You can put tags indirectly. [10:02.890 --> 10:04.010] Just, it's easy. [10:05.010 --> 10:08.030] Social engineering is easier on social networks. [10:08.190 --> 10:09.510] I mean, it just makes sense. [10:09.750 --> 10:12.350] You're on this social network to be connecting to other people. [10:12.490 --> 10:13.370] Some of them you might know. [10:13.590 --> 10:14.410] Some of them you might not. [10:14.910 --> 10:17.950] So, there's already a lot of social interaction going on on these sites. [10:18.810 --> 10:22.650] And then, it's easy to spread things because they're designed for sharing. [10:22.650 --> 10:26.450] You should be sending links around through your social groups. [10:26.910 --> 10:29.010] So, that works in our favor, too, really. [10:31.370 --> 10:33.250] So, everybody always puts one of these in here. [10:33.370 --> 10:35.990] And I don't know if they're actually useful. [10:36.290 --> 10:38.150] But the vulnerability... [10:38.150 --> 10:40.470] This is about a year ago that I worked on this stuff. [10:40.670 --> 10:41.930] You find these everywhere. [10:42.150 --> 10:43.030] I've done it for work. [10:43.130 --> 10:45.170] I've done it for hobby things. [10:45.390 --> 10:47.990] These CSRF vulnerabilities are easy to find. [10:48.210 --> 10:50.450] So, this one is mostly already patched. [10:50.450 --> 10:52.830] I'm not going to tell you which parts they messed up patching. [10:53.770 --> 10:55.450] It was disclosed responsibly. [10:55.750 --> 10:56.990] So, the admin knew about it. [10:57.070 --> 11:00.290] I told them it was going to be released, you know, four or five months after. [11:01.510 --> 11:04.150] All of the attack, I've just did it with my own accounts. [11:04.450 --> 11:08.170] So, it was never in the wild, you know, spreading out MySpace worm kind of thing. [11:08.350 --> 11:10.810] There's not 10,000 users that have me as their best friend. [11:12.390 --> 11:15.070] Overall, the admins were pretty good about it. [11:15.190 --> 11:17.670] I find that's pretty common when you use responsible disclosure. [11:18.230 --> 11:19.750] Your actions are your own. [11:19.890 --> 11:20.390] Not mine. [11:20.650 --> 11:21.310] Yadda, yadda, yadda. [11:21.470 --> 11:22.630] Don't blame me when you get arrested. [11:24.330 --> 11:29.470] So, this particular attack flow, it's got an exploit located on my server. [11:29.590 --> 11:31.590] So, I'm the attacker website in this case. [11:31.890 --> 11:32.990] It's post-based. [11:33.910 --> 11:36.750] I do a little bit of tracking with a tracking account. [11:36.890 --> 11:43.050] So, basically, when a user is hit with this exploit, it sends a tracking message to this particular account. [11:43.050 --> 11:44.810] It just gives you a sense of metrics. [11:44.970 --> 11:52.290] And since I was doing it with my own accounts, I really wanted to make sure that, you know, as soon as it got anywhere else, I knew about it immediately so I could kill it. [11:53.390 --> 11:54.590] The status updates. [11:54.730 --> 12:00.790] Vampire Freaks has this similar service to Facebook where you can, you know, post, I'm eating a sandwich or whatever. [12:00.790 --> 12:05.810] And it gets sent out to all of your friends and I guess they tell you about what sandwiches they're eating and the like. [12:06.490 --> 12:13.710] So, you get this kind of viral component built right in because you're able to share little bits of information with everybody really quickly. [12:14.250 --> 12:24.090] So, the social engineering involved is luring people that are logged into Vampire Freaks to the specific attack server, the URL located that I have control over. [12:26.790 --> 12:29.610] So, again, the social engineering, it's a post based exploit. [12:29.790 --> 12:32.610] So, it makes it a little bit trickier than the git based one. [12:32.710 --> 12:34.370] I can't just stick an image tag somewhere. [12:35.510 --> 12:44.570] You'd have to be using some kind of cross site request forgery or sorry, cross site scripting to be able to force a form post from inside of Vampire Freaks. [12:44.750 --> 12:46.750] But I can do it off site. [12:46.910 --> 12:48.510] So, you just have to kind of get them there. [12:49.490 --> 12:54.870] With this kind of thing, again, the social network basis of it, it's really easy to lure people to wherever you want them to go. [12:55.030 --> 12:59.490] You just post some kind of enticing link in a forum post or a personal message. [12:59.610 --> 13:03.910] And this has the benefit of that they have to be logged in to be viewing a personal message. [13:04.030 --> 13:04.950] I mean, it only makes sense. [13:05.270 --> 13:09.410] You can't see the personal messages for your account until you're in your account. [13:09.410 --> 13:18.370] So, you send somebody a forum or a personal message with some kind of enticing link, you know, free software, porn, whatever it has to be, to lure them there. [13:19.430 --> 13:23.390] Again, you kind of get more mileage out of this stuff when they don't know that they've been duped. [13:23.590 --> 13:30.530] So, in this case, there's a base 64 encoded URL parameter that points to some decoy content. [13:30.530 --> 13:41.870] So, when you make this personal message to lure them to your site, you can kind of pick the title of the message and then have some kind of decoy content, a BBC news article, something stupid. [13:42.090 --> 13:48.790] And you just base 64 encoded so they can't just look at the link and see, you know, well, I'm not really going to BBC.com. [13:49.170 --> 13:58.750] And then the main page of the exploit will just decode this URL parameter and then iframe the content as big as it can, essentially, to cover up everything else. [13:58.750 --> 14:05.450] It just looks like they've gone to whatever article it is, besides, you know, the URL and the URL bar, but you can ask phishers about that. [14:05.610 --> 14:06.750] People don't really give a damn. [14:09.070 --> 14:13.590] So, the exploit code itself, it's pretty easy to follow through. [14:13.970 --> 14:16.950] It's crafted post requests sent to vampire freaks. [14:17.910 --> 14:25.670] The thing about sending post requests is that you're sending data, you get a response, but you don't want the response because of same origin policy. [14:25.670 --> 14:27.870] You can't be looking at the response. [14:28.030 --> 14:36.790] You don't need to, but you also don't want the user to see all kinds of responses saying, you've sent a personal message to this person or you've changed your status update to this. [14:37.250 --> 14:46.970] So, if you put it in an iframe and you either set the display properties to invisible with CSS or you just set the size really goddamn small, then you've concealed the response. [14:47.150 --> 14:47.930] You don't care about it. [14:48.010 --> 14:48.770] They don't see it. [14:48.910 --> 14:49.610] Everybody's happy. [14:49.610 --> 14:54.530] So, again, these post requests are submitted automatically by JavaScript. [14:54.830 --> 15:01.090] So, if you have JavaScript enabled, as soon as you visit this site, the benign content gets iframed up. [15:01.250 --> 15:08.110] The little iframes all submit automatically and there's really no chance to say anything, you know, cancel requests or do anything really. [15:08.610 --> 15:11.370] So, there's, in this case, three post requests. [15:11.670 --> 15:14.930] The first one will change the registered email address. [15:14.930 --> 15:16.870] And this becomes important later on. [15:17.270 --> 15:20.630] The second one will send that tracking personal message. [15:20.910 --> 15:23.590] And then the third one is the spread, essentially. [15:23.810 --> 15:28.170] And it'll update the user status pointing back to wherever they were duped into going. [15:30.790 --> 15:35.510] So, these are actually the form data at the time that this stuff worked. [15:36.270 --> 15:44.530] Basically, when you're doing this kind of attack, all you need to be able to do is locate the forms on the actual website and find the parameters that you're interested in. [15:45.290 --> 15:46.470] Some of them are mandatory. [15:46.670 --> 15:47.290] Some of them aren't. [15:47.410 --> 15:50.850] So, there's a little bit of guesswork in terms of trying to minimize how much data you're posting. [15:51.030 --> 15:53.930] You know, maybe you don't need to have some of the parameters. [15:54.230 --> 15:58.270] The ones that we're really concerned about in, like, this case is the new email. [15:58.770 --> 16:01.550] And you got to make sure you get the form action right. [16:01.830 --> 16:06.730] So, I don't have it in there, but whatever page I grab this off of, that would be what you're pointing your post to. [16:09.110 --> 16:11.730] Again, the tracking personal message, same kind of idea. [16:11.950 --> 16:13.410] I've kind of cut out some of the crap here. [16:13.590 --> 16:14.870] It's really gross HTML. [16:16.070 --> 16:17.870] You're looking at a couple parameters. [16:18.170 --> 16:26.690] You know, the hidden value of the user you're sending the message to, their particular user ID, the content of the message, that sort of deal. [16:27.750 --> 16:30.950] And again, you can kind of see the idea of this status update. [16:31.250 --> 16:38.830] Vampire Freaks has a fantastic purple default color scheme that is just awful in terms of readability. [16:40.150 --> 16:41.470] So, again, you kind of get this. [16:41.530 --> 16:56.450] This one was a little bit trickier because there's a little bit of Ajax redirection, but it's just a matter of kind of going on the website with something like Firebug and tracing through the flow of how your posts would normally go, figuring out the target of that post in terms of which script it's going to, [16:56.630 --> 17:02.330] and then which parameters are mandatory, what the value should be so you can kind of make a valid request. [17:02.590 --> 17:03.910] You're making valid requests. [17:04.010 --> 17:06.630] You're just controlling what they are and who sends them. [17:08.590 --> 17:12.150] So, the code sample in terms of what's on the server. [17:12.450 --> 17:15.130] I'm going to post the slides and links to all this stuff later. [17:15.590 --> 17:19.410] This cross-domain post function I took from another website. [17:19.530 --> 17:21.070] I have the resources in the end. [17:21.170 --> 17:27.070] It's just an easy way to generate iframes and form posts really quickly. [17:27.250 --> 17:32.890] Since I'm doing three form posts, it's just kind of a generic function to create these form posts. [17:33.310 --> 17:42.310] So, what it's doing is it's taking parameters, sending it to a script that writes the form content out, and then it puts that form content into this iframe. [17:42.390 --> 17:46.050] You can see the width and the height are set to one, so they're super little tiny. [17:46.230 --> 17:48.090] You don't actually see what gets returned to them. [17:48.270 --> 17:50.990] And then it just kind of appends itself into the DOM. [17:52.870 --> 17:59.110] So, I've cut out the other two form posts, but you can see the one here still for the status update. [17:59.350 --> 18:15.250] It's just invoking this cross-domain post function to create using this form writer script to create a form request to this Ajax controller PHP script with the right action in terms of form parameter. [18:15.730 --> 18:19.550] The news link itself, you can see it's just pulled from the document location. [18:19.870 --> 18:22.730] So, wherever they are, that's what their status gets updated to. [18:24.390 --> 18:26.810] And then at the bottom here, you can kind of see... [18:27.490 --> 18:34.150] If you know secure web development, you can immediately see that this itself is vulnerable to cross-site scripting, but it was kind of a proof of concept. [18:34.390 --> 18:46.770] So, it pulls the ID parameter from the URL that's Base64 encoded, decodes it, and then creates the giant iframe that has, you know, the benign content in there that they've been tricked into viewing. [18:48.310 --> 18:49.690] So, this is what you end up getting. [18:50.110 --> 18:55.410] You pull up some website that you've been tricked into viewing, and it's got this benign content loaded in. [18:55.470 --> 18:56.850] You can see the ID parameter. [18:56.990 --> 19:09.130] I mean, it's pretty sketchy looking, but you could definitely do work here if you were a real attacker in terms of picking a legitimate sort of base URL or minimizing the ID parameter, things like that to make it look more, you know, more natural. [19:09.430 --> 19:11.870] In this case, it was never getting out in the wild. [19:11.990 --> 19:16.830] I don't have any malicious intent, so I didn't spend a lot of time trying to make it seem natural. [19:17.930 --> 19:23.390] But what appears benign is really kind of wheels within wheels. [19:23.730 --> 19:26.150] So, you can see here, it's done a status update. [19:26.250 --> 19:30.330] And again, this is kind of where you'd want the smaller URL, because this status update's pretty gross looking. [19:30.570 --> 19:37.850] But it points back to the website that actually performed the attack, and then it sent this tracking message down at the bottom there. [19:38.010 --> 19:39.790] Just a simple hello and a timestamp. [19:41.090 --> 19:43.170] So, I have actually attacked my own account here. [19:43.290 --> 19:44.250] Probably not the wisest thing. [19:45.630 --> 19:50.330] So, what's interesting is it kind of becomes a death by a thousand cuts sort of deal. [19:50.530 --> 19:58.070] And that's where most developers kind of fail to realize the importance of cross-site request forgery, is that anything your users can do, you can do. [19:58.350 --> 20:02.150] And little actions can build up to have, you know, incredible potential. [20:02.150 --> 20:10.310] So, with the email account address changed, and this is a really common paradigm, now you can use the forgot my password feature. [20:10.650 --> 20:11.630] And guess where it's sent? [20:11.810 --> 20:15.030] It's sent to whatever email address you forced them to change it to. [20:15.310 --> 20:15.930] So, mine. [20:16.770 --> 20:25.430] The interesting thing about vampire freaks is they've done, like, the worst idea you possibly could in terms of security, and they've sent the original password back clear text. [20:25.610 --> 20:29.470] So, they haven't hashed it, and there's a big database full of everybody's passwords. [20:29.790 --> 20:38.950] So, you kind of have to think, well, what are the chances that one of these idiots on vampire freaks has used the same password for their email, their bank, whatever. [20:39.170 --> 20:40.730] You know, people use the same passwords. [20:40.810 --> 20:42.690] You get this kind of life password idea. [20:42.890 --> 20:48.170] And now that life password has been sent clear text to some guy's email. [20:48.830 --> 20:56.070] So, and then there's the tracking by the IM, and this kind of idea of propagation by sending the status update. [20:56.270 --> 21:01.350] You know, if you were really trying to attack this, you'd probably put some kind of luring text into the status update, too. [21:01.630 --> 21:03.770] Like, well, check out this cool site I just found. [21:03.890 --> 21:05.190] You guys should all come view it. [21:05.570 --> 21:12.910] And so, it'll spread sort of, you know, Wayne's World style with all the little friends telling their friends who tell their friends, and it just kind of grows from there. [21:14.630 --> 21:17.570] So, again, it's just bad, bad, bad, bad, bad. [21:17.750 --> 21:18.810] Don't ever do this. [21:19.030 --> 21:23.530] I mean, you have to be at least doing some basic MD5 hashing or something. [21:23.790 --> 21:27.550] Because you can see here, username paradox, password snazzy pants. [21:27.950 --> 21:35.490] So, if I happen to be using that really bad password for my email, my bank site, anything, whoever's attacked me now has it. [21:38.050 --> 21:42.810] So, it's probably a good idea to start talking about some protections against this kind of thing. [21:44.130 --> 21:48.330] There's generally two really common protections against cross site request forgery. [21:48.470 --> 21:50.370] The first is this idea of referrer checking. [21:50.370 --> 21:55.010] In the sense that all the actions on the site should be passing along the page referrer. [21:55.110 --> 21:59.810] Whatever caused the action... I'm sorry, whichever page caused the action is the referrer. [22:00.050 --> 22:03.750] So, the application can check that referrer and see if it makes sense. [22:03.790 --> 22:12.230] If your change email post request is coming from binaryparadox.net, and you're changing a vampire freak's password, it doesn't really make a lot of sense. [22:12.370 --> 22:13.950] The app can probably just discard that. [22:14.950 --> 22:17.810] In terms of being effective, it's strange. [22:18.050 --> 22:20.590] Because a lot of the research says that it's not effective. [22:20.990 --> 22:25.130] Because of things like plug-in vulnerabilities, you can forge referrer headers. [22:25.310 --> 22:29.090] Obviously, if you load up your browser, you can force the referrer to be whatever you want. [22:29.290 --> 22:29.830] Really common. [22:29.990 --> 22:32.230] If you can control the request, no problem. [22:32.430 --> 22:37.050] But it's a lot harder to spoof this referrer when you're doing it remotely through a cross request. [22:37.450 --> 22:38.650] So, is it effective? [22:39.290 --> 22:39.730] Possibly. [22:39.730 --> 22:40.430] Maybe not. [22:41.470 --> 22:46.550] Again, this cross-site scripting paired CSERF... Well, really, it doesn't matter. [22:46.690 --> 22:50.510] Because if you've got cross-site scripting problems in your application, there's issues regardless. [22:50.850 --> 22:53.730] So, CSERF's probably less of a concern. [22:55.630 --> 22:58.670] The traditional method is this idea of a nonce. [22:58.930 --> 23:04.890] And it's just a difficult to predict key or secret that the application can generate per request, ideally. [23:05.270 --> 23:07.010] And stick it into the form. [23:07.190 --> 23:08.950] So, the server comes up with some secret. [23:09.170 --> 23:12.150] And it tucks it into the client's session. [23:12.290 --> 23:13.130] So, that server side. [23:13.410 --> 23:18.150] And then it writes it out as a hidden form parameter to all the forms it sends the user. [23:18.650 --> 23:26.690] So, when future requests come back in, if they've come from the application itself, that secret should match up with whatever's in the session. [23:27.030 --> 23:39.710] And anybody outside of that kind of scope, well, they can't know what that nonce was because they can't see any of the content being sent from there because of this idea of same origin kind of policy in the browsers. [23:41.110 --> 23:43.990] You can use cross-site scripting to bypass this. [23:44.090 --> 23:51.090] If you can access the DOM on the site somehow, you can pull out the nonce and then generate it again or do all kinds of trickery in that sense. [23:51.750 --> 23:55.770] So, Jack Manineau at the bottom there, he's another web application researcher. [23:55.870 --> 24:01.210] He kind of put it nicely when he said that CSERF prevention is not cross-site scripting prevention. [24:01.990 --> 24:05.330] And cross-site scripting kind of trumps CSERF protection. [24:05.530 --> 24:09.050] If you're vulnerable to cross-site scripting, then you're vulnerable to CSERF. [24:11.230 --> 24:15.290] So, you can see that's what VampireFreaks did in terms of their email changing script. [24:15.590 --> 24:23.290] The interesting thing to note here is that this hidden parameter validate that they've added is not being generated per request. [24:23.510 --> 24:30.790] So, it's being generated per user account, which means, based on the look of it, probably like a SHA-1 hash or something. [24:30.930 --> 24:34.030] They're hashing some detail related to your account. [24:34.470 --> 24:53.990] And since it's not being generated per request randomly, if somebody then went and figured out what they're hashing and what the relation it is with your account, if it's like your first name or your last name concatenated together and then hashed, then the protection's broken because the attacker can just use the same scheme if they're targeting a specific user by hashing it ahead of time and [24:53.990 --> 24:55.490] then including it in all of their posts. [24:55.750 --> 25:01.670] So, it's always recommended that you'll be generating these nonces per request and ideally as randomly as possible. [25:04.690 --> 25:09.410] So, there are some other attacks and benefits that aren't immediately apparent for this kind of thing. [25:09.570 --> 25:18.630] And then, I'm gonna relate it to some other attacks that aren't sort of the typical cross-site request forgery, but share enough properties that I think it's appropriate. [25:20.890 --> 25:23.410] One of them, and one of my favorites, I think, is... [25:23.410 --> 25:25.090] It's called a cross-protocol attack. [25:25.410 --> 25:30.950] And it's largely the same as CSERF, except you're not really duping authentication in this case. [25:31.090 --> 25:49.610] What you're doing is aiming the payload form data at a non-HTTP service, which sounds crazy, but when you start using the right kind of form encoding generally used for file uploads, and you start having these non-HTTP services that are very generous in terms of what kind of junk data they'll let you have before a valid request, [25:50.170 --> 25:51.690] you can do all sorts of nasty things. [25:51.870 --> 25:54.030] And this, again, is another older attack. [25:54.310 --> 25:55.750] I'm gonna butcher the name here. [25:56.350 --> 25:57.850] Johan Topp, probably. [25:58.070 --> 26:07.170] He came up with this paper called HTML form protocol attack in 2001, and it was basically tricking browsers into sending arbitrary data to a specified port. [26:07.770 --> 26:20.410] FTP, SMTP, NNTP, POP3, all of these kind of traditional old protocols that are generous about throwing out weird stuff that comes in in terms of HTTP headers before the request. [26:20.690 --> 26:30.090] And then because the form encoding's been tricked, you can really sort of lay out your form data so that it forms a valid request after all of this junk data. [26:30.270 --> 26:41.670] So if the junk data is discarded, and you've got a valid request, then if you're using FTP or SMTP, you can start putting put commands and things like that with arbitrary data that gets forced. [26:42.130 --> 26:49.530] So what happened was, most of the major browsers, the easiest fix, they just started blocking ports by default that weren't related to HTTP. [26:50.290 --> 26:58.770] So the IRC port, the FTP... or sorry, not FTP, but SMTP ports that you should never really be sending HTTP data to, they just blocked them. [27:00.050 --> 27:08.910] The fun part, and what makes it relevant to this talk, is that in the past year, cross-protocol attacks have kind of had a resurgence, thanks to Goatsy security. [27:10.230 --> 27:12.890] And blacklists themselves, they're never perfect, right? [27:13.050 --> 27:18.630] You have to know all the bad ports, and all the services that could be on them, and specifically block those ports. [27:18.870 --> 27:27.330] And you have to be careful, because, you know, if you block the wrong ports, maybe you're breaking some enterprise application, and you've got developers and businesses breathing down your throat. [27:27.330 --> 27:30.130] So what they did was they had two separate attacks. [27:30.330 --> 27:35.290] The first was the Firefox XPS IRC attack, and the second was a Safari version. [27:35.590 --> 27:43.890] The first one, the Firefox one, what happened was, through this blacklisting process, Mozilla forgot to block the default IRC port. [27:44.310 --> 27:50.230] And they were able to reflect IRC spam to specific IRC networks. [27:50.430 --> 28:03.870] And what happened is, through the process of this reflection and the cross-site kind of request forgery nature of it, is that the people spamming these channels weren't Goatsy security, they were whoever happened to browse the website. [28:04.130 --> 28:10.410] So they're getting K-lined off their own channels, if you can trick developers from those channels, or users, or anybody, to view this webpage. [28:10.450 --> 28:14.710] Suddenly they're spamming their own channels, and the moderators kick in and start banning their IPs. [28:14.790 --> 28:20.910] But some of the moderators are then getting tricked into going to the channel, or the exploits, so they're banning themselves, and it was a mess. [28:21.730 --> 28:29.770] Safari, this one was interesting, because their blocklist was good, but they had one of these old C vulnerabilities, in terms of the unsigned short overflow. [28:30.390 --> 28:41.150] So, if you added the right amount, it would overflow a blocked port into a new number that wasn't blocked, but would be decoded to the same when it overflowed. [28:41.570 --> 28:50.410] So, like it says here, you add 65,536 to a blocked port, you get a new number, it's not blocked, so troll on. [28:53.650 --> 29:05.150] The interesting thing about a lot of these attacks is that, when you think of the exploit flow, you're obscuring the origin of the attack, really, in the sense that it's very hard to connect it back to whoever set up the attack site. [29:05.410 --> 29:11.290] The user requests bad content from somewhere, and then the bad content forces the user to perform an action. [29:11.530 --> 29:25.190] So, unless you can get access, in terms of what sent the user there, either their browsing logs, or if it was posted to the website itself, the luring URL, then there's really not a whole lot of ways to link the attack back to the attacker. [29:26.270 --> 29:31.330] The attack source is the user, and again, what the user can access, the exploit can. [29:32.450 --> 29:46.830] This becomes interesting when you start thinking about the general idea of firewalls, because the attacker can be outside of the firewall, and the victim inside, and if you can send them a link when they visit it, the attack is coming from inside the firewall. [29:47.030 --> 29:58.590] So, they're able to access Internet resources, networking equipment, test servers, whatever you normally consider off-limits, is suddenly available, because it's the user themselves that are performing the action. [29:59.190 --> 30:17.490] There's been interesting research in terms of these small office, home office routers, because if you can trick one of these users to view the content, you can access the router from the user's perspective, and do things like reflashing the firmware, changing the DNS server addresses, [30:17.970 --> 30:20.250] really anything you can do through most of these control panels. [30:20.250 --> 30:29.590] They weren't really hardened, because it's assumed you're accessing it from like 192.168.1.1 or something, you know, the local net block. [30:29.930 --> 30:33.830] So, you can do a whole bunch of bad things with that. [30:34.510 --> 30:39.550] So, I've kind of got this picture of it here, to just really drive the point home. [30:40.630 --> 30:44.930] So, you've got the attacker sending this luring link through the firewall to the victim. [30:46.490 --> 30:53.770] The victim then goes out, accesses this attacker site, and pulls content back through standard HTTP stuff, through the firewall. [30:54.110 --> 30:58.130] Not gonna be blocked unless the attacker site is already known as some kind of bad site. [30:59.290 --> 31:02.710] And then from there, you can fire off requests to anything, really. [31:03.030 --> 31:10.990] And there's been work in terms of doing some strange sort of port scanning techniques, by loading up images that point to a whole bunch of stuff that you think might exist. [31:10.990 --> 31:15.250] And then you can kind of time how long it takes for the image to load or not load. [31:15.590 --> 31:20.630] And you've been able to discover whether there's boxes at certain addresses, or services on certain ports. [31:21.530 --> 31:25.830] So, you can actually use this kind of idea to port scan things behind a firewall. [31:27.970 --> 31:31.650] So, I thought I'd throw this in at the end here, just because it's getting so much attention lately. [31:32.170 --> 31:34.650] There's this attack concept called clickjacking. [31:34.970 --> 31:38.990] It's kind of a terrible name, but everybody wants a cool name for all their new stuff. [31:40.030 --> 31:43.230] I consider it almost an evolution of cross site request forgery. [31:43.750 --> 31:46.410] There's probably a lot of people that are gonna disagree with me on that one. [31:46.610 --> 31:49.030] But you're still forcing authenticated client actions. [31:49.230 --> 31:51.230] You're just doing it in a different way. [31:51.510 --> 31:57.210] What they do is you sort of load the target website in an iframe again. [31:57.470 --> 31:58.990] But you make that iframe invisible. [31:58.990 --> 32:05.330] And then you figure out certain layouts so that you can move this attacking... [32:05.330 --> 32:08.510] The site you're trying to attack underneath the person's mouse cursor. [32:08.730 --> 32:11.970] And then you put up some big button like, you know, click here for the porn. [32:12.370 --> 32:18.550] And you lay it out such that when they click that button, the click passes through this fake button. [32:18.710 --> 32:23.670] And is actually clicking the form on the website to send a message and things like that. [32:23.670 --> 32:29.010] So it uses the real forms on the website rather than forcing some kind of fake request. [32:29.290 --> 32:33.530] So it bypasses this problem with the nonce because the nonce is loaded right into the form. [32:33.750 --> 32:35.330] They're actually using the form. [32:35.450 --> 32:36.610] They just don't know they are. [32:36.790 --> 32:39.050] And this has been a real problem for Facebook lately. [32:39.190 --> 32:43.310] All of these like exploits where people think they're clicking to like something. [32:43.470 --> 32:45.310] And then it gets sent out through all of their friends. [32:45.750 --> 32:46.990] This is all clickjacking. [32:46.990 --> 32:48.990] So I thought it added in at the end. [32:49.130 --> 32:50.370] Because it's basically the same idea. [32:50.530 --> 32:52.790] You're just forcing these authenticated client actions. [32:53.790 --> 32:56.690] Just now it's a little bit smarter because it's using the whole page. [32:57.250 --> 33:03.710] And they're getting better in the sense that they even worry less about trying to lay the fake elements on top of the valid elements. [33:03.750 --> 33:06.710] Because with JavaScript, you can just have it all float around the mouse. [33:06.810 --> 33:09.870] So if you move the mouse over here, then the page zips over to here. [33:10.070 --> 33:12.230] So there's really no way to not click on it. [33:12.330 --> 33:15.830] You know, if you click somewhere outside of this fake button, you're still clicking on the form. [33:15.830 --> 33:19.550] If you click anywhere inside the page, you're clicking on this form. [33:19.730 --> 33:23.090] So it's been awful in terms of trying to protect users from that. [33:23.530 --> 33:25.470] You're just hijacking the user input. [33:27.510 --> 33:27.910] Oops. [33:29.630 --> 33:31.130] So that's the end of my presentation. [33:31.150 --> 33:35.010] I got a lot of time here for questions if anybody's interested in grilling me here. [33:35.190 --> 33:36.590] I'm, like I said, a developer. [33:36.770 --> 33:38.270] I do this kind of stuff and it's a hobby. [33:38.470 --> 33:41.450] So if I've said anything wrong, feel free to correct me. [33:43.330 --> 33:43.730] Yes. [33:43.730 --> 33:47.300] Do you have remediation for clickjacking? [33:47.840 --> 33:49.240] Remediation for clickjacking? [33:49.400 --> 33:49.840] Yes. [33:50.380 --> 33:51.660] There's nothing great. [33:52.040 --> 33:55.640] Obviously, you can use something like NoScript, turn it off JavaScript. [33:55.960 --> 34:01.940] But again, you can't recommend that to your grandma because either she'll just stop using the Internet or she'll allow anything anyway. [34:02.720 --> 34:13.500] One of the newer techniques in terms of fixing clickjacking is an extra X header that you can put into your websites that say, I should never be iframed. [34:13.620 --> 34:15.860] If I'm being loaded and iframed, just break. [34:16.180 --> 34:20.420] The problem with that is because it's one of these X headers, you need browser support. [34:20.800 --> 34:22.640] I think IE8 has it. [34:22.940 --> 34:24.480] The new Firefox has it. [34:24.640 --> 34:26.420] But websites have to opt into it. [34:26.900 --> 34:30.640] And your user has to be using one of the right browsers for it. [34:31.120 --> 34:33.680] There's other kinds of iframe protection techniques. [34:33.680 --> 34:40.420] A lot of websites have hunks of JavaScript up at the top that try to detect when they're being framed and they bust out of it. [34:41.020 --> 34:43.120] There's been a paper, I think, last year. [34:43.220 --> 34:46.000] I don't know if I have it in my resources and I can't remember the name. [34:46.180 --> 34:54.600] But they surveyed a bunch of these websites with the frame-busting JavaScript and found that most of them did it wrong and you were able to still iframe the pages. [34:54.920 --> 34:59.600] So really, the only effective defense against clickjacking is this extra header. [35:00.120 --> 35:02.500] And it's not really pervasive yet. [35:03.920 --> 35:04.400] So... [35:04.400 --> 35:04.600] Yeah? [35:05.080 --> 35:15.120] As far as I understand, actually, no script will block clickjacks even if you don't have blocked all global scripts turned on. [35:15.280 --> 35:16.160] I think you're right. [35:16.300 --> 35:16.400] Yes. [35:17.300 --> 35:21.500] No script in particular has extra cross-site scripting protection. [35:21.940 --> 35:23.000] And I think you're right. [35:23.060 --> 35:25.840] They've added a special clickjacking protection. [35:26.160 --> 35:26.780] So you're right. [35:26.840 --> 35:30.620] It's probably better advice than I'm admitting to tell people to use no script. [35:30.620 --> 35:35.560] Even if they allow global scripts, like you say, I guess it'll still probably block these clickjacking attacks. [35:36.800 --> 35:37.860] So, any other questions? [35:41.180 --> 35:41.500] Pardon? [35:42.880 --> 35:43.860] Well, I put that in there. [35:44.020 --> 35:44.740] I'm from Toronto. [35:44.740 --> 35:46.860] So we just survived the G20 stuff. [35:47.080 --> 35:49.320] And there's a lot of injustice still going on there. [35:49.520 --> 35:58.900] Byron, in particular, was a CISP security professional who was doing some questionable things pre-G20 to kind of illuminate this idea of security theater. [35:58.900 --> 36:02.100] taking pictures of the cameras and the fences that were being installed. [36:03.060 --> 36:08.200] Supposedly buying things that were on, or that would potentially get you on a watch list. [36:08.560 --> 36:11.320] And they picked him up and he's still being held without bail. [36:11.320 --> 36:15.960] So this Friends of Byron Wiki is being run by the Toronto Hack Lab. [36:16.260 --> 36:17.360] He was affiliated with them. [36:17.380 --> 36:21.980] So they're trying to collect, you know, sensible resources and try to raise awareness. [36:23.060 --> 36:23.940] At the back there? [36:25.680 --> 36:26.880] Can't really see because of the light. [36:57.950 --> 36:58.390] Right. [36:58.390 --> 37:04.170] So his comment at the back there was that the refer protection that I mentioned being not all that great. [37:04.770 --> 37:09.890] A lot of people turn off this idea of sending referrers because they're worried about privacy issues. [37:10.030 --> 37:13.950] I know the Tor button plugin and a bunch of other things, they all scrub this referr data. [37:14.330 --> 37:29.050] And as he mentioned, if you're using this referr data to kind of determine when the requests are valid and when they aren't, if somebody's turned off sending referrers because it's something valid to do, then all of your forms will just break for them because that'll look like attacks. [37:30.790 --> 37:31.710] Any other questions? [37:34.860 --> 37:35.660] Another back there? [37:35.840 --> 37:35.920] Okay. [37:46.190 --> 37:46.650] Right. [37:46.890 --> 37:46.950] Yeah. [37:47.110 --> 37:49.170] There's a good list of default passwords. [37:49.370 --> 37:58.190] And then there's been lots of vulnerabilities in terms of these crappy D-Link firmwares in being able to access admin sort of sections without being logged in. [37:58.790 --> 38:03.850] So, normally that kind of vulnerability is not that big of a deal because you're not able to access the router. [38:04.050 --> 38:08.430] But if you suddenly can through a cross-site request forgery, you can kind of pair it with that. [38:08.750 --> 38:09.570] Otherwise, you're right. [38:09.730 --> 38:14.050] I suspect you're not gonna find a lot of people that leave themselves logged into their router admin panels. [38:14.330 --> 38:25.410] So, you're kind of relying on either a default admin password kind of deal or one of these other exploits that let you get to admin access kind of things without being logged in as an administrator. [38:26.310 --> 38:27.250] So, sorry. [38:27.330 --> 38:32.370] I've got resources at the end here that'll be posted up on my website at the bottom there, binaryparadox.net. [38:32.370 --> 38:36.790] And I believe those ones are all from GNU Citizen. [38:37.130 --> 38:38.890] They do a lot of web application stuff. [38:39.030 --> 38:44.370] And they had, like, I think a whole month almost where they were just hammering on specific router firmwares. [38:44.490 --> 38:45.830] This BT Home Hub. [38:45.850 --> 38:48.070] I think BT is based out of Britain somewhere. [38:50.250 --> 38:51.090] Any other questions? [38:51.930 --> 38:52.210] Sorry. [38:52.310 --> 38:53.110] I'm being blinded here. [38:55.230 --> 38:55.630] No? [38:55.950 --> 38:56.070] Okay. [38:56.270 --> 38:57.090] Well, thank you very much. [39:14.850 --> 39:15.990] Happy last presentation. [39:16.250 --> 39:16.790] Thank you very much. [39:17.210 --> 39:18.130] Let me give you a card. [39:18.410 --> 39:18.870] Oh, okay. [39:18.990 --> 39:20.310] In case you're ever looking for a job. [39:20.570 --> 39:21.230] Oh, excellent. [39:21.370 --> 39:21.870] In California. [39:22.170 --> 39:22.590] Thank you. [39:23.110 --> 39:24.170] Thank you very much. [39:24.270 --> 39:26.770] Thank you very much. [39:26.850 --> 39:27.650] There is a sales service. [39:27.890 --> 39:29.310] Pardon me? [39:29.510 --> 39:30.310] There is a sales service. [39:30.510 --> 39:31.130] Pardon me? [39:31.530 --> 39:31.850] There is a sales service. [39:31.850 --> 39:42.190] Actually, I was working for a co-op term with the president's choice financial application. [39:42.450 --> 39:45.610] So I can probably get you some contact information if you drop me a line. [39:45.790 --> 39:46.210] Okay. [39:46.210 --> 39:47.690] Or give me your email address or something. [39:48.490 --> 39:49.950] Can I take you on the way for that? [39:50.470 --> 39:50.890] Okay. [39:51.750 --> 39:53.650] I'm not affiliated with them at all anymore. [39:53.830 --> 39:56.310] This is just kind of a college sort of co-op program. [39:56.470 --> 39:59.610] But if you have serious information to pass on, I can probably find you somebody there. [40:00.590 --> 40:01.310] The only... [40:01.310 --> 40:02.670] It's not a security problem. [40:02.930 --> 40:03.070] Right. [40:03.270 --> 40:05.830] If you try to negotiate TNS to place, which we do in Pro. [40:06.210 --> 40:06.370] Okay. [40:09.970 --> 40:14.210] So I would like to email someone there and say, Hey, we would love to not have a special hack in Pro. [40:14.590 --> 40:14.950] Right. [40:17.190 --> 40:17.930] So I'll take it. [40:17.930 --> 40:18.570] Okay. [40:18.570 --> 40:19.770] Let's see if I can get your information. [40:19.990 --> 40:20.430] This is fine. [40:20.950 --> 40:22.190] I have a co-op program. [40:22.610 --> 40:23.990] I use some of the apologies. [40:24.330 --> 40:25.150] This is what I already mentioned. [40:25.590 --> 40:25.810] Okay. [40:25.950 --> 40:30.990] If you refer to an individual that you know on a white hat, they might be able to have a solution to solve this issue. [40:31.490 --> 40:31.630] Yeah. [40:32.470 --> 40:33.750] I won't get into detail right here. [40:38.750 --> 40:39.050] Sure. [40:39.530 --> 40:39.870] Sure. [40:39.970 --> 40:40.290] No problem. [40:40.290 --> 40:41.550] I'll drop you a line with Jerem. [40:42.510 --> 40:43.390] It's just Daniel. [40:45.250 --> 40:45.950] No problem. [40:47.550 --> 40:48.250] No problem. [40:48.490 --> 40:49.990] I really like that monkey sphere. [40:51.370 --> 40:51.810] Thanks. [40:52.670 --> 40:53.090] Pardon me? [40:54.450 --> 40:54.890] Nope. [40:55.150 --> 40:55.230] Nope. [40:55.450 --> 40:56.770] I'm just trying to pack up here and get away. [40:59.950 --> 41:00.390] Sorry. [41:00.630 --> 41:00.650] What? [41:00.650 --> 41:00.850] We are out of sight of each other. [41:00.850 --> 41:01.790] I was going to get one of them and everything is awesome. [41:02.170 --> 41:02.490] I think that depends on whether I can get them on Affiliate and I can get them guys ever