Cybersecurity for coders: insights from a Microsoft Team Leader at NATO Locked Shields | Grzegorz Tworek

In today’s episode

• The enduring relevance of assembly, C++, and other low-level languages amidst modern programming trends.
• Why these languages are becoming less popular and what this means for future development.
• Essential security considerations for both coders and companies to stay protected.
• Exploring zero-day vulnerabilities: What they are, how to find them, and why they matter.
• The dynamic race between good guys and bad guys in the cybersecurity landscape.
• Building and leveraging a community of security experts for better defense strategies.
• The role of AI in writing code and the implications for the future of cybersecurity.
• A deep dive into NATO's Locked Shields exercise: Which country leads the pack in cyber defense?

Transcription

Grzegorz: I believe there will be always a need for assembly programmers. At the same time, there are people developing malware, developing exploits and also believing it brings some value to the industry. There is no clear proof when it comes to statistics or anything you can measure. Actually, the open source is safer. I'm fascinated by all those GPTs etc. Things, but at the same time, I do not trust them fully when it comes to writing a code, and I saw…

Łukasz: Welcome to the Dev is in the Details. Today we're thrilled to have a cybersecurity expert who has been a leading voice in the field since the 90s. As a second-generation IT professional he has written, blogged and spoken extensively about security, especially within Microsoft ecosystem. He has built and led security teams, developed numerous tools and played roles in catching and advocating for hackers. With over 15 Microsoft MVP awards, his expertise in low-level programming and security is unmatched. Join us as we dive into his journey and insights on the evolving world of cybersecurity. Please welcome Grzegorz Tworek to the show. Grzegorz, welcome.

G: Hello, good morning everyone.

Ł: Our today's topic about critical concerns about security in software development - very, very exciting topic, also very up to date these days with everything that is going on in the world right now. So I'm curious, especially when we deal with low-level languages like C or C++ what are the security concerns and considerations that one as a coder or as an organization that builds software has to take into account?

G: It's quite an interesting topic because I would say those languages, like low-level languages like undefined, C++, are going out of fashion. They are not that fancy. If someone wants to be a developer nowadays, if he wants to learn something new, it's quite rarely targeting C, for example, with some exceptions for very specific platforms like PLC and some other stuff. Well, who wants to be a C developer nowadays, starting his career? So one of the concerns we have is that languages are not that popular, which makes those communities less popular as well, and the community experience is not driving developers into modern way of thinking about development. At the same time, those languages, especially C and C++ they have some specific fame for a reason are relatively easy for non-experienced developer to make a, leading you to some very unsafe scenarios, and that's the scenario I will say.

Ł: Okay, but do you predict that they will actually disappear in the near future, or is it more like a case that it's going to become a certain niche where people will be superbly paid for Because there's so many systems that will still have to be maintained and developed further right in these languages?

G: Well, I'm trying to look at Cobol at this point.

It is not a low-level language, for sure, but when you take a look at Cobol, it was invented in late 50s, 70 something ago, and I heard it will disappear right now. For the last 30 years Cobol is no longer used and it's still used. So I believe it is not that easy to predict something will disappear in IT world. But when it comes to C or C++, there's one thing I see, because I believe there will be always a need for assembly programmers, for programming the machine code on the deepest level, because it has to be programmed and someone has to do it. And C, c plus, plus are literally the next level over the assembly. So if you want to program to create a bios, to create a firmware, to create like embedded software most likely those languages would be used theoretically you can use assembly, but it's a bit too unfriendly to really create an entire software. So it will not disappear, I believe. However, it may be an interesting scenario to predict which part of the C, C++ development will be taken over the AI.

Ł: Fantastic. Okay, and what is the modern trend like if you say they are less and less popular? What is gaining when they're losing traction?

G: My perspective is focused mostly on deep operating system programming and using API, maybe not Kernel development itself, because it's not that popular, not that easy, and I'm not doing this at the same time. I'm trying to analyze the software, but not writing it actively. But the next layer, the layer next to the Kernel in the user mode, is something I focus on and I clearly see Rust is going to take its place. Nowadays it is happening right now. I see it is more and more popular. The community is growing and most likely Rust will be the next language to be used commonly.

Ł: And you can use Rust to write driver's code as well, or you know what, the usual things that C++ used to be used or is still used for.

G: This is the goal. So, for example, in Windows Kernel we have API libraries to communicate with the Kernel, with the Windows Kernel, and now those libraries are published and interfaces are published and are prepared for being used from Rust as well. So, for example, Microsoft is trying to push developers towards Rust at the same time. Well, the new hardware I mean totally new, something that did not exist before and which requires a Kernel driver is not that common. Such devices I mean devices are appearing relatively rarely, which means if there is a new model of the graphic card, new network interface, new, something that requires a Kernel driver, in most cases a company developing it has some code base already prepared, so it's more like evolution. Developing it has some code base already prepared, so it's more like evolution, so the code will move the same way as well, in my opinion. So the existing C C++ code will be fixed, will be improved, will be new features, will be built around the existing code instead of let's write everything in Rust from scratch.

