黑客网站渗透入侵破解拿权限
10.5K subscribers
2.38K photos
108 links
Download Telegram
在进行APP设计时,要清楚哪些Provider的数据是用户隐私数据或者其他重要数据,考虑是否要提供给外部应用使用,如果不需要提供,则在AndroidManifes文件中将其exported属性显式的设为“false”,这样就会减少了很大一部分的攻击面。

人工排查肯定比较麻烦,建议开发者使用阿里聚安全提供的安全扫描服务,在APP上线前进行自动化的安全扫描,尽早发现并规避这样的风险。

注意:

由于Android组件Content Provider无法在Android 2.2(即API Level 8)系统上设为不导出,因此建议声明最低SDK版本为8以上版本(这已经是好几年前的SDK了,现在一般都会大于此版本);

由于API level 在17以下的所有应用的“android:exported”属性默认值都为true,因此如果应用的Content Provider不必要导出,建议显式设置注册的Content Provider组件的“android:exported”属性为false;

如果必须要有数据提供给外部应用使用,则做好设计,做好权限控制,明确什么样的外部应用可以使用,如对于本公司的应用在权限定义时用相同签名即可,合作方的应用检查其签名;不过还是尽量不提供用户隐私敏感信息。
/网站渗透 /黑客编程技术
/软件渗透 /提取数据
/网站权限 /网站入侵破解
有需求的找我
@MoA_Ke
TeslaCrypt(以及AlphaCrypt,下文统称为“TC”)算是比较“成熟”的勒索软件,其版本从0.2逐步升级到目前已知的最高版本4.0+(也不知道有没有Insider Preview)。随着版本的升级,其加密和密钥处理技巧也在不断升级。
勒索软件的制作者为了打到目的,通常会给用户一个比特币钱包的地址。用户向该钱包付款之后,可以得到一个解密密钥,用此密钥即可解密。有报告指出,不同的受害者需要向不同的钱包中打款,这暗示着比特币钱包的生成过程可能与加密密钥的产生存在一定关联。因此,先大致了解下钱包是如何生成的。
比特币钱包生成的基本步骤是:
初始化一对可用于ECDSA签名的密钥Public/PrivateBtcKey
用SHA256对PublicBtcKey做蛤希,得到S256_PublicBtcKey
用RIPEMD-160对上一个结果做哈希,然后在哈希前部加入版本号得到VR160_S256_PublicBtcKey
在上一哈希前部加入版本号,并做两次哈希,将结果的前4字节附加在VR160_S256_PublicBtcKey后,最后使用Base58算法编码。这时得到的就是长33个字符的钱包地址。
TC被首次载入时,就生成了一对PublicBtcKey/PrivateBtcKey。其中,PublicBtcKey就是向用户显示的地址,而PrivateBtcKey则被发送给C&C服务器,以进行之后的转账操作。不同版本的TC,这一点是不变的。
TC作者本次公布的密钥是四号密钥,应用于TC3.0以及TC4.0版本。这两个版本都采用了比较完整的分层密钥机制,并且提高了样本隐蔽性。TC4.0的准备过程
准备随机数生成器等;
生成随机数,并用714号曲线(即secp256k1)建立比特币钱包,对应密钥Public_BtcKey和Private_BtcKey;
对Private_BtcKey做SHA-256哈希,得到Private_HashedPRBK,用Public_BtcKey算出钱包地址,一会展示给客户;
用Private_HashedPRBK带入曲线,得到第二对密钥Public_HashedPRBK;
拥有一对密钥Public/Private_MalMaster。这对密钥里,Public_MalMaster是由TC作者置入程序的,而Private_MalMaster则是本次被作者公布的“主密钥”,难以被运算出来;
/网站渗透 /黑客编程技术
/软件渗透 /提取数据
/网站权限 /网站入侵破解
有需求的找我
@MoA_Ke
内网渗透思路探索 之新思路的探索与验证

基于这样的渗透思路,开始尝试寻找试验目标。

关于试验用目标,有几点要求,首先是在一个工作组环境中,(其次)拥有较多的主机或者较大网络。经过不断寻找,成功渗透进一个满足我需求的内网。

目标是一个学校,渗透的过程比较平常,注入,上shell,反弹不成功,正向反弹,控制服务器,没有太多的亮点。

然后开始针对网络设备进行攻击。利用正向反弹工具,将我的kali接入了内网,定向攻击网关设备。利用snmp的弱口令,直接获取了三层交换的控制权限。

注:kali的snmpwalk 不能利用proxychains走socks5代理,攻击内网机器,暂不清楚原因。

这里需要多说一下,我并没有直接进行固件级别的EXP测试,因为在exploit-db上的路由器固件的远程命令执行exp并不多,有很多的exp并没有公开,并且由于自己没有构造EXP的能力,遂放弃通过EXP获取权限的思路。
/网站渗透 /黑客编程技术
/软件渗透 /提取数据
/网站权限 /网站入侵破解
有需求的找我
@MoA_Ke
jsPDF 本地文件包含/路径遍历(CVE-2025-68428)漏洞分析

