Okay, so our next speaker for the day has just finished his PhD on security of yeah, I think that deserves a round of applause on the topic of security of a WPA, TLS and RC4. He's now doing his postdoc and focusing on wireless security, so and the next talk the title is predicting and abusing WPA2 80211 group keys. Please give a big round of applause to Mati van Hof. Okay, thank you for the nice introduction. So I am indeed Mati van Hoef and I'm going to present predicting and abusing WPA2 group keys or more officially 802.11 group keys. So first a quick introduction to Wi-Fi security. What was the state of Wi-Fi security before I did this research? Well, essentially Wi-Fi security has been thoroughly investigated. There have been a lot of results. For example, we know with the very first security algorithm of Wi-Fi wired encrypted privacy, in other words, web. It was horribly flawed. You probably all noticed that you can crack a web network within mere minutes. In fact, if you download the latest tool suite of Air Quack NG and there is enough traffic on the network, you can really obtain the pre-shared key of the network within only a few minutes and sometimes if you're lucky, even seconds. So the first attempt by the 802.11 group to introduce a security protocol, it didn't really went that well. We also have other attacks recently against wireless networks on in particular against WPA2. One example, which is quite recent, is that some vendors or some ISPs, when they hand out their router, they initialize it with a default password with a default passphrase and it turns out that these are rather predictable. In particular, this default password, which should be shown somewhere here on the back of your router or on the car to receive with it, it was derived from the MAC address. So if you want to attack one of these networks, you simply have to sniff the network, determine the MAC address and from that, you could derive the shared key, the pre-shared key of the network. And similar to this, you also have dictionary attacks against the WPA2 handshake. So these are all known attacks and the way that this dictionary attack works is essentially, you can force a client to disconnect from the network and then it will reconnect with the network. And if it reconnects, it of course performs a fresh handshake with the access point to negotiate session keys. Now, the bad part about this handshake is that as an attacker, you can capture the four messages that are exchanged in this handshake and then you can perform offline guessing attacks at the password of your network. And if the handshake would have been better designed, these kind of dictionary attacks would not have been possible. Unfortunately, the way the handshake was designed, you can make a capture of the handshake, you can process this offline on these kind of dictionary attacks are unfortunately possible. I think a few years ago, there was also a attack which shows that using a bit of social engineering as well, you can even attack WPA2 enterprise networks. And these are networks where you have to type in your username on the password. So think of Iterom or your company network, or also here in the CCC network, you also have one of these enterprise networks as well. And the idea behind this attack, I'm not going to go in detail here because these are known, but one of the parts that they use is they broadcast a network with the same SSID name as the target network, but they include a small space bar behind the name. And if you then look at the network name in your operating system, you won't notice that the network is, for example, Iterom and then a space bar after it. So it's essentially a completely new network. And if you connect to a completely new network, your operating system won't really complain because otherwise it would say, okay, previously you connected to Iterom, now it certainly uses a different certificate, this is bad. But because the space was after the SSID, your operating system will think, oh, it's a new network, everything is fine. But as I mentioned, I'm not going into detail, I'm just mentioning it as related work in a sense. Lately there have also been a few more theoretic attacks against WPA T-CIP. They are similar in spirit to the text on the web, except cracking WPA T-CIP is much, much more difficult, even though there are also other weaknesses in WPA T-CIP, so you should not use it. But there are theoretical attacks that allow you to recover the session keys as well. Though they are very hard to execute in practice. So why am I telling you all this? Well, if you look at all this previous research about the security of wireless networks, we can see that a lot of this work is focused on the security of the pre-shared keys or of the negotiated session keys. So that has received a very large amount of attention from the research community and also from hackers. However, the keys that are used to protect broadcast traffic, so the group keys, they are not widely used. So here is something strange with the slides. For some reason, one slide is missing. But anyway, so these group keys, they are used to encrypt broadcast on multicast traffic. And that is in contrast with session keys. So for example, if you see here, your access point, it has a group key. And it also has a session key for every client that is connected to the network. So what we noticed is that the security of these negotiated session keys is properly studied, but the security of the group key is not studied. So what I did during my research is that I investigated how these group keys are managed during their full lifetime. So what do I mean with the lifetime of a group key? Well, we have our access point here. When you start your access point, so when you start your router, the first thing that happens is that it generates a fresh and random group key. And here we notice that the random number generator, so the RNG that is used to generate this group key is flawed. So the standard suggests a bad random number generator as a reference implementation. And we will see in practice that certain vendors also implement a random number generator that is predictable. And this will allow us to predict the group key. So that's essentially the first stage of the lifetime of the group key when it is generated. The second part is when a client connects to the network. When it connects to the network, it performs this four-way handshake. It negotiates the session keys. These are sometimes also called the pairwise keys. During this handshake, the group key is also transported to the client because of course it needs to know the group key to be able to decrypt broadcast on multicast traffic. And what we found here is that we can manipulate this handshake as a man and a middle attacker. And we can then use, we can then force uships of RC4. Meaning the group key when it is being transmitted from the access point to the client is encrypted using RC4. RC4 is an insecure cipher. You should not use it. In this context, we will see that we also, currently it's a theoretical attack, but we do have an attack against the way RC4 is used in this situation. Now, also one of the more interesting parts is also, let's say that we now as an attacker have the group key, what can we do with the group key? Because of course, if we know that key, we can decrypt broadcast on multicast frames, we can inject broadcast on multicast frames, but can we do even more? And here we're going to show that using some clever tricks, we can use the group key to inject unicast IP traffic. So not just broadcast traffic, but also unicast traffic. And we will even show how we can decrypt nearly all internet traffic of the network. And then at the last part of the presentation, I'm going to propose a new idea on how to better generate random numbers if you have a Wi-Fi device. But the main part of the presentation will be these first three steps on in particular predicting the RNG and then abusing it to decrypt traffic on inject traffic. So before I get to the main content of the presentation, I'm going to give a little bit more background on how these group keys are used. So let's say we are in the following situation. We have our access point here, which has the group key of the network on which has the two session keys of the two connected clients here. Let's assume that in this situation, Client A wants to send a broadcast network over the complete network. Now, if Client A would send this broadcast frame itself, then there is a problem because there are certain situations where clients are out of reach of each other. So that's the hidden terminal problem. If Client A would broadcast the message, Client B would not receive it. So this was of course anticipated by the designers of the Wi-Fi protocol. So instead, what happens if this client wants to send a broadcast frame, at first sends it to the access point. And it will essentially send this frame with as the immediate receiver the access point. However, the final destination is the broadcast MAC address. Because the immediate receiver is the access point, it will be encrypted using the session keys. And when the access point receives this frame, it will also use the session keys to decrypt this frame, but then it will see, oh, okay, the final destination is actually the broadcast MAC address, meaning I will have to forward this to all clients. And of course, all clients are in range of the access point. So in this case, all stations will receive it. And when the access point sends the broadcast frame, the immediate receiver on the final destinations are both the broadcast MAC address, meaning in this case, the group key is used to encrypt on sent as frame. So the important takeaway message here is that only the access point normally will send real group frames because the client will first forward it to the access point as a unicast frame. So that's for the quick introduction. So as I mentioned, the talk will mainly be about predicting the RNG and then decrypting all traffic. So let's start with predicting the RNG. So the first question is, okay, does the Wi-Fi standard specify some methods on how to best generate these group keys? And it turns out that yes, they do specify a method. And in particular, they have a certain procedure for generating the group key that will be used. On the crypto people call this the key hierarchy that is being used. So it's actually fairly straightforward. When your access point starts up, it will generate a public counter value. So a random counter, it does not start at zero. It can start at any value you want. But it's public. So an attacker or outsiders are allowed to know this variable. Apart from that, it also generates a private master key on this has to stay secret. Otherwise, all your security guarantees are gone. So once you have generated these two fields, we simply take a hash of both of them. On the output of that hash is the current group key. And the current group key is also called group temporal key. On the reason they call it temporal is because you can refresh it every hour or every day or every 10 minutes. And that's also the advantage of this construction. Because if you want to generate a group key, it's very simple. You simply increase the public counter by one. You recalculate this hash value. And then you get a new group key. So this design seems very nice. Because if you want to generate a new group key, you simply increase this public counter by one. And you calculate a new hash. Unfortunately, this design is actually quite bad. Why is that? That is because these two values are only randomly sampled when your device boots onto new entropy is never introduced into the system. So if for some reason an attacker either compromises this key and knows it, he can predict all future keys. Or in our case, if the random number generator is bad, we can probably predict all future keys that are generated. So this is a bad design and should be avoided. Unfortunately, it is officially specified this way in the standard. So in principle, the standard recommends everyone to use this key hierarchy, this procedure. So okay, now we know that if we can predict these two values, we can derive our group key. So the next question is, how are these random numbers generated? Again, the Wi-Fi standard provides us with an answer because it suggests an example random number generator. If you read the standard, it actually sounds quite promising because it says the RNG that we use should generate cryptographic quality randomness. To show you the quote in detail, a station must be able to generate cryptographic quality random numbers. Once you can look in the appendix at section M5 to see how you can achieve this. So this sounds very promising. Until you actually go to the appendix, on there it says, whoa, wait a minute, what we're going to show is just an example solution. Ideally, you should extend it yourself. And of course, that's not really, this is a strange situation because in the standard itself, it says this RNG in the appendix is secure. But if you actually read the appendix, it says this is just an example solution. It may not be that secure after all. So we have an inconsistency in the standard here. And just to come back to the text that is shown in the appendix, it says that, okay, you probably should combine it with other recommendations on how to generate random numbers. This is expository only. Again, you should probably improve this, which is very strange to see this kind of language in a standard. So we basically have an inconsistent description here. It says that it should be secure, then it says it's not really secure. So the question is, how secure really is this random number generator? And the next question is, how many platforms implemented? So let's look in detail at how the random number generator is implemented. And here we see that the standard basically defines a function, which is the RNG. And first and for all, it's a stateless function. I'll come back in a minute, why that it's a bad idea. But first and for all, it has a very vague description, even if they only meant this to be like an example solution to get people on the way. Because if you look at the code, there is a main Y loop here, a main loop, and it simply says, repeat this algorithm until it's random enough. They don't specify what this means. So that's very strange and suspicious. A bit suspicious as well as also at the end of the algorithm, at the end of the loop. So during certain parts of the loop they say, if the time is not available, you can simply set it to zero. So this line might not be that bad. If they include something like, if you set the time to zero, maybe you should include, should do more iterations of the main loop. But they simply say, oh well, if it's not available, you know, just skip it. So like I mentioned, the standard is a bit hard to interpret because they say it's an example solution. But in other parts they say it's supposed to be good. But even if they only meant it as an example for the vendors, this description is still just too vague. Now to come back to this stateless part here, the random number generator is executed on demand. And only when this function is being called is randomness collected. And again, this is a very strange design, because if you have a proper RNG, for example, the one in OpenBSD or the one in Linux, or the one in any decent design, basically, their entropy is constantly collected in the background. For example, you have your timing of interrupts, timing of packets, you have clock skew, and so on. Normally, all this randomness is collected in a so-called entropy pool. And then if you need randomness, you can extract a random number from this entropy pool, for example, using a hash or any other construct. But the fact that this function is executed on demand is also a very bad sign. So all that is not that promising. And if we then look at the actual events where it extracts randomness from, we can see that it's mainly based on the time stamp of that frames are arrived and also on clock jitter. So let's look at these two sources in detail. We have our frame arrival times. So if your router would be connected to an internet cable and there would be a sufficient amount of traffic, then you could simply collect this based on internet traffic. However, you don't always have the guarantee that there is sufficient traffic available. The standardization committee, the people realize this, like there may not be that much traffic available. So what they said is, no, if there is not that much traffic, simply wait until a client wants to connect and then send a few messages of the handshake, then abort the handshake, restart the handshake, then abort the handshake, restart the handshake until you captured enough frames. So this first one for all would be very time consuming. The second bigger problem is, if you are a client and you are constantly trying to connect with a network but it fails a few times, then your device will simply blacklist the access point and this will not work. So the fact that they even simply suggested using this is my opinion absurd. So the second source is the clock jitter on drift. So if you have a clock in an implementation and it's never completely accurate, there is also a small amount that you can't predict as an attacker. The problem here is that they don't specify a minimum resolution that the clock should have. So a vendor can use any clock at once, even one with a very low resolution, meaning only a very low amount of entropy is collected. And of course that's quite bad. So after I saw this, I thought to myself, okay, this is just basically a big mistake of the standardization people. Surely everyone realized that this was bad, aren't they implemented something better? But when I actually looked at codes, so yeah, this is really like, what the hell are you doing? So if you look at vendors, we have, for example, media tech. It used to be called also rallying. And they implement this random number generator almost as specified with a few changes. And those changes actually weaken it a bit more. They also did one good part, by the way. I'll come back to that in a minute. Then there's also Broadcom. The random number generator they use depends on the operating system that is being used. Then there is also Open Firmware, which is a good example of an embedded system on Terras host APD, which is the open source implementation of Linux. As you can see, they do it properly. So we did a very rough estimate of how many networks are run using this media tech or Broadcom implementation. So this was just using a very quick war drive around my city. And I determined whether the device is using media tech or Broadcom based on the fingerprint of the beacon. How that works is explained in a different paper. But essentially, I did a very, very rough estimate. At most, let's say 25% of networks could be vulnerable to this. I would say maybe 5% or 10% could be attacked using a text similar to the one we're going to present. Just to show that these are a bit popular and you might be able to use this in practice. But anyway, let's look at the first implementation, the one of media tech. So what did they do? Well, first and for all, they implemented the key hierarchy, so the procedure on how to generate these group keys as proposed by the standard. So just to recap, this is this construction where you generate two variables, one which is secret, the other which can be public, then a hash is taken onto the output as shown. They do improve this slightly, actually. So they do one thing that is good, namely instead of when they want to generate a new group key, instead of simply increasing the counter by one, they actually constantly generate a completely new random value for the counter. That's actually a very good decision, because then you are introducing new entropy every time you generate a group key. However, this group master key, that one is only sampled at boot time. Okay. So we now know how their construction works. Now the question is, how do they implement this random number generator on Can we then try to attack it? Well, this is the bad part of their design. They only use clock jitter to extract randomness on to collect entropy. In particular, it uses the so-called Jiffy's counter of the Linux kernel. So the Jiffy's counter is something that is increased every tick, but not every processor tick, but every logical tick. And I'll come back to that in a minute. So this RNG is likely quite bad. And this is good for us, because at least for us as attackers, because we simply have to predict the group master key on this public counter, which is also called the genomes, the group nones. And if we can predict both of them, we can derive the group key. So let's try to attack this RNG. As I mentioned, it uses this Jiffy's as the counter. The problem is, these Jiffy's have the best millisecond accuracy, which is rather low. In fact, it's really low. So this means in practice that the GMK, so this secret key, which is generated at boot, generally it always uses the same Jiffy's value, so the same clock values. So that means in practice, for the GMK, there are say around 200 to 300 possible values. At least if you have a, I tested this on my device, on for a specific device, on specific firmware version, then you have a limited set of possibilities. Of course, if you run a different firmware version, then some other things might happen during the boot process, influencing the time when these Jiffy's values are collected. But if you know the implementation, you are attacking, you have a very limited set of values. Then the second part is we have to predict this genomes value. On most routers, the group key is regenerated every hour, meaning this genomes value is also sampled every hour. So in order to predict this value, we need to know the uptime of the router to predict the range of possible Jiffy's values that were used. How do we determine the uptime of the router? Well, it's quite simple. The uptime is leaked in the beacons of most routers. So we simply have to sniff beacons, then we can estimate the uptime of the router, and then we can estimate the time of when this genomes was generated. So basically, what do we have to do for a successful attack? We need to capture one encrypted broadcast or multicast message. We have to capture also a few beacons to estimate the uptime, and then we can do a search through the whole key space. We tried this against our own router, so that's this one. Here we noticed, well, we implemented a program on the GPU, in particular on OpenCL to make sure we can do this in a timely matter. We found that using the GPU in my laptop, which is just standard GPU, you can even get better GPUs or even multiple ones, but even just on my normal laptop, I can crack the keys within three to four minutes. Thank you. So this is assuming the router also has an uptime of one year, and if the uptime is around one year, then there's also a lot of clock skew, meaning predicting the genomes is harder. So if I'm going to demo the attack in a few minutes, then I know that the uptime was very low, meaning I can reduce this number even further, because there hasn't been that much clock skew, meaning predicting it will be easier. So this, in a sense, is also a worst-case estimate. However, I do have to note that this is only if you are attacking one specific device. If you know which device you are attacking, let's say you don't know the exact firmware that is running, then you have to perform a bigger search. So the end result here is that you get both the master key and the current group key. So I planned a demo here. Now, Wi-Fi demos are always very risky, especially in a situation like this. So fingers crossed. So let me first try to mirror the screen. Let's hope we don't already fail here. Okay. So here I have a Wi-Fi device that is running in the monitor mode. And I have a script that will capture the frames sent by my router. So I already put it in monitor mode, so that is simply this script. Just execute some commands to put it in monitor mode. And I'm now going to capture packets that are sent by my router. And I made a Python script for that. So let's execute that on capture packets from my router. As you can see, it's now trying to capture packets, but nothing is received yet. And that is normal because the router is not yet started. So let's put it on. This was planned by the way to show you it's real. So now the router is booting. And in a few seconds, it should be receiving beacons from which it can derive the uptime of the router. You can see, there we go. We got a beacon. Now it's waiting for an encrypted broadcast packet. Now, this is one small limitation of the attack. As you can see, it was waiting until my laptop connected to this network. Because if no one is connected to the network, then there is, of course, no traffic. So there must be at least one client, or for some reason, your router has to send one broadcast frame that is encrypted using the broadcast scheme because otherwise there is nothing to crack. We don't have any data. So in this case, we captured this frame. So let's try to open this capture file. So you can see here we captured a lot of beacon frames. This beacon frame has a field here, which is called the time stamp. On from this we can determine the uptime. So here you can see it. Here it's very close to zero. And every time it increases, on from this we can determine the uptime of the router. There you go. On at the very end of this capture, we have this broadcast packet, which we want to decrypt. So let's try that. So as I mentioned, this works on the GPU. So first I have to type opti run to enable my GPU while executing the next command. So I simply have a script here. I'm attacking the MediaTek implementation, and I'm using the capture I just made. So now it parses this file here. It lists all the networks that we captured. In this case, because we are in a crowded room, I made sure that I only captured frames from my network to try to make sure that the demo indeed works. And you can see now it's trying to predict the group master key. And it has estimated that the Jiffy's values that were used there were around this number. And the Jiffy's values that were used for the genomes it has estimated around this value. Now you may be wondering why is this Jiffy's values so high? Doesn't it start at zero? This is actually very interesting, in my opinion. The Linux kernel starts at the Jiffy's value of minus five minutes. Why do they do that? Well, that's because if you are a developer, on there somehow is a bug in your driver that after five minutes when your Jiffy values overflows there is a problem that developers would very quickly detect issues if your Jiffy's value would overflow. This is just to explain why this number is so high, even though we just booted the router. And anyway, you can see that we successfully found the group key here. And it even decrypted the packet for us. So that worked. And it wrote the single decrypted packet to a file as well. So let's open that as well so you can see that it indeed works. Here, that's the wrong file. On here you can see the decrypted broadcast packet was an ARP packet. On here you can see the decrypted packet. So we indeed correctly predicted the group key until we were able to decrypt this packet. So let's now try to switch back to the presentation. Okay, I will have to go through these slides again probably. Okay, so that was the demo. The demo gods have praised us. Thank god it worked. So now let's come back to the other vendor, the Broadcom vendor. So as I mentioned, this depends on the operating system that they are using. In particular, if they are using Linux, then they implement the group key hierarchy as specified in the standard, but they simply read randomness from def uRandom. So that is much better than the random number generator proposed in the standard. However, a few years ago, there was a paper called Mining Your Peace and Queues by Henninger et al. They showed that specifically on embedded devices and on older Linux kernels, def uRandom might be predictable. So this means that on certain devices, def uRandom is predictable, and in turn all the group keys might be predictable as well. Now if you run a newer Linux kernel, this should no longer be an issue. However, because a lot of routers use an old kernel, this might be an issue. I haven't tested this. This is simply based on their paper that def uRandom is not ideal for older kernels essentially. So that's for Linux. This Broadcom implementation also runs on VxWorks on the ECOS. So for those of you who don't know what these operating systems are, VxWorks on the ECOS, they are both essentially real-time operating systems. VxWorks is proprietary. It's used a lot in aerospace, so it's used in the Mars lander. It's used by SpaceX. It's also used in drones. And of course it's also used on certain routers and access points. Then there's also ECOS, which is essentially similar. It's also a real-time operating system except it's open source and it is again used in aerospace and it's also used by the military in certain situations. But of course we focus on when it's used in the router and when it's used as an access point. So we see that in this case Broadcom again implements the 802.11 group key and for random numbers it has simply takes the md5 hash of the current time in microseconds. So again that's not ideal at all. There is also another disadvantage of their implementation. They use this public counter in the handshake, in the four-way handshake that you use when you connect to the network. Now this is perfectly allowed. There is nothing wrong with that. But it does make it easy for us as attackers because we can collect the value that was used here in the handshake onto the one that was used while generating the group key will be only a few numbers away from this value that was leaked. So really the only thing we have to predict here is the group master key. And if we have the group master key we can then again predict the group key. So one popular router which is vulnerable to this is the WRT54. At least if you have one that uses version 5 or higher then it uses VxWorks kernel. So if you have a router which is version 4 or lower it runs on the next.  But if you have version 5 of this device or higher then you might be vulnerable. Unfortunately I only had older versions of this router at home. So I simply simulated this attack. Again using OpenCL code. And even with just simply quite modest assumptions. I predict that you need around four to five minutes on my GPU to crack it. Let's say that for some reason my simulation is not perfect. Then you can use a more powerful GPU to still predict it. But again taking the MD5 of the current time in microseconds it's simply not sufficient to collect enough randomness. So that concludes both these implementations. Then we also have two other examples. The first is called OpenFirmware. On the second is hostapd. So OpenFirmware essentially it's a simple open source BIOS system. What was really surprising to me is that during the BIOS these people have very basic support for Wi-Fi functionality. At least as a client. You can even connect to a WPA2 secured network. Now for me that was very surprising to see that BIOS supports Wi-Fi. But they do. Now I do have to say here that they only implement client functionality. So they don't implement access point functionality. So they don't actually generate a group key. However they do use a random number generator to generate other values that are used during the Wi-Fi handshake. Ante use a very very simple methodology. They simply take the amount of ticks that have occurred since boot. They run that to a linear congerential generator which is simply a deterministic function and that's used as the random number generator. The output of this is hashed to get a sufficiently long output. But still this is very easy to predict. And we included this because this is a very good example of an implementation that is running on an embedded system where there is no kernel available to provide you with random numbers. So in this case we are in the BIOS. There is no kernel. There is no libraries we can use to generate random numbers. But we see that in that situation very bad solutions are used. At the end of the presentation I will show a way where even in these scenarios in embedded system we can still try to come up with good ways to generate random numbers. So as last example we have host APD which is essentially the most used access point on Linux for example it is used by Android if you set up a hotspot. And they have a very good implementation. They implement the 802.11 group key. They extended it to include entropy every time a new group key is generated. So that's very good. Even better than that they read from def random on boot and for some reason there is not enough entropy available. It will simply wait until the first client connects and then it will try to read again from def random. If there still isn't enough entropy available it will simply reject connections. So in other words if you use host APD everything should be fine. Of course if the kernel and everything works properly. So that concludes how we can generate and predict this group key. We will now explain how we can, so this is the second main part of the presentation, how we can exploit this group key to inject on decrypt traffic. So let's start with a simple case. We want to inject a unicost IP packet and we want to send it towards a client. So your initial ID maybe okay you have your IP packet right here. You simply put that into a broadcast Wi-Fi frame. So here we have the Wi-Fi header of course very simplified. Basically we have flags in the header which says that this broadcast frame is sent towards the client of our network and the receiver is the broadcast MAC address. Because the receiver is the broadcast MAC address this IP packet and everything with it is encrypted and protected using the group key. However this will not work and why is that? Well the client notices that this unicost IP packet is received on a grouped address Wi-Fi frame and this is the so called whole 196 check and basically says you should reject packets that are sent on a group addressed link layer but are sent to a unicost IP address. In other words this technique will not work. So how can we try to bypass this technique? Well the realization we have to make is that this check occurs when a link layer packet is being passed on to the network layer where we have these unicost IP addresses and an access point only works at the link layer. So if we can somehow abuse the access point then we might be able to bypass this check. So let me simply explain the technique that we're going to use. So we have our network here with the victim with the attacker which wants to send a packet to the client but what the attacker will do it will first send this IP packet towards the access point. So again we have our IP packet here. Now we add a bit more complicated Wi-Fi header which says this group frame, this broadcast frame is sent to the access point. The immediate receiver is in this case the broadcast MAC address. However the final destination of the frame is the victim. So what will happen if the access point receives this frame? Well it will notice okay the frame is indeed destined for me. I will use the group key to decrypt it because I did receive it on the broadcast MAC address. Everything is fine. And then it will notice while it's still operating at the link layer. Oh but the final destination is actually the victim. So I have to forward this packet to the victim. The access point of course has the session keys, the pairwise keys of the client. So it will simply take this IP packet. It will encrypt it using the session keys for us. And then it will simply send it to the victim for us. And now when the victim receives this packet everything seems okay. We have our unicast receiver addresses, a unicast IP address. It is properly encrypted. So everything is okay and the attack works. The second part is that we want to also decrypt packets. The idea behind this is very simple. It's also very simple to explain. We simply are poison the router on the client so that the IP address of the gateway on the IP address of the client are the broadcast MAC address. And then both the router on the client will send unicast IP traffic through a broadcast MAC address. And it will encrypt it using the group 3 group key which we have so we can decrypt this packet and then forward them to ensure that connectivity stays on that the client doesn't notice anything. So that's actually quite simple. How we can we prevent this? Well the first thing is that if the access point receives a broadcast frame but with a unicast final destination it should not forward these. On an even better counter measure is that in an infrastructure network, so not necessarily in a mesh network but in an infrastructure network where you have an access point, the access point should simply ignore frames that are received on a broadcast MAC address. And then these issues would be avoided. So I would say that Ata was the most fun part of the research. We're now going to look at a theoretical attack against the handshake that is being used where we can force usage of RCE4. So okay, let's first quickly explain how the handshake works. So we have our client here which sometimes is also called the supplicant during the handshake and we have our access point. So the beginning is very simple. Your access point is constantly transmitting beacons. Those beacons contains the features of the access point. For example whether it supports 802.11 or whether it supports AC and it also includes the supported ciphers of the network. In practice this basically means whether it supports WPA T-CIP or AES CCMP. Then the client will select either T-CIP or AES. Anna will send an association request to the network. On this packet here basically tells the network I want to join. On this is the cipher I want to use. And reply to that the access point generates random nonce. The client will also generate a random nonce. So these random nonsense are used to prevent replay attacks and they are used to assure that fresh session keys are negotiated. So here we have the access point nonce, so the A nonce and we have the supplicant nonce also the client nonce. So it's the same as the client nonce which is the S nonce. Once they both have received these S nonces they can receive they can derive the session keys. After this first stage of the handshake we are essentially going to confirm that everything was okay that there was no attacker. And the access point is going to send the group key the group temporal key in message tree of the handshake. On the message tree it also includes an authenticated cipher list of the ciphers that the access point supports. So this is to prevent downgrade attacks. Let's say that we have a man in the middle attacker which here says okay I only support the old T-CIP cipher then the client would connect using T-CIP. However at this stage the real access point which send message tree which includes the real cipher list which is authenticated using the password of the network essentially. Meaning an attacker cannot modify the packet on the client would notice after receiving message tree if there was a possible downgrade attack because this authenticated cipher list might not match the ones that was received in unprotected beacons. So the problem with this design is that the group key here is transmitted unencrypted before the client can prevent undetected downgrade attacks. So what can an attacker do here? An attacker can put up a rogue access point it can modify the beacon messages and say hey I only include I only support WPAT CIP which means that the client will connect using WPAT CIP. And in case that the session cipher is WPAT CIP then this group key here when it is transmitted to the client is encrypted unprotected using RC4. If AES would have been used then we also would use AES to protect the group key and everything would be fine. However in this case we are using RC4 if we can if you are performing this attack. And RC4 is of course quite bad. So for the crypto people around here I'm very quickly going to explain how RC4 is used. You basically have a 16 byte initialization vector which is public. You have a 16 byte secret key on the first 250 key stream bytes are dropped. This is actually a very strange construction if you're a bit used to RC4. I'm simply going to intuitively explain the problem with RC4 in this case and also the problem with RC4 in general. Here you see a graph which kind of illustrates the behavior of RC4 in this case. So normally if you would make these kinds of graphs for a secure cipher for example for AES this would be completely white. So what does this graph illustrate? Well say for example here you are at key stream position say 300. If we then go look at key stream value let's say around 90 we can see that there's a blue dot here. What does that mean? That means that the key stream byte at position 300 is slightly less likely than uniform to contain the value 90. Normally this should be uniformly random. Normally if you have a proper cipher every key stream byte should occur as often as all the others. However you can see here in the colors that these blue key stream bytes at certain values occur less often on these red ones occur more often than others. On this graph depends on the specific analyzation vector that is being used. So the only thing I would take away from this slide is that if you use RC4 some key stream values occur more often than others and we can abuse that in an attack.  The reason is because we need to collect a lot of encrypted traffic to perform our crypt analysis. In the case of Wi-Fi this is very time consuming to do. However attacks only can better. In fact a few weeks ago I found a trick to execute these handshakes more frequently meaning this time would be I think at least divided by two or three. So let's say that someone would put more time in this we could probably lower this value more and more every year. So the takeaway messages from a cryptographic standpoint RC4 is broken and you should simply not use it anymore. So the counter measure is if you have a network at home simply disable WPA2 T-CIP. So if you have a network not only should you select that it has to use WPA2 you have to explicitly configure it to only use AES. In that case you are safe against this specific attack. So finally the last part of the presentation is just a very short short suggestion on how we can improve the random number generator. We want to make sure that the improvement that we suggest even works on embedded systems where there is no kernel available and where there is very little chance of collecting randomness. Well our observation is essentially well okay we have a Wi-Fi chip on this Wi-Fi chip can monitor all the Wi-Fi signals around. So why not simply extract randomness from all the Wi-Fi frames that we receive. In other words why not collect randomness from background noise. And we actually found one device it is this one. This has a so-called spectral scan feature and this means that this chip is able to collect a lot of samples of the current Wi-Fi background noise even if there is no traffic or nothing is going on. And we can generate a very large amount of samples every second. The current downside is that this is a bit energy. This takes a lot of energy so you can't run this very long. But we did implement this idea to extract randomness from the background noise of the Wi-Fi channel and we did a few statistical tests on this and our results were promising. It shows that we can indeed extract randomness from background noise. Now this is just a proposal. Some more research here is needed but I did think that Wi-Fi vendors should provide a feature that common Wi-Fi chips exports some of this randomness which can then directly be used or it can be used by the kernel to strengthen the current pool of randomness. So that concludes my talk. There are a few important lessons to take away here. The first is if you have a random number generator always check the quality of the output and especially if you put this in the standard don't put very bad example algorithms which are really bad. If you design a specification what you put in there should be good and it should work. Otherwise just reference an external source where this is explained better. And to protect, to defend against the attack where we decrypt all traffic of a network like I mentioned the access point should ignore any frames that are received on broadcast MAC address or which should simply not forward unicast frames that are sent on a broadcast MAC address. Finally regarding the protocol that is used in the handshake you should try to avoid sending sensitive data before trying to protect downgrade attacks. So that concludes my presentations. If there are any questions feel free to ask. Thank you Mati. We have a few minutes left for questions so if you have any questions please line up next to the microphones and ask your questions make good use of our time. If we have any questions from the internet yes please. Yes two questions from the internet. The first one would you consider WPA2 with a pre-shared key still safe? If the pre-shared key is good unpredictable then these type of dictionary attacks they are no longer possible however you still have the issue of the group key and in fact this group key which is badly generated this applies to both enterprise networks on networks that use a pre-shared key. Currently I believe that the handshake that is used in Wi-Fi can be improved so if you use a pre-shared key I don't consider it as strong as an enterprise network where you have proper credentials so I would say that an enterprise network is more secure in most cases however as a general user if you have a complex pre-shared key then you're still good. Okay question from here. For the art proofing did you consider a gratuitous ARP offer on the networks? Because you already have access to the broadcast so Well I think that's what we used to poison the entries of the client so we send a broadcast ARP packet to poison the client on the router if that explains your question Yeah but you can explain all the clients in the network should you send a gratuitous ARP so you basically broadcast the ARP entry to anybody on the network just not one single client with the Unicast? Well you can send it to any client you want you can say I want to inject traffic of this client or you can maybe try to send it to all clients I haven't looked at that much in detail I just tested if you want to attack one client that works if you want to attack another client you can just do the same attack Okay thanks Yes Um have you for regarding your problem I have a very access point sends the broadcast packets further as a Unicast packet Is it demanded in the standard to do it this way or have you checked with all implementation do it this way or only some? That's a good question I don't know exactly what the standard says what I do know is that not even all implementations implement this whole 100 and 196 attack so there you can even directly send frames to the client without needing to abuse the access point so I don't think that this idea of forwarding packets is explicitly mentioned in the standard I think they just haven't thought about that but I would guess that most implementations would be vulnerable to this forwarding trick through the access point I mean I would be surprised if certain vendors thought about protecting against that it could be but I think the chance is low Okay, last talk last question sorry no no okay then I think we're done again big round of applause for a great talk to you


