嘲笑别人的 deepseek 偷跑 100 元后,我被偷跑了 2700 元

maomaosang 2026-07-06 18:38 1

一个月前社区有篇帖子《大家抓紧看看 deepseek 开放平台有没有异常 apikey!》,我在一楼对楼主贴脸开大,没想到这么快就轮到我自己了,区别是我被偷跑了 2700 元,是我嘲笑对象的 27 倍。


我被偷跑的平台并不是 deepseek ,而是杭州的另一 LLM 厂商,为了避免麻烦,隐去名字了,下面就叫它杭州厂。


事情是上个月发生的,然而时至今日,我仍然不知道我的 apikey 为何被盗,也请大家帮我分析分析。




我厂是个小作坊,主用火山的豆包模型,杭州厂是故障备份,系统按请求结果自动切换主备。我们每天在火山大约消耗 1 亿 token ,杭州厂这边则是零零星星,一个月消费一两块。


6 月底,杭州厂的商务打电话给我们,说发现 LLM 用量突增,希望线下拜访了解业务,我们这才发现当月 LLM 账单暴增到 2000 多。


在 5 、6 两个月,我们断断续续被盗刷了大约 2755 元。我们的主力业务 apikey ,使用了两个业务不会用到的模型,一个是翻译模型,另一个是个新模型,输入 1.4 亿,输出 3.5 亿,IP 是 114.242.33.* 北京联通家宽。杭州厂的工单人员抽查发现,所有请求都是在干一件事:翻译。而翻译的文本题材天南海北,毫无规律,有些文字甚至都不太通顺。




在更换 apikey 的时候,我们发现了一些很奇妙的事情


我们原本在杭州厂有 4 个 LLM apikey ,创建时间从去年 3 月到今年 4 月。被盗用的是最早的 key ,4 个 key 除去 sk-的前缀后,按照创建时间,开头分别是 0,2,a,d ,看起来是一个自增的 32 位的 uuid 。如果 uuid 的生成算法有缺陷,就可能被撞出来


建立新 key 时,发现杭州厂的 apikey 系统已经彻底革新,新 key 达到了 100 个字符以上的长度,甚至给每个账号提供了不同的 base url ,这就解决了我们担忧的被撞的问题,真是巧啊


工单面对我撞 key 的疑问,在沉默了一周后,回复「 Key 本身也具备足够的安全性,无法被暴力破解」。




当你发现一只蟑螂的时候…… 我们就查了查自己的屋子:



  • 我厂能接触到这个 apikey 的一共 5 个人,至少有 3 年没有程序员离职,除了夜里发布或者紧急修 bug 很少加班,据我所知应该没有人对公司心怀怨恨,吧

  • 我们从不使用中转站,AI 工具都是公司在模型厂商那里直接买的,或者团队成员买了报销,不走任何二道贩子

  • 代码没有托管在任何国产 git 服务商中

  • 所有的 apikey 都写在一处,但其他 llm apikey 没有任何被盗刷的迹象

  • 上个月,因为周额度剩余太多,我们用某顶尖模型扫描过全部代码,agent 干了一整晚,安全报告中没有可能导致 apikey 泄露的漏洞

  • 前段时间的 apifox 问题,团队有一位小伙伴中枪,我们连夜换了 ssh key ,服务器没有任何异地登录迹象


实在是也找不出什么问题。




总之,到最后也没弄明白,黑客到底怎么拿到这个 apikey ,又为什么要翻译那几亿文字。


这件事留下的谜太多了。。。

