در پروداکشن از "hardened images" استفاده کنید تا سطح امنیت سرویس یا محصول خودتون رو بلافاصله ارتقا بدید

https://www.docker.com/products/hardened-images/

در حالی که در ایران انطباق (compliance) با استانداردهای PCI SSC اجباری (mandatory) نیست اما مطالعه در این مورد هم خالی از لطف نیست



https://cybernews.com/hosting-hub/how-to-make-your-e-commerce-site-pci-compliant/

خب شاید باورکردنی نباشه اما دارم برمیگردم به windows 💀

دلم برات تنگ میشه مینت 🫡

🦑... setting up...🐋

طبق ritual دیروز بعد از نصب ویندوز مشغول debloat کردن بودم، از این دوتا ابزار بیشتر استفاده کردم:

Revo Uninstaller
ChrisTitus Windows Utility

پیشنهاد میکنم شماهم تا جای ممکن از شر bloat روی سیستم ویندوزی خودتون خلاص شید و spyware هایی رو که microshit تحت عنوان سرویس بهتون ارائه میده‌رو تا جای ممکن محدود کنید.

برای دوست داران امنیت سایبری:

در این ریپازیتوری می‌تونید روم‌های رایگان TryHackMe رو به‌صورت دسته‌بندی‌شده بر اساس Category ببینید.

این منبع می‌تونه برای همه سطوح مفید باشه،
بخصوص اگر ابتدای مسیر یادگیری امنیت هستید...

https://github.com/Hunterdii/TryHackMe-Roadmap?tab=readme-ov-file

سوال شماره 26 :
Remove Duplicates from Sorted Array
Difficulty => Easy

وقتی می‌گیم یک الگوریتم in-place است، یعنی داده‌ی ورودی را مستقیم تغییر می‌دهد و از حافظه‌ی اضافی خیلی کمی استفاده می‌کند (معمولاً O(1)).
یعنی:
آرایه‌ی جدید نمی‌سازیم
فقط با چند اندیس یا پوینتر کار می‌کنیم
نتیجه داخل همان داده‌ی اولیه نوشته می‌شود
چرا مهم است؟

• سوال محبوب مصاحبه‌ها
• مصرف حافظه کمتر → کارایی بهتر
• حیاتی در سیستم‌های محدود و مقیاس بزرگ

مثال معروف: حذف المان‌های تکراری از آرایه‌ی مرتب (sorted) با الگوی two-pointer.

وقتی می‌گیم Shift Left، منظور یک اصطلاح فنی پیچیده نیست؛ فقط داریم درباره‌ی زمان حرف می‌زنیم.

در نمودار زمانِ توسعه‌ی نرم‌افزار:
Design → Code → Test → Deploy → Production
سمت چپ = مراحل اولیه
سمت راست = مراحل پایانی
پس Shift Left یعنی جابه‌جا کردن کارها به سمت چپ این خط زمان.

در امنیت:
به‌جای اینکه بعد از نفوذ بپرسیم «چطور هک شد؟»
از اول می‌پرسیم «از کجا ممکن است هک شود؟»
در عمل Shift Left یعنی:
فکر کردن به تهدیدها قبل از نوشتن کد
گرفتن بازخورد سریع، نه گزارش‌های سنگین آخر پروژه
پیشگیری به‌جای واکنش
تبدیل امنیت از یک مرحله‌ی جداگانه به بخشی از توسعه

درواقع Shift Left یعنی زودتر فکر کردن، نه سخت‌تر کار کردن.

و نه، به این معنا نیست که «همه‌چیز مسئولیت دولوپر است»؛ بلکه یعنی همکاری زودتر و هوشمندانه‌تر.

هر چیزی که زودتر کشف شود، ارزان‌تر، سریع‌تر و تمیزتر حل می‌شود.

یه رودمپ بدرد بخور:


https://github.com/x86byte/RE-MA-Roadmap

این یکی هم رودمپ خوبیه برای Exploit Development:


https://dayzerosec.com/blog/2024/07/11/getting-started-2024.html

BASED

یه note خلاصه و کوتاه روی تاپیک Linux Privilege Escalation
به مرور کامل تر میشه
صرفا جهت رفرنس و هینت برای مطالعه فراتر




# os version
# kernel version
# running services

ps aux | grep root

#installed packages and versions
#logged in users

ps au

#user home directories

ls /home

#check .bash_history
#sudo privileges
#configuration files

#readable shadow file
#password hashes in /etc/passwd
#cron jobs

ls -la /etc/cron.daily/

#unmounted file systems and additional drives

lsblk

#SETUID and SETGID permissions

#writable directories

find / -path /proc -prune -o -type d -perm -o+w 2>/dev/null

#writable files

find / -path /proc -prune -o -type f -perm -o+w 2>/dev/null

