CompTIA CYSA+ CS0-002 – Mitigate Software Vulnerabilities and Attacks Part 4

5. Design Vulnerabilities (OBJ 1.7)

Design vulnerabilities. In this lesson we’re going to talk about some software design vulnerabilities and what are some things you can do to overcome them. Now, when it comes to vulnerabilities, vulnerabilities often arise from the general design of your software code. And so if you do bad software code design you’re going to have a lot more vulnerabilities. So in this lesson we’re going to focus on three main types. We have insecure components, insufficient logging and monitoring, and weak or default configurations. Now, when we talk about insecure components, what is this? Well, it’s really any code that’s used or invoked outside of the main program development process. So when you’re dealing with this and you start dealing with insecure components, this can come from a lot of different areas. For instance, it could come from code reuse.

Now this is where you take one block of code from somewhere else in the program, just copy and paste it and use it. Again, where you take it from one application and put it into another application. A lot of times people go on to Stack Exchange and they’ll go and copy people’s code and put it into their own. Now there’s nothing wrong with doing that initially, but if you’re ever using code and you don’t know if it’s secure or not, you could be bringing in vulnerabilities into your program by doing that. And so this is why we consider it an insecure component. Another thing we might use is a third party library. Anytime you bring in a library to do some function for you, you are importing that code into your program. And so you might bring in a dynamic link library in Windows or a shared object library in Linux and that might give you the ability to do network connections or do cryptography.

But if those things were not secure, you now brought that insecurity into your program. And the third thing is software development toolkits. Again, SDKs are really helpful as a programmer because I don’t have to go and create all those pre built functions. But if the person who built those pre built functions didn’t do a good job, you’re bringing in those vulnerabilities as well. And the other issue with these three areas is especially with SDKs and third party libraries is sometimes they built it thinking it was good and then six months later there’s a vulnerability to it. If you’re using an old version of a library or an old version of an SDK, you aren’t using the latest and greatest patched one and therefore you’re missing those security fixes and you’re bringing in those insecurities into your program. The second area we want to talk about is insufficient logging and monitoring.

Now this is any program that does not properly record or log detailed enough information for an analyst to perform their job when there’s an incident that happens. So if I create a program and I don’t have any kind of logging and monitoring, well, that’s not going to be very good for my analysts who have to deal with the incident response later. So we want to make sure we’re always setting up our logging and our monitoring to support our use case and that way we can and answer the who, the what, the when, the where and the how when things go wrong. Now, what is your use case? Well, that’s up to you and your organization. You’re going to determine how much logging you want, how long you want to store it for and all those details like we talked about back in our logging lessons.

The third area we want to talk about is weak or default configurations. Now this is any program that uses ineffective credentials or configurations or one in which the defaults have not been changed for security. When you’re dealing with weak or default configurations there are lots of these things out there in the marketplace and they are running amok in a lot of people’s networks. Now, many applications choose simply to run as root or local admin. That’s their default configuration. You need to ask yourself does this program really need to be root? Does this program really need to be an admin? And if not, don’t let it run that way because you want to use Lease privileges. Also, sometimes you have some of these programs and by default their permissions are really vague, they’re really permissive and so they allow a lot of files and directories to be read and write and executed to. And this would be a weak configuration.

Another place I see this all the time is when you’re using hardware appliances or you’re using some kind of software that has a password and username already built in and it’s often something like administrator. Administrator or admin. Admin or root. Root. This is a weak or default configuration that should be changed immediately once you install it into the environment. Now, what’s the best practice to prevent some of these weaknesses? Well, the biggest one is to utilize scripted installations and baseline configuration templates to secure your applications during install. So if I’m going to install some program there should be a security configuration template or a scripted installation that actually goes through and makes those things more secure. This would be something that your organization does itself or something provided by the manufacturer.

6. Platform Best Practices (OBJ 2.2)

Platform best practices. In this lesson we are going to talk about some platformspecific best practices and some of the vulnerabilities you may experience. Now, when you’re thinking about different platforms, we have lots of them, including client server applications, web applications, mobile applications, embedded applications, firmware and system on a chip or SoC. We’ve talked about all of these areas before in this course, but now we’re going to think about it from a software development perspective. Now, when you’re dealing with a client server application, this is an application where part of the application is client software that’s installed and run on a separate piece of hardware. And then you have a server application that’s installed on a server and they’re going to interact between the two over a network.

Now, why is this dangerous? Well, because attacks can be directed in one of three places. They can be directed at the local client code on the workstation, or at the server application on the server, or the network in between. And so you really have to think through this fully because you have three places that there could be attacks. For instance, if I install a piece of software and it’s the most secure piece of software in the world, but I install it on a laptop that already has malware or rootkit, well, guess what? That software is now going to be insecure because the underlying operating system has already been compromised. And so when you’re doing all this, you have to think about the client system and you need to make sure it’s secured with the right scanning and patching in any malware solutions.

