Aggregator

在使用某抢票软件的时候，由于要设置抢票成功后的通知，就用了QQ通知。结果发现当QQ在锁定时，也可以获取到QQ的控制面板进行操作，竟然绕过了QQ的锁定，于是就去尝试如何实现QQ锁定的绕过。

A draft disposal schedule for the NZSIS, GCSB, and National Security Group of DPMC is open from 19 November - 10 December 2018 for feedback.

想尝试逆向APK来发现一些接口和安全问题，但是Mac下没啥好用的APK逆向工具，于是我就参考文章：https://blog.csdn.net/jyygn163/article/details/71731786 的思路在Mac下使用homebrew安装：

JD-GUI去http://jd.benow.ca/下载，这里我是用的是jar版。

手动敲命令太繁琐了，写个shell脚本一键化。

在.bash_profile文件（环境变量）加入这个命令alias apkdec="/Users/chen/HackBox/Tools/Android\ Decompile/DeApkScript.sh"，这样当终端打开的时候就可以使用apkdec命令了，而脚本DeApkScript.sh的内容如下：

功能实现如下：

• apktool获取资源文件
• 将apk文件重命名为zip文件
• 解压zip文件中的.dex文件
• 切换解压目录
• 将dex文件转换成jar文件

这样，最后只需要使用JD-GUI反编译JAR即可看见源码了。

运行命令：

首先对classes-dex2jar.jar文件进反编译，但似乎在Mac下JD-GUI支持的不太好，所以我选择使用luyten（Download：https://github.com/deathmarine/Luyten/releases），如下是两张对比图：

在luyten下使用Command+G快捷键全局搜索，搜索域名寻找接口（因为这个APP需要内部人员才能登录所以从正常的入口是无法找到接口进行漏洞挖掘的）

寻找了一番看见这样一个接口：

二话不说访问之，提示：

不懂Java的我一脸懵，但是天下语言都是互通的，大概的了解了代码的意思（可能理解的不到位，就不说出来误导了），于是找到这样一个函数：

从我的理解来看这个接口就是有这两个参数appId、userName，于是加入GET请求参数中请求：

其中appId的参数值返回在了页面中，该请求响应报文Content-Type: text/html，所以尝试构建XSS，运气好，确实也存在XSS问题：

学习、不断的学习。

Government Communications Security Bureau’s (GCSB) cyber defence services called CORTEX has been named Best Security Project or Initiative at the 2018 Information Security Awards NZ.

最近ASRC的事情（PDF导致的URL跳转漏洞）闹的沸沸扬扬的，一开始没怎么去关注，后来想去玩一玩的时候发现作者没有给出比较好的说明来告诉大家如何玩、操作PDF的事件和漏洞原理。小白的我来探究一下。。

本人是macOS系统所以用不了迅捷PDF编辑器，后来尝试寻找各种适用于Mac平台的编辑器无果之后，还是向Adobe妥协，下载了破解版的Adobe Acrobat Pro DC 2018(也支持Windows)。

随便用Word文档导出了一个PDF，使用Acrobat打开，进行编辑，找了一会终于找到了页面属性设置的地方。

点击右侧的组织页面功能：

选择这一页点击更多->页面属性：

选择事件动作->触发器选择打开页面->选择动作打开网络链接->添加 输入地址：

设置成功：

漏洞测试浏览器：谷歌浏览器 Chrome

漏洞测试GIF：

这个漏洞的局限性在于浏览器的不同，那么为什么会只存在于部分浏览器上呢？

一开始的猜想是与浏览器的内核有关，Chrome是基于Webkit的内核分支，而Safari也是基于这个的，但是经过测试发现发现Safari无法跳转。

结果：NO

之前了解过FireFox浏览器是使用pdf预览插件是Chrome的PDF Viewer，但是至今为止最新版都只是很久以前的版本了（火狐官方也进行了一些细微的修改）：

谷歌自己呢早就更新迭代了：

chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/pdf_viewer.js

结果：很大概率和浏览器PDF预览插件有关，可能是谷歌在之后更新引入了对PDF事件的支持。

PoC下载：PoC.pdf

最近看见一些漏洞利用到了短文件名回想到之前发现的漏洞，发现自己对短文件名的原理一无所知，现在来一探究竟。

windows下的文件短名是dos+fat12/fat16时代的产物，又称为8dot3命名法，类似于PROGRA~1（目录）或者元素周~1.exe（文件）这样的名称。 8是指文件名或目录名的主体部分小于等于8个字符 ; 3是指文件名或目录名的扩展部分小于等于3个字符 ;中间以 . 作为分割在FAT16文件系统中，由于FDT中的文件目录登记项只为文件名保留了8个字节，为扩展名保留了3个字节，所以DOS和Windows的用户为文件起名字时要受到8.3格式的限制。

查看Windows下的短文件名：

可以看见图中的123123~1.TXT，就是1231231231231231232.txt的短文件名表示。

为什么现在Windows系统还存在短文件名这种表示？

从win95开始，采用fat32已经支持长文件名，但是为了保持兼容性，保证低版本的程序能正确读取长文件名文件，每当创建新文件或新目录时，系统自动为所有长文件名文件创建了一个对应的短文件名。使这个文件既可以用长文件名寻址，也可以用短文件名寻址。

知道了什么是短文件名，再看如上文所贴图，图中文件1231231231231231232.txt的短文件名就是123123~1.TXT

Windows短文件名8dot3命名规则：

• 符合DOS短文件名规则的Windows下的长文件名不变
• 长文件名中的空格，在短文件名中被删除
• 删除空格后的长文件名，若长度大于8个字符，则取前6个字符，后两个字符以~#代替，其中 # 为数字，数字根据前六个字符相同的文件名的个数顺延。若个数超过10个则取前5个字符，后三个字符以~##代替，其中 ## 为两位数字，若个数大于100也依此规则替换。
• 对使用多个.隔开的长文件名，取最左端一段转换为短文件名，取最右一段前三个字符为扩展名
• 如果存在老 OS 或程序无法读取的字符，用_替换

将Windows注册表（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem）中的NtfsDisable8dot3NameCreation这一项的值设为 1

CMD实现关闭短文件名：

如果想开启（将值设为0）：

需要注意：即使关闭了短文件名功能，也不会删除原有创建过的短文件名