This is not the scenario I would imagine. On the other hand, some devices that are appearing out of nothing quite often do not require a Kernel driver, for example I'm referring to Windows, because this is the world I'm living in. But we have two driver frameworks in Windows, starting from Kernel version 6. It is user mode driver framework and the Kernel mode driver framework, and Microsoft is actively pushing developers out of Kernel. So it is way easier to develop a driver not staying within a Kernel and having a full functionality. The rule of thumb is if you put the device into the computer enclosure it will require Kernel driver. If you connect it by cable, probably user mode driver will be enough. So developing real Kernel drivers is not that common and it has a lot of requirements from Microsoft for allowing you as a developer to run your code within the Kernel. Because within the Kernel you have no security boundaries and if you have a Kernel code running well you own the system. So Microsoft is not willing to let you in there.

Ł: Okay. Resonates with me very strongly, as it's in Unix world. You also have a Kernel layer and then user space layers. I presume it's similar, right? Do you predict that because of this there's going to be a significant improvement in security of applications and what kind of bugs or flaws are discovered, that they can be exploited to various degrees in those applications because of the RAS taking over C++, c++ is on its own as a programming language, is a reason for a specific type of error.

G: It is mainly about memory corruption. So we have four typical scenarios it is corruption of the return address on the stack. It is corruption of the return address on the stack. It is corruption of the function pointers in the heap, another way of allocating memory. It may be about executing the code via corrupt pointers and it may be to corrupt some values impacting behavior of the application. So those scenarios are actually exploited and it is a direct result of how C C++ is managing its memory, the application memory.

It has a lot of history. It is rooted in the hardware design as well, for example on the Intel platform that we are commonly, there is no way, or it was no way when it was designed, to distinguish if it's a code memory or if it's a data memory. So it's totally uniform and it lets multiple bugs related to putting something in the data memory and then using it as a code. Very common way of messing with data and in C it is relatively easy to do it intentionally because, well, pointing to the memory, which is not the execution memory, or using your code as a data to be used in other scenarios. Something that is absolutely easy in C++ is just, I would say even natural in C. Sometimes it is used for good purposes. Sometimes it's just a mess related to different scenarios. But if you are not experienced and if you do not have your development and your code perfectly well maintained, it is really easy to mess with data and code and read the memory and then use it or jump to data location or override, for example, using the simplest thing as a buffer overrun to override your stack space with the data you are willing to put into your data space, etc. So C, C++ is, I would say, allowing it by default.

This is the way how those languages are working and how the hardware platform, especially Intel-based or Intel architecture, is working from a couple of years. We are trying to fix it using multiple ways. For example, we have a no-execute bit for memory areas, so we can mark an area of the memory. Please do not execute this part of the memory because it is not intended for the execution, but you have to know it and you have to follow this rule if you try to apply such protection.

Later you may figure out that something stopped working because it was designed in a way, I would say misusing it or intentionally using it in a non-very typical way, to say it politely, or because there was just a mistake. But something relies on it. It has no visible side effects and we are using it and we block it. The side effect is not exposing itself, so everything stops. So Microsoft introduced in the Windows kernel the NX bit, if I'm right, in Windows XP, and even for Microsoft application it was not always allowed to enable it because it could stop execution of Microsoft applications. They had to fix it later. For the languages like Rust or other languages which are memory safe the naming is for a reason. Those are memory safe. Usage of the memory is guarded in a slightly different way. So it is impossible to misuse data types. In C we can cast literally everything over everything. We can take an integer and cast it over pointer or vice versa, etc. So it's up to you.

Ł: Absolutely, Grzegorz just so I understand when you talk about the memory abuser, those mistakes you mean within a single program, right? Because I'm trying to understand. If I have a memory management, there is also an aspect where operating system, I would imagine, disallows certain things. So, for instance, if I have program A and program B, I would imagine that they cannot cross-reference each other as memory, or am I mistaken, they can?

G: You are right, it is about process boundaries because the memory addressing within process is virtual. Memory addressing is like you live in the city. So if you say this is the main street, number five, you are by default referring to the same city. You could spell an address referring to the same city. Theoretically you could spell an address referring to another city, but it is always relative and virtual when it comes to memory addressing. So those types of attacks are targeted to one process. It may be more interesting when it comes to some privilege operations, because some code may be executed this way, but in cases it is about staying within the same process, which means in most cases within the same identity. But it still can lead to some behaviors we do not want to observe in our machines.

Ł: Got it and as a part of the job that you do is to basically probe and investigate if programs have this kind of mistake or bug, or how do you? I can, if you could talk a little bit more into how the reverse engineering process of finding this kind of issues looks like, to whatever degree you can, of course, but that is something which I cannot comprehend completely.

G: So one of the typical techniques which is funny, but if something is stupid but it works, it inn't stupid is the technique called fuzzing. So we are trying to put some random data random I mean some patterned data, the pattern we are aware of into random places, trying to put too much data and then scan the memory content, observing if our pattern appears out of sudden in some strange places. Yes, then we have a place to dig in.

