今天我们看到一个通知，多家医院信息系统出现勒索病毒，建议大家检查防范，此病毒只要做好安全措施，不会感染，也不具有传染性，不过一旦发病，系统就会面临瘫痪。
通 知
近期有多家医院出现勒索病毒事件，为了保证医院信息系统安全，近期各个厂家要将自己的设备和系统进行一次完整的体检，并出具体检报告，今天（02月11日）务必将工作计划报上来，需要医院做哪些配合也要一一说明。
基于信息系统安全考虑，各个厂家此次体检报告内要明确本系统都用到那些端口，以后医院安全设备将启动白名单制度，不用端口直接关闭。
疫情还没得到很好的控制，黑客已经复工，由于多数医院的信息化建设落后，风险意识薄弱，成为了众多勒索病毒的攻击目标，本文总结了几种常见的几种数据库勒索病毒，以及检查整改方案，供大家参考。
1、登录脚本AfterConnect.sql被注入
1.1、来源
盗版PL/SQL Developer的AfterConnect.sql脚本被注入病毒，其他工具也存在。
1.2、现象
数据库中存在被加密的存储过程，名字如下：
"DBMS_SUPPORT_INTERNAL "
"DBMS_ SYSTEM_INTERNAL "
"DBMS_ CORE_INTERNAL "
“DBMS_STANDARD_FUN9”
三个触发器名字如下：
"DBMS_SUPPORT_INTERNAL "
"DBMS_ SYSTEM_INTERNAL "
"DBMS_ CORE_INTERNAL "
一旦重启数据库，代码会判断数据库创建时间大于1200天，然后开始truncate某些表以及tab$被删除，恢复起来比较复杂。
详细可以参考：《知己知彼-关于Oracle安全比特币勒索问题揭秘和防范》https://www.modb.pro/db/1737。
1.3、巡检排查
检查是否使用盗版工具，Login.sql、AfterConnect.sql、toad.ini是否被注入。
检查数据库中是否存在以上对象：
SELECT OWNER
, '"'||OBJECT_NAME||'"' OBJECT_NAME
,OBJECT_TYPE
,TO_CHAR(CREATED, 'YYYY-MM-DD HH24:MI:SS') CREATED
FROM DBA_OBJECTS
WHERE OBJECT_NAME LIKE 'DBMS_CORE_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SYSTEM_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SUPPORT%';
SELECT ' DROP '||OBJECT_TYPE||' "'||OWNER||'"."'||OBJECT_NAME||'";' OBJECT_NAME
FROM DBA_OBJECTS
WHERE OBJECT_NAME LIKE 'DBMS_CORE_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SYSTEM_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SUPPORT%';
SELECT JOB, LOG_USER, WHAT
FROM DBA_JOBS
WHERE WHAT LIKE 'DBMS_STANDARD_FUN9%' ;
SELECT ' -- Logon with '||LOG_USER||CHR(10)||' EXEC DBMS_JOB.BROKEN ('||JOB||', ''TRUE'')'||CHR(10)||' EXEC DBMS_JOB.REMOVE('||JOB||')' STMT
FROM DBA_JOBS
WHERE WHAT LIKE 'DBMS_STANDARD_FUN9%' ;
SELECT OWNER,'"'||OBJECT_NAME||'"' OBJECT_NAME,OBJECT_TYPE,CREATED
FROM DBA_OBJECTS
WHERE OBJECT_NAME LIKE 'ORACHK%';
或者使用墨天轮上的脚本直接检测：checkBitAttack_1 modb.pro/download/4
1.4、预防
- 不要下载盗版或者渠道不明的软件
- 规范工具使用，限制IP访问
2、安装包prvtsupp.plb被注入
2.1、来源
多数为网上网盘下载的11204的Linux安装包的prvtsupp.plb被注入病毒。
2.2、现象
核心部分为一个触发器DBMS_SUPPORT_DBMONITOR一个存储过程DBMS_SUPPORT_DBMONITORP，重启触发清空了tab$操作，导致数据库启动时bootstrap阶段无法完成，数据库无法启动，报错ORA-00600: internal error code, arguments:[16703], [1403], [20]
详细参考：《ORA-600_16703比特币攻击案例分析》https://www.modb.pro/db/738
2.3、巡检排查
- 检查文件$ORACLE_HOME/rdbms/admin/prvtsupp.plb是否被注入
- 检查是否有触发器DBMS_SUPPORT_DBMONITOR和存储过程DBMS_SUPPORT_DBMONITORP，参考1.3脚本。
2.14、预防
- 介质全部从官方正规渠道下载
- 安装之前校验介质的MD5
3、云上MySQL常见的勒索方式
由于使用MySQL数据库的部分开发商没有安全意识，直接将MySQL的3306默认端口开放在公网中，并且设置弱密码，过去我们接到过很多次云上数据库勒索的案例，99%都是以上情况。
会删除所有表（当然黑客会将表备份到自己的环境），然后创建一张比特币勒索的信息表：
一旦数据库被删除，恢复起来难度非常高。
所以针对这种情况需要采集以下措施防范，同时适用于其他数据库和服务器
- 定期对数据库进行备份，为磁盘快照
- 修改默认端口，并修改安全组端口不对外网开放，限制IP访问
- 设置复制密码，并定期修改
4、参考
-
我们为全国医疗卫生机构提供免费的数据库远程故障诊断、性能分析、架构咨询、紧急救援等服务，并承诺所有请求即刻响应。《 共克时艰 · 略尽绵薄丨云和恩墨打响三大战“疫”》https://www.modb.pro/db/15411
-
疫情当前，我们针对医疗行业整理了一个专栏，汇集了墨天轮上相关的文章和文档，其中包含医疗信息化建设，高可用容灾架构设计，互联网医疗的落地，医院系统上云，以及日常运维规范和最佳实践，现免费开放给所有同仁。《共克时艰 | 医疗信息化建设架构设计专栏》https://www.modb.pro/topic/15346
