西部数据用户面临另一个 RCE 安全文章

西部数据用户面临另一个 RCE

更多全球网络安全资讯尽在邑安全对于那些不能/不会升级他们的 My Cloud 存储设备的人来说,向又一个零日和更多潜在的远程数据死亡问好。坏消息一共有三条,尤其是对于西部数据客户而言。对于上个月数不清的数据消失的西部数据客户来说,情况似乎还不够糟糕,还有另一个零日等待无法或不会升级其 My Cloud 存储设备的人。最新的零日漏洞包含一个攻击链,允许未经身份验证的入侵者以 root 身份执行代码并在供应商的网络附加存储 (NAS) 设备上安装永久后门。它存在于所有运行不再受支持的旧版 My Cloud 3 操作系统的西部数据 NAS 设备中:研究人员称该操作系统“处于不确定状态”,因为西部数据最近停止支持它。西部数据表示,其更新——My Cloud OS 5——修复了该错误。也许是这样,但发现 OS 3 漏洞的研究人员Radek Domanski 和 Pedro Ribeiro告诉安全记者Brian Krebs,OS 5 是对 OS 3 的完全重写,它歪曲了一些流行的特性和功能。因此,并非所有用户都可能升级:当 6 月份发生远程数据擦除时,许多用户在支持论坛中引用使用 OS 3 时强调了这一假设。“它破坏了很多功能,”多曼斯基在谈到 OS 5 时说,正如 Krebs 所说。“所以有些用户可能不会决定迁移到 OS 5。”还有希望。Domanski 和 Ribeiro 已经开发并发布了他们自己的补丁来修复他们在 OS 3 中发现的漏洞。一个问题:每次设备重新启动时都需要重新应用。全球 RCE 数据擦除上个月,我们看到了这样的错误可能导致的后果:世界各地的客户都在哀叹,因为他们的旧 My Book Live 和 My Book Live Duo 设备上的数据被远程擦除了数年(在某些情况下为数十年)。六月的攻击实际上是两次攻击合并成一个乍一看的攻击:一个来自 2018 年的旧远程代码执行 (RCE) 错误,西部数据首先将其归咎于远程擦除,然后是一个以前未知的零日漏洞启用未经身份验证的远程出厂重置设备擦除。正如 Ars Technica 的 Dan Goodin在一篇引人入胜的文章中详述的那样,Ars 和安全公司 Censys 的 CTO Derek Abdine 分析了受影响设备的日志,发现这些设备似乎陷入了某种拉锯战,Abdine假设可能是多个攻击者之间为控制受感染设备而进行的斗争。最新的零日现在是Krebs 上周报告的最新错误。这是更广泛的新型西部数据 My Cloud NAS 设备中的第三个同样严重的零日漏洞。Domanski 和 Ribeiro 最初计划于去年在东京举行的Pwn2Own黑客大赛上展示它。他们从来没有这样做:正如供应商倾向于做的那样,Western Digital 在这对搭档——他们作为 Flashback Team 一起黑客——要展示的前一周推出了更新。鉴于更新消除了他们的错误,研究人员无法竞争。Pwn2Own 规则规定,漏洞利用适用于目标设备支持的最新固件或软件。但在 2 月份,他们确实发布了他们拼凑的攻击链,如下面的 YouTube 视频所示。两人让西部数据“尝到了他们自己的药”,让该公司只有一周的时间来修复漏洞,作为 OS 5 更新下降导致 Pwn2Own...
阅读全文
全球的WD My Book用户发现其设备被恢复出厂设置;微软宣布在Windows 11中禁用Internet Explorer 安全新闻

全球的WD My Book用户发现其设备被恢复出厂设置;微软宣布在Windows 11中禁用Internet Explorer

维他命安全简讯26星期六2021年06月【安全播报】全球的WD My Book用户发现其设备被恢复出厂设置https://www.bleepingcomputer.com/news/security/wd-my-book-nas-devices-are-being-remotely-wiped-clean-worldwide/微软宣布在Windows 11中禁用Internet Explorerhttps://www.bleepingcomputer.com/news/microsoft/rip-internet-explorer-will-be-disabled-in-windows-11/【威胁情报】Zyxel发现针对其企业防火墙和VPN设备的攻击活动https://securityaffairs.co/wordpress/119351/hacking/zyxel-firewall-vpn-attacks.htmlCheck Point披露Atlassian平台的XSS等多个漏洞https://research.checkpoint.com/2021/a-supply-chain-breach-taking-over-an-atlassian-account/Kaspersky披露分发IcedID和QBot的两轮新钓鱼活动https://securelist.com/malicious-spam-campaigns-delivering-banking-trojans/102917/声明:本资讯由启明星辰维他命安全小组翻译和整理 本文始发于微信公众号(维他命安全):全球的WD My Book用户发现其设备被恢复出厂设置;微软宣布在Windows 11中禁用Internet Explorer
阅读全文
西数:黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案 安全新闻

西数:黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案