最新回复 (31)
  • JerryZhi 07-06 18:41
    1
    心疼楼主 1 分钟,虽然钱不多但真挺糟心的。
    另外实在很好奇,能察觉出 uuid 生成算法有问题的人注意力得有多惊人
  • xiaomushen 07-06 18:44
    2
    百炼的调用费用,混在阿里云的账单里,确实很容易被忽略
  • afkool 07-06 18:53
    3
    是不是类似 apifox 之类的事件把凭证上传了?感觉 apikey 跟密码一样,也得没事更新下。。
  • Yserver 07-06 18:59
    4
    百炼说是提供了不同的 baseurl 实际上原来的公用 baseurl 依然可用
  • vexify 07-06 19:03
    5
    盲猜用了开源的组件例如 litellm ,放在公网上,人家专门研究 0day ,扫全网,发现特征,被入侵了都不知道,据我所知,有部分中转站,是扫 key 拿来薅的
  • vexify 07-06 19:05
    6
    2000 多已经很少了,有些公司被刷几万块都不知道呢,业务混在一起的 =_=
  • bluetree2039 07-06 19:07
    7
    恐怖😱
  • ujujzhaos 07-06 19:08
    8
    你们没在阿里的加个限额吗
  • kneo 07-06 19:11
    9
    >杭州厂的工单人员抽查发现,所有请求都是在干一件事:翻译。
    >而翻译的文本题材天南海北,毫无规律,有些文字甚至都不太通顺。

    还能直接看用户数据的啊?都不演一下吗?
  • maomaosang 楼主 07-06 19:19
    10
    @Yserver 😱 确实是没对这里做测试,看来新的 baseurl 只是用来做资源隔离的,不是 random key 的一部分

    @vexify 因为历史原因,调用 llm 的库都是我们自己写的,甚至几乎没有 ai coding 参与,从这套东西里面找开源库的话,得找到 curl 这里去了,确切的说是 php-curl 。

    @ujujzhaos 没有,因为业务上已经有限额了,所以这里没做,确实是疏忽,当天已经加上了。

    @kneo “抽查”是工单人员经过我们授权后查看的,工单里面有一套这样的流程。
  • anivie 07-06 19:39
    11
    @kneo 为什么要演,监管要求本来就要所有数据都留存审查啊。都国内厂的服务了,没直接开摄像头跟我大眼瞪小眼已经很感恩了
  • wang93wei 07-06 19:43
    12
    为啥不看一下 Nginx 之类的访问记录呢?我们之前火山的 seedance 生图的也被刷了,Nginx 访问记录能看到确确实实是直接拿到 env 了,字节码都一致。
  • wang93wei 07-06 19:45
    13
    我们找火山的工作人员看,人家说都是从我们服务器发起的请求。而且是半夜。
  • Mzs 07-06 20:03
    14
    我估计你的想法没错 要不然好端端得为啥 key 的生成方式大变
    杭州厂后端的很多逻辑都还没根据新的 key 规则做变更-相当于是 2 套
  • digitv 07-06 20:04
    15
    据我多年的工作经验,这类问题应该人的可能性更高一些。
  • maomaosang 楼主 07-06 20:05
    16
    @wang93wei 不是业务层被刷的,而是黑客不知怎的拿到了 apikey ,从北京联通家宽发起的请求,我们服务器在杭州上海,团队在上海
  • candyhead 07-06 20:14
    17
    数额太小,报警可能不理
  • hatori 07-06 22:10
    18
    估计是 key 被用在翻译插件里了,很多人用所以翻译啥的都有
  • hatori 07-06 22:11
    19
    @hatori 刚刚没看清,都是同一个 ip 的话那就不好说了
  • o0 07-07 00:47
    20
    这个东西就跟原来 cdn 一样,至少得设置个阈值才安全
  • sunrealzhang 07-07 09:32
    21
    前几天看到微信一篇文章,结合楼主说的翻译问题,我觉得可能性不小,同意 18 楼的观点。
    https://mp.weixin.qq.com/s/bve-dJ4xGneLlzjT6sWANg
  • sunrealzhang 07-07 09:33
    22
    “图 3 揭示了该活动最关键的盈利模型:用户缴纳小额费用后,C2 服务器会将一个可用密钥下发至插件客户端,插件随即优先使用该服务端密钥替代用户自身密钥发起 AI 请求。合理推测,下发的密钥正是从其他受害者处窃取的凭据。攻击者构建了一套以被盗 API 密钥为底层资产的非法 AI 服务分发体系:一侧持续从免费用户处收割密钥,另一侧向付费用户出售算力访问权,形成自给自足的攻击闭环。这种模式将 API 密钥作为流通商品的地下经济运营”
    @sunrealzhang
  • maomaosang 楼主 07-07 10:24
    23
    @sunrealzhang @hatori 感谢分享,我也补一点细节。

    我们在杭州厂的一个 llm apikey ,是专门用于团队内部使用沉浸式翻译插件的,但本次被偷跑的不是这个 apikey 。

    黑客的请求集中在一个 IP ,但请求的时间和频率很奇怪,参见下表:
    https://imgur.com/a/3moyXRz
  • maomaosang 楼主 07-07 10:26
    24
    ![图表]( )
  • maomaosang 楼主 07-07 10:31
    25
    再分享一张被偷跑 token 的用量

  • realpg 07-07 11:06
    26
    阿里吗?不要视图追责,要代金券,一定会给的。
  • coderxy 07-07 11:41
    27
    加 ip 白名单。 只要用 key ,就要做好被泄露的准备。 极端一点,离职员工把 key 背下来也不是不可能。
  • ohmyzsh 07-07 11:46
    28
    以后大厂出事,你还会帮着洗
  • maomaosang 楼主 07-07 11:53
    29
    @realpg 诉求提了。钱对公司来说是小钱,但是泄露的事情比较大,如果确认是撞到的,就算不退钱,我们换完 key 也就放心了。但如果不是撞的,家里还找不出来蟑螂窝,就非常膈应了,类似于不怕贼偷就怕贼惦记
  • realpg 07-07 14:31
    30
    @maomaosang #29
    看这个访问量的图

    以我个人多年从业的经验来看,不像是撞的,更像是有目的的偷的 然后充分分散到各个偷的账户以实现可持续发展 因为你这个账户平时用量太低了,才显露出来

    撞的一般都会简单粗暴的用 因为早晚会大规模发现

    还是检查你们的工具链和各种插件吧
  • crime1024 07-07 15:30
    31
    不能限制请求的 ip 必须是公司的 ip 吗 然后,公司自己代建中转站,让业务方便审计+每人限额
* 帖子来源V2EX
返回