验证码爆破-xp_CAPTCHA挖洞体验

最近在挖生产环境的漏洞,试用了一下xp_CAPTCHA的白嫖版和付费API版,体验其实都挺好的,样本太少就不对比识别准确性了。主要写写安装和使用步骤以及踩过的坑和相应处理方式。

安装踩坑(xp_CAPTCHA白嫖版)

我是java 11.0.13以及python 3.10.7, jar包直接装的java8编译版本无报错通过,但server.py(release里面有)依赖的onnxruntime不支持3.10,所以这里没有办法,下载了作者的打包版,在win机器使用虚拟py 3.6启动(这里也给后面带来了一个小坑,会解释的),作者的打包版见项目readme下方网盘链接。

下载下来之后解压双击.bat文件就可以启动了,任何需要修改的,进Python36文件夹编辑server.py。

因为我尝试爆破的也是一个POST请求,所以主要的操作方式是参照这个链接

这里踩了一些坑:

  1. 80端口被系统占用:解决方法参考链接,(这里也可以选择改成别的端口)
  2. Python requests库报错SSLError: dh key to small():解决方法参考链接,因为我使用的是作者打包的py3.6,所以采用第二种方法,加入语句requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS = 'DEFAULT:@SECLEVEL=1'降级。

所以我最终使用的test脚本是这样的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#coding:utf-8
from flask import Flask
import requests
requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS = 'DEFAULT:@SECLEVEL=1'

app = Flask(__name__)

@app.route("/")
def get_captcha():
burp0_url = "https://xxx/getVerificationCode"
burp0_headers = {"Cookie":"xxxxx","Sec-Ch-Ua": "\" Not A;Brand\";v=\"99\", \"Chromium\";v=\"99\", \"Google Chrome\";v=\"99\"", "Accept": "application/json, text/plain, */*", "Sec-Ch-Ua-Mobile": "?0", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36", "Sec-Ch-Ua-Platform": "\"Windows\"","Sec-Fetch-Site": "cross-site", "Sec-Fetch-Mode": "cors", "Sec-Fetch-Dest": "empty", "Accept-Encoding": "gzip, deflate", "Accept-Language": "zh-CN,zh;q=0.9", "Connection": "close"}
requ = requests.post(burp0_url, headers=burp0_headers, verify = False)
print(requ.text)
return requ.text

if __name__ == "__main__":
app.run(host='0.0.0.0', port=6666, debug=True)

使用踩坑

这里踩坑主要是对抗资产本身的一些校验机制,譬如我遇到的是请求验证码的Cookie(放在test.py的header里)要和请求登录的包内cookie保持一致,不然可以识别到验证码但请求登录时还是提示验证码错误。

高级用法同样参考上述这个链接和作者的readme后半部分高级用法指引。

Logseq使用体验

初见

之前一直在整理自己的知识库,在尝试过不少笔记软件之后确定了自己的需求:能自主同步到github存储、支持markdown、支持知识库结构、支持win和Linux系统、功能丰富插件市场好

当时选择的是VScode+各种插件支持的方案,在磨合过程中也逐渐形成了自己惯用的插件和自定义配置,但涉及交叉领域的笔记时仍会经常头疼如何分类、放在哪个文件夹更合适、文件夹结构如何调整、分类后如何快速找到。

尽管我已经相当科学的使用了类图书馆索引的方式来构建排序我的文件夹结构,但我经常对分类情况不太满意。当然,这其实算是文件夹体系的一个共同缺陷,所以一直有在找更好的解决方案。

后来接触到了Logseq,最吸引我的大概就是双链笔记号称的无压分类,以及分类细粒度更高的特点(当然它也比较完善的符合了我的需求)。

到目前已经使用了2个月,也算是过了磨合期,配置和插件选择都相对稳定了下来。所以简单的来讲一讲体验。

踩坑

Logseq对我这个一直用惯了传统文件夹体系的人来说,一开始上手还是比较迷茫的。什么是‘块’?什么又是‘页’?为什么没有文件夹和目录?如何才能直观的看到我所有的笔记、确定我之后还可以找回它的位置?

而且由于Logseq的特性,原本markdown的内容直接拖进来会搞的一团糟,在翻阅各类使用说明和前人的使用方式后,我决定把以前的内容放一放,先在logseq写新笔记,用到某些旧笔记内容时再迁移内容,给自己减轻一些迁移压力。

logseq的体系,与以前的不太一样,但如果不需要精细化的使用,实际上也不会做太多的改变。一开始还会纠结,几段连续的内容,到底要不要合并到同一个‘块’方便管理,后来就直接回车,一句话一‘块’都没关系,省时省力,基本也不会想要回来重新梳理合并。一开始会觉得一边记markdown的结构另一边还要关注新‘块’的缩进位置太过麻烦,后来就干脆放弃了纯md的结构,只在想要强调或者需要整理输出时简单用md装饰一下标题。而且如果实在懒,可以完全不用缩进,把所有内容都摊在第一级、把样例、注释等可能更需要隐藏起来的内容放在第二级也没关系(需要迁移的时候再去改缩进就好啦)。

在写笔记的过程中,也在不断的适应着新的体系,在前人的使用习惯上做一些自己的优化。看着现在的内容逐渐增多,还是小有成就感的。

logseq生成的体系图

优化