文章来源:安全圈在遭到一系列远程攻击之后,西部数据(WD)敦促 My Book 用户立即断开互联网连接。在官方公告中,WD 表示 My Book Live 和 My Book Live Duo 网络附加存储(NAS)设备可能通过出厂重置被远程擦除,使用户面临失去所有存储数据的风险。在公告中写道:“西部数据已经确定,一些 My Book Live 和 My Book Live Duo 设备正受到一个远程命令执行漏洞的影响。在某些情况下,攻击者已经触发了出厂重置,似乎是要删除设备上的所有数据”。被利用的漏洞目前编号为 CVE-2018-18472,这是一个根远程命令执行(RCE)漏洞,在 CVSS 严重性评级为 9.8。攻击者能够以 root 身份进行远程操作,他们可以触发重置并擦除这些便携式存储设备上的所有内容,这些设备在 2010 年首次亮相,在 2015 年获得了最后的固件更新。当产品进入报废期时,它们通常无权获得新的安全更新。正如Bleeping Computer首次报道的那样,论坛用户于6月24日开始通过WD论坛和Reddit查询他们的数据突然丢失的情况。一位论坛用户认为,由于他们的信息被删除,自己 "完全完蛋了"。另一位用户评论道:“我愿意拿出我的毕生积蓄来获取我的博士论文数据、我孩子和死去的亲戚的新生照片、我写的但从未发表的旅行博客以及我过去7个月的所有合同工作。我甚至不敢想这对我的职业生涯会有什么影响,因为我失去了所有的项目数据和文件...”。在撰写本文时,论坛用户正在交易潜在的恢复方法和想法,并有不同程度的成功。西部数据说:“我们正在审查我们从受影响的客户那里收到的日志文件,以进一步确定攻击和访问机制的特征”。到目前为止,这些日志文件显示,My Book Live设备是通过直接在线连接或端口转发在全球范围内被攻击的。WizCase之前已经公布了该漏洞的概念验证(PoC)代码。在某些情况下,攻击者还安装了一个木马程序,其样本已被上传到VirusTotal。My Book Live设备被认为是参与这次广泛攻击的唯一产品。西部数据的云服务、固件更新系统和客户信息被认为没有被泄露。西部数据正在敦促客户尽快将他们的设备从互联网上撤出。西部数据说:"我们知道我们客户的数据非常重要。"我们还不明白为什么攻击者触发了出厂重置;但是,我们已经获得了一个受影响设备的样本,正在进一步调查"。该公司还在调查受影响客户的潜在恢复方案。精彩推荐黑白之道周边商城,各种精美衣服帽子鼠标垫,猛戳↓↓↓湖南永定公安:某健康公司未履行网络安全义务!罚!来!千人白帽养成计划第四期,来了!多一个点在看多一条小鱼干 本文始发于微信公众号(黑白之道):西数:黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案
阅读全文
围观0CTF2018之ezDoor CTF专场

围观0CTF2018之ezDoor