Stevenson gets the 32 to 7 whenever Alvernia here tonight at Mustang Stadium. Glenn Clark, Peter Green now joined here on the All Access Post Game Show by the head coach of the Mustangs, Coach Paul Cantabene. Coach, for your birthday, your team went out and got you the most goals scored in Stevenson La Crosse history. That's not a bad gift. No, they did a good job. I think, you know, for the most part, you know, we shared the ball and I got a lot of people in the game and got to see some people do some things. Some people not do some good things, but I was just good to everybody in and it's a fun time and I'm glad we're able to do that and, you know, it's good just to have a couple of these games a year, you know, after the stretch that we've gone through. So it was just good to get everybody in, get everybody a little bit playing time and it was a fun game and it was good to go. Coach, what player may be off the bench today and press you the most? I think Ben Acosta did a great job.  You know, he came back from a year ago and stomach surgery and lost 40 pounds and everything. He's did a great job. So hitting the get a little hat trick for him. I thought that was great and, you know, it was just good to see a couple guys get some goals in there and play. So, you know, I think Ben Acosta did the best.  So it's been good. Coach, obviously, when you're in a lopsided game, you're doing something well. But as we were talking about in the first half, I think what impressed both of us so much is that even for the context of a lopsided game, it seemed like everybody was remaining sharp that you didn't see a lot of lazy lacrosse when the regulars were out there. Yeah. And that's what we wanted. And that's one of the keys we really talked about is to play well early and stay sharp and not fall into a trap here and you're not playing the team that doesn't have as many people as talented. You want to make sure you keep up that level. And I think we did a really good job early doing that, scoring a lot of easy goals, moving the ball. And I was really pleased with that. And when we got the starters in there and did that, that's what you really want to see. So I was really happy about that. Coach, Albright's coming up on Saturday. What are the things that you guys been trying to work on that you still think might need some work going into Saturday? Well, I still think you got to do a better job sliding. I think you saw some of the younger guys get in there didn't slide as well. I think we got to do a good job of that. And we got to clear the ball a bit better. I think a couple times that we didn't do a great job as I would have liked with that. But I think one of the things we are doing well is shooting the ball better. I think, you know, we're shooting the ball really well now and we got to continue to do it. But those, you know, we just got to stay with it, not know who we are, not get out outside of who we are. We stay who we are. We're pretty good. We try to start doing things that we aren't. That's when you get a little bit of trouble. So I just like what we're doing now and hopefully we can keep it going. You know, we've had, you know, I think we're seven games now and we played really well and six of them. And we just got to get we just got to keep it moving forward. Alright, we'll wrap with this. Who do we need to petition to get Andrew Novak credit for the goal off the check there. I just talked to Greg Royce. I think it's his goal. You know, I think I've never heard of there's a team goal in the thing. I've never heard of a team goal in men's lacrosse. Usually as a person that's closest to the ball that goes in, he said he's going to double check the rule for me. You know, stat guys will get there. But I'm pretty sure that's the rule. But if not, I'll try to petition him to give it to Drew, because that's his first career goal. But we'll see what we can do. And it was a really cool moment. Obviously, I was like, actually, I was like, please don't go in. But but it did. That's one of those things. That's lacrosse, man. That's the way it works. Where things happen. Alright, Coach, congratulations. Good luck Saturday at all right. I appreciate it. Thanks, coach Paul can't have been again a happy birthday to him yesterday was a coach's birthday. Appreciate him coming up and chatting with us here on the all access postgame show.