It is one of the techniques. It can be relatively easily automated. This is the big benefit and it does not require reversing everything. But if we know where to dig in, then the reversing happens. But obviously seeing the code, seeing the mistakes in the code, is the best way, and I can observe some trends in securing the way how we code. We have AI. Maybe it is not that common yet when it comes to the evaluation of the code itself, but a couple of years ago, if you remember basics of C, it was kind of the rule they tried to teach us If you do an if comparison, put your constant first, then equals your variable next, because if you mistakenly use one equal sign instead of two equal signs, you will not make an assignment nowadays, if you put single equal sign in the if condition, your development environment will alert you.

You are doing something that is theoretically legal, but probably you made a mistake here.

Ł: Not my intention.

G: Development environment is trying to guard you. In multiple places you have warnings about suspicious pointer usage, about types mismatch, something that is legal, but probably you do not want to do it this way. So this is one of those things. Another one we can observe I'm not sure if it's introduced by Microsoft, but Microsoft is using its C implementation and in Visual Studio. Microsoft C standard is about SAL security annotation language.

Every single parameter for the function can be annotated about what we passed with this variable. Do we expect to put some data into the function as a parameter or obtain the result from the function in or out? If we have some very typical thing for calling functions in C we specify multiple parameters for example size of the data and the next the pointer to the data as two parameters for the C function. So we can annotate those parameters in the function definition telling. The first parameter is a size and the second is the pointer, and we expect that it's pointing to a memory of this size that the first parameter is telling us about. So we annotate the function definition using this way and then compiler checks it if it matches somehow, if we allocate the memory in somehow reasonable amount and it's compared to the code which is written determining parameters to this function. So we are trying, we as an industry are trying to be more and more smarter in automated analysis of the code. But you can still do everything.

Ł: It's kind of like meta-information, right? About your intentions of what you described, and I'll ask you later for the link to it so we can also put it to footnotes for our audience, because it's fascinating. We'd like for other people to maybe read about this more, but it reminds me about what we do in Elixir in Erlang, basically as well, that you can semi-auto test the code, because if you show what kind of input intentions you have and what kind of output intentions you have, then afterwards you can see whether the testing that happens behind the scenes or automatically for you is verifying that intentions meet the criteria of the code that it performed on.

G: I don't expect AI here to jump in seriously.

Ł: Yeah absolutely

G: Because we no longer write functions Right now. I'm fascinated by all those chat, gpt, etc. Things, but at the same time, I do not trust them fully when it comes to writing a code, and I saw too many jokes about how inaccurate it can be. So well, I believe it applies to the code as well. But if it happens, even the copilot relying on the code base which is well known in open source projects on GitHub for example, and trying to predict what you would like to have in a function, judging by its name and parameters and the way how it is called, etc. Probably it will make the code safer, assuming the code safer, assuming the code base, being a source of the data, is safe. But in most cases it is.

Ł: Yeah, I mean, it opens up so many discussions separately on the also model poisoning and whatnot. Right, with regard of where the source for Copilot will come from. Yeah, that's interesting on its own, but let's maybe hold on to one thought that I had when you were telling me about code reading and understanding and so on. So this just assumes you have access to the source of the application, the source code. But do you tend to do we still do decompiles and things like that? I remember years ago I was learning how to decompile Java programs and in fact we could actually get them one-to-one like 100% code back from the binary, or actually the bytecode, the machine code that Java outputs. How is it with C and C++ codes or even with Rust itself right? I imagine it's going to be similar constraint, I'm not sure how it looks for Rust.

G: I never tried it. When it comes to the C C++, we have some ideas how it works. We can distinguish different functions being called, we can analyze those calls and I would say C C++ is quite close to the assembly. So, judging by the assembly which is actually decompiled, we can try to figure out which C code was behind this. At the same time, one of the first thing you do with the code after decompiling it is identifying things you know. If there is a data structure and it seems familiar, you start to rename it and rename it Because the compilation has no knowledge about your function naming, about parameters naming, and maybe for the machine it is enough if your function number 500 uses variable number 501 and 502.

But if you go through the listing, a couple of screens of the listing referring to places in the code, a couple of thousands of lines, before making this consistent in your mind is next to impossible, at least for me. And so you are starting to rename things you know to easily tell you what it's all about narrowing down the number of those which remain unknown. And if the code is totally unknown and you have no idea what it does actually, maybe decompilingiling relatively small application or part of the application is reasonable, but when it comes to something bigger it will be very hard, especially for object C++ code, because, well, objects are quite special here as well.

Ł: Got it? Yeah, it's fascinating. So, in other words, you're doing your best to find common patterns and things you recognize and, based on this, you just know what that intention was, even if you don't know where it came from or what the actual code is.

G: Right, that's how I understood it this is how it works and, like similar scenarios, the more you do it, the better you can recognize them later, and I can observe my colleagues, for example, doing some reversing challenges in CTFs, for example in capture-by-fact contents. I know how much I have to learn still. I'm able to recognize basic things. Learn still, I'm able to recognize basic things. Maybe I'm slightly better because I work close to the operating system API, so I better know what runtime or API function does. What we can expect from this. This is relatively easy when it comes to the compilation, because it can be matched with Microsoft public symbols. The code itself is a bit more cryptic, but then my colleague jumps in and it matches together and it works together. But yes, by observing how your code looks after being compiled, you slowly gain a knowledge allowing you to do the same in the opposite direction.