创建: 2021-09-26 11:07更新:http://scz.617.cn:8/web/202109261107.txt上半年看PHP 7的Opcode时放狗命中两个有趣的链接My-CTF-Challenges - LyleMi https://github.com/LyleMi/My-CTF-Challenges/blob/master/ezDoor/README_ZH.md0CTF2018之ezDoor的全盘非预期解法 - zsx https://blog.zsxsoft.com/post/36zsx展示了一个技巧,让VLD可以作用于OPcache生成的some.php.bin。两位作者都提到一个非凡的项目Binary Webshell Through OPcache in PHP 7 - Ian Bouchard https://www.gosecure.net/blog/2016/04/27/binary-webshell-through-opcache-in-php-7/Detecting Hidden Backdoors in PHP OPcache - Ian Bouchard https://www.gosecure.net/blog/2016/05/26/detecting-hidden-backdoors-in-php-opcache/PHP OPcache Overridehttps://github.com/GoSecure/php7-opcache-overridehttps://github.com/GoSecure/php7-opcache-override/issues/6该项目可以解析OPcache生成的some.php.bin,有它打底,省了好多从头看源码、文档的麻烦。当时要对付的是ionCube 7.x,计划从some.php.bin起步熟悉Opcode,事实证明这样做相当靠谱。some.php.bin是PHP版本强相关的,Ian Bouchard的原始实现适配不了当时我的目标版本,我选择完全重写一版,这事就过去了。后来我适配过7.0.33、7.1.33、7.2.34以及7.4.23。正事告一段落时,回头来测Ian Bouchard提供的test.php.bin,意外发现前述4个版本无一适配。Ian Bouchard的.bt、.py可以解析他自己的test.php.bin,同时,从LyleMi与zsx的文档看,也能解析"0CTF2018之ezDoor"提供的flag.php.bin,实测确实如此。这就令人纳闷了。https://www.php.net/distributions/php-7.0.4.tar.gzhttps://www.php.net/distributions/php-7.0.8.tar.gzhttps://www.php.net/distributions/php-7.0.33.tar.gz我只有7.0.33的运行环境,一度怀疑7.0.4相关数据结构有变,看了几份源码,确认相关数据结构没有变化,重点对比zend_op_array结构。昨天确认Ian Bouchard的php7-opcache-override项目对应7.0.x。之前因看到system_id_scraper.py中对PHP 7.4特别处理,误以为该项目升级适配了7.4。后来发现该项目只适配7.0.x,而且这个x是个较低的版本,比如7.0.4、7.0.8等等,该项目并不适配7.0.33。OPcache生成的some.bin是版本强相关的,但我没想到7.0.4与7.0.33能有大差异。懒得细究源码和文档,凭经验直接用作者提供的的test.php.bin愣找了一下差异所在。数据结构相同,结构优化对齐带来的填充相同,但7.0.4、7.0.8所有涉及相对偏移运算的地方,都只有0x50 + some_off0x50是zend_file_cache_metainfo的内存大小。"0CTF2018之ezDoor"提供的flag.php.bin是下面第二个链接,第一个链接是其源码https://github.com/LyleMi/My-CTF-Challenges/blob/master/ezDoor/source/flag.phphttps://github.com/LyleMi/My-CTF-Challenges/blob/master/ezDoor/source/src/flag/93f4c28c0cf0b07dfd7012dca2cb868cc0228cadLyleMi为增加CTF难度,将flag.php.bin中zend_file_cache_metainfo.magic的最后一个字节删掉了,为了套用Ian Bouchard的.bt、.py对之解析,需用二进制编辑器补回这个。LyleMi和zsx写明了这点。对flag.php.bin进行反汇编,一种可能的结果展示main() (27) = ASSIGN($flag,"input_your_flag_here") (29) = INIT_FCALL(,"encrypt") (29) = SEND_VAL("this_is_a_very_secret_key",) (29) = SEND_VAR($flag,) (29) var_2 = DO_UCALL(,) (29) tmp_1 = IS_IDENTICAL(var_2,"85b954fc8380a466276e4a48249ddd4a199fc34e5b061464e4295fc5020c88bfd8545519ab") (29) = JMPZ(tmp_1,->9) (30) = ECHO("Congratulation! You got it!",) (35) = EXIT(,) (32) = ECHO("Wrong Answer",) (35) = EXIT(,)encrypt($pwd,$data) // function_table key=encrypt (16) $pwd = RECV(,) (16) $data = RECV(,) (17) = INIT_FCALL(,"mt_srand") (17) = SEND_VAL(0x539,) (17) = DO_ICALL(,) (18) = ASSIGN($cipher,"") (19) tmp_6 = STRLEN($pwd,) (19) = ASSIGN($pwd_length,tmp_6) (20) tmp_6 = STRLEN($data,) (20) = ASSIGN($data_length,tmp_6) (21) = ASSIGN($i,0x0) (21) = JMP(->32,) (22) = INIT_FCALL(,"chr") (22) = INIT_FCALL(,"ord") (22) var_6 = FETCH_DIM_R($data,$i) (22) = SEND_VAR(var_6,) (22) var_6 = DO_ICALL(,) (22) = INIT_FCALL(,"ord") (22) tmp_8 = MOD($i,$pwd_length) (22) var_7 = FETCH_DIM_R($pwd,tmp_8) (22) = SEND_VAR(var_7,) (22) var_8 = DO_ICALL(,) (22) tmp_7 = BW_XOR(var_6,var_8) (22) = INIT_FCALL(,"mt_rand") (22) = SEND_VAL(0x0,) (22) = SEND_VAL(0xff,) (22) var_8 = DO_ICALL(,) (22) tmp_6 = BW_XOR(tmp_7,var_8) (22) = SEND_VAL(tmp_6,) (22) var_6 = DO_ICALL(,) (22) = ASSIGN_CONCAT($cipher,var_6) (21) = PRE_INC($i,) (21) tmp_6 = IS_SMALLER($i,$data_length) (21) = JMPNZ(tmp_6,->12) (24) = INIT_FCALL(,"encode") (24) = SEND_VAR($cipher,) (24) var_6 = DO_UCALL(,) (24) = RETURN(var_6,)encode($string) // function_table key=encode (3) $string = RECV(,) (4) = ASSIGN($hex,"") (5) = ASSIGN($i,0x0) (5) = JMP(->20,) (6) = INIT_FCALL(,"dechex") (6) = INIT_FCALL(,"ord") (6) var_4 = FETCH_DIM_R($string,$i) (6) = SEND_VAR(var_4,) (6) var_4 = DO_ICALL(,) (6) = SEND_VAR(var_4,) (6) var_4 = DO_ICALL(,) (6) = ASSIGN($tmp,var_4) (7) tmp_5 = STRLEN($tmp,) (7) tmp_4 = IS_EQUAL(tmp_5,0x1) (7) = JMPZ(tmp_4,->18) (8) tmp_4 = CONCAT("0",$tmp) (8) = ASSIGN_CONCAT($hex,tmp_4) (8) = JMP(->19,) (10) = ASSIGN_CONCAT($hex,$tmp) (5) = PRE_INC($i,) (5) tmp_5 = STRLEN($string,) (5) tmp_4 = IS_SMALLER($i,tmp_5) (5) = JMPNZ(tmp_4,->4) (13) = RETURN($hex,)对flag.php.bin进行反编译,一种可能的结果展示function main (){    $flag = "input_your_flag_here"; //  (27)    if ( encrypt( "this_is_a_very_secret_key", $flag ) === "85b954fc8380a466276e4a48249ddd4a199fc34e5b061464e4295fc5020c88bfd8545519ab" )    {        echo "Congratulation! You got it!"; //  (30)        die; //  (35)    }    echo "Wrong Answer"; //  (32)    die; //  (35)}function encrypt ( $pwd, $data ) // function_table key=encrypt{    mt_srand( 0x539 ); //  (17)    $cipher = ""; //  (18)    $pwd_length = strlen( $pwd ); //  (19)    $data_length = strlen( $data ); //  (20)    $i = 0x0; //  (21)    for ( ; $i < $data_length; ++$i )    {        $cipher .= chr( ord( $data ) ^ ord( $pwd ) ^ mt_rand( 0x0, 0xff ) ); //  (22)    }    return encode( $cipher ); //  (24)}function encode ( $string ) // function_table key=encode{    $hex = ""; //  (4)    $i = 0x0; //  (5)    for ( ; $i < strlen( $string ); ++$i )    {        $tmp = dechex( ord( $string ) ); //  (6)        if ( strlen( $tmp ) == 0x1 )        {            $hex .= "0" . $tmp; //  (8)        }        else        {            $hex .= $tmp; //  (10)        }    }    return $hex; //  (13)}与flag.php对比了一下,反编译结果能用。encrypt()是个对称加密算法,异或,因此decrypt()几乎一样,除了不要encode()返回结果。<?php//// 前半截取自OPcacheDecompile_x64_7.0.x.py的输出结果//function encrypt ( $pwd, $data ) // function_table key=encrypt{    mt_srand( 0x539 ); //  (17)    $cipher = ""; //  (18)    $pwd_length = strlen( $pwd ); //  (19)    $data_length = strlen( $data ); //  (20)    $i = 0x0; //  (21)    for ( ; $i < $data_length; ++$i )    {        $cipher .= chr( ord( $data ) ^ ord( $pwd ) ^ mt_rand( 0x0, 0xff ) ); //  (22)    }    return encode( $cipher ); //  (24)}function encode ( $string ) // function_table key=encode{    $hex = ""; //  (4)    $i = 0x0; //  (5)    for ( ; $i < strlen( $string ); ++$i )    {        $tmp = dechex( ord( $string ) ); //  (6)        if ( strlen( $tmp ) == 0x1 )        {            $hex .= "0" . $tmp; //  (8)        }        else        {            $hex .= $tmp; //  (10)        }    }    return $hex; //  (13)}//////////////////////////////////////////////////////////////////////////////function decode ( $string ){    $ret = "";    for ( $i = 0x0; $i < strlen( $string ); $i+=2 )    {        $ret .= chr( intval( $string.$string, 16 ) );    }    return $ret;}function decrypt ( $pwd, $data ){    mt_srand( 0x539 );    $cipher = "";    $pwd_length = strlen( $pwd );    $data_length = strlen( $data );    $i = 0x0;    for ( ; $i < $data_length; ++$i )    {        $cipher .= chr( ord( $data ) ^ ord( $pwd ) ^ mt_rand( 0x0, 0xff ) );    }    return $cipher;}//// php72 -f CTF_ezDoor_test.php//printf(    "%sn",    decrypt    (        "this_is_a_very_secret_key",        decode( "85b954fc8380a466276e4a48249ddd4a199fc34e5b061464e4295fc5020c88bfd8545519ab" )    ));//// php70 -f CTF_ezDoor_test.php//// printf// (//     "%sn",//     encrypt//     (//         "this_is_a_very_secret_key",//         "flag{0pc4che_b4ckd00r_is_4_g0o6_ide4}"//     )// );//// printf// (//     "%sn",//     decrypt//     (//         "this_is_a_very_secret_key",//         decode( "af8b20dc63d276caf90064976e4e6cabb5495f989ae6a24a0603cc2632ec95e603fa66348c" )//     )// );?>zsx指出PHP 7.1改过mt_rand(),LyleMi提供的flag.php中的"85…ab"是用PHP 7.2生成的,为了正确decrypt(),必须用php72跑。同样的明文,php70生成的密文是"af…8c"。本文没有任何技术价值,要点只有一个,如果对PHP Opcode感兴趣,Ian Bouchard的php7-opcache-override是个非凡的起点,可以用它来实战一下"0CTF2018之ezDoor",绝对值得。LyleMi出的这道CTF题真地很有趣,而zsx让VLD作用于OPcache生成的some.php.bin,初见时,很是赞叹。我不会PHP,更不会WEB安全,偶然路过,只是围观一下。相关推荐: 红帽杯 - WriteUpWebfind_it<?php $link = mysql_connect('localhost', 'root'); ?><html><head> <tit…
阅读全文
Apple设备可通过利用的“Find My”网络功能收集蓝牙设备信息 安全新闻