Thiosemicarbazones, TSC, conjugated with tripeptids were designed and synth-sized for the purpose of tyrosinase inhibition. The results showed that TSC1 conjugates exhibit higher inhibitory effects against mushroom tyrosinase compared to COGIC acid, a widely used reference compound. Furthermore, the in-silico analysis revealed that the difference in the activity between TSC1, conjugate and COGIC acid could be attributed to the different steric hindrance caused by the presence of the tripeptid moiety. This article was authored by Patrikia Ledwin, Waldemar Goldemann, Katazina Haldes, and others.


Welcome to Amsterdam and KubeCon CloudNativeCon 2023. Join John Furrier, Savannah Peterson, Rob Streche, and UPSCOD. As the Kube covers the largest conference on Kubernetes, CloudNative, and open source technologies together with developers, engineers, and IT leaders from around the globe. Live coverage of KubeCon CloudNativeCon 2023 is made possible by the support of Red Hat, the CNCF, and its ecosystem partners. Hello and welcome back to the Kube this afternoon here in Amsterdam from KubeCon and CloudNativeCon. I want to thank you for joining us. We have an exciting 4.30 in the afternoon bringing the cupcake energy type of interview going on. I'm Rob Streche and I'm here with Joe and we have two fantastic Red Haters with us, Christian and Harriet. So nice to meet you and thank you for coming on board. Thank you, thanks. What's been the most exciting thing you guys have seen? I mean, I saw that it was packed. You were saying when we were catching up earlier that when you had the hats, the fedoras, I should say fedoras and not hats, we had one here and it magically disappeared. Somebody must have co-opted it. They didn't have to do that. Yeah, they co-opted it. You have to hold on to them when you get them. I know, I know. The valuable commodity, you said it was completely packed. What are some of the conversations that you're both having with these customers who are coming by? Yeah, everyone wants to talk about get-ups, which is really exciting. I think it's a wonderful technology and I'm so glad that so many people are interested in it. Yeah, yeah, and getting, over the years, getting people coming by the booth, the questions they're getting more and more advanced. So, you know, kind of speaks to a little bit about the evolution of the technology. So it's very, it was very great to be able to talk a little bit more advanced topics now that it's been around for a little bit. So help me out. What is, where was it and where did it go to? Because what makes it more advanced the discussions that you're having with them? Yeah, I think the adoption is growing. So before it was a buzzword, right? It was buzzwordy, right? On purpose, right? It's kind of earwormy, get-ups, like what is that? But as folks are starting to adopt it and are starting to actually putting in production, that the situations and the questions are starting to get a little bit more advanced. And so what's interesting to me is, back in the day, we used to focus on the technology aspect of this. So we would ask questions like, what is get-ups? What products do I use? How do I install them? The questions I've been seeing is, so we've got get-ups now. How do I make my company successful with it? And so instead of focusing on the technical solutions, we're looking at the organizational problems. And that makes me wonder, what are those organizational problems that we solve by using get-ups? Yeah, absolutely.  Especially now that, like Christian said, get-ups has been around for a while, it's matured enough that the larger organizations are interested and they're at the point where they feel comfortable adopting it. So they've got problems like, all right, we've got all these, we've got thousands of edge devices, how do we start deploying out to those? And we've got all of these different teams, how do we do multi-tenancy? Like, how do we make our access control work for us with get-ups? That makes a lot of sense. I think we've been hearing it as well. And I think that as Kubernetes, I mean, we're almost 10 years in now. So it's crazy. That overlap back with OpenStack, when I was doing stuff in OpenStack, is kind of a funny time, because now I'm hearing we were on with the Kuvert guys earlier, and how some of that is actually part of the stuff that I did when I was back in OpenStack. So it's fun to see how it is. What I have seen is that the energy here has just been unbelievable. And I think part of that energy has been the movement from DevOps, SRE, all different groups, all highly fragmented to your organizational. Now it's more platform engineering. Are you seeing get-ups as being kind of the foundation to platform engineering and how people are looking at that as well? Yeah, I've seen it as a cornerstone, really. Get-ups is really, I always say it's a cornerstone to a lot of different practices. And only because it's taking advantage of the technology, the cloud-native technology, right? Of Kubernetes and just in general cloud-native. And so it's really the cornerstone for things like platform engineering. It's kind of like on the tool belt of platform engineering. And also things like DevSecOps and just DevOps in general, CICD. It's just been really kind of a foundational thing now more than anything. Yeah, but at the same time, if we're talking about get-ups, I mean, the definition evolves. And that's a natural state of things. But get-ups is not a single thing. Get-ups is not one piece of technology. So help the audience kind of understand what get-ups is and by definition, what kind of technologies do we need to be successful? Yeah, so Red Hat is part of the get-ups working group in the CNCF, right? So Sandbox Project, but it's really a group of SMEs from both our Argo world and the Flux world. And also from folks like from the Spinnaker background and the Carvel people, just kind of like practitioners that are getting together and trying to define what get-ups is and kind of just like, let's bring all our best practices, all the knowledge that we've known and lessons that we learn and let's define what get-ups is. And that's kind of what one of the things that the get-ups working group, which I'm involved with, which I'm a maintainer of, is that, okay, let's define what get-ups is because we don't want to turn into something like cloud, right? Like what does cloud mean? It could mean anything, right? Nowadays, right? So I encourage everyone to go to openget-ups.dev. We have a set of four principles that kind of just a guide you to what like, okay, if I want to do get-ups, what are like kind of the things I need to, kind of the practices that I need to do in order to really take advantage of the get-ups practices. Yeah, I think exactly building off what Joe was saying is the fact that people, like the first day on the keynote, I went in there and I started looking at the readouts from this, from all of the different successes that have been built over in the different, why am I blanking on the name of the things, but different working groups that are going about it. The one thing that was, I guess you could say, very telling to me, and I know with your guys' background and how you just described get-ups and that, I think it was one of these, and this is building off of that, is that having just a one minute, hey, this is what Flux does, this is what does Argo does. I think that helps bring those new people because 58% of the people here are new to this, right? I mean, that was one of the stats that you were saying, if you have 10,000 people and 58%, it's their first coupon, it's crazy. That's wonderful. Yeah, it's fantastic, and I think that brings the new energy and helps build that. So what is Flux for those at home that don't know what Flux does? Yeah, yeah, so Flux is a get-ups controller that continuously syncs your desired state, which is get to your running state, which is in Kubernetes, right?  You have a desired state somewhere in Git, usually, and you want that matched into your running state. And so that is like really the ground, you know, like the main idea of get-ups and any tool that employs the get-ups principles. And is it looking for drift and things like that? Yeah, drift detection, drift correction, and you know, things like that. Yeah, and you get the like self-healing right out of the box. So it doesn't just have to be application deployment, which I feel like a lot of people coming to get-ups, they think it's just CD, it's just that you're deploying your applications, but it's not, it's infrastructure as well and configuration management. So you can set your desired state and then you've got your controller that's always polling and checking, like has someone gone into my cluster and made silly mistakes? And it can go and self-heal that for you. So you don't even have to think about it. After you set up your desired state in Git, it's set and forgotten, it fixes it for you. So I wonder how this works in larger organizations and maybe you can speak to that a little bit because if I'm a single developer or a small team, this is not a hard problem to solve. It becomes very, very complex once you start to scale this across the organization. So I wonder what are kind of the best practices that you need to implement as a get-ups, ready organization to be able to scale it across thousands of developers? I think my favorite topic there, it's always going to be access control. So when you're looking at, okay, so we've got all these teams, we're taking our first steps into get-ups. How do we make it go? How do we scale it up? You can't just kind of launch yourself into that. You've got to like take a look at your organization and be like, all right, what teams do I have? What are our business needs? What are our regulatory requirements? Can we just give everyone access to all this stuff? Is that all right? Do we need our teams who deal with billing to be hived off this side and no other development teams can push to those clusters, or you've got to have a really solid understanding of what your business needs and what your threat model is and what your risk tolerance is before you kind of come in and we can't say, this is how you do it because it's so based on everyone's individual organizational needs. Yeah, and you bring up a good point where your risk tolerance is, I think, a very good way of capturing it because it's not a all-or-nothing situation. It's always a gray area, especially in larger organizations. And so giving people the guardrails of, this is where we start. It's guard of the heavily, it's a small team. The freedom is fairly small, but then as you grow, as you adopt, the guardrails come out, basically. Yeah, and I always say to what Harriet, to build off what she was saying, I always say that get-ups almost reveals some of the gaps you have in your organization because you are, when I talk to customers, when I talk to people about get-ups, they're like, well, what do you mean it's automatically synced? And then my first question is like, why does that make you nervous? Because if you have good practices in place, to Harriet's point, those aren't as scary, right? If it's scary to you, then it's more of an organizational people problem, as I like to say. It's like, okay, what's wrong with our structure and how can we best change in order to implement some of these things? Which almost, I don't want to over exaggerate, but it almost goes back to lean practices. Yes. But applied in a very technical sense, down to earth, in a way that actually makes sense to technologists in that space, in the operational space. And again, I think that makes sense because get-ups is not one technology, it is a way to solve your organizational issues. And I think that you're right on the money there. That being said, I think there's a bright future ahead of us with get-ups because I think it makes a ton of sense. It solves a lot of operational problems, but we have this AI thing looming over us. Because we're basically talking about, policy is code, compliance is code. We're talking about drift detection and remediation. That is something we have to do fairly manually right now, defining those policies. What's your take on AI and kind of taking over that manual work? Yeah, I think, well, for me, I think it's a very important step, especially in the sustainability aspect of it. I think AI is going to play a big part in the sustainability with respect to get-ups. Because as I was saying, it's like the cornerstone to a lot of these things. And being able to automatically shift workloads, get-ups is going to play a big part there. Just by, but when you say sustainability, your meaning, sustainability of the infrastructure? Well, I mean, environmental sustainability is what I meant. Yeah, thank you, yeah. Clarify a little bit is, yeah, environmental sustainability. AI being able to say, oh, it's better to run this workload over here because it's better environmentally than over here, right? It's going to be less, cost is always going to be an aspect of it. It's going to be less about cost and more about environmental sustainability. And get-ups is going to be a cornerstone of that because it's going to need to automatically shift those workloads. And as you were saying, a lot of that stuff is manual now and it's AI becoming more and more advanced. We'll be able to do more of these things. And I see it at least from the environmental sustainability. AI and get-ups is going to play a big role there. And so this, you know, this all solves a lot of operational toil. It removes a lot of these manual work. I think that's great. But then we have this, you know, this pool of talented people that have automated away a big part of their job, which kudos, that's the goal of your job. But what's kind of next for this group? And by extension, what's next for get-ups? What's next for Argo specifically? That's an exciting question. Well, like I don't think AI is going to take away, like it's never going to take away everything. There is always stuff that needs human oversight and human inputs. Like who is going to have that business knowledge if not the people who are working there? The AI can't understand that itself. So I think the folks who have automated away a bunch of their jobs, they now have the time to explore more into like, okay, so we've got these business needs, how can we meet them more efficiently and how can we meet them better? Yeah, I think it's interesting that you brought up access control earlier because I think that's one place where actually you need more people involved because of AI and what AI could do and potential leaks or confidentiality or what have you changing that types of stuff. What else do you see on the horizon for this? Is there other stuff that you're looking at and going, hey, these are what I want to, we're here next year and sitting here and you hope that, hey, we've gotten through acts to get there. So for me, at least from the get-off space, I've been working a lot with me specifically with our Ansible team at Red Hat because get-offs was born and grown in the cloud native space. You need almost Kubernetes, it's almost like the default, you have to use it, but a lot of these practices extend beyond just like Kubernetes, right? There's always going to be a need for controlling infrastructure outside of Kubernetes, not just like bare metal deployments but also things like switches and things like firewalls, those kinds of things and Ansible is, at least for Red Hat, it's going to play a big role there and I've been working with our Ansible team too, it was okay, how do we define get-offs in a non-cloud native way, right? How does that look like? And because there's going to be a lot of gaps, there's the immutability aspect of Kubernetes that doesn't exist on bare metal or on a switch or a network equipment or something like that. I think evolving get-offs past cloud native where it's all encompassing, I think for me, that's hopefully next year, you sit me down here, I'll be talking about that because that's something that, I think, get-offs needs to extend just beyond cloud native. That's awesome, I think that's really what I think the people at home are going to hope and they're going to hold you to it, so. Yes, yes, yes, exactly, yes. Let's get there. And a long camera's saying it, so yeah. Exactly, it's on the internet, so it's forever now, immutable. So I want to thank you both for coming here, I want to thank Joe, I want to thank you for co-hosting, this has been fun, it's our first time together. Absolutely. Yeah, so it was a good time, really appreciate it, and I want to thank you all for watching us again on 420 from Amsterdam, really love it, and I want you to have a great rest of your day wherever you are in the world, and thank you for watching V-Cube where, oh, why did I screw that up already? But the leader in high tech coverage, thank you for coming and we'll see you again.


