philm-iOS-wiki
  • 介绍
  • 网络层
    • 说明
  • UI
    • 说明
    • 在ios7以前使用ColorSpace的坑
    • UITableView偏移异常问题
    • drawRect时单独设置文字阴影无效
    • Xcode9下相册访问权限问题
    • 避免同时点击多个Button
    • scroll上的button延迟响应问题
    • uibutton触发边界事件
    • ios 11 上tableview 改动
    • YYImage 显示指定区域的图片
  • 数据持久化
    • 说明
  • 其它
    • 取消延迟执行之坑
    • NSString 转换 float 的精度问题
  • 每周阅读
    • 目录
    • 深入思考NSNotification
    • gitBook使用小助手
    • iOS App签名的原理
    • 响应链
    • iOS10跳转系统到设置页
    • SDWebImage下载高清图内存问题
    • iOS圆角避免离屏渲染
    • 常用的延时调用
    • iOS 神经网络
    • SDWebImage缓存策略
    • 3Dtouch
    • 为什么 Objective-C 对象存储在堆上而不是栈上
    • 深入浅出理解视频编码H264结构
    • CATextLayer学习
    • cocoaPods
    • 任意网站支持RSS
    • Metal简介
    • 动态更改icon
    • CAReplicatorLayer
    • 增加点击间隔
    • 勒索病毒当道的时代
    • iOS常用宏定义
    • Metal实现YUV转RGB渲染视频
    • 获取当前下载的app及下载进度
    • OpenGL ES 三种类型修饰 uniform attribute varying
    • 技术部门引入OKR
    • 基于runloop的线程保活、销毁与通信
    • 深入理解哈希表
    • TOLL-FREE BRIDGING 和 UNMANAGED
    • 开发者能拿到的标识符
    • Swift自定义LOG
    • 系统通知整理
    • iOS 中的 imageIO 与 image 解码
    • CGImageRef基本介绍及方法说明
    • Swift 3.0 语法
    • webview加载部分网页
    • 在CAAnimation中暂停动画
    • 把代码迁移到协调器上
    • ios11API更新整理
    • 非越狱iOS设备的远程控制实现原理
    • 关于本地化
    • swift命名空间
    • CoreML与coremltools体验
    • 力学动画
    • Swift 4官方文档中文版: The Basic(上)
    • swift 中的KVO用法
    • GPUImage的图像形变设计(简单形变部分)
    • iOS响应式架构
    • 移动端图片上传旋转、压缩的解决方案
    • AVFoundation使用指南AVAssert使用
    • 过渡动画
    • 谈谈 MVX 中的 Model
    • AVFoundation编程-AVPlayer使用
    • GPUImage的图像形变设计(复杂形变部分)
    • What's New in LLVM 9
    • ios的事件机制
    • GPUImage源码解读(一)
    • GPUImage源码解读(二)
    • iOS 启动优化
    • 模块化 Swift 中的状态
    • swift中的let和var背后的编程模式
    • Swift Runtime动态性分析
    • RAC下的响应式编程
    • GPUImage源码解读(三)
    • 如何准确判断webView是否加载完成
    • NSObject的+load和+initialize详解
    • ios8以后设置启动图
    • GPUImage源码解读(四)
    • Swift自动闭包
    • IOS11新特性
    • GPUImage源码解读(五)
    • 理解 OC 内部的消息调用、消息转发、类和对象
    • 修饰符
    • IOS 切面统计事件解耦
    • GPUImage源码解读(六)
    • CoreImage介绍
    • 影响Core Animation性能的原因
    • Instruments中的动画工具选项介绍
    • GPUImage源码解读(七)
    • Xcode 7新的特性Lightweight Generics 轻量级泛型与__kindof修饰符
    • GPUImage源码解读(八)
    • Core Image之自定 Filter
    • iOS通用链接
    • 谈nonatomic非线程安全问题
    • 深拷贝与浅拷贝
    • CIKernel 介绍
    • iOS11适配
    • GPUImage源码解读(九)
    • CVPixelBufferCreate使用的坑
    • ios一窥并发底层
    • ARKit进阶:物理世界
    • ARKit的工作原理及流程介绍
    • UI线程卡顿监控
    • FBKVOController使用
    • GPUImage源码解读(十)
    • WKWebView在ios11崩溃问题解决方法
    • 微信iOS SQLite源码优化实践
    • HEIF 和 HEVC 研究
    • 谈谈 iOS 中图片的解压缩
    • 提升 iOS 开发效率! Xcode 9 内置模拟器的9个技巧
    • ObjC和JavaScript的交互,在恰当的时机注入对象
    • iOS数据保护
    • iOS11中网络层的一些变化(Session707&709脱水版)
    • GPUImage源码解读(十一)
    • 一种避免 iOS 内存碎片的方法
    • pods的原理
    • GPUImage源码解读(十二)
    • GPUImage源码解读(十三)
    • iOS 11 Layout的新特性
    • iOS应用瘦身方法思路整理
    • GPUImage源码解读(十四)
    • CAEmitterLayer属性介绍
    • 浅析移动蜂窝网络的特点及其省电方案
    • 如何在 table view 中添加 3D Touch Peek & Pop 功能
    • iOS中锁的介绍与使用
    • NSLog效率低下的原因及尝试lldb断点打印Log
    • GPUImage源码解读(十五)
    • GPUImage源码解读(十六)
    • CADisplayLink
    • GPUImage源码解读(十七)
    • CADisplayLink
    • 老生常谈category增加属性的几种操作
    • 30行代码演示dispatch_once死锁
    • GPUImage源码解读(十八)
    • YYImage设计思路
    • GPUImage源码解读(十九)
    • 深入理解Tagged Pointer
    • iOS 11:WKWebView内容过滤规则详解
    • Swift语法对编译速度的影响
    • GPUImage源码解读(二十)
    • GPUImage源码解读(二十一)
    • iOS App间常用的五种通信方式
    • YYCache深入学习
    • 冲顶大会插件
    • iOS高性能图片架构与设计
    • YUV颜色编码解析
    • iOS传感器:App前后台切换后,获取敏感信息使用touch ID进行校验
    • GPUImage源码解读(二十二)
    • GPUImage源码解读(二十三)
    • 从零开始的机器学习 - Machine Learning(一)
    • 从零开始的机器学习 - Machine Learning(二)
    • GPUImage源码解读(二十四)
    • Objective-C消息转发机制
    • iOS 程序 main 函数之前发生了什么
    • MMKV--基于 mmap 的 iOS 高性能通用 key-value 组件
    • Objective-C 消息发送与转发机制原理
    • 谈Objective-C block的实现
    • GPUImage源码解读(二十五)
    • podfile语法
    • 轻量级低风险 iOS 热更新方案
    • 使用objection来模块化开发iOS项目
    • swift 中delegate的使用注意
    • 使用appledoc自动生成api文档
    • UITextChecker的使用
    • ARKit 如何给SCNNode贴Gif图片
    • Unity与iOS平台交互和原生插件开发
    • SceneKit编程珠玑