Ł: Fantastic idea actually. So you build your own app, you compile it and you see how it behaves and acts in the assembly level, or you basically let's call it the compilation behavior, because you are are just curious would require a lot of time and some determination, because if it works, who cares about the assembly anymore? Yeah, true, true.

G: If you are debugging, for example, you will dig into it because you have to, and then you can do this just as a side effect of your work. But I would definitely recommend to observe the code being a result of your, the machine code being a result of your high level code, even if it's a level quotation mark, like C and, for example, with Visual Studio. It's very easy. You can just switch the view to assembly and do step-by-step debugging, going step-by-step, and for every sequence of machine code statements you have on top of it a line saying in your C code it is the line E equals E equals one, and then you see a bunch of assembly code lines. So it is relatively easy to match those and after observing it for hundreds of times you will start identifying it even without the same code Repetition.

Ł: Just out of curiosity. This was not on my list of questions, but how do you start such a thing? Do you read a bunch of books first, or there is a course that you take, or you just start playing and breaking programs. What's the? You know, if one would start, would be liking to start a career in that direction. What would be the first steps?

G: it depends on the area. So well, um my, my very beginning was a basic programming I mean programming language, which is not nowadays considered as the best language to start with. But on the other hand, when I started with BASIC, I could start programming literally 10 minutes after unboxing my first computer. It was perfectly normal back then, so the learning curve was a bit flatter, I would say so it was important. And nowadays, literally yesterday, I had a session online about how to start developing your code in Visual Studio and there's so much harder. You have to install it. You have to know what to install, not to mention installs for like 15 minutes, the installation part only like watching the progress bar because it's so complex. But after being a fan of BASIC, I started to do the IT which they tried to teach me Pascal and C. This is also saying something about the era when it happened, and for a long time I was a huge fan of Pascal.

Pascal is quite a great language. One of the most surprising things that I have realized at some point is C is younger than Pascal, so theoretically C could use lessons we had the chance to learn with Pascal, but they did not. The notable example in the pure C is how it manipulates with strings. I understand the beauty of string manipulation in the pure C. I understand the beauty of string manipulation in the pure C, but Pascal does it so much more convenient. It's hard to compare. So I work mostly in Pascal. However, the original Nicholas Virch Pascal is useless because it is so undefined when it comes to practicalities, to calling typical libraries, to working on particular operating systems etc. So we have different flavors. Borland in the past did the perfect job here. C was, I would say, from scratch, from its very beginning, ready to be actually used, not only for theoretical school usage but for writing a real code. So it was just more useful.

I switched more towards C after I started to dig deeper in the Windows API, because Windows API is mostly C. When it comes into source code of Windows it is a mix of C and C++ and the API of Windows is mostly C, with some C++ cases as well. There are C++ APIs which are looking weird for me, especially if those are kind of an exception, because, for example, you have to instantiate class and then invoke methods of your class made out of API class. So it is kind of weird. Api VSS volume shadow copy is using such API, for example, plus entire com set of interfaces, maybe not native to the API but still present in Windows. So I started to dig. My first specialization is digging deeply into Windows operating system security and touching it to API is the native way. So it is how it all merged together at some point.

Ł: Okay, fascinating. I I started my journey with logo.

G: You know the little turtle, turtle drawing thing um a lot of charm and when it comes to teaching children programming, it makes a lot of sense. Um right, I'm a huge fan of all those tiny devices based on ESP32 and similar CPUs, so it's like 4x4 centimeters with own touchscreen, own battery, and you program it with Python. But you can do Scratch as well and it can do some interesting things. You can program your own watch and wear it as a watch and it will display whatever you want to display and react to the touch, the way you can even cheat on your exams using something which we wouldn't recommend.

Absolutely Programming those devices can be interesting as well, but I remember Logo and it is also good for learning geometry.

Ł: Exactly the angle is sometimes challenging.

G: It's not like going back and forth or drawing a rectangle.

Ł: To be honest with you, this is how I went through late primary school, early high school with my geometry classes. Because I had fun. That stuff is animated in Logo Program. I had no fun playing with all the measurements and everything on a piece of paper. So that's how I actually got through with it. But never I had met like maybe, networking class in college.

I had some discussions about security, but is it safe to assume that there isn't a college or a, a place you go to? It's all on your own, um, like going back to materials and and directions, or do you have to join certain community? Like I know, in in the old days when there were still mailing lists and whatnot, right, the, the kernel community, I remember openbsd community. They were um. They were having a lot of people around them who were like really fantastic, smart people who who were even inventing problems before they happened and they were able to predict this because of their experience. You know that system. I would imagine it's similar for Windows space.