All right Todd's got a quickie for us. All right Todd says I just learned from my older son that an iOS 15 in the control center Which you reach by swiping down from the upper right hand corner You can click on the moon icon in the focus button To do what? It toggles do not disturb on and off. Oh So this is like the quick tip we shared last week about doing the same thing in Mac OS control center That's inch Yeah, so I'm not just tapping the focus just tap it it'll disable But I believe if you hold it then it'll go into like the enhanced Focus menu with more options than just disable or enable right stir right So I like it. That's probably something that was found totally by accident. Yeah, it sounds like it Yeah, well and when we talked about it about Matt in Mac OS. It's the same thing. It's like oh, I mean it you know These quick tips are things that are super obvious as soon as you know them and not at all obvious right up until that point At least the ones we've been talking about so far today Cool What's next? right Speaking of do not disturb Scott has one for us So during episode 907 you discussed turning on a max do not disturb setting using a variety of Keyboard combinations in my opinion you missed an obvious solution My new a max wireless Apple wireless keyboard has the do not disturb icon Crescent moon shape Imprinted on the f6 key. It wasn't programmed to turn do not disturb on off automatically out of the box But it was a 30 second fix to get it to work as intended Just go to and we've been here before System preferences keyboard shortcuts and select mission control then check the box next to turn Do not disturb on off so that it's enabled And then assign a modifier key to f6 He used Option f6 so that you can easily remember it by the icon on the key. I attached the screenshot I'm a keyboard shortcut fanatic and use this shortcut pref paying extensively to modify keystrokes to control every app For example, I've used this instead of add-ons for mail to switch mailboxes and to move messages to mailboxes Being able to easily reprogram keys and have them show up in the menu with the correct new keystroke Is one of the things for me that makes them act the best choice for people who just want to get stuff done Yeah Wow, that's really smart. I never I love this idea