Powered by GitBook
On this page
  • 1. 匿名之恶
  • 2. 勒索尾随大漏洞
  • 3. 蠕虫传播可以打破隔离“神话”
  • 4. 成本考虑
  • 5. 一些好习惯
  1. 每周阅读

勒索病毒当道的时代

Previous增加点击间隔NextiOS常用宏定义

Last updated 7 years ago

昨天(2017-05-13)的 WannaCry 勒索蠕虫席卷了全球,即使像我们这样游走在边界的人,也还是吓了一跳。

无数没打 MS-17010 补丁的 Win 电脑或服务器中招,尤其是不少学校、相关单位有各种大内网的,这一波就可能直接导致这些机构工作瘫痪...

全世界铺天盖地的,充斥着下面这个勒索病毒界面:

不用赘述这个过程,说一些这大半年来的一些观点吧,有些大观点在年初开篇时已经提了,摘录如下:

黑客技能的分支领域确实很多很多 黑客攻击无时无刻不在发生,比你想象的可能还要激烈 除了大规模撒网攻击,你几乎没被黑的价值 安全的本质是信任,“紧内聚松耦合”是伟大的思想 黑客攻击里存在上帝视角,防御也一样 任何黑客攻击都不会让互联网毁灭 黑客可以只是一种身份,除此之外,黑客和正常人没什么区别 成本是任何人都需要考虑的重要因素,包括黑客 ...

这次已经载入史册的 WannaCry 勒索蠕虫事件,应该更能引起大众的安全意识吧?虽然我相信,很快会淡忘。无论怎样,下面这几点观点或建议,来自我们这些长期游走在边界的安全人员,希望能触动到你。

1. 匿名之恶

匿名货币如比特币,几乎所有的勒索病毒,都只接收比特币,原因很简单,比特币可以做到匿名,这正是这些犯罪分子最好的挡箭牌。

虽然这并不能否定匿名货币的价值,但这残酷的“恶”事实,你我有目共睹。不说匿名货币,只要是匿名的,总会有一个角度淋漓尽致地暴露人性的丑恶。

我曾经开玩笑说:比特币这么凶猛,真应该感谢这些勒索病毒。