logseq本身还在Beta测试阶段,功能丰富度相对欠缺,会有一些bug时不时的冒出来(譬如我经常丢失插件的加载状态需要手动重开插件),好在开发团队和社区十分高效。对我这种热爱折腾的人来说,基本是可以接受的。

顺便介绍一下我目前稳定使用的插件。

  1. Heading level shortcuts,快捷键设置md标题级别和格式。对频繁使用md标题的人来说还是值得一用,稍微精简了操作。
  2. Doc View Exporter, 生成HTML方便在浏览器上导出为pdf。目前在logseq中使用体验最好的导出pdf插件,美中不足的是对过长的内容生成HTML时会丢掉最下方内容,以及需要在导出前手动将所有折叠块展开,不然也无法导出被折叠的内容,希望后续官方开发团队能支持适配度更好的pdf导出和markdown导出。
  3. Todo list,全局收集所有的to-do内容。使用起来非常方便,to-do随便扔在哪里都可以一键完成。
  4. Awesome Styler,自定义背景,支持背景图片。一开始我很喜欢用它搞一些花里忽哨的背景,后来逐渐简洁了起来。目前主要用它做一些显示颜色的微调。
  5. Bullet Threading,在原版的基础上加深了当前块的结构引导线。方便定位当前块的层级,是我不能没有的东西。
  6. Tabs,使用tab展示多个页面,方便切换。是我不能没有的插件,但tab开多了显示会卡,毕竟不是官方功能。
  7. Block to page,把整块转成页面。使用频率很高,适合一些随便写写积累多了之后导出成单独页面的需求。
  8. TOC Generator,目录生成。目前会将它结合右侧Contents做成一个伪文件夹的目录形式,方便索引。
  9. Git,实现内容同步到git项目。是我的必需插件,在按照个人习惯调配好之后非常好的满足了我的同步需求。
  10. Char Spacing,盘古之白吧算是。为了美观非常有必要。
  11. Randow Notes,笔记随机漫游。在笔记很多了之后,随机漫游是一种很方便整理复习笔记的方式,压力也不会太大。还有一个同款是以块的维度漫游,个人没什么需求。

展望

logseq目前对我来说算是很好的完成了知识收纳的目的,缓解了我的分类焦虑。但实际的知识调用、临时查阅能否满足需求,尚未进行高强度的测试(指的是OSCP考试那种现场查并粘贴复制POC的场景)。但再差也不会差到哪里去,logseq的查询功能响应还是挺快的。

可能需要担忧的是从logseq整个迁移出去时,由于logseq并不完全适配md导致需要大量整理格式的问题。但好在目前没什么压力会迫使我考虑再次迁移知识库,即便logseq现在停止更新,当前内容也足够支持我做好知识管理。

据说logseq或者说双链笔记的所谓“海平面下的冰山”是它的unlinked ref,也就是未引用当前page但提及了page标题的内容,意味着潜在的知识关联。虽然我已经有所了解,但它可能还需要一些插件or功能的支持(譬如一些模糊匹配、一些明显的标记、或者一种全新的漫游笔记方式),并且,也需要更好的定义page标题。

至于是否推荐logseq,功能特性、测评、优缺点有很多人做了很多,不再赘述。如果是像我一样有构建知识库需求、又涉及了很多交叉领域知识的分类焦虑,那么尝试一种新的笔记方式未尝不可。

Chatgpt翻译外文书籍初体验

很喜欢的番剧5月马上要出新剧情,为了方便挖掘细枝末节推理剧情走向,我从Kobo买了之前第三季的小说。实际上这是个原创番,先有动画版再有小说版。但据考究党所言,小说里有一些动画删减的内容和补充,所以还是兴冲冲买了下来。当然我并看不懂日文,冷门番也不好找新小说的译文。于是,尝试了一下使用Chatgpt来翻译小说,算是尝试着积累一些对新玩意的体验。

使用的是python3 开源项目bilingual_book_maker,感谢作者。

当前(23.3.27)支持epub和TXT较好,pdf支持稍差。支持多种翻译api,包括Chatgpt api的gpt3 和gpt3.5(默认)、Deepl、彩云小译。暂不支持非API版本的Chatgpt free或者Chatgpt plus,易风控。

如何使用

我使用了Chatgpt api免费版,主要是还有$18余额没有过期。

首先挂好代理,登录chatgpt api平台获取你的api key,注意这个key跟github一样,生成后只给你展示一次,如果忘了就要新建一个key。

clone项目,pip安装依赖。

具体使用命令参考项目说明,我这里用的是python3 make_book.py --book_name test_books/xxx.epub --openai_key [你刚才申请的key] ,默认翻译为简中所以可以不用配置。

使用体验

实际成本

总共3本日文小说,目前已经完整的翻译了一本,原文187K字,费时5.5个小时,用了$1.1,共3652个请求。(如下图)

image.png

从成本上来说,还是十分划算的。

翻译效果

简单截开头一页示范一下效果。(首先声明这是我自己为了方便阅读操作的,购买正版小说,仅自用,不会传播)

image.png

翻译的时候也可以选择不输出原文,但我认为原文一定有翻译无法明确表达的感觉,所以保留了原文。

可以看到内容是通顺的。当然实际还是会发现一些问题。比如一系(的)执行官被翻译成了一名执行官。但好在我对这部作品整体设定比较熟悉,阅读时可以接受一些失误。

