Plenary Session
24 May 2019
9 a.m.:
BRIAN NISBET: Hello. You few, you happy few. Good morning, so, it is the last day of RIPE 78 and we have lots of exciting things for you, which is what I was telling myself as I walked home at 2 o'clock this morning going, you are opening the session again tomorrow? Anyway, three out of four, I tell you.
So, importantly this morning, first up, we have Nurani talking about the IANA numbering services Review Committee. Thank you very much.
NURANI NIMPUNO: Good morning, you fresh‑faced RIPE community members, I am very impressed with all of you being here this morning. I am the chair of the IANA numbering services Review Committee, and I am going to give a quick update on our work.
So, as you may or may not know, the IANA Review Committee came out of the IANA stewardship transition where we added this Review Committee mechanism as a way of adding accountability between the RIRs and ICANN in the services that they provide to us.
And we decided that it would be composed in very similar way as the ASO‑AC, with representatives from all five regions, three from each region. And the role of the Review Committee is to provide advice to the NRO EC in the review of the service levels of the IANA numbering services, so IANA provides IP addresses, AS numbers, to the RIRs, and there is an SLA between the RIRs and IANA for this, and so this is an added mechanism to make sure that everything works as it should be.
So, we simply publish a report once a year, we base that on a matrix that we ask the RIRs to put together. IANA puts together monthly reports on the services that they provide and that's what the matrix is based on and we simply take that review it, ask for any other comments from the RIRs and then also ask the community if they have any comments.
So, from the RIPE region, we have got Filiz Yilmaz who is sitting here at the front, myself, who is the Chair and also there is a staff representative in each RIR region and in the RIPE region it's Filipe.
So part of our role is to make sure that the community knows about this, which is why they ‑‑ why I'm here, at 9 a.m. on a Friday after a RIPE dinner. And to make sure that if people have comments they want to provide, they can do so, and they know how to do that.
So, the very first year we spent a lot of time defining ourselves, the charter, mandate, scope, etc., but we didn't have to do that this year so it was very simple task. We put together a call for comments on this IANA services performance matrix and we have published our report. So what has our exciting report say.
Well there has been a flurry of activity and in 2018, there were two IPv4 allocations and three AS number requests between the RIRs and IANA.
And so there was one IPv4 request and allocation in March, which was responded to on time, implemented on time and accurately implemented. Two AS number requests in August, another IPv4 request in September and another AS number request in December.
And all these five requests were fulfilled accurately and on time. There was no indication of failure or near failure by IANA to meet the SLA. We also didn't see any particular interesting patterns or concerning patterns, and we also had no concerns raised by the community so we did a call for comments and we also published a reminder to that. We didn't receive any comments during that period, which was not really a surprise to us, given that the reports ‑‑ sorry, given that the, all the allocations have been made accurately and on time.
There were two minor formatting comments made after the comment period. They are not official as they are not part of the public comment period but we said they made sense and we said we would take them into consideration for our next report.
And that was basically it. But there is one more issue that I wanted to bring to you, and that is that when we formed the IANA Review Committee, because this is in the process of the IANA stewardship transition, we wanted to make sure to fill the seats of the IANA Review Committee immediately, and a very simple way of doing that was to take the members of the ASO AC and put them in this position, so Filiz and myself were volume untold to be on this committee, but this was never actually defined as a process or, it was never published and it was never announced. So we discussed this with the secretariat and the secretariat suggest that instead of coming up with a new mechanism to select new members of the IANA OC, that we simply use the ASO‑AC members for this, so it's just an added task, it's not within the role of the AS so AC but just an added role that we had to the ASO‑AC members. We think this is ‑‑ we said we think it's very pragmatic solution, and but we wanted to put it to the community, if anyone has objections or comments on this.
And if everyone agrees, we will simply go ahead and work with the secretariat it and document it, and publish it and announce it.
So boring is good, we think. We hope that you agree. If not, let us know. We are also very open to any thoughts or concerns you might have about the process or about the report, and in particular, let us know if there are objections to selecting the IANA OC members by ‑‑ from the ASO‑AC but adding this as an additional role.
Some references for you. And that was it. So, that was all from me. Thank you very much. I am happy to take questions, thanks.
(Applause)
BRIAN NISBET: Thank you very much. Are there any questions? Comments? Everyone is ‑‑ so that means the community are perfectly happy with the ASO reps fulfilling that. Okay. Cool. Thank you very much.
So, and next up, we have Filiz talking about the update from the ASO Address Council.
FILIZ YILMAZ: Thank you. Yes, from the ASO‑AC as a RIPE representative. First of all, thank you very much for being here at this time of the day. I am very impressed, I am more impressed with myself that I am standing here and I will try to be coherent.
So, what is ASO‑AC? We are this bunch of people who are looking on to the global policy development side of things and the way we organise our is that we are 15 people, three representatives from each region, each service region of the RIRs. Two of them ‑‑ two of us from one region is our elected members by the community at large, and there is one member that is appointed by the Boards of the RIRs.
We are also ‑‑ communicate and collaborate with the RIR and ICANN observers, but they are not officially part of the ASO AC, the 15 people are.
We have different terms coming from ‑‑ determined by our RIRs, and what we do is mainly, is the global policy development process related. We also advise ICANN Board when necessary on Internet number matters.
One other important task that we fulfil is to place two members of the ICANN Board, seat 9 and 10. We select these individuals.
On a particle note, we also appoint members to other ICANN bodies when and if requested, but mostly the regular one is a NOMCOM
The way we communicate is mainly electronic. We have monthly meetings but there is also one face‑to‑face annual meeting that we are required to attend and that is an ICANN meeting.
These are the people that are in the ‑‑ that are in service currently. You see their names over there. As ‑‑ in our case, from the RIPE NCC region as Nurani mentioned, myself and her we also sit ‑‑ we also fulfil the IANA Review Committee position. The other members, they don't have that obligation, they have different mechanisms to fulfil that committee. And the reason I'm mentioning this here now, we need to document this because this, now, comes automatically. If you are interested in becoming an ASO‑AC member, then you will be ‑‑ you will be also fulfilling IANA R seat so that function needs to be not somewhere so that you know what you are getting yourself into.
So, like I said, we have certain activities and we focus on in a certain scope and the main one is the global policy development process, and this, we take this mandate from the memorandum of understanding that was signed in 2004, the very first time between RIRs and the ‑‑ and ICANN. And there it is defined as the global policies are defined as the ‑‑ those policies that are in agreement by all RIRs and some they ‑‑ somehow, they do relate to an IANA function or some other ICANN‑related body. So it needs to be the same and it needs to be coordinated between RIRs before ICANN will go for any implementation about them.
The way they are developed is following the same principles of the ‑‑ processes of the RIRs. Mainly, they stand still from the regional communities, they get discussed there and if the regional community within the regional RIRs service region the policy is accepted, then it gets moved to NRO for a stamp as like, okay, this is a global policy. And then it comes to us, saying, ASO‑AC review the process, and our job is not to review the policy at that point, our job is to review the policy development processes that are followed in our respective regions so that if the process is okay and everything was covered and done according to the processes that are in place, then we can ask ICANN Board for rectification.
Our other activity as I mentioned, is to fulfil the ICANN Board seats, two of them, namely seat 9 and 10, and this year, recently, we have fulfilled the seat number 10. The nomination phase ‑‑ these things have very strict rules as we set it down and we have strict time‑line and this is set by our operating procedures. The nomination phase for this already started last year in September and we just made the announcement about a month‑and‑a‑half ago, with the name of the selected candidate on 22nd March, and Mamar Kinara was selected for seat, he was ‑‑ he was fulfilling the seat already and he is now selected for another term.
One other activity that we have been busy in, I should say in the last year, and even longer than a year, is dealing with the results of the ASO review which was conducted back in 2017 and this is a regular review that needs to be conducted every now and then and NRO is involved making sure that this process takes place. I'm sure some of you may have been interviewed during this review. And out of this review process, we received, as ASO, received 18 recommendations. Out of those, about five were relating to ASO‑AC and we have been working on those recently and we just concluded our agreements, what to do with recommendations 9, 10, 15 and 16, and you can find these in the link above. There is a nice document that NRO secretariat now outlined, where the implementation or agreement or what we are doing about any recommendation is document.
The most recent ones are relating to meetings, mailing list, chair duties and term limits. The meetings in ‑‑ in regards to meetings on mailing lists, there were two recommendations specifically saying they should be more open because ASO‑AC conducts closed meetings and the recommendation was that they should be open to public or at least publically archived. And we took on that and we are working on this. We agreed to make them open, except times that we are discussing, of course, ICANN Board's nominations and individual variation criteria, etc..
The ‑‑ one other recommendation was about term limits of the chair and vice chairs. In the past, we had hard‑working volunteers from the community who was being ‑‑ who fulfilled the chair function for years. However, for good governance, the recommendation was that there should be term limits and it should be renewed and we agreed on doing that every five years, so now RIPE ‑‑ sorry, ASO‑AC chairs will have five years of a term.
And all this will ‑‑ is part of our, of course, documentation and they will be ‑‑ we are in the process of having the text written down and this will be part of our operating procedures since we just concluded work, soon they will be published.
And finally, yes, we have been also looking into just so self reflect how we are doing overall and let you know what we are doing and how we are doing. We decided that there was a request that the ‑‑ part of the ASO‑AC members are explicitly publicised, put out there, so in that regard, your current representatives, together with our Board appointee, we are doing good. We have been attending all the meetings, we have been present. So, good on us.
And if you have any questions, I can take them. Otherwise I am done.
BRIAN NISBET: Thank you very much. Are there any questions. There are, okay. I didn't mean to sound that surprised.
AUDIENCE SPEAKER: Herve Clement: Being part of the ASO ‑‑ it's not ‑‑ thank you Filiz for all the datas you provided about the work we provide within that community. I think tried work in a coordinated way to do that, and so I wanted to ‑‑ I think it's important to maintain that link between the ICANN and so the set of the different system of registries and the community also. Thank you.
FILIZ YILMAZ: Thank you.
JIM REID: No affiliations or anything like that. This was very valuable work, Filiz, but I think there is a small but important thing you overlooked which was to explain the ASO is a constituent part of ICANN that is required under the ICANN by‑laws and this is key into ICANN's multi‑stakeholder model because in this case the ASO is a ‑ for the RIRs of the addressing people to be part of that whole bigger ICANN machinery alongside registries and registrars and governments and all the rest of it and I think it's important to make sure that's understood. I think most people in the room probably do know that, but I think it would be helpful in the future always make a reference to that point, that's why this thing exists. Thanks.
FILIZ YILMAZ: Can I address? Thanks for the reminder. And this is an interesting part because ASO has two hats under it, there is ASO‑AC and NRO, number resource organisation. ASO Address Council scope is pretty defined so this is why I am just ‑‑ I wanted to ‑‑ we wanted to update you on our activities, but you will see on the recommendations as well, as you mentioned, Jim, there are 18 recommendations and out of the 18, only five of them relate to ASO‑AC, the rest is in fact for the overall address support organisation, which includes the NRO heads and RIRs and, yeah, that is the part, maybe Axel or John Curran can give another update in the future for a moreover Youghal generic presentation for ICANN activities. Point taken, thank you.
BRIAN NISBET: So I just have one question I was thinking myself. It seems like a long time since we have had a global policy.
FILIZ YILMAZ: Yes.
BRIAN NISBET: Maybe this is an unfair question to ask, but how realistic are global policies at this point in time? I mean, you know, do you in your independent capacity or otherwise, have any feeling for the chances of someone actually managing a global policy at this point? I mean, we have seen obviously policies ‑‑ the same or similar policies being raised in multiple different RIRs but not as a global policy, and I'm wondering if you have any feeling for how likely it is that people will continue to attempt to raise global policies at this point?
FILIZ YILMAZ: Well, it is a good question. We are sorted in terms of the current mechanisms that we have to work with, IPv4, version 6, ASNs, those require global policies to note how they should be delegated. And they are in place. Now, if one of the within the RIR regions there is a request that those delegations or the size of them or the way they are delegated needs to be changed, if there happens to be a need arising, then there will be one. From the RIR side, I believe from the Review Committee hat, that I am also part of it, I see that there is no issue so it is very unlikely to see soon but you never know, things change as we ‑‑ as we know nowadays. So, yeah.
AUDIENCE SPEAKER: Can I just add to that ‑‑ Hans Petter Holen, also former ASO‑AC member for many years ‑‑ it's very important to understand the definition of global policy within the scope of the ASO, because putting a policy proposal in all the regions does not mean that it is a global policy within that scope. The global policy within this scope is only dealing with interactions between IANA and the RIRs. And that's important. So, it sort of changing the size of blocks or making the process different and so on, that would be a change to the global policy. And I guess the global policies that were put in place so were so good that there hasn't been any need for any updates to those. Thank you.
BRIAN NISBET: Thank you. And I think that's one of those things and Jim alluded to it as well, we sort of assume the community knows what's going on, we also talk about bringing new people and having new LIRs and rapid growth and all the rest into the community. So maybe that's a thing for us to consider about how we further communicate those pieces to us. But thank you very much.
FILIZ YILMAZ: Thank you.
(Applause)
BENNO OVEREINDER: Thank you. Next speaker is Theodor Gislason. Very happy he is here. He also attended the social last night, but I served him a double shot latte, so I think he will do fine.
THEODOR GISLASON: Can everyone hear me? Great. I hope you have had a great time here this in Iceland this week. I only attended yesterday and I am a bit under the weather, as I am sure some of you are as well and I have also been told by a good friend of mine in the audience here that people are are not afade to ask questions, which is great, so please, don't hesitate if you think I'm saying something that you either disagree with or you think is ‑‑ needs a little bit of more clarification, just don't hesitate and I will try as best as I can.
So this is the title of my talk, it's probably a little bit of a click bit there, but I hope you enjoy it, but, yeah. And that is my name.
Okay. So these are the companies that I represent, I am a founder and CTO of SYNDIS which is kind of a small offensive security testing, we have a spin‑off company called adversary which is a training platform to teach engineers and developers thousand hack so they can understand the impact of vulnerabilities and code and application systems. I am also on the Board of Nanitor which is a technical security compliance product and just because I know I should not do any sales, but the digital marketing person at adversary pleaded with me and because I see a lot of you are using your computer, and a lot of you using Macs, which is great, if you want to hack or are bored during this talk, go ahead, you can go to this site and slash redeem and use the code RIPE 78 and there is about 30 labs that you can try your hand at, everything from buffer overflows to more generic stuff.
I am not going to stop, I am not going to do any more of that. This is the talk today and I am hoping that I can engage you in a way where I am sure of you are completely aware of this but just give you the mindset of the hacker or the malicious offensive party who is targeting specific organisations or individuals such as yourselves, and I was going to have a live demo but I was supposed to be at 10:00 and so I don't have time to prepare but if people are interested in seeing the exploitation phase and how it works because all the things I am going to discuss today are logic vulnerabilities, I would be happy to show you outside of the room later if people want to gauge that a little bit, I just don't have time connect the computer so it's plan B.
Okay. How many people here use Facebook on regular ‑‑ not a lot ‑‑ okay. So I am sure there is a reason for that, and obviously we ‑‑ actually I use Facebook and my profile is pretty much public, and I do that for a reason, because pretty much everything you put on Facebook anyway is being harvested and most of social media, this is happening everywhere and I think we are aware of that, we see pretty good examples of abuse and so, yeah, and why don't we want to expose our information through social media? Because we are worried what people do with that information. And if you bear with me here for a second, because I am not a member of RIPE NCC, I did a little research and obviously I know RIPE and some of the mandate that you have and how important it is, you literally control the Internet, it's like having the keys to the kingdom and that so it makes a lot of sense, because I am a hacker, I have been doing it for about 25 years now, you are my targets if I was a malicious person. It makes a lot of sense to me. And, yeah, as I said, we are aware of this, most of us, and we are afraid of social media and things like that, but we also have lots of other social media, lots of other social media, for engineers, developers, where we are exposing ourselves every day, our habits, our interests, our friendships, our code, the applications that we use on our machines throughout dot files or configuration files or whatever it may be. And for me and for malicious people ‑‑ I do this for a living, and it's super interesting for me but I also know this is interesting for those that are malicious, and because it's a treasure chest of information, and obviously this is just a short example of a what you could use, but I put RIPE NCC in there for a reason, because I wanted to try to incorporate RIPE into this talk a little bit, and if I take a look at it, this is a tool that I use at work which I call Cloud Sitter and what it does, it just enumerates data through public APIs of services such as GitHub in this case but it could be GitlLab or whatever. Anyway has a public API which you can use all the users and data and so forth and I wanted to take a look at RIPE just for a second. Like, five minutes.
And on GitHub is just out of curiosity, is anyone here a public member of RIPE on the GitHub? One person. Great. Okay. So you are one of the 12 people in there. But there is 35 repositories, public repositories that contain a wealth of data, a wealth of data. And you can surmise and make assumptions based on this public information, there is 12 people, there is people obviously like Python and Java and Shell script and JavaScript. Interesting. This tool that we use, and I am sure a lot of other entities use, like to enumerate all the data that's stored in these Cloud repositories. And because in the public repositories you have, even if you are not a member of RIPE NCC, maybe you have committed some code changes, maybe you have done something over time. And that leaves a trail and Git, which is the ‑‑ yeah, you can have all the information, it's publically available, everything that happens over time and all the details, who sent it, when and so on and so forth. And just by enumerating that and using these public repositories, I found a few other people, maybe someone will recognise themselves here, so, yeah, obviously I know there are about ‑‑ over 800 people that attended the conference this week, so it's definitely not a full list, but it's a good target selection for me, about 276 associated parties and I mean obviously because it's all public, I can get a little bit of information about all of these people in the tool. You can get their emails, work emails, private emails, it's all public, all part of the commit log, all public. You can get their SSH keys, the public keys. Did people know that? You can even find secrets, which is being abused all the time now, but I actually don't think that's the most interesting part here. For me, there is so many abuse cases here. You could use it for marketing purposes, you could use it for any number of purposes, but for me, it's the preferences; what a person uses on their computer. I can find out you are a mac user, if you are ‑‑ if you have committed a lot of code I can figure out what editor you like to use and any number of interesting things and make assumption and infer what is useful for me because I want to hack you, I want to break into your computers, because you have the keys to the kingdom.
Okay. So, does this work in the real world, is a good question. And I'm going to share a little bit of insider of engagement with a company we did with Dropbox and you can read their version of it and I encourage you to take a look of it. If you Google it security testing to make Dropbox and the world a safer place. It's a task blog it's more technically detailed the things I am discussing. If people want to take a look at that and ask questions, great. But it's their version of events, which I think is always a good thing to note. But what the project was that we did with them, was a black box red team engagement. We don't know anything, red team versus blue team type of scenario. And that's pretty much what it was about.
And I'm not going to stop very long for these type of slides, but the reason why a company like Dropbox would do something like this you are measuring whether your security controls are effective or not. It's a jack box thing as well. And you are trying to assess whether there is a good return on investment of your security team.
And for ‑‑ for me personally being a hacker of 25 years it's a challenge. Usually when you do red team or penetration test something like that and I am sure you have heard this before, it's really easy most of the time. And this is kind of sad, and so whenever you are going up ‑‑ against someone that has invested heavily, it should be more of a challenge, and indeed it is. So that is fun. Because we are like living in extremely rapidly growing evolving cyber battlefield, I don't like that word but I will use but you can see the evolution of technology and cyber threats. There is so many things there. Being someone who was raised in the 90s when I was phone freaking and all sorts of other interesting things I can't talk about, it was very different, it was people that had had the hacker mindset, being curious. It's evolving and it's evolving into something that's rather disgusting. It's the organised crime and the fraud, which is just rampant. We see that all the time. I am sure you have seen it through your work. But what is also happening is that you have nation states affecting the outcome of democracy, and elections and I find it really interesting as a hacker that the only organisation hacked during the 2016 US election was the DNC, the Democratic National Committee, and Hillary, Hillary Clinton, not the other, because I am sure it would have been just as easy to break in.
And so, yeah, just it's a wild time that we live in that this is possible today through hacking.
Okay. And we also ‑‑ this is my pun. The fruits are RIPE for the picking. There is a lot of stuff out there, you guys know this a lot better than I do, I know you do in fact, and but there is definitely a lot of things, there is lots of targets and so there is ‑‑ yeah. Okay. So how do I do this?
Is there a mouse? There is a video. What is also happening and for me this is great, this means a lot of business, lots of work, but over time, this is a nice info graphic from the world's biggest data breaches over the years and we can see a trend of some sort. And, yeah, there is something happening here. It's the golden age for cyber offensive testing and that kind of stuff. Anyways, things are changing and we know this is driven by money and other reasons, political reasons, but what is also happening and I think people are not as aware of this as they probably should be, is, hackers are not stupid; they are lazy, yes, but not stupid ‑‑ if you put them in a group, I should say. And they are realising that data itself has value outside of just encrypting it through like ransomware or something like that ‑‑ ten minutes ‑‑ I am sorry ‑‑ okay.
BRIAN NISBET: You probably have longer. All very relaxed this morning.
THEODOR GISLASON: I have no sense of time. But so hackers are realising that data has value and a good example of this is what happened to Uber, have people heard of this? Hackers, I think they found an API key on GitHub or something and used it to steal customer data from an exposed AWS machine or something like that. And they sent an e‑mail to the company quite literally saying, we will release this data publically if you don't pay us 50,000 dollars. And they paid. They paid. And the hackers deleted the data, of course. So I think this is going to grow, because when people are faced with, like, ransomware, it's a disaster recovery problem but when you are faced with extreme fines if the data is released, it's a different problem.
So, okay. Lots of Mac users in here, and this is a myth, I'm sure some of you are also aware of, I hear this all the time, and the primary reason, in my opinion why Macs ‑‑ this myth exists, it is because it doesn't have critical mass of users yet, and when it does, yeah, times will change. So, if I turn it back to what I was talking about before, you are the target. When I was doing this work for Dropbox, it's pretty clear most of their engineers, the people I am interested in, I am not interested in the service desk people, I am interested in the engineers because they have production access, right? So, it's pretty clear most of them are Mac users. And you can see lots of trends, what software they use through enumerating all of these services, and one of the things I did was, do like low effort high high impact vulnerability research. The point there is, if you know someone is running a no name marked down editor on their machine, nobody has ever heard of this except a few people that are interested in it but it leaves a trail in your public repositories, I can expend a little effort to find a high critical impact vulnerability in that particular software and target you as an individual. This is what I did. And I found a number of these for this particular project, I am not going to go into all of them, I am just going to talk about one related to Apple which was kind of a happy little coincidence that it was discovered because it wasn't really the intent. The intent was to use other vulnerabilities and I will name the product in case someone is using it here, I term, anyone use that? Not any more. Okay. So there is a problem with I term, I am not going ‑‑ but it is the reason why the exploit chain was created that I am going to discuss here. And so zero day, I don't have to go into any details what it is, it's something else nobody else knows about, it's a vulnerability in code or an application or the logic or whatever that you can weaponise into something we referred to as exploit. But another analogy would be it's just a cyber bomb and it's something that you can use for very nefarious purposes, as we have seen when they are targeting individuals.
Okay. So it's ‑‑ it can be extremely malicious and an evil thing but it's also technically interesting and I think it's beautiful and I think there is an art to this type of thing. So, but it usually relies on some fundamental vulnerability in code or the operating system or piece of software or whatever it is. And there is lots of defences today. There is a sandbox and, you know, they are pretty good. I guess. And if we take, this is from Synac, I am stealing their slide here, this is one example of modern operating system defence that is running on your Macs, it's called Gate Keeper and if I assume this Mcwhich it is, it's set up in the secure way, I know none of you use it this way butts used where allow apps only downloaded from the Mac App Store. It's a default setting. Usually identified developers means the application is signed by a valid signature. And so, if you see this example here, it's gait keeper and malware dot app can't be opened because it's from an unidentified develop. If you were ‑‑ phishing attack, this is what you get. It can be bypassed, if you find a good vulnerability or a number of vulnerabilities, you can bypass this particular defence. For the demo I am going to show you it required three vulnerabilities to bypass all the operating system level defences and gait keeper to gain arbitrary code execution on the Mac OS devices. You can read them if you want to check out. It's procession and maliciously crafted web page may result in the mounting of a disc image. Think auto run. And may result in the launching of an application. That is where the gatekeeper protection comes in. And a maliciously crafted application may be able to bypass code signing enforcement. This is exploit chain for real vulnerability used in the real world for an engagement.
I am going to do a video. This is just the exploit, not a weaponised version of it so it's a bit louder than it should be, but you can just see the version of it. Some people may ask, and I know what about Chrome, there is a way to invoke this through Chrome, you need a bug in Chrome. Or a person can open a JHTML attachment which invokes Safari. It's run and mounting a decks image, runs terminal and the calculator. Code execution. And this is a total sandbox escape because it's invoked through the browser which is supposed to be running in a sandbox and, yeah, pretty much, pretty much, not everyone, I mean some people are more security‑aware and they enhance the security of their operating system, but this is pretty much the point here. You can ‑‑ this is the weapon you can leverage for whatever purposes you use. Usually you wouldn't go find vulnerability in an Apple product to hack a company like Dropbox because you would use other tools you are running on your machines. Easier to find exploits and vulnerabilities that makes it a lot easier. But, yeah, the reason why hackers do this, we do this to target people with access, people that have the access already so you don't have to spend a lot of resources on lateral movement because we are lazy. And just to give you kind of an idea of the cost, there is a competition every year, called zero day initiative, at a conference in Canada and they have a competition there. Unfortunately Apple and salve fare, it's not the highest value target, tells you a lot, you can see worth on the open market and this is very public open market, it's about 55,000 dollars US. If would you sell it somewhere else, I'm sure you would get a lot more but you would also be accessory to murder. So there is a definite, something to think about there. Am I over on time?
BRIAN NISBET: How much longer?
THEODOR GISLASON: Just a couple of minutes. So just this particular exploit chain that we discussed ‑‑ did we see the demo? Sorry. I am too tired here. So was it ‑‑ how much effort was this? Was it crazy amounts of dedicated time? And I actually I know, because my background is in binary exploitation, that it's a lot of work to do a good exploit especially from memory corruption issues, but this was the logic chain exploit so there was no low level manipulation here. But this wasn't a huge amount of effort. In fact, the idea was to exploit another vulnerability which is the I term vulnerability, I just needed a delivery mechanism for it and when I was heading out to San Francisco at the airport I thought maybe that would work and one thing led to another and about 24 hours later I had a working proof of concept and most of the work happened on the Wow plane, I don't know if you remember that airline? But I had a great seat there. This is the computer I did it on. It's still vulnerable. So it's the throw away. I am leaving out a lot of details obviously here, but I hope you enjoyed it, and just to send, because I am definitely out of time or running out of time, you are the target. Yes, you are. And be mindful of the power that you have and what you expose through mediums you may not realise, give people like me and evil versions of people like me, a lot of information about yourselves. Because people don't want to post anything on Facebook because they are afraid of it being used for analytical purposes, but there is a lot of other information out there and so be mindful of that. And because I hate this question, and I am sure some of you do as well, when someone especially senior level management asks whether something is secure, it's a terrible question. I hate this question. Nothing is secure. It's much better, in my opinion, to measure security or the state of security or how secure you are, like, by the cost or the amount of effort it takes to break whatever security controls you put in place, this is the true measurement, in my opinion. And it's also critical, whoever you are, whether it's RIPE NCC or whatever, figure out who you are defending against. I'd love to control the Internet, I'd route it to million dollar home page or something, something fun. But figure out who you are defending against because there is scales that ‑‑ yeah, so, yeah, if you have questions, I am going ‑‑ I also want to go back to this because the salesperson is going to kill me, please try it out. The idea is to give people the idea to see what it is to hack in the real world so we can better have a good understanding of it or the impact really is, and because everybody understands how you robe a bank you go in with a gun and ask for the money but most people don't have this understanding of how we break into things. So if you have any questions?
(Applause)
AUDIENCE SPEAKER: Constanze Buerger from the ministry of interior of Germany. I think we are aware of all your facts and messages but the way forward is the question, how to make sure that we are secure for the next years, and I don't want to regulate, that's too much politics, able to regulate very fast. But that is not a solution from my perspective, so ‑‑ and I use this new device here, and I disabled all the things you explained, but what's the reality? I can't work any more, so I tried to enable the RIPE app, the communication app, but it's not working, so that's the fact. So... and I can work, I can use these social media things and tools, or not, that's the alternative. So my question is for you and for the audience, let's go forward and make the world more secure but help us to do this.
THEODOR GISLASON: I think it's a great question. It's unfortunately a question, because I break things, I am not a solutions architecture but I agree with you completely, because the alternative for me is, I'm just going to stop this computer stuff and I am going to start a pizza place somewhere in Italy and have a good time. So ‑‑ I would love that. But I don't have a solution. I only present problems and ‑‑ but I think this audience probably is much more adept at solving these regulatory and technical problems underpinning the kind of state we are currently living in than I ever would be. But I'd love to have a dialogue about it.
AUDIENCE SPEAKER: Tom Strickx from CloudFlare: I was wondering did you actually use your exploit chain in a Speer phishing attack against Dropbox?
THEODOR GISLASON: Yes.
AUDIENCE SPEAKER: How did their blue team respond to that?
THEODOR GISLASON: I had this in my notes, I should have said that in the presentation, they caught me right away. And can you imagine how I felt?
AUDIENCE SPEAKER: At least you tried.
THEODOR GISLASON: I tried, but they have a great security time and they completely nailed me to the wall, it felt horrible because I had invested some time here and, yeah, and it was ‑‑ it was because they had good, constant monitoring, they have a great security team, and so I was a little bit sad because there had been a lot of exploitation effort there but for me it's a learning experience, I will try not to make the same mistake I did that caused the alert because we did a nice debrief at the end so it's a learning experience for me but absolutely they completely caught me, I felt like a fool.
AUDIENCE SPEAKER: Thank you.
RANDY BUSH: IIJ and Arrcus. It is worth mentioning that although you cannot make your machine secure, there are things you can do to improve it.
THEODOR GISLASON: Sure.
RANDY BUSH: And there are long lists of them and there is good advice for both Mac users and of other strange operating systems but I have a question: How many people have their hard disc ‑‑ full disc encryption turned on? It's pretty good.
THEODOR GISLASON: I was in a conference not very long ago and I don't think anyone in there had it on.
RANDY BUSH: Yeah, well, different conference.
THEODOR GISLASON: Yes, internal auditors.
RANDY BUSH: But so there are things you can do, that's one of them. If your neighbour had their hand up and you don't, get them to show you.
THEODOR GISLASON: Yes. Just on this point, I don't remember what the ‑‑ what the repository was on GitHub but there is a great repository about making your Mac more secure. It's hundreds of different ‑‑
RANDY BUSH: There are a couple of them, including some put out by a couple of governments.
THEODOR GISLASON: Yes.
RANDY BUSH: But if people can write me, I collect these things, but I am sure he does too. You can Google them.
THEODOR GISLASON: But just to be on that particular point, it makes breaking in to a person much harder ‑‑
RANDY BUSH: But not impossible.
THEODOR GISLASON: Not impossible. It does increase the cost, the particular exploitation I discussed wouldn't have worked if you had disabled one setting in Mac OS which is save file types in Safari, which means it will automatically open a particular file type. This is a horrible setting. And if that had been disabled the first part of the exploit chain wouldn't have worked. So it's a great point.
AUDIENCE SPEAKER: Magnus at Netnod: Just a short comment on this full disc encryption. It only saves you at one state and that's when the laptop is powered off, because when you boot it up and you unlocked it, it's like an unencrypted disc so you should be aware it only works when powered off. If you close the lid you still are vulnerable so it's just protecting you when not really using the laptop at all, you use laptop containers ‑‑ if you should protect ‑‑ for things when you are working with your laptop.
THEODOR GISLASON: Yes. Personally I use Knox for enencrypted containers.
(Applause)
BENNO OVEREINDER: Next up is Taiji Kimura.
TAIJI KIMURA: Hello, I am from Japan. I think my first attending the RIPE meeting is ten years or more, I think, but my presentation is a first. So, it's very happy to be here.
This is about RPKI, and this is in short story, things happen in Japan but it maybe happened worldwide. Before talking about it, I will explain about the RPKI in the Asia Pacific region.
And the second part is my main story, the last two is from my observation.
In Pacific ‑‑ Asia Pacific region, we have national level of registry we call them NIR. Several exist, and three NIRs started their RPKI service, so it looks like full three configurations. And technically, the resource certificate is like this, RIR, certificate has more resources than NIRs.
In Japan, we also have RPKI service as a trial for accumulating ISPs' operational knowledge. The number is quite low comparing with RIPE, but interesting is that this. This is because large ISPs in Japan started creating and ROA and we have a tutorial course periodically, but the starting RPKI service is, it's not forced to members, it's based on the ISPs' demand.
The next part is my main story.
One customer experienced reachability problem and this customer is very interesting. It's operating IPv6 and routers, mobile routers. Anyway, the customer reported to an ISP in Japan unreachable for one website in Europe. He used mobile router, it's reachable. IPv6, reachable. Trace route, reachable until AS one front of the destination.
Then, the ISP responded for the customer as guiding reboot customer's router as usual in help desk. It is good for many troubles in customer side.
Then, asked on the web form for the website about reachability. This is the support ‑‑
And ISP assumed that the prefix for the customer is filtered in the path. So, the ISP asked for the AS front of the destination number 5, but no good answer returned because no relationship with the ISP. As you can see, ISP and AS number 5.
Then, the ISP asked AS 1 to 4 to help asking AS 5, but all the responded as no action will be taken because no problem found for the prefix.
As you may guess, they checked by using their own IP address so source addresses are different from the ISP.
Finally, the ISP got a response by e‑mail contact found in peering DB. The reason was invalid prefix length it means that's different from the ROA created two or three years before. The prefix length in BGP route has been changed for personal reason after creating ROA for several years, human or organisation cannot remember the things over years. Then by fixing maximum prefix length in ROA, reachability has been recovered.
This is not simple case, I think. It's not just ‑‑ nor just technical issue but will be happening in worldwide.
What will happen with dropping packets using ROA? It makes it where we will be heaven or operational hell.
Three things will happen:
IP address holder may leave ROA different from actual BGP route. So it's difficult to remember two or three years before. End user will experience unreachability without any sign or alert. And only BGP operators can know the reason and only IP address holder can fix the problem. So different players need to react to solve the problem.
What should be cared from now? We have long chop sticks, we don't need to aware of the length of the network, but we can use it for helping people or ignoring something in the world.
So, let's spread the idea on using ROA is my message. For network operators, please try and know what to happen when using ROA. For AS ISPs, when unreachable happen for some specific routes, remember to investigate origin validation state. And consider communication over different NOG or regions like this.
What we can do:
The adoption rate is often talked but it's not only for ‑‑ only the indication of security. And encourage communicating between engineers and between tech and non‑tech persons. It includes the customer supporting staff. And spread the culture of mutual help in BGP and Internet without making it a tie in the rule.
Conclusion: Dropping invalid routing using origin validation with ROA can make unreachable network. To ease recovery from misconfigured routes or ROA, communication is important.
I said chopsticks in this story, but the original one is in for spoons. It can be unique, same story but difference could be based on the difference of the regions, but we have the same tool for different regions. There are many information events, technical presentations at RIPE meetings, so I will make this story as mental story. We are between the hell and heaven, we can choose. So, let's use this tool for helping each other. That's it from me. Thank you.
(Applause)
BRIAN NISBET: Thank you very much. Are there any questions or comments?
AUDIENCE SPEAKER: ‑‑ I just want to recommend people to use the NLNOG RING which is fantastic tool for testing for various places all over the world, and I think when we have problems like this and you say it's not common, it's very, very nice presentation but we just need to make it more common because then we will have it on top of the mind when we are researching reachability problems. So thank you.
TAIJI KIMURA: Thank you.
BRIAN NISBET: I think the thing with the hopeful increase with things like ROAs and things like that and new problems that we were finding, that we have to go back a bit to a lot of the ‑‑ we have kind of all assumed in many ways that BGP has worked, and we have been fine. I am being very blase here. But now when we put put more things on to BGP we have to go back to a point of the communication that we all used to do on a lot more regular basis between ISPs and ASs so I think this is a very timely reminder.
RUEDIGER VOLK: Deutsch Telecom. For supporting good operational results with the RPKI, it is not only a thing that ROAs are registered and people get them and use them for various filtering purposes. There actually is a need for improved communication, as you are saying, and actually organising this in a way so that parties have good access to the information relevant for them. So, one part of your story is that the people owning the address space quite obviously lost track about the information that they are responsible for and kind of, that part should be addressed by setting up systematic reporting to the address holders which are many in the RIPE region obviously something like 20,000 organisations or is it 24, who knows? And giving them regular feedback about what the system is seeing about their resources, also keeping in mind that with the various parties involved in the overall system, actually the intentions of the holders may not be any more correctly reflected in the formal system. And the formal system, of course, in the end, decides what the ‑‑ what actually happens to the packets if the formal system is applied correctly, if the formal ‑‑ if the formal system does not apply correctly, of course we don't know and the outcome is completely undefined. And yes, I think ‑‑ I think for that kind of information, and the relevance that address holders actually should, once in a while, check whether their intentions are actually met, is something that kind of is not the usual thing for quite some time, that we actually will have to push in that direction.
RANDY BUSH: IIJ and Arrcus. After all BGP is so easy to use and so obvious to measure, etc., etc., unlike BGP, which you can do with your left hand while not looking, this you actually kind of have to know the tool you are using and understand it. And kind of I think you are responsible for that, and come on, kids...
BRIAN NISBET: I think maybe we need to have some sort of community had a has meetings where we can communicate better together, Rotterdam, next October anybody? Thank you very much.
(Applause)
So, our second and last lightning talk of the session is Roland, talking more about RPKI, it's almost like a thing, the RPKI way back machine.
ROLAND VAN RIJSWIJK: Yes, I work with NL dot labs as you may know by now. This is ‑‑ normally talk about DNS and I am glad I jumped on the RPKI band wagon just on time because it seems to be the thing, this is not the first presentation about RPKI.
And I am going to talk about what we dubbed the RPKI way back machine for those of you who watched quantum leap in the 80s and 90s, Ziggy says there is a 20% chance we will end up in 2011.
We make RPKI reliant party software, that is the stuff that validates this RPKI information and allows your router to make decisions based on that information on whether or not to drop announcements. Now, Routinator has seen a lot of uptake and a thankyou to all of you in the room who are actually started using it but of course we want to test our software to make sure it's robust and functions properly and we got some really, really nice data from the RIPE NCC that we could use to test our software with. We got 8 years of RPKI ROA data for all of the RIRs and we decided we wanted to try validating all of that.
So, what did we do? RIPE NCC actually started archiving all of the RPKI data from pretty much the get‑go in 2011 and they dumped this for us into Targz files, no host or I can files, that was a bit of an issue so we wrote a Python script, Ziggy, that could help us transport us back in RPKI time.
Al with Ziggy in his hand.
Right. So what did we do? You can give the script a date and what it will do is find all of the files that contain the RPKI data for that date, unpack it in a format it likes, Trust Anchor locators, which allows you to sort of, the start of your validation chain. And then we run Routinator using a tool called fake time which is available on most Unix systems. And we did this from January 2011 when the data set starts until February 2019 which is the last date for which we had data archived, but as far as I know the archive still continues to today.
A very quick recap on the RPKI jargon because you are going to see this on the next couple of slides. RPKI is the resource public key infrastructure as I hope you all know by now. And ROA is a route origin authorisation which authorises a certain autonomous system to 00announce certain prefixes or to originate certain prefixes if you will. And VRP is a verified ROA payload. Yes, and that is an acronym in an acronym. We are tech people, after all.
This is a cryptogamically valid statement about a prefix from a ROA so Routinator was able to do successfully validate the ROA and then it outputs a VRP which the router can use.
Right. So, we processed all of this data and I put all of this in R and made some plots and the first one I want to start with is what does this data look like over time? What you see in this graph is starting in 2011 and ending somewhere this year, the number of validated ROA pay loads that we managed to squeeze out of Routinator. What you can see here is that RIPE has an and nice rising curve. This is for IPv4. But it's suddenly starts here, that can't be true, right? As it turned out before this date, the objects that RIPE had weren't quite following the specs and Routinator refuses to validate them, which is fine because this was an experiment that I literally ran over the course of this week, but that means we have to sort of make some changes to our software so we can actually validate all of that as well.
Another thing that stands out is this huge spike here. I marked it on the graph as three ASs deaggregate ROAs "disable" max length. So they changed their RAOs such they all match very specific prefixes, but this was not a conscious act, this was software making ‑‑ doing something. This was actually APNIC, they confirmed this via e‑mail, they made a change to their RPKI system and one of the side effects of that was that it started massively deaggregating ROAs and as soon as they found out that this was happening, they made some changes to the software to stop that.
This is actually somebody who owns a lot of prefixes, consciously deaggregating in the RIPE space so they changed their ROA policies.
Right. Of course, I can't get away with not doing this for IPv6 so here is the same graph for IPv6. And if you ‑‑ if I flip back and forth, you can see that the shape of the graph is more or less the same. So for IPv6, deployment of RPKI seems to at least follow sort of the same trend, which is good news because people are paying attention to both.
Another thing that would be interesting to look at is the prefix size in the ROA payloads over time, and the take away from this is that the red line is 2015, the purple line is 2019, is that the prefix sizes in ROAs are going down, so it is much more common MoU to find RAOs for a /24 than for larger prefixes, and as you can see here this is the 50% line so more than 50% of VRPs now contain a /24 as prefix in v4.
Funnily, max length is also following that same pattern but way more extreme there. So the ‑‑ here, 62.5% of RAOs have a max length set to 24 and the other take away from this is again if I flip back and forth what you can see is that max length is actually used, so people publish ROAs with a prefix that is bigger but then set max length to allow announcement of smaller sub prefixes.
In v6, we see similarly a distribution of different prefix sizes, but the other take away from this is that before ‑‑ so red again is 2015 ‑‑ in 2015 this was pretty much a bi‑model distribution with either /32 in the ROA or /48 but very little in between and that has changed over time. We now see many RAOs with different prefix sizes for v6, and similar story for max length and again max length is used for v6 as well as you can see.
So we were wondering, for those of you who are a bit more familiar with the RPKI space there is some debate about whether using max length is a good idea or not. What I did is make a plot from 2015 to now and the reason I started there is we know the data is sane from that point in time. How many VRPs contain a max length that is different from the prefix size in that VRP? And you can see here that it's ‑‑ it starts roughly at 20% and then it goes down and this is the aggregation event that gets undone but what you can see here that is creeping back up again, and we are hypothesising people have starting dropping invalids but then you run into mismatches where the ‑‑ somebody is announcing a more specific prefix that is not covered by the ROA and then they can do two hinges: Can announce a new ‑‑ set a new ROA or they can change the max length in the ROA and I think the previous speaker mentioned a similar solution. And what we believe we may be seeing here but we need to check that over the coming months that is what might be happening, people are fixing stuff and one of the ways to fix it is set your max length correctly.
Also max length is used more for IPv6 than for IPv4, which kind of makes sense, the address space is a lot bigger.
So one more thing: Geoff Huston presented yesterday in the Routing Working Group about developments in the routing space, and one of the things that he mentioned was that people, unsurprisingly, keep announcing smaller and smaller and smaller prefixes. We see the same thing in RPKI, where this is, what I plotted here is the average prefix size in both the ROA and the average max length in the ROA and both are rising. So we are now at an average ‑‑ an effective average prefix size of almost 22 and three‑quarters. So that's approaching a /24.
For IPv6, we see more or less the same thing. It's slowly rising over time.
So, conclusions, because I am running out of time and otherwise Brian is going to kick me off the stage: We wanted to test Routinator and what we found out, it actually took sometime for RPKI to stabilise as a well‑defined standard as the RIPE data shows, which we weren't able to validate from day one. But we are looking into fixing that and supporting the older standard in Routinator as well. This is very interesting data, as a researcher at least, because it tells you something about the development of this protocol over time but we have this unique opportunity because RIPE actually recorded all of this data from the very first moment that RPKI was getting deployed, which is a very valuable resource for researchers.
Now, the next step for us we are going to compare this against actual routing information so we can say something about what fraction of announcement was actually covered by RPKI, were they valid or invalid, and we are working on the paper about that, with data from RIS and route views.
I want to end with an acknowledgment, a big how the shout out to the RIPE NCC for archiving this data and especially Emile who helped a lot in cleaning up the data and making sure we could use it and we are discussing how this data can be made available publically so other people can do research on this as well. And with that, if you have any questions, let me know now or come to me after the session.
BRIAN NISBET: Thank you very much.
(Applause)
And obviously we thought we would have a NLnet Labs presentation so you could start early today. We have time for one probably comment or question, please.
AUDIENCE SPEAKER: Tom, Cloudflare. On your graphs you show that there was, for the v6 prefix length, yours went beyond 48 so there was RAOs being signed for /64s and stuff like that and you didn't show the same thing in the IPv4 space, is that because nobody is doing it, which I doubt, or is it because you just didn't bother?
ROLAND VAN RIJSWIJK: I actually cut the graph, it goes beyond 64 and for v4 it goes beyond 24 as well but it is a very small number of, a small number of VRPs, because it would be ‑‑ just see a sort of a straight line in graphs so I cut it out. But there are a handful of RAOs with prefixes beyond 64 in v6 and prefixes beyond 24 in v4. And one more thing: There are a lot of extra slides in there this so if you download it from the RIPE website, I crammed all of the graphs that I made into the other slides but obviously I didn't have time to show you all of them.
AUDIENCE SPEAKER: Tom: Thank you. Awesome presentation.
BRIAN NISBET: I assume at the end of the graph there is a Gif of somebody sobbing silently.
So that's the end of this session. We are back and you are back with the same Chairs because we are that lucky this morning, in half an hour. But importantly, the conclusion of the NCC General Meeting is in 15 minutes' time in this room. Please remember ‑‑ so you can come back in, stay here or come back in that for that. Please rate the talks and we are back at 11:00. Thank you very much, enjoy your coffee.
LIVE CAPTIONING BY
AOIFE DOWNES, RPR
DUBLIN, IRELAND