But how did they get there? You know, like you see the result. You see the person on the other end who is already having certain knowledge, and they know even what kind of questions to ask right to start pursuing it knowledge, and they know even what kind of questions to ask right To start pursuing it. So, even like you mentioned before, that you're looking at the capture, the flag and some of these guys are better and you know that you have still a lot to learn, but that means you have some sort of scale in your head and you can measure yourself Right, but you don't even but but but.

But that means you understand the scale and where you can go from where you are now. Well, if you're starting from zero, you have none of these tools and not even an option to ask the questions, right? So, going back to this for a minute, if you could just elaborate you know, if I'm, you know, hypothetically dropping everything now and sitting down, would you just say install Visual Studio Code, write a couple of programs and read through assembly. You know, just watch it 400 times and then things will start building in my head and the neurons will connect. Or is it more like hey, there is you know this list or that list or a book or I don't know a course online, or how does that look like?

G: I would definitely try to jump into the community because if you, you're, if you are beginning and you, if you are starting and you have some questions, most likely someone has been there already. So inventing everything from scratch on your own it will be a waste of time, and you can see it from this perspective. At the same time, it may be kind of intimidating if you jump into a highly advanced community and start asking very basic questions. So you have to pick that one and it's a matter of luck. At the same time, highly skilled experts are perfectly well aware that no one is born with all this knowledge. We all had to start at some point, so even the most advanced expert been there. So in the worst case, no one will answer or someone will guide you into some other community. For example, we have a lot of communities. Picking the wrong one is not a hard thing to do. It may happen and it happens all the time.

If you look through different lists and forums and so on, you will observe questions which clearly do not match the main reason why this community exists. If you follow those suggestions where to go first, you can also ask a community. I would like to do what you are doing right now. Please tell me when to start, for example, when it comes to Windows internals. This is a question I'm hearing quite often where to start, what book I should start with, for example and there's one book I always recommend. It's called Windows Internals. It's a huge book, but I know who has written it, what is inside and how it makes you more skilled in this area. So if you want to start reading something on your own, please start with this book, and if someone gets such advice and uses it, probably it will be beneficial for such person willing to go up in the career, in the experience, etc.

I'm seeing myself as an expert in a couple of areas, but I'm not afraid of asking at all. It happens quite often, literally. This week, I asked on Twitter how to get a message giving me a port number for some specific connection, because you can pick a different port number and you can listen to multiple port numbers and if connection happens, it would be great to know which port it is using From some higher level. It's not easy to figure it out and I had a couple of leads where I can dig deeper, but I have no such knowledge and I'm not afraid of asking because, well, maybe someone has been there and I can see benefits from using it. Please observe what others are doing.

You mentioned courses as well. I would not start with buying expensive courses unless you know perfectly well what you are doing. We have a lot of free I mean financially free knowledge over the internet. It is about some courses over in YouTube. We have some great blogs. We have a lot of open source programs. We can try to analyze, understand what those are doing and learn from the code. So we have a lot of costless options.

Ł: I would say Exploring them first will be at least cheaper and sometimes even better. So I'm totally convinced. Right? You mentioned the question from Twitter, the ports. It would imply that someone, in order to ask these questions, you need to understand a little bit about networking right Between computers in TCP IP protocol, and what are the standards, standard things that run on each port, right, that you have SSH on 22nd on average, right or usually, or you have HTTPS on 443, I guess, if I remember correctly. So maybe people need to study networking first to do this, right? Is there areas of expertise which are easier than the other ones? Like you could study how their local program runs and it doesn't use. Well, I guess it can use loopback, local local network loopback interface you can always meet someone telling you you should dig deeper.

G: If someone is telling you you should understand networking, some other tell you you should understand electricity and radio signal okay, moving it. The next one will be about transistors and yet another level deeper will be about quantum effects in the semiconductor. So always dig deeper. It is actually one of the beauties of IT for me, because you can dig deeper, because every single thing on the entire stack was built by someone and you can report it if you are determined enough. It is not true for medicine, biology, astronomy, etc. We didn't build that part of the world, but when it comes to IT we have such power.

The entire knowledge about how this works is, in my opinion, impossible to be gathered by one person. So it never happens. It's just too much. I'm sometimes showing I was invited as an author for a couple of chapters in a book called Introduction to IT Security, and it is introduction and it has three parts each of those being an editor maximum how much they can put into one single piece of a book, because they cannot technically put more pages. So it's the biggest book possible, time three. And it is introduction only to a part of the IT being IT security only to a part of the IT being IT security. So it shows something about the area we're trying to cover.

So pick the place it may be more than once you feel comfortable with and just face it. You will never understand the entire scope. It's how the IT is looking nowadays. It is just impossible. Do not feel ashamed. You do not understand ARIA. If you are an expert on DNS server, probably you do not know that much about the frontend, so you can work together with someone being fluent in frontend and you can help him with serving the DNS records properly. That is how it's working.

Ł: Totally resonates with me. I can correlate to this in so many different ways with my coding background and coding languages and even domains of coding mobile versus server-side code. Front-end code design Absolutely Absolutely. Code design Absolutely Absolutely, and like when you say you pair with someone to help you. Does this happen a lot? Or do people generally are friendly? Because in my domain there is no encoding domain? In general, coding high level, especially in web or mobile development, there's not so much of at stake.