Former Beaver offensive lineman Jake Krause has signed a contract with the Alliance Phoenix of the newly formed Alliance of American Football League. Now that league they'll start right after next year's Super Bowl and has a 12-game schedule during the spring. The league offers three-year non-guaranteed contracts for a total of $250,000 and it contains an opt-out if a player has an NFL team come knocking on its door. If you enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland PBS.


The Nigerian Navy has arrested 15 suspected crude oil thieves in Bayelsa state. They were arrested along the Akasa River in Brass' local government area of the state. Investigation by the Navy also led to the arrest of seven other accomplices. Our correspondent, Jesse Essay, completes this report. The suspects were arrested on December 6, 2021 by operatives of the Nigerian Navy ship NNS on board this vessel, MTT-4. The vessel was found to be transporting about 700,000 liters of illegally sourced crude oil which is worth 148 million Naira. The suspects are Nigerians and upon interrogation, they led the operatives to the source of the stolen crude where an unspecified amount of black gold was also discovered. The Navy went further to identify the source of the stolen crude and was led to the spot where about four dugout pits containing unspecified quantity of crude oil were discovered which is more than what was found on the vessel. The discovered storage pit has been reported to relevant oil and gas companies for evacuation. The arrest is one of the numerous successes recorded by the Nigerian Navy in its ongoing operation still operation Quiet Waters aimed at dominating the Nigerian maritime environment towards creating deterrence in order to create a secure maritime environment for economic activities to strive. Commodore Patrick Effer comments the federal government for the support of the Navy and wants maritime offenders to desist. It is noteworthy that the Nigerian Navy remains unwavering in its drive to read Nigeria's maritime environment from all forms of criminalities. This drive can be justified by the recently commissioned vessel by the president and commander in chief of the armed forces of Nigeria president Muamadu Bware and as I speak some of the newly commissioned vessels and other vessels at sea patrolling the nation's exclusive economic zone. It might interest you to know that the chief of the naval staff is currently at sea for exercise Quiet Waters. I must add that the arrest of MT-4 is one of the theories of arrest recently made by the Nigerian Navy. The suspects will be handed to the appropriate prosecuting agencies for trial. Just see a see plus TV news brass.


