一个人的闲言碎语

2020年7月22日星期三

[转]AFL(二)afl-qemu无源码fuzz

七月 22, 2020 Posted by drovliu , No comments
使用brew/apt方式安装的afl没有afl-qemu-trace(不支持使用QEMU模式),所以我们需要下载afl的源码自己编译。

0x1 安装配置

编译完成后,需要配置qemu环境。不过,afl提供了一个脚本,在qemu-mode文件夹下的build_qemu_support.sh。运行这个脚本来配置qemu环境,但qemu-mode只支持linux,macOS可以在docker上使用,docker使用参考macOS上使用kali-linux for docker
$ ./build_qemu_support.sh
=================================================
AFL binary-only instrumentation QEMU build script
=================================================

[*] Performing basic sanity checks...
[-] Error: QEMU instrumentation is supported only on Linux.
编译成功信息如下:
[+] Build process successful!
[*] Copying binary...
-rwxr-xr-x 1 root root 10956864 Dec 13 12:26 ../afl-qemu-trace
[+] Successfully created '../afl-qemu-trace'.
[*] Testing the build...
[+] Instrumentation tests passed.
[+] All set, you can now use the -Q mode in afl-fuzz!

遇到的坑

  1. 运行后会提示libtool等资源库没有安装,使用sudo apt install安装即可:
    $ ./build_qemu_support.sh
    =================================================
    AFL binary-only instrumentation QEMU build script
    =================================================
    [*] Performing basic sanity checks...
    [-] Error: 'libtool' not found, please install first.
    $ apt-get install libtool-bin
    
  2. 安装一些软件包时,有时会出现找不到glib2的错误:
    $ apt install glib2
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    E: Unable to locate package glib2
    
    查看build_qemu_support.sh相关代码,需要在/usr/include/glib-2.0/或者/usr/local/include/glib-2.0/有相关库:
    if [ ! -d "/usr/include/glib-2.0/" -a ! -d "/usr/local/include/glib-2.0/" ]; then
    echo "[-] Error: devel version of 'glib2' not found, please install first."
    exit 1
    
    可通过安装以下工具来解决:
    sudo apt-get install libgtk2.0-dev
    
  3. qemu编译错误:
    util/memfd.c:40:12: error: static declaration of 'memfd_create' follows non-static declaration
    static int memfd_create(const char *name, unsigned int flags)
             ^~~~~~~~~~~~
    In file included from /usr/include/x86_64-linux-gnu/bits/mman-linux.h:115,
                  from /usr/include/x86_64-linux-gnu/bits/mman.h:45,
                  from /usr/include/x86_64-linux-gnu/sys/mman.h:41,
                  from /root/afl-2.52b/qemu_mode/qemu-2.10.0/include/sysemu/os-posix.h:29,
                  from /root/afl-2.52b/qemu_mode/qemu-2.10.0/include/qemu/osdep.h:104,
                  from util/memfd.c:28:
    
    afl默认qemu版本太老,官方已经patch
    ./configure
    @@ -3923,7 +3923,7 @@ fi
    # check if memfd is supported
    memfd=no
    cat > $TMPC << EOF
    -#include <sys/memfd.h>
    +#include <sys/mman.h>
    
    ./util/memfd.c
    @@ -31,9 +31,7 @@
    #include "qemu/memfd.h"
    -#ifdef CONFIG_MEMFD
    -#include <sys/memfd.h>
    -#elif defined CONFIG_LINUX
    +#if defined CONFIG_LINUX && !defined CONFIG_MEMFD
    
    修改完成后使用如下指令重打包,再修改build_qemu_support.sh里的QEMU_SHA384重新编译即可,SHA384值可以使用sha384sum获取:
    $ tar -Jcf qemu-2.10.0.tar.xz qemu-2.10.0/
    $ sha384sum qemu-2.10.0.tar.xz
    

更换qemu版本