I would say with security, you got you know people's money in the banks and you got you know probably bigger actors, countries, and whatnot. It can get pretty political, I would say so. Is community like open to new people, given the fact that you know there could be actors who basically want to obtain the knowledge for the wrong reasons, so to say, or for their own personal agendas? Is this something? I cannot imagine this happening at all. In my vicinity we built mobile apps. We built web apps. It's very open. No one assumes any wrong intentions. There is no second thought about this at all. But I would imagine in your domain this has to be a natural, constraint, right, natural, something that people will think about. How does that, you know, impact any decision making where someone opens up and shares the knowledge or collaborate and so on. How is how is that done?

G: I was thinking about it a couple of times. Because if I do some research, well, that's the common question exposing is more beneficial or more harmful. So you have to answer it. In my opinion, if you behave quite open when it comes to technical details, to some research, it is beneficial because both sides are listening to it and if you are saying it clearly earlier, you will provide some time for defense. Otherwise someone could discover it and do not publish and then use only for bad purposes. So I believe sharing makes a lot of sense.

Of course, if something can be quickly used to attack someone else, the best practice is something we call responsive disclosure. So talking to the vendor first. To work with the vendor, vendor has to work with you and sometimes it may be frustrating. For example, a very common case with Microsoft I'm working with. In a couple of cases you are reporting something to Microsoft, you obtain an answer, it is not a bug, and then three months later you see in some release notes or kind of release notes, we fixed this bug because we considered it important. But come on, you told me it's not important at all. So from the security perspective, from the industry perspective, it's not that bad because they fix it before it starts to be harmful. But on the other hand, when it comes to the community, to the value for a developer willing to discover something for free, sharing with the vendor first, it is not something that makes you willing to do this again.

Ł: Oh wow, I'm actually surprised by this

G: Because it is somehow, they're somehow trying to get off, so you simply do it. Or another case I observed a couple of months ago about some way of interacting, maybe not crossing any security boundary, but a way of disrupting operation of the antivirus. They closed my report as unsolved because the main reason was they could not reproduce it. But the justification was they could not reproduce it because I did not provide screenshots or movie showing how I'm doing this. I provided the text description, in my opinion, good enough. So instead of asking me more questions, instead of inviting me for a call when I can show them whatever, because I believe the signal itself was kind of information we want to work with, they close it because there were no pictures. The statement in the comment for the closing was there are no pictures showing how you did it.

Ł: I thought these times or these kinds of activities or behaviors are behind us and nowadays majority of companies would actually appreciate this and have a bug hunting or bounty program or typically they don't, but in practice it doesn't look like this.
‍
G: Well, in practice, it's about such tiny, frustrating, sometimes frustrating, uh details. When it comes to backbone this, I believe it is the worst possible way, but we do not know. Okay, this is the the bad way of making code better, but no one invented anything more friendly. You mentioned how I can identify someone's intentions, and so on. A couple of days ago, I obtained an invitation for being involved and somehow promote a company or portal I do not know how to actually call it Collecting zero days and paying for them and I could not find any reasonable information about that part. The only thing.

I also discussed it with my colleagues. They pointed one interesting thing they can pay for such bugs, and they posted a list of possible ways of payment, including russian banks. So well, if they can pay to a russian bank, probably it is non-us, non-eu. So who are they? And this is the reason why I actually dropped the, the I did not even start the cooperation because it looked a bit too shady. So you do not want, in typical cases, to be on the wrong side. This is not why we are doing this. At the same time, there are people developing malware, developing exploits and also believing it brings some value to the industry. If we take a look on the code security and the industry level of safety in general terms in 2024, and if you take a look like 15 years back, the progress is huge no-transcript Got it.

Ł: Can you say a few more words about what zero day is for our audience, so people understand what that means and why is this important? Sure?

G: Of course, we have bugs in our application. Some of those can be just functional ones, some of those may relate to the security, and it is one thing for any single product to have a kind of a process. More or less the structure is to fix bugs, and we also. Bugs are sometimes found by our own internal forces. Sometimes are reported external. So even if we have a rare correlation of facts that the bug was found by someone else, it can be actively used to bypass some security mechanism and it is not yet fixed by the vendor. We call it zero-lay. So it is a bug which is exploitable but is not yet fixed, and it is kind of an expensive or precious thing because it can be used for bad purposes. But there is a bad guys industry as well, so they are willing to pay for it for sure because it can be used for their operations.

Ł: Yeah, exactly, I was going in the direction of how this can be weaponized, because ultimately it's like a military race. Right For knowing these things, and that's why.

G: We are living in quite dangerous times and it is used for military purposes as well. So it is happening At the same time. Well, both sides are acting there. We are trying to prepare our defenses. We are trying to prepare our offensive skills as well. We are doing a lot of exercises, literally.

