搜尋結果

0x00 前言 在內網滲透的過程中思路才是最重要的，本次內網滲透的主機雖然不多，主要還是鍛煉自己內網滲透的一個思想。 0x01 环境搭建 靶場： win7(內)：192.168.138.136 win7(外)：192.168.10.25 域內主機： win2008：192.168.138.138 0x03 web服务器渗透 nmap探测端口 nmap -T4 -sC -sV 192.168.10.25 這裡可以看到幾個主要的端口，例如80、135、139、445，這里首先就可以想到可以利用的點有ipc、smb...

0x00 前言 文章所述漏洞已經提交至漏洞平台，且所有惡意操作均已復原 0x01 源码泄露 http://www.xxx.com.cn/www.zip老規矩拿到源碼先通關關鍵詞找敏感信息 key pwd passwd password找到了半天居然找不到一個有效的密碼 最後在robots.txt中看到CMS的信息-EmpireCMS 查詢知道是開源cms後，直接百度查詢數據表結構 知道了管理員記錄表為phome_enewsuser,在源碼裡全局搜索 0x02 敏感信息泄露 點擊進去得到管理員用戶名，密碼hash和鹽值 直接解md5得到口令...

0x00 前言 此次滲透中的所有修改已經復原，且漏洞已經提交至cnvd平台 0x01 源码泄露 在一個月黑風高的夜晚，閒來無事的我又開著腳本利用hunter進行互聯網站點源碼的掃描 在查看備份文件掃描結果時，看到了寶貝 二話不說，訪問下載得到源碼！ 可以在注释信息处发现dedecms的痕迹 0x02 敏感信息泄露 获得源码的第一步当然是获取敏感信息先嘗試全局搜索（crtl+shift+f）關鍵詞 key pwd passwd password1.數據庫信息洩露 2.後台管理員密碼洩露 md5解密嘗試解密，居然是一個弱口令...

故事的起因比較簡單，用三個字來概括吧：閒得慌。 因為主要還是想練習練習內網，所以用了最簡單粗暴的方法去找尋找目標，利用fofa來批量了一波weblogic，不出一會便找到了目標。 簡單的看了下機器環境，出網，沒有殺軟（後面發現實際是有一個很小眾的防火牆的，但是不攔powershell），有內網環境。 所以這裡直接嘗試cs自帶的Scripted Web Delivery模塊，直接創建一個web服務用於一鍵下載和執行powershell。 運行剛剛生成的powershell 這邊的CS成功上線。 這裡我們先來看看系統的信息。...

0x01 前言 目標是一大學，在一次挖洞過程中遇到個sql注入，嘗試進一步利用擴大危害，漏洞已報送平台進行了修復 0x02 sql注入getshell失败 在id處連續加兩個單引號都報錯，經過探測發現是數字型的注入且過濾了空格，這裡可以用/**/代替 於是直接上sqlmap python sqlmap.py -u url --batch --tamper=space2comment.py –dbs 發現是dba權限： python sqlmap.py -u url --batch --tamper=space2comment.py --is-dba 試了很多方法找web路徑...

前言 本文為一篇利用非常規手段突破安全策略的內網滲透記錄 环境简述说明 web打点getshell，webshell是冰蝎，权限为.net，权限很低，服务器为server 2016，目标不出网！装有杀毒软件（火绒、微软自带的WD），ASMI默认开启，而且对power shell有特殊策略限制。Tcp、icmp、DNS协议不通，无法直接与公网的cs服务端建立连接，（内网的cs服务端也无法与其建立连接）公网也无法访问目标web服务（纯内网web服务）极其严格的出入站策略入站規則：只有http允許入站，只有一個80、8080兩http端口能供內網機器正常訪問...

0x00 初探内网 在向信息中心的老師申請了對學校進行一次內網滲透測試的授權之後，我開始著手對學校內網中在用系統進行了一波信息蒐集。其中大部分都使用了新版的未爆出0day的框架組件，這讓我一開始的打點過程陷入僵局。但是在我重新翻了一遍學校開放的各種web系統後，我發現了一些令人驚喜的系統。 學校使用了很多新系統，但是並沒有把老系統關閉，經過一番搜索確定了這個老系統存在任意文件上傳漏洞。 沒有任何過濾，可以說就是撿漏了。 而且也返回了一句話木馬的路徑。但是我遇到了一個很奇怪的現象，用蟻劍和用菜刀連接後，返回的路徑不一樣，其中的文件也不一樣。...