So, believe it or not, many people watching this How Divers 2 video won't be aware the reason we ain't really progressing the latest major order is because many players are actually doing it wrong. Today, I will explain everything you need to know about this new major order with a few great tips on the best way of us getting this done. The winner of yesterday's 2100 super credit giveaway is Keeper of Rocks 4618, hit me up on my discord link down below to claim your super credits. Now guys, do you want to win 2100 super credits? If you do, it's simple, liberate this video with a massive thumbs up, make sure you are subbed with those post notifications turned on and leave me a comment down below. Give me your best advice for a new or solo player. You will be picked and announced on tomorrow's How Divers 2 video. Also guys, I'm trying to build my own How Divers 2 community where we can talk about the game, play it together, this, that and all that good shiz. Join my discord link down below and say hi to everybody. Let's go. Now, I'm well aware of the videos out there stating this new major order is a trap and they link that with the audio files but hey, that's a driven narrative for this game to progress as a whole. It's meant to be and we are meant to complete this major order. I think even if it fails guys, another similar major order will follow until we get it done so we can progress the way this game is meant to be progressed. So although we love a good league, we are all interested to see what happens if this major order is failed. We need to get this done guys. Now although I don't think people are intentionally trying to fail this, I mean that would be kind of stupid if you ask me, I think we ain't progressing this as quick as we should be because many players are kinda doing it wrong, either finding it too difficult or simply doing the wrong missions to progress these four planets while three now because one has been liberated people. Now before I do go any further, I don't plan for this video to come across condescending. I really just want to help out players who may not know exactly what to do and also give them tips if they're struggling, even solo players like myself, trust me guys, I know the headache it can be, I can't tell you how many times I've been killed by my own team calling their airstrike over that solo, it's so crazy it's unreal. It's actually a major factor while making this video. Now I'm guessing many people that will watch this video will know exactly what they're doing so do leave advice for other players down below. So we need to liberate for, well three planets now, one has already been liberated to complete this major order. The ones that are left to liberate are, as I make this video, are at a prime, meridia and truing, we need to get these done. So the description reads of this actual major order, termicide dispensers and towers have been built all over every barrier planet, they need only to be activated to quarantine the bugs for good. So first things first people, to progress this major order to begin with, you need to be doing the right missions, so for starters, you need to be doing and completing the activate the terminated control system missions on these while thru remaining planets, nothing else here upon completion will count towards progress for these planets to be liberated for this major order, so if you're in a team or playing solo, this is the mission you want to be starting or joining.   So if you are not aware, the mission is quite simple and this is how it's done and how it takes place. So within these missions guys, in a quick rundown of how these are completed, as soon as you join, in your notice that notification on screen, activate terminal at the base of the central tower, pick up your map guys, you'll see a glowing red symbol, head there, press that button and then the process starts.  Now in my opinion, it's best to do these one at a time, so if you're playing with randoms or as a solo player, listen out for pings or ping yourself, so everyone has a clear direction on which one you can go to first, it doesn't matter what order you do these in, they can go to anyone you want to. So once a silo has been selected, then head over. Now to start these guys, simply press that button, like that control panel and from here, you'll notice on the screen, you'll have a silo status which is the actual silo's health, and you'll then have a progression bar. Now the progression bar slowly goes up, but you'll also notice that silo also has a health bar. So once you've started this process, you'll notice guys, and you'll hear a notification of bug breaches, it's your job here to defend. Defending is key. These bugs will attack said silo and drain that health bar. If the health bar gets down to zero, you'll see on the screen about the silo status being critical. If it gets back down to zero, you have to repress that button and do the whole process of defending this again. Now also, and it's very important to know and keep in mind, you can also damage the silo. So airstrikes in and around these silos, if they hit it, they can drain all of its health, meaning you have to start this process again. So keep that in mind. Now you have to defend these silos for a good few minutes and it isn't easy and there are hordes of these bugs. I think there's like four bug breaches in and around the map and they all head to that said silo. Now a few tips on this in a quick second. Once you do activate each silo, defend it, you move on to the other, when all three are done, you now head to that extraction point. Here you will see another yellow terminal. Here you initiate that process of initiating the termicide dispersal and here you complete the mission. And from this point, you defend and extract as normal. Bugs are spawning, take them out, do your thing and get out of there. You've now added and helped towards this major order, its progression. So a few tips and tricks you can use here with these silos. So what I've noticed is at these silo spots, when defending, there are very clear spawn points around each one. Now you can hold down if you are efficient enough with your arsenal. In a team of four, this shouldn't be a problem with you. If you are playing solo, try to see where your squad is in regards to what area near said silos they are trying to hold down. You then rotate the silo to check other spawn points and get another angle on said spawn point to help hold it down. Remember airstrikes and things like this will damage that silo holding progress and even damage it to a point where you reset and have to start a game. In my opinion, the best strategy I'm going to use here are probably the mines as well as the Tesla towers. I ain't high enough level now to get the Tesla towers but my friend was using one earlier and they're absolutely incorrect. These are by far the best in my opinion. But I have noticed and this only happens once the progress has started. A lot of the bugs will completely ignore that Tesla tower. In fact, I think all besides the chargers will ignore the Tesla towers but do quote me if I'm wrong there guys. Just make sure said progress and said silo you're defending has already started before you throw that Tesla tower down. Also if you're planning on using these specific in where you put them both for the mines as well as the Tesla tower. The mines you don't want to put by the silo just make sure you put them away from the silo. The Tesla tower though it doesn't actually affect the silo. I don't know why this happens but it doesn't damage the silo which is pretty cool. Just make sure you place them in the right spots where they can do optimal damage without taking unnecessary damage from critters which may target them. Also it's not really smart to place said Tesla towers or even mines near any path you may take or mainly to pass. That's kind of obvious as these things will absolutely destroy you. Other strategy you can use here are basically most defensive ones. These will work great for you. The EMS mortar is badass too. Even the XOR suits if you can unlock them. Use them, these are good to use at the same time. Anything which helps hold targets off will be great here, totes included. Now another strategy you could try instead of doing one at a time is to actually separate in a team because I believe what's actually happening here once those bridges are open and those bogs start pouring out they will disperse to the active silo or active silo so if more than one is indeed active what this means is they will separate or even head to a single silo meaning less of a problem to deal with on another silo. I mean I can see this being a good thing to try if you are being overrun and you're struggling but I do feel doing one at a time if you're in a good team and I know what they're doing is probably the better option as you can hold down all positions much, much easier. But yeah guys, you've already deliberated one planet with everyone knowing what they're doing and using those stratagems, they lost, not properly. This should be absolutely no problem whatsoever and I expect over the next couple of days this will become polluted and we'll be able to progress the planned progression they have in store for us. So yes guys, like I said if you have any tips and tricks or any new players in the game or people are struggling with this major order do let us know down below in that comment section. Remember guys, if you wanna join my HowlDivers2 community do join my Discord linked down below. Guys, thanks as always for stopping by. I hope you enjoyed the video and hopefully I will see you on that next. One.