如果想使用更新版本qemu,可以直接将build_qemu_support.sh设置的版本换成官方的较新版本,但更换版本后问题较多:
#VERSION="2.10.0"
VERSION="2.12.1"
#QEMU_SHA384="68216c935487bc8c0596ac309e1e3ee75c2c4ce898aab796faa321db5740609ced365fedda025678d0"
QEMU_SHA384="92957551a3a21b1ed48dc70d9dd91905859a5565ec98492ed709a3b64daf7c5a0265d670030ee7e6d16da96436795435"
  1. patch错误:
    patching file linux-user/elfload.c
    Hunk #2 succeeded at 2233 (offset 146 lines).
    Hunk #3 succeeded at 2268 (offset 146 lines).
    patching file accel/tcg/cpu-exec.c
    Hunk #1 succeeded at 37 (offset 1 line).
    Hunk #2 succeeded at 147 with fuzz 2 (offset 1 line).
    Hunk #3 FAILED at 369.
    1 out of 3 hunks FAILED -- saving rejects to file accel/tcg/cpu-exec.c.rej
    
    patch针对的是上层路径的文件更新,可以直接注释掉
    #patch -p1 <../patches/cpu-exec.diff || exit 1
    
  2. 缺少pixman,安装即可
    apt-get install libpixman*
    
  3. LINK错误:
    LINK    x86_64-linux-user/qemu-x86_64
    linux-user/syscall.o: In function `do_syscall':
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/syscall.c:11983: undefined reference to `afl_forksrv_pid'
    linux-user/elfload.o: In function `load_elf_image':
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2236: undefined reference to `afl_entry_point'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2236: undefined reference to `afl_entry_point'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2271: undefined reference to `afl_start_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2271: undefined reference to `afl_start_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2275: undefined reference to `afl_end_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2275: undefined reference to `afl_end_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2236: undefined reference to `afl_entry_point'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2236: undefined reference to `afl_entry_point'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2271: undefined reference to `afl_start_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2271: undefined reference to `afl_start_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2275: undefined reference to `afl_end_code'
    /root/afl-2.52b/qemu_mode/qemu-2.12.0/linux-user/elfload.c:2275: undefined reference to `afl_end_code'
    collect2: error: ld returned 1 exit status
    Makefile:193: recipe for target 'qemu-x86_64' failed
    make[1]: *** [qemu-x86_64] Error 1
    Makefile:478: recipe for target 'subdir-x86_64-linux-user' failed
    make: *** [subdir-x86_64-linux-user] Error 2
    
    上层patch中对源码文件做了修改,导致部分外部变量没有导入,注释掉相关patch即可:
    # patch -p1 <../patches/elfload.diff || exit 1
    # patch -p1 <../patches/syscall.diff || exit 1
    
  4. afl-qemu-trace测试失败
    [+] Successfully created '../afl-qemu-trace'.
    [*] Testing the build...
    [-] Error: afl-qemu-trace instrumentation doesn't seem to work!
    
    应该是用64位afl-qemu-trace工具测试32位程序引起的,忽略即可,或者通过如下指令指定32位架构:
    $ CPU_TARGET=i386 ./build_qemu_support.sh
    
    结果如下,实际也是忽略了测试:
    [+] Successfully created '../afl-qemu-trace'.
    [!] Note: can't test instrumentation when CPU_TARGET set.
    [+] All set, you can now (hopefully) use the -Q mode in afl-fuzz!
    

0x2 使用afl-qemu fuzz

0x21 同cpu架构程序

以系统中wget指令为例,使用如下指令执行fuzz,-Q参数表示使用qemu模式;-m参数设置使用内存大小,不设置则默认200MB:
$ afl-fuzz -i fuzz_in -o fuzz_out -m 200 -Q wget @@
运行成功界面如下(ubuntu for docker):

0x22 不同cpu架构程序

0x221 获取目标文件

Android adbd程序为例,获取adbd文件:
$ file /system/bin/adbd
/system/bin/adbd: ELF executable, 64-bit LSB arm64, static, for Android 28, BuildID=2ef781f7497eaad0b8ba145996afd9a1, not stripped
$ adb pull /system/bin/adbd ./

0x222 编译目标架构qemu模式

如果fuzz的程序与qemu架构不同,则可能出现如下错误,需要用之前方式指定正确架构进行编译qemu模式:
$ afl-fuzz -i fuzz_in -o fuzz_out/ -Q ./adbd @@
...
[-] Hmm, looks like the target binary terminated before we could complete a
    handshake with the injected code. There are two probable explanations:

    - The current memory limit (200 MB) is too restrictive, causing an OOM
      fault in the dynamic linker. This can be fixed with the -m option. A
      simple way to confirm the diagnosis may be:

      ( ulimit -Sv $[199 << 10]; /path/to/fuzzed_app )

      Tip: you can use http://jwilk.net/software/recidivm to quickly
      estimate the required amount of virtual memory for the binary.

    - Less likely, there is a horrible bug in the fuzzer. If other options
      fail, poke <lcamtuf@coredump.cx> for troubleshooting tips.

[-] PROGRAM ABORT : Fork server handshake failed
         Location : init_forkserver(), afl-fuzz.c:2253
编译arm64版本工具,qemu支持的架构类型见./qemu-2.10.0/linux-user/host/目录,其中arm为32位arm,aarch64为64位arm:
$ ls  ./qemu-2.10.0/linux-user/host/
aarch64  arm  i386  ia64  mips  ppc  ppc64  s390  s390x  sparc  sparc64  x32  x86_64
以64位arm为例,编译指令如下:
$ CPU_TARGET=aarch64 ./build_qemu_support.sh
编译aarch64版本后,继续执行fuzz:
$ ../afl-2.52b/afl-fuzz -i fuzz_in/ -o fuzz_out/ -Q ./adbd
依然错误:
[-] PROGRAM ABORT : Test case 'id:000000,orig:testcase' results in a crash
         Location : perform_dry_run(), afl-fuzz.c:2852

0x223 qemu user mode检查

由于可执行文件的架构不一样,所以需要按照QEMU user mode仿真做一下检查,运行成功后再进行fuzz,详情参考:IoT(七)通过qemu调试IoT固件和程序里的用户模式调试程序。
在该文中,adbd程序由于缺少外部资源依然执行失败(如需对有外部资源依赖的程序进行fuzz,可在该平台编译对应版本的fuzz工具),故重新选取能够执行成功的静态编译工具,如Android上的三方工具busybox:
$ file busybox
busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
$ qemu-aarch64 busybox
BusyBox v1.25.0-NetHunter (2016-03-19 19:36:31 EDT) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list[-full]
   or: busybox --install [-s] [DIR]
   or: function [arguments]...
....
此处可成功对busybox进行fuzz:
../afl-2.52b/afl-fuzz -i fuzz_in/ -o fuzz_out/ -Q ./busybox @@

2020年4月16日星期四

利用 hexo 搭建github blog

四月 16, 2020 Posted by drovliu , , , No comments
主要还是看 hexo 的 next 主题挺不错的,所以选择了用 hexo 搭建 github 的 blog。
使用 hexo 搭建 blog 的前置条件还是很多的:
1. brew install npm
2. npm install -g hexo-cli
3. npm install -g hexo
如上,即已安装前置的 node.js 和 hexo。
之后需要创建一个新文件夹(文件夹必须为空,否则无法 init hexo),目录下执行
1. hexo init
2. npm install
3. hexo g
4. hexo s
即启动本地 blog 服务,输入 http://localhost:4000/ 即刻本地查看。
此时需要同步到 github,在 github 进行部署。
这里需要编辑 _config.yml 以通过 hexo d 进行发布(单纯同步工程至 github 不可行)。
deploy:
  type: git
  repo: git@github.com:username/username.github.io.git
  branch: master
这时一般是没有 git 命令的(执行 hexo d 会报错),需要安装 hexo-deployer-git
npm install hexo-deployer-git
此时,通过如下命令可进行发布
1. hexo clean
2. hexo g
3. hexo d


访问 username.github.io 即可访问自己的 blog。

2020年3月11日星期三

有效的xmind8 for mac 序列号

三月 11, 2020 Posted by drovliu No comments
1、官网下载最新的安装包 XMind For Mac,断网安装(安装软件需在断网情况下进行!!!).
双击打开安装包xmind.dmg,直接拖动安装.
   
安装完成之后,打开 偏好设置-->常规-->启动,将如图所示的两个标签的对勾取消掉,然后点击确定,关闭软件.

  



2、下载破解包 XMindCrack.jar,链接: https://pan.baidu.com/s/1sCbCQHTI24CgyaVrwGW_kQ  提取码: dejw
3、激活xmind:
1>将下载的破解补丁复制到安装好的软件包下的Eclipse这个目录中:安装好的XMind-->鼠标右键显示包内容-->Contents-->Eclipse。

2>打开安装目录Eclipse中的 XMind.ini  (我下面使用的软件是Visual Studio Code,需要的自行Google吧)
3>在 XMind.ini 最后追加一行XMindCrack.jar的绝对路径,并保存。(绝对路径如下可复制)
-javaagent:/Applications/XMind.app/Contents/Eclipse/XMindCrack.jar

4>重新打开 XMind, 点击 帮助-->序列号-->输入序列号,进入XMind激活页面,然后输入以下序列号 ,邮箱可以随便填,可以填自己的,提示激活成功之后点击'关闭'即可。
序列号:
XAka34A2rVRYJ4XBIU35UZMUEEF64CMMIYZCK2FZZUQNODEKUHGJLFMSLI QMQUCUBXRENLK6NZL37JXP4PZXQFILMQ2RG5R7G4QNDO3PSOEUBOCDRYSSXZGR ARV6MGA33TN2AMUBHEL4FXMWYTTJDEINJXUAV4BAYKBDCZQWVF3LWYXSDCXY5 46U3NBGOI3ZPAP2SO3CSQFNB7VVIY123456789012345

2019年3月4日星期一

安全周事记(20190304)


  • 浏览器漏洞导致黑客可以在用户关闭网页(浏览器进程保留)时依然留下后门。
    吐槽:开发者原意是为了方便其他(正常)开发者,可是黑客的钻研精神往往更厉害。
  • 漏洞攻击者利用四个winrar的漏洞,通过诱使用户使用WinRAR打开恶意构造的压缩包文件,将恶意代码写入系统启动目录或者写入恶意dll劫持其他软件进行执行,实现对用户主机的任意代码执行攻击。
    github上公开了该漏洞的poc,acefile - WinRAR 解压代码执行漏洞 POC:
    https://github.com/Ridter/acefile
    吐槽:还好我不用winrar,感谢winrar的中国代理。
  • 从 2017 年底到 2019 年初,腾讯御见威胁情报中心发现一个疑似来自印度的 APT 攻击组织持续针对巴基斯坦等南亚国家的军事目标进行了定向攻击。腾讯御见威胁情报中心对该组织的攻击活动进行了长期的深入分析,从溯源结果来看,该组织的最早的攻击活动可以追溯到 2012 年。
    响尾蛇(SideWinder)组织是一个成熟的 APT 攻击组织,该组织擅长使用 office 漏洞、hta 脚本、白加黑、VB 木马等技术来实施攻击,并且攻击手法还在不断的进化中。目前该组织的攻击目标主要在巴基斯坦,但是由于地缘关系,也不排除针对中国境内的目标发起攻击,因此相关部门、单位和企业切不可掉以轻心。
    吐槽:大家的精力都用在了取名字上了。
  • 该木马还教会了作者关闭其他可能存在的挖矿及DDoS木马。
    吐槽:堡垒都是从内部攻破的。
  • 从2018年4月起至今,一个疑似来自南美洲的APT组织盲眼鹰(APT-C-36)针对哥伦比亚政府机构和大型公司(金融、石油、制造等行业)等重要领域展开了有组织、有计划、针对性的长期不间断攻击。其攻击平台主要为Windows,攻击目标锁定为哥伦比亚政企机构,截止目前360威胁情报中心一共捕获了29个针对性的诱饵文档,Windows平台木马样本62个,以及多个相关的恶意域名。
    吐槽:取名上面的竞争越来越激烈了。
  • 360威胁情报中心截获了多个使用WinRAR漏洞传播恶意程序的样本,并且我们还观察到了多个利用此漏洞进行的APT攻击活动。可以明显的看到,攻击者针对该漏洞利用做了更精心的准备,比如利用WinRAR压缩包内图片列表不可预览来诱导目标极大概率解压恶意文件、将恶意ACE文件加密后投递、释放“无文件”后门等。
    吐槽:winrar有望取代flash,成为新一代的突破口。
  • 漏洞的根源在于this.submitForm()这个PDF Javascript API。像this.submitForm(‘http://google.com/test‘)这样一个简单的调用就会导致Chrome把个人信息发送到google.com。 可能被泄露的信息包括:
    1. 用户的公共IP地址。
    2. 操作系统,Chrome版本等(在HTTP POST header中)。
    3. 用户计算机上PDF文件的完整路径(在HTTP POST payload中)。
      漏洞利用:3.1 Google Chrome 被发现零日漏洞 可让黑客获取用户数据 黑客通过此种方式可以获得的数据包括设备的IP地址、操作系统和Google Chrome版本,以及本地驱动器上PDF文件的路径等等。
      吐槽:最好还是不要给予内部纯文档阅读器联网权限。
  • 如果返回的国家代码为意大利(代码39),恶意宏将会使用Shell函数来执行下一条攻击指令。
    吐槽:通过地区代码进行恶意代码行为限制的病毒不多见了。
  • 详细介绍了逆向过程。可以看看。
    吐槽:目前大部分微信防撤回软件应该都解决了这个问题。
  • 前员工遗留的一个后门。
    吐槽:机翻拯救失业。
  • 过期域名,尤其是过期事业单位的域名被恶意利用。监管和内审都应该关注一下。
    吐槽:还是事业单位资产管理的问题。
  • Check Point安全研究人员近日在调查多个恶意文档时发现了朝鲜APT组织Lazarus疑似针对俄罗斯的攻击活动。研究人员分析发现这些文件是感染链的一部分,目的是删除与Lazarus组织相关的后门KEYMARBLE的更新变种。
    吐槽:机翻看着真难受。
  • 提出新一代智能恶意邮件监测与溯源的系统框架,将多元行为分析、威胁情报溯源、动态沙箱检测、深度样本意图分析等智能化威胁感知和邮件监测技术应用在恶意邮件监测与溯源系统中。通过人工智能技术将几百种基于知识工程的邮件安全元素与威胁、业务模型关联建模,使系统具备更智能的威胁感知能力和更准确的恶意邮件检测率。同时,通过邮件样本溯源技术,系统可以进一步溯源恶意邮件的来源和相关的黑客组织。
    吐槽:啥流行就把啥扯上去,貌似就是学术论文的关键。
  • RapidScan在漏洞扫描器和网站审计软件的自动化部署上做的非常出色。它支持很多效果不错的工具,使用这些工具可以容易地探测常见的网站漏洞。再加上UserLAnd这样的App,我们可以把一部不显眼的Android手机武装成一个功能齐全的黑客设备。
    地址:rapidscan
  • 这个逻辑是存在ut值的时候会对当前用户的手机号进行验证,然而在没有ut值的时候无法获取当前用户信息,也就无法进行手机号验证,同时也未对手机验证码以及旧密码进行验证导致密码修改成功。
    吐槽:业务逻辑漏洞需要不断尝试才可挖掘出来并利用。
  • PFLD算法,目前主流数据集上达到最高精度、ARM安卓机140fps,模型大小仅2.1M!
    吐槽:简直牛批了。
  • 文章被删,不记得具体内容了,参考:http://webscan.360.cn/vul/view/vulid/1020
    吐槽:删的莫名其妙。
  • 2018 年全年,360 互联网安全中心共截获移动端新增恶意程序样本约 434.2 万个,平均每天新增约 1.2 万。全年相比 2017 年(757.3 万)下降了约 42.7%。自 2015 年起,恶意程序新增样本量呈逐年下降趋势。
    病毒新增减少,但诈骗案例增多。
    吐槽:电信诈骗越来越严重,危害也越来越大。
  • 2019年1月24日,攻击者通过云控指令对该木马(通过驱动人生升级通道下发传播的木马)又进行了新的更新,更新文件下载URL:http[:]//dl.haqo.net/updater.exe,下载到本地保存的路径为:C:\Windows\temp\updater.exe,该恶意代码执行后便会将自身移动到系统关键目录并释放多个文件执行,上传主机的相关信息并从指定的恶意域名查询指令,根据云端指令执行恶意行为,当前云端的指令仅仅是控制感染主机进行挖矿操作,后续攻击者可以根据需要改变云端指令,从而控制感染主机执行更加危险的操作。
    吐槽:僵尸网络,名不虚传。
  • CTF中流量分析题目的案例分析,值得看看。
    吐槽:确实CTF有点越来越像应试教育了。为了难而难?

2019年2月25日星期一

安全周事记(20190225)


  • 网络犯罪分子正在利用一个在2018年12月被发现和已修补的ThinkPHP漏洞传播Yowai(Mirai变种)和Hakai(Gafgyt变种)两种僵尸网络病毒。
    网络犯罪分子利用字典攻击破坏使用PHP框架创建网站的Web服务器,并获得这些路由器的控制,以实现分布式拒绝服务攻击(DDoS)。
    吐槽:Yowai还会清除竞争对手的后门程序。黑产的世界才是血腥和残酷的。
  • 由于商店应用初始更新检查使用HTTP,攻击者在控制网络流量(例如,在网络上实施中间人攻击)的前提下,可以更改用于负载平衡的URL并修改对镜像的请求至用户所控制的域名。这将允许攻击者欺骗Galaxy Apps使用任意带有有效SSL证书的主机名,并模拟应用商店API来修改设备上的现有应用。(最重要的是)攻击者可以在三星设备上利用此漏洞实现远程代码执行。
    吐槽:MITM攻击真的随处可见。
  • google开放自己的零信任框架后,各大安全公司开始推崇“零信任”安全架构成为网络安全流行框架之一。
    吐槽:国内安全公司大多还是跟风为主。
  • 话不多说,看图:
    吐槽:毛熊之厉害,可见一斑。
  • 印度国有天然气公司(Indane)面向经销商和渠道商的网站上,尽管只能通过有效的用户名和密码进行访问,但部分内容已经被谷歌搜索引擎编入索引。
    吐槽:据说爆料者担心受Indane报复~
  • 木马模块只是接管了官方游戏的登录流程,从而达到偷偷盗取用户账号密码的目的。
    吐槽:主要骚操作就是买SEO广告。
  • 对于安全狗杀形,d 盾杀参的思路来绕过。生僻的回调函数, 特殊的加密方式, 以及关键词的后传入都是不错的选择。
    对于关键词的后传入对免杀安全狗,d 盾,河马 等等都是不错的,后期对于菜刀的轮子,也要走向高度的自定义化
    用户可以对传出的 post 数据进行自定义脚本加密,再由 webshell 进行解密获取参数,那么以现在的软 WAF 查杀能力几乎为 0,安全软件也需要与时俱进了。
    吐槽:不明觉厉系列。
  • 信息安全五大时期:
    1. 通信安全时期
    2. 计算机安全时期
    3. 网络安全时期
    4. 信息安全时期
    5. 数据安全时期
      吐槽:数据亦是信息的一部分,只不过当前互联网蓬勃发展,数据积累为大数据,所以安全也跟风谈着重谈数据安全。七本质依旧是保障信息安全。
  • 通过各种贴吧、论坛等信息逐步追溯,过程中一些关键点:QQ、支付宝名字认证等;然后最关键的,还是对人的社工。
    吐槽:所以说,黑产从业者的赚钱门路真的五花八门。
  • 吐槽:科普贴
  • 本次的漏洞是出现在ndex.class.php中的likejob_action()和saveresumeson_action()函数,由于这两个函数对用户的输入没有进行严格的显示,同时利用mysql的特点能够绕过waf。
    吐槽:有源码的注入只需要耐心;前提是挖洞的脑洞有。
  • 主要实战了如何用wireshark做流量分析,信息提取。
    吐槽:恩,跟分析木马差不多的原理咯。都不用分析泄露了什么数据?
  • Justniffer是一款功能强大的网络协议分析工具,它可以捕捉网络流量并以定制化的方式生成日志文件。除此之外,它还可以模拟Apache Web服务器日志文件,跟踪响应事件并从HTTP流量中提取出所有截获到的文件。
    Justniffer项目官网:【传送门
    吐槽:还是wireshark分析器好点吧。
  • FireEye的Mandiant应急响应和情报团队识别出了一波DNS劫持攻击,这波攻击影响了大量域名,其中包括中东、北非、欧洲和南美地区的政府机构、通信部门以及互联网基础设施。研究人员目前还无法识别此次活动背后的攻击者身份,但初步研究表明,攻击者与伊朗有关。
    吐槽:跨国DNS劫持,所以在国家机器面前,个人信息安全如何保障?
  • 近期绿盟科技应急响应团队检测到多家政府、教育、企事业单位网站被黑客植入恶意链接,访问链接后会跳转到指定色情网站。攻击者利用第三方的编辑器的未授权访问及上传漏洞,上传相关恶意HTML页面。结合SEO技术,提升恶意站点在搜索引擎的收录和权重。
    吐槽:事业单位网站、app外包的危害将一直持续下去。
  • 暴力破解还可用于发现Web应用程序中的隐藏页面和内容,在你成功之前,这种破解基本上是“破解一次尝试一次”。
    吐槽:当然,暴力破解更多用于密码爆破;虽然也有爆破漏洞啥的(fuzzing),但其目的往往仅是发现问题(crash)。
  • 2018年,勒索病毒攻击整体态势以服务器定向攻击为主,辅以撒网式无差别攻击手段。
    政企单位防范勒索病毒建议从七个方面着手,即及时更新最新的补丁库、杜绝弱口令、重要资料定期隔离备份、提高网络安全基线、保持软件使用的可信、选择正确的反病毒软件、建立高级威胁深度分析与对抗能力。
    吐槽:勒索变现-新纪元。
  • 最为严重的就是Torpedo,它利用了蜂窝寻呼协议(paging protocol,运营商用于来电或者短信之前通知手机)的弱点,在短时间内拨打和取消手机通话可以在通知目标设备来电的情况下触发寻呼协议,从而让攻击者追踪受害者的位置。研究人员说,知道受害者的寻呼时机还可以让攻击者劫持寻呼通道,并通过欺骗消息(如Amber警报)或完全阻止消息来插入或拒绝寻呼消息。
    吐槽:又一核武器埋下。