本次測試為授權測試。注入點在後台登陸的用戶名處 存在驗證碼，可通過刪除Cookie和驗證碼字段繞過驗證 添加一個單引號，報錯 and '1'='1 連接重置——被WAF攔截 改變大小寫並將空格替換為MSSQL空白符[0x00-0x20] %1eaNd%1e'1'='1 查詢數據庫版本，MSSQL 2012 x64 %1eoR%1e1=@@version%1e-- 查詢當前用戶 %1eoR%1e1=user%1e-- 查詢當前用戶是否為dba和db_owner ;if(0=(SelEct%1eis_srvrolemember('sysadmin')))...

0x01 前言 隨機找的個台灣某越科技集團下的站點作為此次測試目標，只是為了學習下內網滲透和MSF的使用。 13年9月份時拿到了一個子域的Webshell權限後就沒再繼續測試了，當時服務器沒有安裝Symantec賽門鐵克，但第二次去測試時發現已安裝了Symantec，並進行了一些安全加固。 0x02 网站和内网的基本信息搜集基本信息探测：目標站點：http://www.ttes*****.com服務器IP：59.***.**.74（台灣省中華電信）環境平台：ASP.NET服務器系統：Microsoft-IIS/6.0（Wind...

前言 前不久的一次授權測試中，感覺缺少任何一步都無法達到getshell的目的,單個漏洞看得話確實平平無奇，但是如果組合起來的話也許會有意想不到的化學效應。 前期测试 拿到這個站的時候一眼就看見了會員登錄界面,一開始想著註冊，但是覺得會員功能應該很少，沒驗證碼啥的，萬一後台管理員也是會員呢那豈不是要是爆破出來了可以去後台嘗試一波。 顯示的是手機號登錄，但是可以嘗試下admin,千萬不要被他的前台迷惑了。很巧的是可以進行用戶名枚舉，而且還存在admin賬號,不爆破都對不起他...

0x00 前言 上面給了個任務，一看，地圖系統，懵逼了，這種的系統一般就是調個百度地圖的api，無交互，想要挖洞簡直難上加難. 一波信息收集後，發現該主站一個功能可以跳轉到該單位的微信公眾號，且存在上傳點，因此有了本文。 0x01 FUZZ 有了上傳點，廢話不多說先看看後綴能不能過 先傳一個圖片，更改後綴嘗試上傳 直接沒了，難道是白名單嗎，嘗試隨意後綴上傳 發現可以上傳，可能是存在waf？ 直接傳內容為一句話，看看會不會被攔截 結果沒被攔截，應該是代碼對後綴做了一些操作， 接下來就是一頓fuzz，搞了半天發現後綴名這邊是過不去了，換行大法直接報錯...

0X01 找到注入点 故事的起因還是因為我太閒了，上班摸魚。 摸著摸著就摸到了某個網站的查詢框。 接著老毛病就犯了，上去就輸入了個1查詢 接著輸入了1’ 嘖嘖嘖，這明顯有SQL注入哇。 果斷掏出SQLMAP神器。 結局很完美，不僅存在註入，還是DBA的權限。 0X02 网站get shell 利用SQL注入去get shell有幾種常見的方法，一種是跑數據，跑目錄找到網站的管理後台，進入到後台想辦法通過文件上傳的等方法去拿shell；要么就通過報錯，phpinfo界面，404界面等一些方式知道網站絕對路徑，然後去寫入shell，不過相對於mysql來說條件還是有些苛刻的。...

0x01 前言 當一個企業把他的業務放到騰訊雲或阿里雲等公有云的時候，其是與企業的內網是不相通的，相當於邏輯隔離了(非物理隔離)，如果企業信息安全做的相對較好，不暴露VPN地址或者路由器或防火牆業務，信息收集的時候，是很難進精准定位到企業的內網使用的公網地址的。這個時候，想要滲透內網相對困難。 下面就介紹一下我從公有云到滲透進內網進行漫遊的實際滲透過程。 0x02 前期打点 怎樣拿下云服務器的不是本文重點，故不做詳細介紹，只簡單介紹思路。 根據公司名字，直接百度，發現官網地址。根據官網地址，進行了一波信息收集：...