Apple设备可通过利用的“Find My”网络功能收集蓝牙设备信息

安全研究人员证实,“Send My”漏洞可以利用苹果的定位服务收集并从附近设备发送信息,然后上传至iCloud服务器。也就是说,苹果公司的“Find My”功能可帮助某些别有用心的人跟踪他们的iOS和macOS设备,这会允许非互联网连接的设备通过使用附近的苹果设备为其上传数据来上传任意数据。Find My网络使用所有活跃的iOS设备作为节点来传输位置数据,这样黑客便有可能模仿AirTag连接到Find My网络并广播其位置的方式,通过加密的广播发送它的位置,而当这个数据被替换成消息时,它可以被加密广播信息所掩盖了。安全研究员Fabian Bräunlein开发了一个概念证明,使用一个微控制器和自定义MacOS应用程序,该应用程序可以通过低功耗蓝牙(BLE)将数据从一个设备广播到另一个设备。一旦连接到互联网,接收设备便可以将数据转发到攻击者控制的Apple iCloud服务器。Bräunlein将该方法称为“Send My”,并提出了该方法的几个用例,包括为物联网(IoT)传感器建立一个良性网络,或随着时间的推移耗尽人们的移动数据计划。考虑到该功能是基于“Find My离线查找系统的隐私和安全设计的固有功能”,苹果几乎不可能阻止这种滥用Find My的行为。Braunlein表示,他的灵感来自于Apple AirTags,Apple AirTag是一款可以挂在随身物品上的蓝牙追踪器。大小跟硬币差不多,方便与任何物品挂在一起,比如你跟钥匙挂在一起,只要钥匙离开配对的iPhone一定范围,手机就会发出声响、跳出警讯通知用户。若第一时间没有收到警讯,也可以透过iPhone的“Find My”定位,一步步找回丢失的钥匙。Braunlein利用了德国达姆施塔特技术大学(Technical University of Darmstadt)的一个团队之前的研究(PDF) ,该团队已经对苹果的Find My网络进行了逆向工程,开发了一个名为OpenHaystack的工具。OpenHaystack允许人们创建自己的附件,这些附件可以被定位器服务找到和跟踪。在此过程中,该团队还发现了系统可能暴露用户身份的漏洞。当通过蓝牙使用时,苹果的“Find My”功能基本上是通过蓝牙众包查找某人的设备或物品的能力,设备之间使用位置信标进行通信。然后,设备的所有者就可以接收到注册在苹果icloud上的“查找我的iPhone”或iOS/MacOS“查找我的手机”应用程序中的设备的位置报告。收集蓝牙设备信息步骤如下:1.当AirTag和Apple Device配对时,会生成一个椭圆曲线密钥对,并将公钥推送到AirTag和一个用于生成滚动公钥的共享密钥;2.AirTag每2秒就发送一次以公钥为内容的低功耗蓝牙广播,使用之前共享的秘密每15分钟更改一次;3.附近的iPhone,Macbook等可识别Find My 的广播,检索其当前位置,使用广播的公共密钥(使用ECIES)对位置进行加密,并上传加密的位置报告;4.在设备搜索过程中,配对的所有者设备会生成AirTag在过去几天使用过的滚动公钥列表,并向苹果服务查询它们的SHA256哈希值。Apple后端返回所请求的密钥ID的加密位置报告;5.所有者设备解密位置报告并显示一个大致位置;要按Bräunlein总结的方式使用该服务,需要许多工程步骤和自定义的硬件。为了发送数据,他编写了一个低成本的ESP32微控制器作为调制解调器,使用基于openhaystack的固件广播一个硬编码的默认消息,然后在串行接口上监听任何新数据的循环广播,直到接收到新消息为止。然后,启用了Find My服务的附近的Apple设备可以接收这些信号并将其发送到Apple的服务器。为了检索数据,Bräunlein也开发了一个基于OpenHaystack的MacOS应用程序,该应用程序使用具有提高权限的Apple Mail插件将经过身份验证的位置检索请求发送到Apple后端。用户会被提示输入4字节的调制解调器ID(可以在刷新ESP固件时设置),之后应用程序将自动获取、解码并显示消息。之后,用户可以获取其他信息或改变调制解调器。Bräunlein想到了Send My利用方法的几种用途。一种方法是将物联网设备连接在一起,以更有效地共享互联网连接。这是使用Amazon 的Sidewalk网络和Echo设备显示的场景;然后,可以使用iOS设备使用“Send My”来创建相同的信息。由于Finding设备会缓存收到的广播,直到它们具有Internet连接,只要人们经过该区域,传感器甚至可以从没有移动覆盖的区域发送数据。对于有更险恶意图的人来说,这种方法可能被用来从某些气密系统或高安全性法拉第笼屋子中窃取数据。法拉第笼是由导电材料制成的外壳,用于阻止电磁场并防止通信信号穿透。攻击者可能会使用Send My来耗尽附近的iPhone的移动数据计划,尽管系统上发送的广播信息的数据容量不是很大(以千字节为单位),所以这种消耗可能需要一段时间。Bräunlein说:由于Finder设备的位置报告数量有限(由于1字节计数值,每次提交255个报告),每个报告都超过100字节,广播许多独特的公钥应该会导致手机发送的移动流量的放大。完整的技术细节可在本周发布的研究人员博客文章中找到。参考及来源:https://threatpost.com/apple-find-my-exploited-bluetooth/166121/ 本文始发于微信公众号(嘶吼专业版):Apple设备可通过利用的“Find My”网络功能收集蓝牙设备信息
阅读全文
西数:黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案 安全新闻