同样,因为脚本是按照段落,一段一段的去发送翻译请求。所以对于这种几个字就分段的日式小说风格来说,请求量还是相对较多的,也会对耗时产生影响。

可能的优化项

在翻阅大家提的issues时,也发现了一些当前chatgpt翻译的问题,比如说上下文之间人名对不上(在日文小说里倒是还好,英文小说可能更严重一些),据说修改prompt可以优化。

现在单线程翻译很慢,脚本pr已经支持了多线程配置,但目前开发者测试下来还相当不稳定(主要是api暂时不那么支持多线程),所以并不推荐。

如果经常使用且自己有翻译功底可以比较清晰的明白AI译文的失误在哪里的话,应该可以调整prompt来优化译文。我自己并不常用所以暂时还是使用默认配置的prompt了。

Reference

bilingual_book_maker
Kobo电子书转换epub
adobe digital editions 4.5.11 installers
ebook conventer

服务网格学习笔记

现状-我们为什么需要服务网格

Kubernetes是一种开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。它可以帮助开发人员和运维团队快速、可靠地构建、部署和管理大规模容器化应用程序,同时提供负载均衡、自动伸缩、自我修复等功能,从而实现高可用性和弹性。Kubernetes最初由Google开发,并于2014年开源发布。成为主流容器编排架构,其本身就是按照云原生的理念来设计,将单体应用拆分微服务。
但随着微服务 数量增多,为了解决微服务管理,避免繁琐的服务发现、监控、分布式追踪等事务,服务网格应运而生。
相比而言,K8S关注的是应用的生命周期,它管理的对象是资源和部署,对于服务的管控力度很小。而服务网格正好弥补了这个缺陷。服务网格可以连接、控制、观察和保护微服务。
image.png
从图中我们可以看到 kube-proxy 的设置是全局的,无法对每个服务进行细粒度的控制,Kubernetes 可以做的只有拓扑感知路由、将流量就近路由,为 Pod 设置进出站的网络策略。
而服务网格通过 Sidecar 的方式将 Kubernetes 中的流量控制从服务层中抽离出来,为每个 Pod 中注入代理,并通过一个控制平面来操控这些分布式代理。这样可以实现更大的弹性。
*CNI:容器网络接口。

基础知识

什么是Service Mesh

服务网格(Service Mesh)是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中,Service Mesh 通常以轻量级网络代理阵列的形式实现,这些代理与应用程序代码部署在一起,对应用程序来说无需感知代理的存在。

Service Mesh 架构图
Service Mesh 作为 sidecar 运行,对应用程序来说是透明,所有应用程序间的流量都会通过它,所以对应用程序流量的控制都可以在 service mesh 中实现。

Service Mesh的特点

应用程序间通信的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现
对于编写应用程序来说一般无须关心 TCP/IP 这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情
目前两款流行的 Service Mesh 开源软件 IstioLinkerd都可以直接在 Kubernetes 中集成,其中 Linkerd 已经成为 CNCF 中的项目。

工作流程(以Istio为例)

Sidecar(Istio 中使用 Envoy作为 sidecar 代理)将服务请求路由到目的地址,根据请求中的参数判断是到生产环境、测试环境还是 staging 环境中的服务(服务可能同时部署在这三个环境中),是路由到本地环境还是公有云环境?所有的这些路由信息可以动态配置,可以是全局配置也可以为某些服务单独配置。这些配置是由服务网格的控制平面推送给各个sidecar 的,
当 sidecar 确认了目的地址后,将流量发送到相应服务发现端点,在 Kubernetes 中是 service,然后 service 会将服务转发给后端的实例。
Sidecar 根据它观测到最近请求的延迟时间,选择出所有应用程序的实例中响应最快的实例。
Sidecar 将请求发送给该实例,同时记录响应类型和延迟数据。
如果该实例挂了、不响应了或者进程不工作了,sidecar 会将把请求发送到其他实例上重试。
如果该实例持续返回 error,sidecar 会将该实例从负载均衡池中移除,稍后再周期性得重试。
如果请求的截止时间已过,sidecar 主动标记该请求为失败,而不是再次尝试添加负载。
Sidecar 以 metric 和分布式追踪的形式捕获上述行为的各个方面,这些追踪信息将发送到集中 metric 系统。

主要功能

流量控制:流控是最主要也是最重要的功能,通过 Service Mesh,我们可以为应用提供智能路由(蓝绿部署、金丝雀发布、A/B test)、超时重试、熔断、故障注入、流量镜像等各种控制能力
安全:在安全层面上,授权和身份认证也可以托管给 Service Mesh
策略:可以为流量设置配额、黑白名单等策略
可观察性:服务的可观察性一般是通过指标数据、日志、追踪三个方式展现的,目前的 Service Mesh 产品可以很容易和和主流的后端设施整合,提供给应用系统完整的监控能力

优点

屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等),服务只用关注业务逻辑
真正的语言无关,服务可以用任何语言编写,只需和 Service Mesh 通信即可
对应用透明,Service Mesh 组件可以单独升级

缺点