One week ago, the biggest NATO exercise finished when civilians tried to help military. It was military exercise led by NATO. On the other hand, it is nowhere like military is trying to do this on their own, even in US or some very well-developed military forces focused on cybersecurity. It is always supported by civilians working in this industry. So I had the pleasure to participate as a civilian in the military exercise. I could say it was pretty successful. We had to defend a country from different types of attacks, including attacks on energy systems, on some air traffic management, on some banks, etc. So it was like an entire country built on virtual machines and then being attacked by the attacking country, and we had to support them defending. And we are doing such things. I mean, every single one involved in IT security is actively participating in different scenarios related to them, sometimes directly, sometimes indirectly, but in most cases, we want to make our countries the place we're living a're living a bit more safe and secure.

Ł: Wow, that's amazing. Thanks for sharing. And how do you feel? How do we compare to major, you know fire powers out there? As a Central European community or country, we're the best. That's great. That's great to hear.

G: I know how it sounds, but it's actually true. This year we had no, it was the first year for this. It's called Locked Shields exercise. The first year started like 15 years ago and this year was the first one where they did not officially provide the places for the top three. Ago and this year was the first one where they did not officially provide places for the top three Because numerical results were so close. It was like a tiny fraction of one percent of difference in points between different teams.

We have participated in the team consisting of Poland and Finland. It was a joint Finnish-Polish team and we scored top three without any official message where we were and we were in the top three. We, as a Poland, our team consisting of Polish experts, sometimes mixed with other countries, we are in top three, top four for the last couple of years. When it comes to the cyber military forces, we are considered. Those rankings are always very weird because you have no weird, because you have no precise way of comparing forces, but we are in the top tier for sure, as a polish force, which is good but it can change any day, literally, of course.

Ł: I mean, this is all playing, playing a catch-up game and being first right. This is amazing, this is. This is great to hear. Um, you know, when I hear about things like that, I always think about a lot of movies where they show how this happens real time and whatnot. But I would imagine this is not so fast right. Most of these things are reactive and proactive in the in a sense. That's their hours and days passing right before certain things are realized and there's forensics and investigation on what really happened. Is that correct or is it more like?

G: Yes, sometimes you can spot something is going on. If you have a lot of performance counters of different types and you know how they look like when everything is working normal way, you can find anomalies just by watching or using some mathematics for finding anomalies. So judging by those anomalies, you can try to react quite quickly. Sometimes it is about using some smart way and before you react you are out of luck, at least partially, and you have to contain the attack and you have to react. You have only reactive powers. For example, a couple of months ago we had an attack based on Outlook, because if you drop someone a reminder in Outlook, you can set a custom sound for this reminder. So it may be just a typical Windows ding or it may be something more fancy. What attackers did in practice? They dropped reminders to a lot of people across NATO countries and the file for playing this fancy sound of the reminder the file was shared from the server in Russia, so every single person receiving such email message reminder downloaded this file from the server.

I see what you mean and they have a lot of information from the download itself and on top of it, windows system, are trying to automatically authenticate. I will not dig into details, but they try to authenticate sending some sensitive information to a totally unknown server. Ah crazy.

Ł: I see where you're going with this, it is, it's smart at the same time, phishing 2.0, you know, definitely.

G: Because you do not have to click it. It's enough if the email reminder reaches your mailbox.

Ł: Amazing and also scary, and on the surface it looks like such an innocent feature.

G: Who cares about? Sound for the reminder.

Ł: Yeah, but on the other hand I'm a bit surprised when you say that people out there use Outlook. You know In really important environments that they wouldn't use some open source or maybe even there's no clear proof when it comes to statistics or anything you can measure.

G: Actually the open source is safer or anything you can measure. Actually the open source is safer, not even counting typical attacks on the source, like the one we faced recently with compression library or some other things intentionally being implemented in the open source. So I know reviewing a code has its value, but only relying on the fact it is possible versus it is not is not making the open source software safer at all. Military across the world, top secret government agencies and so on are still using open source software.

Ł: Insane. I mean it's okay that they use it. It's just that. I give you another example.

A couple of years ago I made a decision decision and I'm generally not a big email user. I'm frequently annoyed by email, so I'm much better with instant messaging like WhatsApp or whatever else Slack we use internally. And when we receive a set of emails or people in the company receive set of emails who were spoofed and they say like Łukasz asks Łukasz send you this email. Company received a set of emails who were spoofed and they say like Łukasz asks Łukasz send you this email. And then in email it was with mixed grammar and anything explaining to people how I am stuck somewhere in Germany and I need to be wired a hundred thousand slots to help me out. They were like, come on, Łukasz would never use email to write us this. You know, that was their first thought, simply because company culture is okay. Łukasz is not an email person, we don't. Łukasz is not an email person, we don't use email so much.

So I would imagine that in and this is a silly example, it's just a coincidence the security of that was a coincidence of me just really not enjoying email and how we set everything up internally. But I would imagine it's going to be similar for I don't know, like you said, nato right that they would use something more robust and something more internal, something where external actors cannot act on right, because they are just not in the system somehow. I mean, you can always get into the system. I would imagine that someone can get hired in my company who just pretends to be a coder. They pass all the interviews and so on and they're kind of internally and they have access to Slack. But as a bigger engagement, they're just sending thousands of emails and hoping that someone will simply receive it.