西数:黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案

关键词漏洞在遭到一系列远程攻击之后,西部数据(WD)敦促 My Book 用户立即断开互联网连接。在官方公告中,WD 表示 My Book Live 和 My Book Live Duo 网络附加存储(NAS)设备可能通过出厂重置被远程擦除,使用户面临失去所有存储数据的风险。在公告中写道:“西部数据已经确定,一些 My Book Live 和 My Book Live Duo 设备正受到一个远程命令执行漏洞的影响。在某些情况下,攻击者已经触发了出厂重置,似乎是要删除设备上的所有数据”。被利用的漏洞目前编号为 CVE-2018-18472,这是一个根远程命令执行(RCE)漏洞,在 CVSS 严重性评级为 9.8。攻击者能够以 root 身份进行远程操作,他们可以触发重置并擦除这些便携式存储设备上的所有内容,这些设备在 2010 年首次亮相,在 2015 年获得了最后的固件更新。当产品进入报废期时,它们通常无权获得新的安全更新。正如Bleeping Computer首次报道的那样,论坛用户于6月24日开始通过WD论坛和Reddit查询他们的数据突然丢失的情况。一位论坛用户认为,由于他们的信息被删除,自己 "完全完蛋了"。另一位用户评论道:“我愿意拿出我的毕生积蓄来获取我的博士论文数据、我孩子和死去的亲戚的新生照片、我写的但从未发表的旅行博客以及我过去7个月的所有合同工作。我甚至不敢想这对我的职业生涯会有什么影响,因为我失去了所有的项目数据和文件...”。在撰写本文时,论坛用户正在交易潜在的恢复方法和想法,并有不同程度的成功。西部数据说:“我们正在审查我们从受影响的客户那里收到的日志文件,以进一步确定攻击和访问机制的特征”。到目前为止,这些日志文件显示,My Book Live设备是通过直接在线连接或端口转发在全球范围内被攻击的。WizCase之前已经公布了该漏洞的概念验证(PoC)代码。在某些情况下,攻击者还安装了一个木马程序,其样本已被上传到VirusTotal。My Book Live设备被认为是参与这次广泛攻击的唯一产品。西部数据的云服务、固件更新系统和客户信息被认为没有被泄露。西部数据正在敦促客户尽快将他们的设备从互联网上撤出。西部数据说:"我们知道我们客户的数据非常重要。"我们还不明白为什么攻击者触发了出厂重置;但是,我们已经获得了一个受影响设备的样本,正在进一步调查"。该公司还在调查受影响客户的潜在恢复方案。   END  推荐阅读【安全圈】赶快更新BIOS 戴尔电脑曝出漏洞:可被远程控制 3000万台中枪【安全圈】新的勒索软件被发现可以利用虚拟机发动攻击【安全圈】Clop勒索软件团伙在警方展开突袭行动后又曝光了两位受害者安全圈←扫码关注我们网罗圈内热点 专注网络安全实时资讯一手掌握!好看你就分享 有用就点个赞支持「安全圈」就点个三连吧! 本文始发于微信公众号(安全圈):【安全圈】西数:黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案
阅读全文
靶场攻略 | Me-and-My-Girlfriend(vulnhub) 安全文章