增加的复杂性: 在一个已经很复杂的环境中引入代理、sidecar 和其他组件会极大地增加开发和运维的复杂性
需要的专业知识: 在容器编排服务(k8s)之上添加 Istio 之类的服务网格要求运维人员足够熟悉这两种服务
延迟: 服务网格是一种入侵的、复杂的技术,它能向服务架构中添加显著的延迟
平台的依赖性: 服务网格的侵入性迫使开发人员和运维人员适应一个高度自治的平台,并遵守其规则(现存的服务迁移足够让开发咬牙切齿!)

适用场景

服务治理与业务逻辑解耦

在运行时,SDK 和业务应用的代码是混合在一个进程中运行的,耦合度非常高,会产生如下问题:
升级成本高:每次升级都需要业务应用修改 SDK 版本号,重新发布。在业务飞速发展的时候,更倾向于专注业务,不希望分散精力做升级等事情。
版本碎片化严重:由于升级成本高,但中间件还是会向前发展,久而久之,就会导致线上 SDK 版本各不统一、能力参差不齐,造成很难统一治理。
中间件演进困难:由于版本碎片化严重,导致中间件向前演进过程中需要兼容各种老版本的逻辑,无法实现快速迭代。
使用 Service Mesh 后,您可以将 SDK 中的大部分能力从应用中剥离拆解为独立进程,以 Sidecar 的模式部署。通过将服务治理能力下沉到基础设施,可以让业务更加专注于业务逻辑,中间件团队则更加专注于各种通用能力,真正实现独立演进、透明升级,提升整体效率。

多语言、多协议支持

随着新技术的发展和人员更替,在同一家公司中往往会出现使用各种不同语言、不同框架的应用和服务,为了能够统一管控这些服务,以往的做法是为每种语言、每种框架都重新开发一套完整的 SDK,维护成本非常高,而且对中间件团队的人员结构也带来了很大的挑战。
有了服务网格之后,通过将主体的服务治理能力下沉到基础设施,多语言的支持就轻松很多了,只需要提供一个非常轻量的 SDK,甚至很多情况都不需要一个单独的 SDK,就可以方便地实现多语言、多协议的统一流量管控、监控等治理需求。

云原生架构转型助力

从单体应用到微服务架构改造以及全面容器化的云原生架构基础往往带来很高的改造成本。SOFAStack 服务网格可以满足未容器化的虚拟机部署方案,也可以兼容过渡阶段的部分容器化和虚拟化混合部署的场景,加速企业云原生架构转型。

金融场景网络安全

当前很多公司的微服务体系建设都建立在内网可信的假设之上,然而这个原则在当前大规模上云的背景下可能显得有点不合时宜,尤其是涉及到一些金融场景的时候。
通过服务网格可以更方便地实现应用的身份标识和访问控制,辅之以数据加密,就能实现全链路可信,从而使得服务可以运行于零信任网络中,提升整体安全水位。

未来发展方向

让 Istio 适用于一切环境和一切工作负载
当前痛点:基础设施向容器化、云原生转型,存在多集群的容器、虚拟机并存的复杂环境。
未来解决方案:需要改造Istio,在其之上增加一层,用于集群管理,并在每个集群中部署一个网关,统一连接到一个边缘代理,让所有的集群互联。这也是 Tetrate Service Bridge 的产品理念
API 网关与服务网格的融合
API网关、反向代理和服务网格的融合产品。

参考资料

什么是 Service Mesh(服务网格)?
Pattern: Service Mesh
What’s a service mesh?
阿里云 - 服务网格 - 应用场景
服务网格现状之我见
我为啥不看好 ServiceMesh
不是所有的应用都需要 ServiceMesh 架构
服务网格对比API网关

扩展阅读

云原生社区-国内最大的独立第三方云原生社区
云原生资料库
《深入理解Istio:云原生服务网格进阶实战》

一次差点翻车的kali v2raya版本更新经历

事情的起因是这样的,我在公司和家里各有一个kali虚拟机,很多新工具骚操作都是先在公司机上跑过觉得好用再回家搞一遍。
由于一些历史原因,我的kali装了v2raya做代理之后并没有跟随apt-get一起更新版本,所以跑了很久的1.5版本。后来发现2.x版本有了负载均衡加上一些其它优化,比较心动,遂更新了一遍,没想到第二遍在家做的时候险些翻车。

正常的更新路线大抵是这样的:参考官方文档,由于我不打算跟随最新版本一起更新,所以使用的是下载deb安装包的方式更新。以下是正确的操作步骤:

  1. 下载最新deb安装包
  2. 使用官方推荐脚本更新xray-core curl -Ls https://mirrors.v2raya.org/go.sh | sudo bash
  3. apt安装deb包

但是,因为一些失误,我这里是先更新了v2raya版本没有更新xray-core,导致新版本v2raya无法运行,报错core版本低。也就是说,我翻不了墙,除非更新core版本,但官方脚本又要翻墙运行。。。

