Web应用隔离防护之Web弱口令爆破

  • A+
所属分类:安全文章

Web应用隔离防护之Web弱口令爆破

01 背景


近些年来,国内政府和企业网站被篡改的类似黑客攻击入侵事件频出,造成的社会影响及经济损失巨大越来越多的企事业单位高度重视Web应用安全。

其中,黑客针对Web应用资产发起的弱口令攻击尤为常见。

即黑客通过已有的大量账号信息,快速批量验证能够访问目标Web资产的账号。这种攻击方式由于利用难度不大,且一旦获取到目标系统的弱口令进入目标Web系统,可以扩大攻击者的攻击范围,被广为使用。


02 常见的Web弱口令攻击场景


一类是为了获取目标应用的访问权限,对账号(如Admin、Root等)的密码进行尝试;

另一类是为了获取到目标系统的用户群体信息,如通过对大量手机号的尝试登录,碰撞目标系统可能存在的用户群体,并对碰撞出的用户群,进行有针对性的商业活动。


03 Web弱口令攻击手法


Web弱口令常见的攻击手法有:准备攻击字典、执行爆破。


3.1 准备攻击字典


进行Web弱口令攻击前,黑客需要预先准备攻击用的账号/密码字典。最常见的途径,是通过之前各大网站泄露的口令,进行分类统计和汇总。

2021年初NordPass发布了2020年的弱口令调查统计结果,第一位的还是连续多年霸榜的123456。


Web应用隔离防护之Web弱口令爆破



图3-1 弱口令排名


基于历年外泄的用户密码信息,很多攻击者会按照不同的维度,整理出常见用户和常用密码的字典。


Web应用隔离防护之Web弱口令爆破


图3-2 口令字典样例


很多Web应用系统出厂时提供的默认账号口令也会成为攻击者利用的对象。


Web应用隔离防护之Web弱口令爆破


图3-3 部分常用安全设备弱口令


对特定攻击目标的账号和密码,黑客可利用社工手段进行收集和生成,如对用户账号的信息收集,通过社交站点、脉脉、领英、招聘类网站等,都可以或多或少找到相关目标的人员信息。



Web应用隔离防护之Web弱口令爆破



图3-4 某站点可搜索到的人员信息


一般情况下,能够获取到企业人员信息,企业内各Web系统的账号基本也能获取到。虽然各家企业的账号命名方式略有不同,但是据统计,最常使用的是姓名的全拼。

而且,存在部分公司在开通员工账号时,会使用统一的初始密码,且没有强制要求账号在初始登录后就修改密码。




Web应用隔离防护之Web弱口令爆破


图3-5 某系统默认密码


一些企业会使用一种常见也被广泛使用的口令生成方式,是根据目标系统所在公司名称、域名等内容,进行有针对性的拼接生成。


Web应用隔离防护之Web弱口令爆破


图3-6 口令生成工具


3.2 执行爆破


字典准备完成之后,实施攻击的核心是查找和抓取登录接口,将字典内容填入接口内,进行快速的登录尝试,根据目标站点的响应内容判断攻击结果。

相关接口的来源比较多,部分场景下,直接通过Web页面内的登录/注册页面就可以定位到,某些则可能需要目录爆破以及搜索JS内容才能获取到。


Web应用隔离防护之Web弱口令爆破


图3-7 获取登录接口


如果相关登录接口需要调整的内容不多,可直接利用Burpsuite之类的发包工具完成,或者需要预先编写脚本,对要使用的登录信息进行预处理,如对用户名进行Base64编码,以满足服务端对此接口的接收要求。


Web应用隔离防护之Web弱口令爆破


图3-8 Burpsuite爆破攻击


04 常见应对方式


针对长久以来的Web弱口令攻击问题,防守方也形成了众多的防御方法。


4.1 口令生成强制安全策略


在口令生成的时候,需要满足一定的安全策略,才会被系统接受,如常见的口令生成安全策略:

1)长度大于8;

2)包含数字和字母;

3)字母包含大小写;

4)包含特殊字符。


4.2 口令管理安全策略


常见的口令安全管理策略,主要有以下方面:

1)定期修改密码,如每三月一改;

2)建立统一账号登录系统;

3)双因子认证;

4)验证码;

上述的口令生成策略并不能完全规避弱口令的生成,比如Qwer1234就符合上述的生成策略,但是因为其“便利”的键盘顺序,为很多人所使用。

口令管理安全策略,如果实现或者管理不当,同样会出现问题。定期修改的密码,新密码与旧密码相比,可能只是最后的尾数做了修改;