And the same thing with the server and the same thing with the network. If you can’t secure all three places, regardless of whether or not your code is secure, you’re going to have an insecure environment. Now, when you’re dealing with server side code, you always want to make sure that whatever you’re accepting from somebody needs to go through input validation. This will prevent things like buffer overflow attacks or integer overflows. This is a really important thing. Input validation in CYSA is a great thing to use and when you see it on questions, it’s pretty much the right answer at least 75% of the time. So when you see input validation, think about it because anytime you’re trying to prevent something like an SQL injection, an XML injection, an overflow attack, anything that’s taking information from a client and going to a server, you always want to have input validation.

The next area we want to talk about is web applications. Now Web applications are any applications which use a generic web browser as the client and it uses standard network protocols like Http or Https to communicate with the server. This is really a client server application, except that that application doesn’t get installed on the client because the client is just a web browser that’s accessing it. Now, web applications can use a multi tiered architecture where the server part is split between application logic and then data storage and retrieval. This way you have application logic that makes decisions and data storage and retrieval like a database. This is a very typical setup when you’re dealing with a multi tier. My website is actually built this way. It is a web application, and we use a multi tier architecture.

We have our front end, which is what you actually see the course on and take your quizzes on. But then we have the back end, which is the data storage and retrieval that’s all stored in the database. So we know that you took this quiz and you got this score, and we can look back in that over time. Now, when you’re dealing with modern web applications, a lot of them don’t even use servers anymore. They use what’s called microservices or serverless designs. I have a couple of web applications that I use that actually are serverless. They’re not ones that our clients use or our students use. It’s something we use for back end systems and bookkeeping. But those same principles apply because we’re dealing with these modern web applications that are serverless in their design. The next area we want to talk about is mobile applications.

And this is any application that’s deployed and run on a smartphone, a tablet, or other mobile operating system. So if you’ve got a smartwatch, it considers itself a mobile application. Now, when we talk about mobile applications, these are often more susceptible to unsecure use of authentication, authorization and confidentiality controls. These mobile devices are definitely vulnerable to attacks launched from the use of open wireless access points as well. A lot of times people take their device and they connect to the local coffee shop. They don’t think about the fact that that network is not secure. So even if your mobile application is secure, if it’s going over an unsecured network, there’s a possibility for infiltration. So you want to keep this in mind. The next thing we want to talk about is embedded applications.

Now, embedded applications are any applications which are designed to run on dedicated hardware platforms. When we talked about things like ICS and SCADA, we talked about all these manufacturing systems. We talked about Smart TVs. These are all examples of embedded applications.

Now, the problem with embedded applications, like we’ve talked about before, is that they traditionally are not focused on security during development and deployment. And so a lot of bugs can exist. And a lot of these are very old technologies that have not been updated in quite some time. So if you have embedded applications in your network, think about this and think about how you can protect them. If you happen to be responsible for embedded application development, go check out OS.

They have a great guide on showing you how you can do this more securely. And then we have firmware. Now, firmware is generally considered a type of embedded application that contains the block of embedded code that’s run it for startup, things like your BIOS, if you want to think of that, that this also performs low level input output device functions, plus bootstrapping of an operating system or application. So when we’re dealing with firmware, we are dealing with something that starts up right at the beginning. And so this makes it a great target for attackers because if they can get access to the firmware, that firmware has complete control over the hardware and system memory. And therefore it makes it a completely lucrative target.

And it makes it really great place to be able to install your rootkits. And it makes it a great place for an attacker to install a rootkit. The last thing we’re going to talk about is system on a chip. This is also known as SoC. This is a type of embedded application commonly used in mobile devices, which contains integrated CPUs, memory, graphics, audio network, storage controllers, and software, all on one chip. Now, the great thing about system on a chip is they’re low power, right? And they have really good efficiency when they’re being able to use processing. But these manufacturers often will reuse a lot of code. So these sock manufacturers will often reuse code by selecting what’s known as an IP block for certain functions. And they make these up using field programmable gate arrays.

Now, what are these IP blocks? Well, an IP block is a set of configurations that uses SoC logic gates to achieve a function. So if I wanted to make sure there was the ability to have a networking card that can be programmed using field programmable gate arrays inside of this IP block, and I can build that and then I can sell that to another manufacturer. So as a sock manufacturer, if I wanted to build a system on a chip, I don’t have to go code my own network adapter. I can just go buy one of these IP blocks and embed it into my chip as I’m building my chip. That’s how these things work. And because of that, you have code reuse. If you’re reusing somebody else’s code and you don’t know the security of it, again, you’re bringing insecurities into your system.

• Category: Uncategorized