靶场攻略 | Me-and-My-Girlfriend(vulnhub)

0x00 前言大家好,我是Jihan,最近复现了一个非常有意思的靶机,就想把它分享出来。本人小白一个,文章写的不是很好,希望会的大佬勿喷0x01 靶机环境1. 靶机下载下载地址:https://download.vulnhub.com/meandmygirlfriend/Me-and-My-Girlfriend-1.ova2. 靶机介绍靶机难度:简单靶机目标:拿到两个flag3. 靶机导入第一步:导入(打开虚拟机-->选择下载的靶机-->选择存储路径-->导入)注:会报导入失败的错误,点击重试即可。                              第二步:导入后,删除网卡并重新添加(NAT网卡)第三步:启动虚拟机0x02 信息收集1.  nmap扫描确定靶机ipnmap -sS -Pn 192.168.159.0/24继续扫描获得靶机ip:192.168.159.173开放端口:22、80等端口,是Apache服务器2. web界面访问发现拒绝访问,试着查看一下页面源代码0x03 漏洞利用1. 使用firefox插件ModHeader,添加请求头X-Forwarded-For然后刷新页面,发现可以成功访问我们发现,有登录界面2. dirb目录扫描既然来到这里了,那我们就扫一下目录试试dirb http://192.168.159.173格式:dirb <url_base> -a 设置user-agent-p <proxy>设置代理-c 设置cookie-z 添加毫秒延迟,避免洪水攻击-o 输出结果-X 在每个字典的后面添加一个后缀-H 添加请求头-i 不区分大小写搜索扫出/config和/misc两个目录,我们试着访问一下这两个目录3. 访问目录打开config.php和process.php,发现是一片空白有个robots.txt,访问下看看发现下面有个heyhoo.txt,哇,有惊喜,打开看看是我胡思乱想了,还是老老实实拿shell吧,我们回到登录页面4. 登录页面在这里一顿乱试,输了个username:admin,password:123,居然成功了。登录进去我们发现里面有个profile文件,点一下试试,跳转到我登录的页面,好了,开整!!!眼睛亮的童志们想必发现了,在登录后的url的参数user_id=14,而不是1,那么之前的那些用户名中是不是藏有管理员的登陆密码呢?5. 修改参数修改url的参数为1:突然发现框中值都变了,那么我们依次输入值,那么数字那么多,最大应该是多少呢?最大的数值是14,因为我们登录账号后,我们的ID是14想看到Password的值也非常简单,右键点击检查,from表单中input value的值即为密码,或者把type="password"为type="text"依次类推将这些密码遍历出来,先放到记事本中。当然这里可以写脚本,本人小白一个,不是很会写,会的大佬可以试一试Eweuh TandinganeweuhtandinganskuyatuhAing MaungaingmaungaingmaungSunda TeasundateaindONEsiaSedih Aing MahsedihaingmahcedihhihihiAlice Geulisalice4lic3Abdi Kasepabdikasepakdorrrrr这里遍历出6个账号密码,那么既然账号密码有了,就尝试呗,还犹豫什么。6. 登录靶机因为下载靶机的时候,有一个靶机背景description,所以我们首先尝试 用户名:alice,密码:4lic3居然成功了查看一下目录文件发现一个小秘密,查看一下得到第一个flag,并且有一段提示,翻译一下,意思是第二个flag必须要提权了格雷特,我哥哥!你看到爱丽丝的便条了!现在保存记录信息给bob!我知道如果给了他,鲍勃会受伤的,但这总比鲍勃被骗好!现在您的最后一个任务是访问根目录并读取flag^_^再查看一下my_notes.txt哇哦!我喜欢这家公司,我希望这里有一个比鲍勃更好的合作伙伴,希望鲍勃不知道我的笔记没啥用,那就整root吧0x04 提权因为是apache服务器,看一下网站的配置文件/var/www/html得到数据库账号密码,尝试提权拿到第二个flag,over!!! 本文始发于微信公众号(贝塔安全实验室):靶场攻略 | Me-and-My-Girlfriend(vulnhub)
阅读全文
vulnhub之Me-and-My-Girlfriend的实践 安全文章