前言 最近對雲安全這塊比較感興趣，學了一波k8s的架構和操作，正好遇上了華為雲的這一場比賽，收穫頗多。 (甚至通過非預期拿下了平台題目集群的最高權限)。 0x00 题目入口发现 拿到題目發現是一個類似於提供IaaS服務的站點，掃描了一波目錄，發現幾個文件以及路由: phpinfo.php robots.txt admin/ login/ static/挺奇怪的是，在一個存在phpinfo的環境下發現了一個beego框架後端的403界面： 初步猜測是.php的文件交給了nginx fastcgi進行處理，而其他路由則是交給了beego進行處理。...

首先在奇安信hunter上搜索找到該SRC的有關資產（具體我就不放了），然後通過微步來搜索子域名找到今天的測試站點。 然後利用xray中檢測到該站點存在Shiro反序列化漏洞 於是考慮直接用feihong的反序列話工具，但是這次feihong的反序列化工具只檢測出key，gatget沒有檢測出來，諮詢了同事琛哥後，故考慮到是因為工具很久沒更新，需要找一條CB的鏈，啪的一下回車 直接開衝，先看下系統中是否存在殺毒軟件，一目了然，系統中存在火絨殺毒軟件。 在確定了目標系統存在火絨後我第一時間嘗試了hta上線，相關文章內容：記一次繞過火絨安全提權實戰案例...

0x01 前言 某日閒來無事，上fofa搜了xx系統，想著碰碰運氣，類似這樣 0x02 测试过程 隨便挑了一個站點打開 Em…，試試運氣，反手admin admin就進去了，是一個管理系統 然後根據網站的功能點，隨便點擊幾個，發現除了常規的操作也沒啥了，翻了一會，發現有一個文件下載操作 好傢伙，藏得挺深，抓包看看，請求的地址好像是一個文件 fileName改成./etc/passwd看看，好傢伙，報錯了 看來應該不是這個路徑，隨後依次嘗試了././etc/passwd和./././etc/passwd都是500錯誤，到了././././etc/passwd的時候就能訪問到了...

0x01 站点1：文件上传 发现源代码泄露 打開自己珍藏已久的辣雞字典，掃描發現存在bin.zip信息洩露，嘗試進行代碼審計 文件位置：SimpleDataPlatform.SimpleDataPlatform.fileUpload 找到ProccessRequest接收請求，可以看到獲取了一堆參數後（初始化），後進入了HandleFiles方法， 跟進HandleFiles進行處理，如果dateType=ZBJHSB時，就繼續處理請求，dateType為GET傳參 路徑為/Uploads/SetData/ZBJHSB，str名稱為時間戳，且str2(後綴)沒有進行限制就進行保存，...

0x00 起因 此次接到的項目是對某客戶端進行安全測試。之前的工作內容除了偶爾測測App 之外，大部分的測試目標還是以B/S 架構的Web 為主，這是第一次對C/S 架構的客戶端進行測試，所以也是兩眼一抹黑，只能先按照測Web 的常規思路來了。 0x01 抓包 首先查看目標客戶端是否存在代理配置功能（大多數沒有） 可以看到只有個簡單的登錄功能，並無代理配置功能 Proxifier + BurpSuite 查看BurpSuite 中配置的代理地址及端口 在Proxifier 中添加代理服務器（ip、port 為BurpSuite 中配置的代理地址及端口）...

0x01 弱口令 在一次針對某站點信息收集的過程中，通過子域名掃描，掃描到某個老舊系統。 一看這都2014年的老站了，肯定有搞頭！ 日常使用burp爆破一波試試，沒爆破出來 但是隨手一試，好傢伙123/123進入系統，屬於是運氣拉滿了 （高強度打碼） 這裡能看到是一個“編輯”人員的權限，並沒有什麼上傳等後台管理的功能，只能耐心過一遍系統的各種功能。 0x02 SQL注入 進入系統翻一翻，沒有什麼敏感信息洩露，但是在一處查詢人員信息的接口發現了SQL注入（xray被動掃描掃出來的）...

0x00 漫长的探索 某天，接到一個任務，要求對某醫院的信息系統做一次安全檢測，看能否發現問題。經過初步的信息收集後，發現該醫院並無官網，只有一個微信公眾號提供了預約掛號，繳費等功能，看來只能把突破點放在這個公眾號上了。 下圖是微信公眾號的一些功能： 當點擊這些功能並抓包的時候，令我看到奇怪的是所有的請求都指向了a.test.com這個域名，如下圖，原諒我的厚碼. test.com這個域名經過查找後發現是一家提供醫療信息系統的本地公司,但不解的是為什麼醫院的系統會放到供應商公司去呢？他們是如何進行數據同步的呢？帶著這些問題我開始了對a.test.com這個域名的測試。...