G: It's not even about clicking anything right, yep, and it is also about the employees seeing this and willing to react, willing to spot. It is something weird in this message. Some time ago I have analyzed a case of the email where an attacker took signature data by scrapping LinkedIn and if you create a profile on LinkedIn you have to put something that originally in the US was a state, there is an address, there is a town and the state and the country. In Europe we do not use such thing. Practically In Poland it is enough to say what town you live in, without specifying the state or voivodeship or however it is called. No one uses it, at least in a typical communication. So if you obtain an email with name and the surname and the company name, and then voivodeship and then country, it's like really, yeah, exactly this is suspicious.

It could not happen and we quickly realized it was scrapped off LinkedIn because on the LinkedIn we have such information. But one of the most common advices do not click on suspicious this and that. You know it is suspicious after you click, Not before, because this recommendation is not that comfortable to be practically used. So it's always about professional judging. I know the company. I helped them not so long time ago because they had cooperation with some party, with some party, with some vendor in China and then obtained a very classical email our bank account is something, something. Please transfer the last invoice to another bank account. Well, a couple of tens of thousands of dollars went to some weird account and no one wants to transfer it there and no one really uh knows how did it happen, why? Yeah, it would be possible, even if they had some procedures for addressing such cases, because it was not the first attempt.

Ł: Remember this case with this guy who, from Lithuania and Estonia, was sending invoices underneath the name of a real vendors from Google and Amazon and others for IT, and he was sending them invoices and because the name was correct, no one asked any questions and for two years they were paying him to some shady account somewhere.

I am frequently amazed. You know how. They're not crazy schemes. There's no crazy intelligence or crazy stuff required to do this, and you would imagine that at this point, banks understand enough to maybe have a prediction model or AI or something, or maybe this is coming hopefully it's coming where they see, like, okay is weird, because you know, even on the basis on which this invoice gets paid from google to this middle of nowhere, right, it just doesn't make sense. Maybe we should ask them if this is really what they want. Right, I know it's about freedom and and whatnot, but just ask them right, okay, you paid that, uh, but you kept paying this for two and a half years to some middle of nowhere big amounts with anyhow yours to some middle of nowhere.

G: Big amounts with some money that you do not own with some other person money.

Ł: It's so easy. So who cares? Yeah, it's not our problem, I get it, but. But because bank right, the, I would imagine, organization bank sees all the outgoing things and they see like, oh, this, this says I don't know lucas and this is lucas, right, but the but this one is in this country and this one is in the other country, and it doesn't really make sense, right, maybe we should just flag it for them. I wonder if this is waiting for disruption, because I would imagine it's really interesting to create infrastructure level above, where all the scheduling on invoices and so on is being evaluated by the company for their own sake, not on the bank level. Bank will just become an API to move money, but above that, you have some sort of intelligence.

G: The same thing is interesting because if it comes to transfers, banks usually say it is your fault, you did the wrong transfer, we can do nothing about this and we do not care, simply saying. It is quite a different scenario when it comes to credit cards, because every single credit card transaction is insured somehow. So if it is an equivalent transaction, a bank has to return it to you for every single credit card transaction. And just take a look If you do some shady credit card operations for example, going to a strange location for a vacation and you try to withdraw money from the ATM, your bank will call you.

Ł: Call you right away, yeah.

G: So if they can lose on it, well, they care about actually their money. When it comes to something they do not have to care about, well, it is your money. Do whatever you want to do. So maybe putting some prefer on banks makes sense as well here.

Ł: Yeah, it's all about changing who is in red afterwards, and that changes their attitude and this, yeah, I experienced this many times as well. For the best, grzegorz, thank you so much. This has been an amazing conversation. I feel educated and I'm feeling very curious. I'll check the books you mentioned. So, thank you so much. Tell us where we can find you on the internet if someone wants to ask a question or something. What's your Twitter? Maybe?

G: For me, Twitter is the main way of contacting the community, even if we had some period when we believe Twitter will fall down totally, but it did not magically, so it is zero gtweet for my Twitter handle. I'm relatively easy to be found by my name. I'm also well, if someone prefers code. My GitHub is also a way of seeing what I'm doing, because I'm not coding actively for money, so I have a fan sharing what I code. It is on the funny side in my case. I'm not coding actively for money, so I have a fan sharing where I go. It is still on the funny side in my case. So feel free to reach me. I'm always happy to help. I'm trying to help and, if I can, if not, I'm trying to guide you to the right direction. Thank you very much for today's talk. It was very interesting for me as well, especially this bit aside of my main area of specialization. It is always giving new insight, new ways of thinking about old things, which is always beneficial. Thank you very much.

Ł: Absolutely, absolutely. It's been a pleasure thanks. Thanks for tuning in. If you enjoyed our deep dive into cyber security with chakras forex, be sure to like, subscribe and share this episode. Let us know what you found most interesting. Stay tuned for more expert insights and exciting discussions in our upcoming episodes. Hear you soon.

Don't miss out on any episode!