vulnhub之Me-and-My-Girlfriend的实践

本周末实践的是vulnhub的Me-and-My-Girlfriend镜像,比较简单,下载地址,https://download.vulnhub.com/meandmygirlfriend/Me-and-My-Girlfriend-1.ova,用workstation打开,能扫描到地址,sudo netdiscover -r 192.168.137.0/24,接着做端口扫描,sudo nmap -sS -sV -T5 -A -p- 192.168.137.116,看有http,用浏览器访问看看,提示只能本地访问,查看源码,提示可以通过改变x-forwarded-for来访问,给firefox浏览器安装Header Editor,填上x-forwarded-for,再次访问,能访问到页面了,注册一个账号登录进去,访问到Profile页面,发现改变id号就能得到其它账号的信息,查看源码,可以得到明文密码,就这样,一直改变id,从1到13,除了自己注册的,还得到其它6组账号密码,eweuhtandingan/skuyatuh,aingmaung/qwerty!!!,sundatea/indONEsia,sedihaingmah/cedihhihihi,alice/4lic3,abdikasepak/dorrrrr,反正数量也不多,一个个试了一下ssh登录,只有alice/4lic3成功了,不是root,需要提权,sudo -l,发现php是以root权限运行的,还记得以前实践过的通过gtfobins查找各种程序的提权方法吧,直接查到,命令一敲,直接拿到root权限, 本文始发于微信公众号(云计算和网络安全技术实践):vulnhub之Me-and-My-Girlfriend的实践
阅读全文
全球西部数据NAS存储设备数据被神秘擦除 安全新闻

全球西部数据NAS存储设备数据被神秘擦除