#LinuxPrivilegeEscalation

- helper noscripts : LinPEAS, LinEnum

- depending on the system and environment the commands could be slightly different, but as long as you get a solid understanding on what info you want and how you could obtain it you should be OK, in other words the principles are the same.

- basic commands :
  

    whoami
    id
    ifconfig
    ip a
    sudo -l
    

   

    cat /etc/os-release
    

- check current user’s PATH :  if the PATH variable for a target user is misconfigured we may be able to leverage it to escalate privileges.

   

    echo $PATH
    

- We can also check out all environment variables that are set for our current user, we may get lucky and find something sensitive in there such as a password
   

     env
     

-checking kernel version and looking for a kernel exploit that matches that version

   

    cat /proc/version
    uname -a
    

-additional info about the cpu
   

    lscpu
    

-What login shells exist on the server?
   

    cat /etc/shells
    

-check for defenses
• Exec Shield
• iptables
• AppArmor
• SELinux
• Fail2ban
• Snort
• Uncomplicated Firewall (ufw)

-look for drives
   

    lsblk
    

-find information about printers attached to the system
   

    lpstat
    

-Can we find any types of credentials in fstab for mounted drives by grepping for common words such as password, username, credential, etc in /etc/fstab?
   

    cat /etc/fstab
    

-check routing table
   

    route
    netstat -rn
    

-in a domain environment check /etc/resolv.conf

-check arp table
   

    arp -a
    

-existing users
  

    cat /etc/passwd
    

-it’s rare but we could find password hashes in the cat /etc/passwd more possible on on embedded devices and routers.


-first hash blocks of the password hash can help us to identify the used hashing algorithm: Salted MD5, SHA-256, SHA-512, BCrypt, Scryp, Argon2


-check all available shells for known vulnerabilities, for example the bash version 4.1 is vulnerable to shellshock exploit

-check for temporary files located in /tmp and /var/tmp
* all files and data stored in /var/tmp are deleted after 30 days and all data stored in /tmp is deleted after 10 days
   

    ls -l /tmp /var/tmp /dev/shm

#LinuxPrivilegeEscalation

اگه از n8n استفاده میکنید مراقب باشید و آپدیت کنید
یه cve جدیدا دراپ شده واسش


https://orca.security/resources/blog/cve-2025-68613-n8n-rce-vulnerability/

https://nvd.nist.gov/vuln/detail/CVE-2025-68613

-services and internals

-check for anything interesting in /etc/hosts

cat /etc/hosts 

-check the last log ins

lastlog

-are any other users on the system with us?

who 
finger

-check /proc/procfs for system information such as the state of running processes, kernel parameters, system memory, and devices

find /proc -name cmdline -exec cat {} \; 2>/dev/null | tr " " "\n"

-check installed packages

apt list --installed | tr "/" " " | cut -d" " -f1,3 | sed 's/[0-9]://g' | tee -a installed_pkgs.list

-also check the sudo version

sudo -V

- it can also happen that no direct packages are installed on the system but compiled programs in the form of binaries

ls -l /bin /usr/bin/ /usr/sbin/

-check GTFObins for potential binaries that can be exploited to escalate our privileges

