Software Development Nuggets for Security Analysts
This is a blog dedicated to those like myself who may have an "alternative" background when it comes to getting into cybersecurity.
My personal path into Cyber Security was Help Desk > IT Field Tech > Route Switch Networking > InfoSec. For most of my career, it was rare for me to ever interact with software developers directly. One thing I found is that as I progressed in my career and started interacting more and more with both internal and external development teams, I'd hear concepts/lingo/jargon that I didn't really understand, or perhaps only understood at a very high level.
Overtime I worked to change that by both learning to program, and honestly just straight up asking when I heard something and didn't understand (don't be afraid to ask for help!).
While I really encourage everyone to learn to program if they have the time and interest, I also recognize those getting started out in cybersecurity may be better off spending their time on subjects more directly related to their field.
So here's a quick blog post / reference that can help you quickly get up to speed on general on topics you're expected to know, but may not have thought to ask about.
OS Directory Structure
Windows, Linux, and MacOS have a specific directory structure for developing applications and where files for said applications reside. Below is an image (courtesy of Wikipedia) of the Linux Filesystem.
It is important that when you are developing an application, that you try to use the proper directory structure for your target OS. Applications that don't follow the proper directory structure for its target OS may be subject to vulnerabilities. For example:
Further reading
Semantic Versioning (or Semver)
Ever notice how software updates typically contains 3 series of numbers such as 1.3.7? Did you know there is actually a method to this and that it isn't just incrementing at every 10th update? This is referred to as Semantic Versioning or semver for short.
From https://semver.org:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards compatible manner
PATCH version when you make backwards compatible bug fixes
This is why you may see projects go from something such as version 4.19.9 -> 4.19.10 rather then incrementing from 4.19.9 -> 4.20.0.
This can be useful for understanding quickly what type of content an update may contain, or for example if a new update comes out for a red team offensive tool.
Protip: You should not assume that devs follow this perfectly or you will find yourself in pain, however in most larger projects it's typically followed fairly well.
Further Reading
Environment Variables
Environment variables are similar to a variable that you may use in an application. The primary difference is that an environtment variable is a variable that is set at the environment level (typically the Operating System).
On Linux systems, you can set environment variables in a few locations:
/etc/environment
/etc/profile
~/.bashrc:
These are commonly used to supply values to an application without having to hardcode said value. You may commonly see a developer set an environment variable for an API key:
Example use of the above environment variable: EXAMPLE_API_KEY:
Understanding environment variables is important as they are commonly used in software development and commonly abused by adversaries. Adversaries may abuse environment variables as a way to maintain persistence by setting the malicious code as an environment variable, and executing said code by supplying the environment variable where it is stored among other things.
Path Environment Variables
An important environment variable to be familiar with is the $PATH/%PATH% variable in Unix systems and Windows. When you try and execute a binary via the CLI it has a specific order of directories that are checked for the binary in question.
By default, it will look in whatever your current directory may be for the binary. If the binary in question isn't in your current directory, it will then check the systems PATH environment variable for which directories to search next. It reads from left to right and are seperated by semi-colons in Windows while Linux uses a colon. This is commonly referred to as the search order.
In English - if I want to use ping, it doesn't matter what folder I am working out of, if enter the ping command the ping binary is located in a folder contained in both the Linux and Windows PATH variable.
HOWEVER - if I develop a custom app, in a non standard folder that is not within the PATH environment variable, and my current working directory is not inside of said folder, if I try and run the binary by name it will give a command not found as the operating system doesn't know where to find the binary without being told.
Default Windows %PATH%:
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;
Default Linux $PATH:
/home/sample/.local/bin:/home/sample/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
If you move your custom app into one of the folders listed in a path above, you will then be able to call your custom application from any directory.
Further Reading
Libraries
You may have seen a developer mention that they are using a library for a certain development project. Libraries are re-useable code that developers will use to prevent them from having to re-invent the wheel for every application. These can be local to the developer, or perhaps large community maintained projects.
If you're familiar with Python, the libraries are imported at the top of the application - IE:
import requests
import json
def main():
do something
Dynamic-link library (DLL's)
On Windows systems, you've probably come across a Dynamic-link library (DLL) during an investigation. A DLL is similar to other libraries (such as Python's requests), however they are compiled (The file format is the same as a PE File or EXE.
Knowing what a DLL is incredibly important as an analyst as they are commonly abused by attackers. Some common ways DLL's are abused:
Code Execution via Rundll32.exe
While DLL's share the same file structure as a PE file (EXE), they are not executed via a double click. (Un)Fortunately - Microsoft has included rundll32.exe by default on all modern Windows systems, and with this a DLL can be executed.
https://lolbas-project.github.io/lolbas/Binaries/Rundll32/ / https://twitter.com/M_haggis/status/1491109262428635136
Example:
c:\windows\system32\rundll32.exe C:\AtomicRedTeam\atomics\T1218.010\evil.dll,#2
In this example we're executing evil.dll and we've specified an ordinal (IE: ,#2) - this is the number representation of a function.
DLL Search Order Hijacking
Early in the article, we went over paths and how it may impact what is known as the search order. To tie things together, lets go over a technique that is extremely popular with threat actors today: DLL Search Order Hijacking
Whenever a program launches, it loads any DLL's it needs to run. To find those DLL's it searches for them in a specific order as defined here: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#search-order-for-desktop-applications
If SafeDllSearchMode (the default) is enabled, the search order is as follows:
1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
An attacker may abuse this order this search order to have an application load a malicious DLL by placing it in a directory that is checked prior to the non-malicous DLL.
Note: There are many other forms of DLL attacks. It is important to understand how they work - and the Mitre ATT&CK Framework is a good place to start as a security analyst to learn about various attacks and how to prevent them.
Further reading
Conclusion
If you're looking to learn to program, but also learn a bit of computer science (both concepts and lingo) I'd recommend checking out MIT's free Computer Science courses. I took the courses via edX and they were the exact same as a paid college down to the software it seemed the interfaces uses.