点击蓝字关注我们全球的西部数据(WD)My Book NAS用户发现他们的设备被神秘地擦除(被执行恢复出厂设置并删除了所有文件)。WD My Book是一种网络连接的存储设备,它体积很小,看上去就像一本立在办公桌上的书。WD My Book Live应用程序允许用户远程访问他们的文件和管理他们的NAS设备,即使该NAS设备位于防火墙或路由器之后。上周,全球的WD My Book用户突然发现他们的所有文件都被神秘删除了,而且无法再通过浏览器或应用程序登录设备。当他们尝试通过Web仪表板登录时,设备声明他们的密码“无效”。“我有一台WD My Book实时连接到我的家庭局域网并且正常使用了多年。我刚刚发现不知何故今天它上面的所有数据都消失了,目录都在但文件都不见了。之前我的2T卷几乎已满,但现在它几乎是个空盘。更奇怪的是,当我尝试登录控制UI进行诊断时,我只能使用‘用户密码’的输入框进入此登录页面。”WD My Book用户在西部数据社区论坛上说道。My Book设备接到恢复出厂设置的神秘远程命令越来越多的My Book用户确认他们的设备遇到了同样的问题。MyBook日志显示这些设备都收到了一个远程命令,要求从昨天下午3点左右开始执行恢复出厂设置,一直持续到晚上。与通常连接到互联网并受到QLocker Ransomware等攻击的QNAP设备不同,西部数据My Book设备置于在防火墙后面,并通过My Book Live云服务器进行通信以提供远程访问。一个远程代码执行漏洞一些用户表示担心西部数据的服务器被黑客入侵,向连接到该服务的所有设备推送远程恢复出厂设置命令。如果是黑客在“清空”全球的My Book设备,那么蹊跷的是,没有人报告赎金勒索或其他威胁,这意味着这次黑客攻击是一个纯粹的破坏性活动。一些受此攻击影响的用户报告说使用PhotoRec文件恢复工具成功恢复了他们的一些文件,但其他用户并没有那么幸运。在最新的公告中,西部数据确认了恶意软件是数据擦除的原因:“Western Digital已确定某些My Book Live设备受到恶意软件的攻击。在某些情况下,这种攻击会导致恢复出厂设置,似乎会擦除设备上的所有数据。”对于WD My Book Look NAS设备的用户,西部数据强烈建议断开设备与互联网的连接。“此时,我们建议您断开My Book Live和My Book Live Duo与互联网的连接,以保护您在设备上的数据。”西部数据在一份公告中表示。据悉,My Book Live设备收到的最后一次固件更新在2015年。此后,一个编号CVE-2018-18472的远程代码执行漏洞与公开的概念验证漏洞一起被披露。攻击者对互联网进行了大规模扫描以查找易受攻击的设备,并利用此漏洞发出恢复出厂设置的命令。相关阅读 大量QNAP NAS设备遭受勒索软件攻击黑客攻击的下一个热点:路由器和NAS漏洞留神个人数据被一锅端:家用NAS再次曝出勒索软件漏洞合作电话:18610811242投稿邮箱:[email protected] 本文始发于微信公众号(安全牛):全球西部数据NAS存储设备数据被神秘擦除
阅读全文
苹果Find My特征bug暴露用户位置信息 安全新闻

苹果Find My特征bug暴露用户位置信息

网络安全研究人员再苹果蓝牙位置追踪系统中发现了2个不同的设计和实现漏洞,攻击者利用这些漏洞可以发现位置相关的攻击,并实现过去7天位置历史信息的非授权访问。该研究成果是德国达姆施塔特工业大学Open Wireless Link (OWL)项目的研究成果,该项目主要研究苹果无线生态中的安全和隐私问题。Find My原理Apple 设备中自带了一个名为Find My的特征,目的是为了更好的定位其他苹果设备,包括iPhone、 iPad、 iPod touch、 Apple Watch、 Mac、 AirPods等。在iOS 14.5 中,苹果还将支持名为AirTags的蓝牙追踪设备,用来与Find My app的追踪功能相匹配。Find My的底层技术是2019年引入的offline finding,苹果设备通过广播Bluetooth Low Energy (BLE) 信号使得其他近距离的苹果设备可以中继其位置信息到苹果的服务器。与offline finding不同的是,offline loading使用的位置追踪机制是点对点加密和匿名的,目的是隐藏其运动性,因此包括苹果在内的第三方都无法解密这些位置信息,也就无法追踪某个特定用户。具体来说,是通过轮换密钥方案实现的,即为每个设备生成一对公私钥对,然后通过编码公钥的方式发出蓝牙信息。重要信息之后会通过iCloud与相同用户(比如同一个Apple ID)的其他苹果设备同步。接收到这一消息的附近的iPhone或iPad 会检查自己的位置,然后使用前面提到的公钥加密该信息,然后和公钥哈希一起发送到云端。最后,苹果会发送丢失设备的加密位置信息到相同Apple ID登陆的其他苹果设备中,设备所有者可以使用Find My app和对应的私钥来解密报告内容,提取位置信息。漏洞和问题因为该方法有公钥加密 (PKE) 过程,苹果公司由于没有私钥所以不能解密位置信息。但是苹果公司并没有说清楚密钥轮换的频率,循环密钥对结构使得恶意攻击者很难利用蓝牙信标来追踪用户位置移动。OWL研究人员分析发现如果不同设备所有者的位置信息都是通过相同的finder设备报告的,那么苹果公司就可以构建一个巨大的用户网络图。研究人员称,执法机构可以利用该设计漏洞来对用户进行去匿名化,即使用户将手机置于飞行模式。研究人员还发现,攻击者还可以利用macOS Catalina 漏洞CVE-2020-9986 来访问解密密钥,然后用密钥下载和解密find my网络提交的位置报告,最终以高准确率定位和识别受害者。苹果公司回应称已经部分解决了相关问题,在2020年11月发布的macOS 10.15.7 版本中改善了访问限制。完整研究报告参见:https://arxiv.org/pdf/2103.02282.pdf参考及来源:https://thehackernews.com/2021/03/bug-in-apples-find-my-feature-couldve.html 本文始发于微信公众号(嘶吼专业版):苹果Find My特征bug暴露用户位置信息
阅读全文