2. 勒索尾随大漏洞

一般一个大漏洞爆发后,由于匿名之恶及巨大的产业利益,随之而来的就是勒索病毒了。这个间隔时间目前来看,一周到一个月几个月的都有可能,而现在应该会越来越快。

从去年进入我们视野的 Redis、MongoDB、ElasticSearch 勒索病毒,到后来只要是个大漏洞(如上个月 Struts2 的 S2-045 漏洞)都来个勒索,这次方程式被泄露的 Eternalblue 漏洞,不到一个月就被尾随来了个震惊全球的 WannaCry...

这个现象应该给我们一个很透彻的教训,一旦一个漏洞爆发,为了不被黑,我们的应急黄金周期需要在 24 小时之内,甚至应该更短。无论业务大还是业务小,都应该不断优化自家的应急黄金周期及应急策略。而如果真的由于各种原因应急滞后一周,那就不得不面对至少可能被勒索蠕虫感染到的风险。

对于我们这些在甲方做安全防御的人来说,这真是内忧外患。外患是要么可能被黑偷走数据要么可能被勒索;内忧嘛,各家有各家的难处,有时候应急快慢得是一场有组织的战役,没有顺畅的内部沟通环境,难。

3. 蠕虫传播可以打破隔离“神话”

当下,国内还是无数单位靠着内网隔离来对抗攻击者,这种方式早被证明非常之脆弱。就比如这次的勒索蠕虫传播,怎么进入大内网的?可以这样:

1) 感染掉一台边界上的 Win 服务器,这台服务器可通内网,于是内网遭殃; 2) 在某个场景下感染了某个人的 Win 电脑,这人跑到其他大内网去上网,于是内网遭殃;

蠕虫嘛,就是这样肆无忌惮地传播,如果再来个感染 U 盘方式,那么传播途径就又多了一条。当年我在大学期间,身处校网络管理团队,并靠着写各种病毒专杀而入这行,后来自己也写了不少各类型的“良性”蠕虫,对蠕虫算是真的情有独钟。现在回头来看看,这么多年过去了,大学网络的脆弱性改善得太慢。

4. 成本考虑

其实这次 WannaCry 勒索蠕虫,截至我发文,才收到不到 17 枚比特币,差不多人民币 17 万。这 17 万,对于这起“震惊全球”来看,确实太少,反而因为这样,导致这个勒索团队不得不优先考虑“跑路”问题,事情搞大了,绝对首当其冲被盯上,17 万够跑一次路。

对于我们来说,我给出一条最中肯的建议:无论电脑手机服务器还是其他任何机器中招了,尽量不要支付任何勒索需要的费用。让一个产业沉寂最好的方式使其亏损。

5. 一些好习惯

除了上面提到的“应急黄金周期”,针对这个事件,还有个好习惯必须养成,那就是:勤备份。个人应该养成重要程度不同的文件的不同周期备份习惯,比如一天、一周的备份策略。

然后,警惕心一定要有。有个有趣现象,前年 iPhone 上的 XcodeGhost 事件,很多用户就喊了“还好我不用 iPhone”,现在这次 WannaCry 事件,又很多用户喊着“还好我不用 Win”。不要侥幸,无论你用什么不用什么,被黑与没被黑不完全由你意识决定,对绝大多数人来说,其实根本轮不到由个人意识来决定是否被黑。

要真黑你,你能躲哪去?:)

最后,这次 WannaCry 勒索蠕虫,如果中招了,确实会有个聪明的但不完备的解决方案,昨晚“懒人在思考”的读者“瘦子风吹不倒”就给我留言说可以通过恢复文件方式来恢复一些文件,原因是因为 WannaCry 没“做得”太狠,感谢这位读者。对如何恢复文件不了解的用户倒是可以参考 360 今天凌晨 2 点发布的恢复工具:

这一点“变通”,360 真是完败了其他安全厂家了。但要注意的是,这是“文件恢复”,并不是解密了被勒索加密的文件,这种加密方式,如果直接硬碰硬,本就可以认为是无解。

对于侥幸还没被黑,且没打补丁的 Win 用户,请参考微软的官方解决方案:

这个解决方案,微软破天方地居然支持了古董 XP,可想而知这次蠕虫事件影响有多么的大。

如果 445 等端口对你来说没特别意义,建议关闭,Win 上自带的防火墙可以设置,自己查查怎么做吧,不再赘述。

在勒索病毒当道的时代,我们要么成为有能力与之对抗的安全人员,要么养成如上所述的好习惯。

https://media.weibo.cn/article?id=2309404107129664487886
https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/