双因子的具体实现中,如果双重验证因子没有进行有效的限制,同样存在被爆破的可能;验证码的自动识别以及人工打码,已经形成了一条黑色产业。


05 Web应用隔离防护


钛星Web应用隔离系统采用了另外一种防护方式,将用户与实际的Web应用系统隔离,对用户隐藏与Web服务端的交互细节,能有效防护针对Web应用的弱口令攻击行为。


5.1 架构说明


Web应用隔离防护之Web弱口令爆破


图5-1 Web应用隔离架构


在架构上,Web应用隔离系统串接于用户浏览器与真实的Web应用服务器之间,对用户透明,用户端浏览器不需做任何配置上的调整。

Web隔离系统与Web服务器之间保持原有的访问交互方式,对用户提供原有服务的“镜像”,隐藏服务端的所有代码层面的细节,基于用户在浏览器端的行为与真实服务器进行交互。


基于这种架构,Web应用隔离主要完成两方面的任务:

任务一,接收用户在浏览器上触发的鼠标键盘操作事件及Get请求,将鼠标键盘事件转化成真实的请求(比如Post、Put等),以及Get请求,发送给Web服务器;

任务二,将源网站所有的活动脚本及API在Web隔离平台执行,重构网页内容,返回给用户浏览器,即用户侧浏览器上,隔离系统展示的Web页面,与用户直接访问原网站相同,但是不含源网站活动脚本及API等信息。


5.2 防御原理


传统的防御方式,一是增加身份验证接口的访问难度,从多个维度上,对用户身份进行鉴定,只有多个维度都满足条件,才会允许通过。二是不断对来自用户的请求进行检测,当发现有大量的异常请求时,再通过安全设备对相关请求进行拦截。

钛星的Web应用隔离防护产品,采用了不同的防御方式。


5.2.1 脚本及API隐藏


Web弱口令攻击的前提及核心是能够找到口令输入的接口,并且接口的响应内容,能够对账号或密码的可用状态进行区分。

Web应用隔离系统会把Web应用服务器的内容,以视觉流的方式,发送给用户端的浏览器,隐藏真实的活动脚本及API,让攻击者无法探测到具体的API,从而无法进行攻击。

正常访问模式下,JS代码中通常包含了大量的接口地址和参数,甚至有的站点因为配置不当,导致Webpack信息对外可见。


Web应用隔离防护之Web弱口令爆破


图5-2 JS信息暴露


Web应用隔离模式下,相关JS代码止步于Web应用隔离服务端,Web用户的浏览器侧只保存有少量客户浏览器与隔离服务端的交互JS。


Web应用隔离防护之Web弱口令爆破


图5-3 隔离模式源码差异


5.2.2 HTTP请求类型过滤


即使通过某种方式,攻击者拿到了真实服务器的认证API,也无法利用。

隔离系统只接受Get请求和用户产生的鼠标键盘操作事件,其它类型如Post、Option、Head等,隔离平台不接受并丢弃,不会传递相关请求到真实Web服务器,这将拦截大部分的爆破流量。


Web应用隔离防护之Web弱口令爆破


图5-4 构造请求数据被拦截


5.2.3 请求URL加密


Web应用隔离模式下,Web浏览器与Web应用隔离设备之间进行交互,以HTTP Get的方式进行。

即Web应用隔离设备只接收客户浏览器发送过来的Get请求,其它类型的请求不再处理。且URL采用了加密,对于通过URL实现的一些攻击方式实现了完全免疫。


Web应用隔离防护之Web弱口令爆破


图5-5 URL加密工作原理


下图为加密后的效果,浏览器地址栏,原有的URL地址中,Host保持不变但其后的Path内容,以加密字符串的方式展示和使用,原有URL不再可用。


Web应用隔离防护之Web弱口令爆破


图5-6 URL加密效果


5.2.4 弱口令输入检查


Web应用隔离系统能够对页面中的密码输入进行识别,并对输入的口令进行检测。当检测到弱口令时,可根据系统预置安全策略(阻止、提示用户修改、仅记录)进行处理。这种方式不需对业务系统进行改造,可有效防范和检测弱口令的生成和使用。


综上,Web应用隔离系统可以完全防护对Web应用系统的弱口令攻击,从根本上解决问题,让服务方从容应对外部安全威胁,为Web用户提供安全稳定的服务。


Web应用隔离防护之Web弱口令爆破

原文始发于微信公众号(疯猫网络):Web应用隔离防护之Web弱口令爆破

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: