鬼故事 - 这不是後门这是工程模式!

鬼故事 - 这不是後门这是工程模式!

https://ithelp.ithome.com.tw/upload/images/20210913/20141165Liwm0dXnx3.jpg
Credit: sandserif

故事开始

故事回到小弯的公司,
有一天小弯公司收到了资安通报,产品有後门帐号并且密码固定。
这件事让公司整个 RD 部门感到吃惊,为甚麽帐号会被发现?
是的,不是为甚麽有这帐号,而是帐号为甚麽会被发现。

这个帐号有如系统的神,该做的不该做的这个帐号都能做,
所以公司工程师在客户 call 电话进来的时候,
通常都会用这个帐号先行一步替客户 troubleshooting,
如此一来往往都能很快的解决问题,公司也食髓知味继续用这招服务客户,
但既然这个帐号已经被发现,也就代表着这整个流程都要更换了。

虽然这个帐号十分方便,但其实工程师们都知道这样的方式是十分危险的,
况且预设启用加上可以从外部连线,并且密码明文保存还都一样。

资安探讨

"工程"帐号该如何保存

在许多关於这类型的帐号在 CVE 里面最大的问题就是密码被找到/破解,
或是高於其他帐号很多权限(e.g. 操作无纪录、修改系统等...),

所以笔者建议了一些事项,供开发人员参考:
心法:你越方便越偷懒,骇客就越方便,除错流程麻烦一点骇客也比较难利用。

  1. 妥善的保存密码
    保护的方式有许多(e.g. linux shadow password),由於无法直接破解,
    所以攻击者拿到 Hash 是无法利用的,只要密码够强,至少能起到一定保护作用。
  2. 无法远端登入或是预设不开启
    预设不开启应该是标准配备,这样才能最大限度的保证没人会在平常使用这个帐号,
    根据设备情境不同,还可以考虑设定拒绝远端使用此帐号,
    许多国际大厂硬体设备都有所谓的工程帐号/模式,但必须透过启用或是特殊实体介面才能使用,
    确保了客户的资讯安全被保障。
  3. 尽量避免同一密码或是采用 OTP
    避免使用相同密码,以免一组密码外泄整个世界就大乱,
    当设备/软件支援 OTP 强烈建议使用,提升登入保护的强度。

<<:  Day2安装vue我选择的是vue3!!

>>:  不知道有没有人可以帮我解答一下T_T

【Day 30】JavaScript Async/Await

async和await是 ES7 引入的标准之一。建立在 promise 的语法基础上,只要 fun...

[NestJS 带你飞!] DAY21 - HTTP Module

很多时候我们会需要去串接第三方的 API,例如:绿界科技的金流服务、Binance 的 API 等,...

Day1: 开始学习演算法和资料结构的契机

近期面试掀起了一波考演算法的风气,就好像回到大学指考那样,老师说这题会考一定要记起来,因此掀起了一...

Kotlin Android 第22天,从 0 到 ML - Canvas

前言: 今天来介绍使用Canvas 的绘图方法来创建 2D 绘图,并画出触控手势的轨迹。 大纲 : ...

[Day12] 建立订单交易API_5

本节将继续实作内文加密,程序如下 def aes_encrypt(key, content, iv)...