for i in $(curl -s https://gtfobins.github.io/ | html2text | cut -d" " -f1 | sed '/^[[:space:]]*$/d');do if grep -q "$i" installed_pkgs.list;then echo "Check GTFO for: $i";fi;done

-use strace to track and analyze system calls and signal processing

strace ping -c1 <IP>

-check the noscripts

find / -type f -name "*.sh" 2>/dev/null | grep -v "src\|snap\|share"

-check running services by specific users

ps aux | grep root

#LinuxPrivilegeEscalation

Path Abuse:



-PATH is an environment variable that specifies the set of directories where an
executable can be located. An account's PATH variable is a set of
absolute paths, allowing a user to type a command without specifying the
absolute path to the binary. For example, a user can type cat /tmp/test.txt instead of specifying the absolute path /bin/cat /tmp/test.txt. We can check the contents of the PATH variable by typing env | grep PATH or echo $PATH.


* Creating a noscript or program in a directory specified in the PATH will make it executable from any directory on the system.



-Adding '.' to a user's PATH adds their current working
directory to the list. For example, if we can modify a user's path, we
could replace a common binary such as ls with a malicious noscript such as a reverse shell. If we add . to the path by issuing the command PATH=.:$PATH and then export PATH,
we will be able to run binaries located in our current working
directory by just typing the name of the file (i.e. just typing ls will call the malicious noscript named ls in the current working directory instead of the binary located at /bin/ls).

PATH=.:${PATH}
export PATH
echo $PATH

-In this example, we modify the path to run a simple echo command when the command ls is typed.

touch ls
echo 'echo "PATH ABUSE!!"' > ls
chmod +x ls

#LinuxPrivilegeEscalation

Wildcard Abuse:

-A wildcard character can be used as a replacement for other characters and are interpreted by the shell before other actions. Examples of wild cards include:

* ⇒ An asterisk that can match any number of characters in a file name.

? ⇒  Matches a single character.


[ ] ⇒  Brackets enclose characters and can match any single one at the defined position.

~ ⇒  A tilde at the beginning expands to the name of the user home
directory or can have another username appended to refer to that user's
home directory.


- ⇒   A hyphen within brackets will denote a range of characters.



-An example of how wildcards can be abused for privilege escalation is the tar command, a common program for creating/extracting archives.

* check the man page for tar and read about: ( --checkpoint[=N] ,  --checkpoint-action=ACTION )


-The --checkpoint-action option permits an EXEC
action to be executed when a checkpoint is reached (i.e., run an
arbitrary operating system command once the tar command executes.) By creating files with these names, when the wildcard is specified, --checkpoint=1 and --checkpoint-action=exec=sh root.sh is passed to tar as command-line options.

#LinuxPrivilegeEscalation

Escaping Restricted Shells:



-A restricted shell is a type of shell that limits the user's ability to
execute commands. In a restricted shell, the user is only allowed to
execute a specific set of commands or only allowed to execute commands in specific directories. Restricted shells are often used to provide a safe environment for users who may accidentally or intentionally damage the system or provide a way for users to access only certain system features. Some common examples of restricted shells include the rbash shell in Linux and the "Restricted-access Shell" in Windows.

* examples of restricted shells: rbash, rksh, rzsh

-In some cases, it may be possible to escape from a restricted shell by injecting commands into the command line or other inputs the shell accepts. For example, suppose the shell allows users to execute commands by passing them as arguments to a built-in command. In that case, it may be possible to escape from the shell by injecting additional commands into the argument.

-Command injection :
Imagine that we are in a restricted shell that allows us to execute commands by passing them as arguments to the ls command. Unfortunately, the shell only allows us to execute the ls command with a specific set of arguments, such as ls -l or ls -a,
but it does not allow us to execute any other commands. In this situation, we can use command injection to escape from the shell by injecting additional commands into the argument of the ls command.

-For example, we could use the following command to inject a pwd command into the argument of the ls command:

ls -l `pwd` 

* This command would cause the ls command to be executed with the argument -l, followed by the output of the pwd command. Since the pwd command is not restricted by the shell, this would allow us to execute the pwd command and see the current working directory, even though the shell does not allow us to execute the pwd command directly.


-Command Substitution :
Another method for escaping from a restricted shell is to use command substitution. This involves using the shell's command substitution syntax to execute a command. For example, imagine the shell allows users to execute commands by enclosing them in backticks (`). In that case, it may be possible to escape from the shell by executing a command in a backtick substitution that is not restricted by the shell.


-Command Chaining :
In some cases, it may be possible to escape from a restricted shell by
using command chaining. We would need to use multiple commands in a
single command line, separated by a shell metacharacter, such as a
semicolon (;) or a vertical bar (|), to execute a command. For example, if the shell allows users to execute commands separated by semicolons, it may be possible to escape from the shell by using a semicolon to separate two commands, one of which is not restricted by the shell.

-Environment Variables :
For escaping from a restricted shell to use environment variables involves modifying or creating environment variables that the shell uses to execute commands that are not restricted by the shell. For example, if the shell uses an environment variable to specify the directory in which commands are executed, it may be possible to escape from the shell by modifying the value of the environment variable to specify a different directory.


-Shell Functions :
In some cases, it may be possible to escape from a restricted shell by using shell functions. For this we can define and call shell functions that execute commands not restricted by the shell. Let us say, the shell allows users to define and call shell functions, it may be possible to escape from the shell by defining a shell function that executes a command.

#LinuxPrivilegeEscalation

Special Permissions :



-SUID : The Set User ID upon Execution (setuid) permission can allow a user to execute a program or noscript with the permissions of another user, typically with elevated privileges. The setuid bit appears as an s.

find / -user root -perm -4000 -exec ls -ldb {} \; 2>/dev/null

-It may be possible to reverse engineer the program with the SETUID bit set, identify a vulnerability, and exploit this to escalate our privileges. Many programs have additional features that can be leveraged to execute commands and, if the setuid bit is set on them, these can be used for our purpose.

-SGID : The Set-Group-ID (setgid) permission is another special permission that allows us to run binaries as if we were part of the group that created them. These files can be enumerated using the following command:

find / -uid 0 -perm -6000 -type f 2>/dev/null

These files can be leveraged in the same manner as setuid binaries to escalate privileges.


* https://linuxconfig.org/how-to-use-special-permissions-the-setuid-setgid-and-sticky-bits


#LinuxPrivilegeEscalation