当然,这里其实还是尝试了用物理机直接下好core包丢进虚拟机,但由于众所周知的vmtools兼容性问题,这里丢不进来,哈哈哈(以及送给大家一个我平时用着挺好但今天没能解决问题的激活vmtools的方式:控制台直接输入/usr/bin/vmware-user

vmtools的问题晚点再说,我又换了一个思路,如果你有看过我之前发的内容,那么你会知道我的物理机-windows是用了clash for windows(很遗憾,是没有tun模式的老版本)。那么如何让clash for windows代理我的kali虚拟机流量呢?

闲言少叙,我还要赶紧睡觉,总之,clash开启allow LAN选项,物理机端打开控制台获取对外网卡IP,虚拟机网络配置不确定有没有影响,我这里是保持桥接。clash如果没有更改过端口的话应该是默认7890。(当然如果你是有tun模式的clash好像是可以直接开启就行)

这样我们就拿到了proxy的地址:物理机ip:7890

虚拟机端配网页访问比较简单,不清楚的可以看ref第一个链接。控制台有两种方式,一种是配置bash的proxy,也是同样在ref第一个链接(我印象里这部分内容我之前搞clash for kali的时候踩过坑,需要手动配置的项目有很多,不只是配bash proxy就可以的,感兴趣的可以看另外那篇文章,因为我不是希望永久使用物理机clash来代理虚拟机流量所以我不折腾配置)

另一种配置控制台的方式就是用kali自带的proxychains4。

sudo权限编辑proxychains4配置sudo vi /etc/proxychains4.conf ,在最后一行添加socks5 物理机ip 7890,保存关闭。

然后以proxychains运行我们想要的更新core脚本:proxychains curl -Ls https://mirrors.v2raya.org/go.sh | sudo proxychains bash,注意这里因为有个管道符,所以应该在管道符前后两个命令都加上proxychains,以及后面的命令是sudo在前proxychains在后。

于是成功利用物理机clash作为代理更新好了core版本,虚拟机又可以快乐起来了!

ref:

  1. https://www.ngui.cc/article/show-586553.html?action=onClick
  2. https://blog.csdn.net/weixin_68281676/article/details/125477791#:~:text=%E9%85%8D%E7%BD%AE%20%E6%96%87%E4%BB%B6%E8%B7%AF%E5%BE%84%E4%B8%BA%EF%BC%9A%2Fetc%2F%20proxychains.conf%EF%BC%8C%E5%B0%86%E6%96%87%E4%BB%B6%E6%8B%89%E5%80%92%E6%9C%80%E5%BA%95%E9%83%A8%E3%80%82%20proxychains,%E8%BF%90%E8%A1%8C%E6%96%B9%E6%B3%95%EF%BC%9A%20proxychains%20%2B%20%E7%A8%8B%E5%BA%8F%E3%80%82

blog重构啦!

Hello everybody!

趁着开工不太忙,我把手里的各种笔记整理了一下,准备整合成一个知识库。同样,也重新审视了一下现有的内容,做了一些调整。

之所以很长一段时间没有更新blog,主要是因为一部分笔记没有脱敏处理就没放上来,其次就是某些特定主题的内容,被我直接做成了一个git项目放在了主页。

我思考了一下我对这个博客的定位,决定把它做成一个更加偏向整合所学->思考总结->产出的地方,不只是安全相关。东一块西一块的产出也造成过一些分类定义焦虑,所以之后会不断的做一些整合修整。

啊顺便说一下22年的一些总结吧。

工作上我自己最喜欢的部分是做了一些风险收敛的研究,写了一些非常落地的风险收敛解决方案。这些内容让我很惊讶的发现了甲方安全运营角度和乙方攻击视角的不同,安全运营最头疼的其实不是‘如何修复漏洞’,而是‘当前修复方案在实际情况中存在一些不对等/无法实现时,如何平衡成本、是否需要修改缓解措施、如何缓解处理效果更好’+‘如何更好更具有性价比的在全部资产上收敛风险’。

在技术上的提升,主要是作为红队实施了一些攻防项目,OSCP虽然没考过但确实学到了很多东西。(啊短时间之内应该不会再考了吧

说到OSCP,在ddl的高压之下,也被迫阅读了不少关于自我提升主题的书籍,实际地应用了一些技巧和思路;尝试了很多个todo APP,终于找到了目前我比较喜欢的一个;尝试了很多种记笔记的方式以及应用,目前也算是找到了最舒适的应用,配置了非常多自定义插件和快捷键调整。

再来说关于23年的。。。展望?

技术上主要方向会是做一些云安全的了解,从攻击技术拓展到安全运营。另外也会看一些数据安全的内容,总之目的都是做安全运营。

除去以上,休闲时间应该会养成并保持定期打HTB的习惯,算是一些复健活动并且我真的非常想过OSCP

再休闲一些的活动就是读书啦,微信读书22年读了10本,今年目前已经读完2本了,超越去年记录指日可待。以及22年底开始从中图网买纸质书,会放在床头睡前读一段,比较助眠。

游戏的话,steam打折买的巫师3还没动,今年还有王国之泪要玩。

就是这样啦,新年快乐!

在kali上安装clash/V2raya的教程

19年写过的东西了,当时被小管家gank文章无了,好在还有备份。这次更新V2raya的时候正好放上来,给自己一个安装指导。

然后,本文仅提供Clash和V2raya的Kali系统对比和安装教程(因为Win的要简单多了)。

先把结论放在最前面,Clash的优点是可以自动切换IP,v2raya要手动切,但个人使用之后感觉Linux端Clash真心不如V2raya,不过win端Clash的舒适度大于V2raya。我自己经过反复踩雷之后选择Kali虚拟机用V2raya,主机Windows用Clash。

当然,Clash的win端想要开全局代理把运行Kali的虚拟机流量代理起来又是另一个很头秃的问题,毕竟Clash创造出来的本意似乎并不是服务于更好的全局代,我至今没能找到简单又完美的开局办法(也可能因为我妥协了换成V2raya for Linux)。

V2ray for win可以直接全局代理搞定虚拟机,但是配置要比Clash麻烦一些。而且出于各种需求,我还是倾向于给Kali自己开代理,主机端就不需要一直开着代理用了。

但从安装在Kali的体验来说,V2raya更适合像我一样,经常从github下个脚本跑的人,毕竟Clash的全局代额外使用了脚本之后在kali控制台内体验仍然不好(再次羡慕Ubuntu的网络全局配置),使用Clash的话往往需要加一条 –proxy x.x.x.x:xxx,还容易不好使。Kali虽然自带proxychains,但一个是配置起来麻烦,另一个是如果用的机场,可能需要多次的手动调整配置文件。

先写Clash,V2raya在下面。

Clash:

下载合适的版本,我在kali2021上用的是clash-linux-amd64-v1.6.0.gz。

解压gzip -d clash-linux-amd64-v1.6.0.gz

(注意修改版本号,改成你自己下载的版本)
给个权限
sudo chmod +x ./clash-linux-amd64-v1.6.0
,这里想把文件名简化一下也可以。(再次注意clash的文件名可能需要改动成你自己拥有的)

运行
./clash-linux-amd64-v1.6.0
, 注意Clash默认每次开机后需要手动开启,也就是该命令每次开机你都需要跑一下。

然后路径
/home/用户名/.config/clash
下会有自动生成的配置文件,没有.config文件的去view里打开show hidden file。(用户名是你自己设置的啊,会不一样)

这里的两个配置文件要更换,如果你的XXX服务商没有提供配置文件,建议win下装个Clash,配好了再把配置文件拿过来,反正win端Clash也挺好用的,装个不亏。

config.yaml:从win端路径C:\Users\用户名.config\clash\profiles拿到一个多半是数字.yml格式的yaml文件,改名成config.yaml,丢进/home/kali/.config/clash替换原文件。(注意这个yml和yaml的区别)

Country.mmdb:从win端路径C:\Users\用户名.config\clash下拿到Country.mmdb,丢进/home/kali/.config/clash替换原文件。(Users在中文版win里面是用户,用户名就是你的账户名字啦)

重新运行
./clash-linux-amd64-v1.6.0
(不需要sudo),打开浏览器访问
http://clash.razord.top/#/proxies
看Clash配置,浏览器端口设置HTTP:127.0.0.1:7890, SSL:127.0.0.1:7890, SOCKS_v5:127.0.0.1:7891(preference->network settings,新版本似乎已经统一到127.0.0.1:7890了,socks_v5要改成7890,具体要看运行clash时候控制台显示什么),访问外网确定能使。(运行clash的terminal不要关,关了就结束运行了)

那么到这里,问题来了,目前的配置能让你的Kali浏览器访问外网,Clash的作用仅仅是帮你在127.0.0.1:7890开了一个代理通道,但除了浏览器以外的流量想要指向代理就得自己设置。这可就有名堂了,比如控制台、环境变量、apt源、npm源、docker,这些都要自行配置指向代理通道。

如果是造轮子达人可以写个自定义脚本,我等渣渣还是优先找别人的轮子了,指路himanshub16/ProxyMan,一键配置(运行不需要sudo),这个脚本有一处难点,就是它原本是写给linux用,所以kali有些环境变量路径不适配,需要切换至bash让脚本自行适配环境变量再切回来,具体操作为:
控制台
exec bash
进入bash模式,
source ~/.bashrc
更改bashrc配置,安装ProxyMan脚本
./install
,配置生效后
exec zsh
回到zsh模式,
proxyman set
设置一键配置端口。 (这里有不会用的实在解决不了的再来问我吧,容易遇到的问题种类比较多,具体问题具体分析)

但以上仅能保证脚本内提及的各种控制台、apt源、npm源等一键配置代理,其它你会用到的临时项目都要手动指向代理通道,或者自己手动添加进配置文件or脚本。(或许也有更好的解决办法但是我还是选择v2raya)

V2raya:

Linux版建议使用v2rayA/v2rayA,比直接上原生V2ray好使。

安装方法指路官方文档,照着搞。

v2raya默认开机自启动,省心省力。(注意!现在的1.5.x版本已经不支持默认开机自启动,也不支持软件源更新时自动更新版本了,具体命令去这里看)

访问http://localhost:2017/,导入你的XXX服务商生成的配置文件,记得把全局透明代理打开。

设置不会改的就保持默认,我自己开了DNS防劫持(有的时候会出现一些连不上的情况,如果排除是订阅源的问题,我会重新开关一下DNS防劫持)。

总结:写的很稀碎并不保姆,累了(划掉)

之所以大费周张地写了很多Clash内容,只是因为相对来说Clash for Kali的教程还是很少,官方文档也是云里雾里,而且也基本没人提新版本的Kali网络配置没有了全局代理,要么能打开谷歌就算胜利,要么旧版Kali教程来回搬运。偶尔有提到Clash for Linux的,也是打开配置文件挨个手动更改配置代理,这很不cool。

虽然我仍然推荐V2rayA,但或许会有人有一天用的上这些内容。

现阶段对blog的规划思考

难得有时间,想整理一下现在的东西。
我见过的一些blog,似乎更加的“有人情味”。
或者,每一篇是完整的,发出即完成,符合RSS订阅人的需求。
有想过,要不要把这些内容迁移出去当知识库,但想了想,如果blog不能作为我自己的知识库来用,那似乎我也用不太上它。
我的地盘即我的规则,还是就这样吧。
但最一开始的那些从hunter-book收集来的东西,没准要再整理,去符合我自己的一些阅读习惯(主要是纯英文tab不方便阅读,英文特性如此)。
也有在私下离线写一些东西,等着完整地发出来。
也会想着去写一些更加有“情感波动”的东西出来,比如现在这个。
不过更多的时候没有太多值得沉淀的“感情类”文字,有的只是不停的思考。

偶然学到的渗透小tips

(人菜就要多学习)

简单套路

  1. 当请求为数据更新操作(添加、删除、修改等),且请求包没添加(或可绕过)Referer来源地址、随机CSRF-token时,考虑CSRF/XSRF攻击(burp自动生成payload)
  2. 上传位置可以尝试上传html,验证有无html解析(毕竟万年碰不到一个能传马的点了!),危害为钓鱼、挂马、挂黑页等。
    1
    2
    3
    4
    5
    <html>
    <body>
    <script>alert(1)</script>
    </body>
    </html>
  3. 测越权,burp插件携带权限cookie批量请求值得拥有(实现该功能的插件很多,比如Autorize)。
  4. JS经常泄漏各种API接口(找链接: https://github.com/Threezh1/JSFinder ,也有非链接需要自己构造包含函数名称及参数的数据包的JS,被动搜索浏览器插件: https://github.com/momosecurity/FindSomething )。
  5. 链接里带有URL的点可以试试改成任意URL测重定向(大概算是依靠链接前半部分造成链接可信任,结合短链接等伪装手法,重定向钓鱼)。

骚操作

APP

  1. 逆向分析YYDS!
  2. APP脱壳找证书,放进抓包工具反编译流量(适用于流量内容不可见的情况,具体教程找找看)。
  3. adb logcat >> x.txt输出本地日志,可能包含本机用户使用APP时输入的敏感信息。
  4. 快速并发数据包,可以实现批量发送短信、刷赞等。(burp-turbo)
  5. 将拦截的响应包内容从fail改为success可以实现验证码绕过等(是原理清楚但从来没改过响应包的我),证明校验为前端校验。
  6. Activity劫持(涉及安卓端命令调用了,目测是比较冷门可挖的)。
  7. LaunchAnyWhere (https://chan-shaw.github.io/2020/04/12/LaunchAnyWhere%E7%BB%95%E8%BF%87%E5%8E%9F%E7%90%86/)
  8. (这是一条防御办法)当APP做证书绑定后,可以在被抓包时不发送业务请求(但据说有办法仍然实现抓包)。
    1. 确认有效的绕过办法1:VirtualXposed + JustTrustMe,已验证可绕过防抓包加固,使用VirtualXposed是否可以绕过防root加固,目前没有样本,暂时未知。
  9. 以下是奇怪的root后替换人脸数据的工具:
    1. Magisk https://github.com/topjohnwu/Magisk
    2. Riru https://github.com/RikkaApps/Riru
    3. LSPosed https://github.com/LSPosed/LSPosed
    4. virtualcam https://github.com/w2016561536/android_virtual_cam

小程序

  1. 发送请求参数被加密时,可解包找公钥。(这怕是不太能防?还是说果然RSA/RSA2不靠谱?)
  2. 绕过批量发送限制:在参数末尾每次多加一个对整体无作用的+(猜测只有当参数在请求末端可行?)。
  3. 测批量时,不仅可以考虑本网站用户的手机号被批量的问题,也可以加上非注册用户手机号实现批量轰炸的情况(扩大漏洞影响)。

Web

  1. api接口无法直接访问时(如swagger),把脚本配置文件(如dirsearch)的host改成网站IP。
  2. 注意邮件、短信等携带的链接、短链接内容,可能存在参数可枚举的问题。
  3. 必应、雅虎、搜狗、谷歌、etc,没准就有一个可以搜到奇怪的带权限链接。
  4. 地址接口
    1
    2
    3
    4
    5
    /fonts/
    /pdf/
    /js/
    /css/
    /img/
  5. 浏览器开插件模拟手机端。
  6. 在线客服处总容易出现奇怪的越权/敏感信息泄漏。
  7. 抓包改发送的邮件内容搞钓鱼(有意思的思路)。
  8. HTTP请求走私(看来还是该多打CTF)
  9. ip/a/b 会强制跳转到登录口,但ip/a/c不会,则使用ip/a/c/../b绕过跳转。访问xx.jsp会强制转到访问aa.jsp,访问aa.jsp/../../(../多个)/xx.jsp实现绕过过滤。
  10. 查询参数留空,可能会出现一次性相应所有查询内容的问题。(遇到过几次,和同事讨论过,大概是因为留空自动从where里排除了,导致全量查询。算是平时比较难去想到和测试的点。)
  11. LDAP 未授权访问 (相比于危害来说,利用未免太过轻松。。。)
  12. HOST碰撞(利用难度低,危害高,技术较新)
  13. API接口服务漏洞,关键词wsdl
  14. 分块传输 bypass waf/ waf缓冲区溢出
  15. dirsearch与burp的简单联动,利用burp的proxy发送请求。但经过与dirsearch作者的讨论,目前dirsearch并不能支持与burp很紧密的联动(指从burp实时获取扫描目录等),有见过导出burp目录给dirsearch做扫描的插件,但与我理想中的实时扫描二级/多级目录下敏感目录的功能不太相符。
    1
    python3 dirsearch.py -u http://whateveraa.test -w $HOME/Desktop/pentest/SecLists/Discovery/Web-Content/merged-no-duplicates.txt -e php -x 301,400,403 --proxy http://127.0.0.1:8080

IOT

  1. MQTT协议越权/未授权

记录一下看到过的burp插件

  1. JSON Decoder 解码JSON(新burp不是可以直接美化json?)
  2. MarkINFO (https://github.com/UUUUnotfound/BurpSuite-Extender-MarkInfo) 高亮敏感信息
  3. highlighter-and-extractor
  4. APIKit (https://github.com/API-Security/APIKit)
  5. BurpCrypto
  6. BurpDomain (https://github.com/404SEC/BurpDomain)
  7. turbo
  8. Logger++
  9. Bypass WAF
  10. JSON Web Tokens
  11. lazyCSRF https://github.com/tkmru/lazyCSRF/releases/
  12. ActiveScan++
  13. LinkFinder

记录一下其他脚本工具

  1. reverse-sourcemap 还原jsmap (可以用curl命令对付不能直接下载的js.map文件)
  2. wxappUnpacker
  3. 微信小程序加解密脚本:http://82.156.16.24/index.php/2021/05/26/4.html
  4. HOST碰撞 https://github.com/fofapro/Hosts_scan
  5. fiddler(虽然不是脚本工具但是有看到某个大佬用这个抓包,可能有特别之处)

note_JAVA代码审计-入门篇

第1章 初识JAVA代码审计

第2章 代码审计环境搭建

  1. 使用环境:JAVA JDK、Docker、Vulhub、IntelliJ IDEA(远程调试)、VMware、Maven

第3章 代码审计辅助工具简介

  1. 代码编辑器:Sublime、IDEA、Eclipse
  2. 测试工具:Burp Suite、SwitchyOmega、Max HackerBar、Postman、Postwoman、Tamper Data、Ysoserial、Marshalsec、MySQL监视工具、Beyond Compare
  3. 反编译工具:JD-GUI、FernFLower、CFR、IntelliJ IDEA
  4. JAVA代码静态扫描工具:Fortify、VCG、FindBugs与FindSecBugs插件、SpotBugs
  5. 公开漏洞查找平台:CVE、NVD、CNVD、CNNVD

Java EE基础知识

Java EE

Java EE常用核心技术

  1. Java 数据库连接 (JDBC):用于规范客户端程序如何访问数据库的应用程序接口。
  2. Java 命名和目录接口(JNDI):Java的一个目录服务应用程序界面(API),将服务名称和对象关联起来,从而使开发可以用名称来访问对象。
  3. 企业级JavaBean(EJB):用来构筑企业级应用的、在服务端可被管理的组件。
  4. 远程方法调用(RMI):是Java的一组用户开发分布式应用程序的API,增强Java开发分布式应用的能力。
  5. Servlet:是使用Java编写的服务端程序,狭义的Servlet指Java语言实现的一个接口,广义上指任何实现该Servlet接口的类。主要功能在于交互式地浏览和修改数据,生成动态内容。
  6. JSP(JavaServer Pages):一种动态网页技术标准,部署在网络服务器上,可以相应用户端发送的请求,并根据请求内容动态生成HTML、XML或其他格式文档的Web网页,返回给请求者。
  7. 可扩展标记语言(XML):是被设计用于传输和存储数据的语言。
  8. Java消息服务(Java Message Service, JMS)是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间或分布式系统中发生消息,进行异步通信。

Java EE 分层模型

  1. Domain Object(领域对象)层:由一系列POJO(Plain Old Java Object)组成,这些对象是该系统的Domain Object,通常包含各自所需实现的业务逻辑方法。
  2. DAO(Data Access Object, 数据访问对象)层:由一系列DAO组件组成,实现对数据库创建、查询、更新、删除等操作。
  3. Service(业务逻辑)层:由一系列控制器组成,用于拦截用户请求,并调用业务逻辑组件的业务逻辑方法处理用户请求,根据处理结果向不同View组件转发。
  4. View(表现)层:由一系列页面及视图组件组成,负责收集用户请求,并显示处理后的结果。

MVC

MVC,即为Model View Controller,三个核心部件,独自处理各自的任务。这种分离思想应用在代码审计中,以抓住关键问题。

Java MVC

  1. Model:表示携带数据的对象或Java POJO,即使模型内的数据改变,它也具有逻辑来更新控制器。
  2. Controller:表示逻辑控制,它对模型和视图都有作用,控制数据流进入模型对象,并在数据更改时更新视图,是视图和模型的中间层。
  3. View:表示模型包含的数据的可视化层。
    工作流程:控制层接收用户请求,决定调用哪个模型,模型处理用户请求并返回数据,最后由视图层将数据转化呈现给用户。MVC模式使视图层和业务层分离,比如修改View层代码时,不用重新编译Model和Controller代码。

Java MVC框架

  1. Struts1
  2. Struts2
  3. Spring MVC
  4. JSF
  5. Tapestry

Servlet