此漏洞源于 jsPDF (Node.js 构建版) 的部分方法(loadFile, addImage, html, addFont)未对用户传入的文件路径进行严格的过滤与校验。远程攻击者可构造包含路径遍历序列(如 ../)的恶意请求,绕过预期的资源目录限制,读取服务器上的敏感文件(如配置文件、密钥等),并将文件内容嵌入到生成的 PDF 文档中。
import { jsPDF } from "jspdf";

const doc = new jsPDF();

doc.addImage("../secret.txt", "JPEG", 0, 0, 10, 10);
doc.save("test.pdf");

漏洞影响
受影响的版本<=3.0.4
已打补丁的版本版本 >=4.0.0
漏洞复现

通过补丁描述可知,提供俩种解决方式

1. 通过控制 Node.js 进程的文件系统访问权限node --permission --allow-fs-read

2. 通过代码层面添加allowFsRead,设置允许读取文件以及目录

继续查看代码,对process.permission以及this.allowFsRead进行判断
读取文件
在readFileSync函数处下一个断点,没有进行任何判断,直接将相对路径解析为绝对路径
读取文件后返回内容,最后调用writeFileSync读取到的文件内容写入文件
新版本必须配置run node with the --permission and --allow-fs-read flags or set the jsPDF.allowFsRead property.

配置allowFsRead后可以成功运行
/网站渗透 /黑客编程技术
/软件渗透 /提取数据
/网站权限 /网站入侵破解
有需求的找我
@MoA_Ke
1
JAVA代码审计篇-用友NC65鉴权绕过分析

首先我们知道用友NC有很多注入漏洞都是基于一个鉴权绕过的前提下进行的注入 也就是用 pageId=login 来绕过鉴权,但是在网上找了找发现都是关于注入漏洞部分的分析,都没有提到鉴权部分的分析(很烦)于是只能自己分析下。

查看PortalLoginFilter类 发现继承了AbstractLfwLoginFilter 并且没有重写doFilter 所以我们就看他的父类AbstractLfwLoginFilter中的doFilter方法。

这里查看AbstractLfwLoginFilter的doFilter方法

在这里,前两个 if 判断条件满足,即可直接进入后续的 doFilter 流程并放行请求。首先关注第一个判断条件,其调用的 isToLogin 方法仅依据从可控的请求参数 pageId 的取值进行判断。当 pageId 等于 loginpasswordmng 时,方法直接返回 `true`,从而绕过登录校验,导致鉴权绕。
this.isToLogin(req, res)
private boolean isToLogin(HttpServletRequest req, HttpServletResponse res) {

String pageId = req.getParameter("pageId");

return pageId != null && (pageId.equals("login") || pageId.equals("passwordmng"));

}

构造请求包进行测试验证
没有加pageId的情况下 没有走到功能点 302响应 被重定向到 /portal 。
加入参数pageId=login 或者pageId=passwordmng 可以看到是参数错误导致的500报错也就是成功绕过鉴权。

/网站渗透 /黑客编程技术
/软件渗透 /提取数据
/网站权限 /网站入侵破解
有需求的找我
@MoA_Ke
modelConfig.getConfigValue(ESCAPE_URL) 用于从配置文件中读取免鉴权访问的路径白名单,并将该配置与当前请求的 URL 进行匹配判断。然而在匹配过程中,代码采用 indexOf 的方式进行字符串包含判断,而非严格的路径匹配。同时,请求 URL 的构造中包含了 `req.getQueryString()`,即将用户可控的请求参数一并纳入匹配范围。
 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {  

PortalLogger.debug((String)LfwResBundle.getInstance().getStrByID("ds", "AbstractLfwLoginFilter-000000"));

HttpServletRequest req = (HttpServletRequest)request;

HttpServletResponse res = (HttpServletResponse)response;

WebContext webCtx = LfwRuntimeEnvironment.getWebContext();

String currentUrl = req.getRequestURI();

String loginURL = this.getLoginJspName();

if (webCtx != null) {

LfwRuntimeEnvironment.getWebContext().setResponse(res);

}

在上述逻辑下,攻击者可通过在请求参数中加入配置文件中定义的免鉴权路径关键字,使请求 URL 命中免鉴权规则,从而导致鉴权绕过。


经过搜索发现在以下配置文件中存在很多免鉴权的路径。

随便选取其中的一个路径构造请求包进行测试如 pt/oncelogin/getAuth ,500返回确实没有被鉴权拦截。

更换其他接口地址试一下320响应了,被鉴权拦截 上述接口确实为免鉴权路径。

接下来使用构造一个参数值为pt/oncelogin/getAuth的请求包进行测试确实绕过鉴权。
/网站渗透 /黑客编程技术
/软件渗透 /提取数据
/网站权限 /网站入侵破解
有需求的找我
@MoA_Ke