• 请不要在回答技术问题时复制粘贴 AI 生成的内容
maomaosang
V2EX  ›  程序员

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

  •  3
     
  •   maomaosang · 11 days ago · 5674 views

    一个月前社区有篇帖子《大家抓紧看看 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 ,又为什么要翻译那几亿文字。

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

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

    还能直接看用户数据的啊?都不演一下吗?
    maomaosang
        10
    maomaosang  
    OP
       11 days ago
    @Yserver 😱 确实是没对这里做测试,看来新的 baseurl 只是用来做资源隔离的,不是 random key 的一部分

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

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

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

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

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

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

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

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

    还是检查你们的工具链和各种插件吧
    crime1024
        31
    crime1024  
       10 days ago
    不能限制请求的 ip 必须是公司的 ip 吗 然后,公司自己代建中转站,让业务方便审计+每人限额
    fov6363
        32
    fov6363  
       10 days ago
    +1,完全类似的经历,先是打电话,然后上去看,glm-5.2 ,也是翻译,所幸余额就几十块钱,就没管。这个 key 至少半年没用过了,不知道什么时候泄漏了
    maomaosang
        33
    maomaosang  
    OP
       10 days ago
    @realpg 我有一些疑问。

    如果是黑来的,既然每小时能烧 500 元,那么一晚上轻松干走 5000 ,何必这样一个多月断断续续只搞 2700 呢。如果计划偷摸搞,为什么又要搞出一个小时 500 元的峰呢,这个消耗量国内大部分 LLM 厂在监控到之后都会有销售跟进的。

    如果我只是受害者之一,加上其他受害者,6 月至少有 20 亿字的翻译量。假设这些用量属于某个翻译插件,按照每用户两万字算,那么这个插件至少有 10 万活跃用户了,这个用户规模还有必要冒这么大的风险四处偷 token 吗。。

    如果是代码库或 env 被盗,怎么不偷火山和其他厂呢,其他厂的模型翻译效果不好吗😂

    这些疑问,以及更多疑问,在我排查的时候就不停的冒出来,互相矛盾,说不通,它完全不同于我过去遇到的任何一起安全事件。

    anyway ,明天还是再查一遍插件,杂碎软件一律删除。

    @crime1024 很好的思路,我后面看看哪些可以设置 IP 。有些 key 也是冲来方便大家日常使用的,不一定非要是工作用,所以有些 key 不太好限 IP ,还是限钱吧。

    @fov6363 请问也是杭州厂吗?你们这个 key 有开通杭州厂主流模型的权限吗,还是说只能用 glm ?(用 glm5.2 做翻译也太豪横了)
    fov6363
        34
    fov6363  
       9 days ago
    @maomaosang #33 也是,有开通主流模型权限,主要是使用 glm-5.2

    maomaosang
        35
    maomaosang  
    OP
       9 days ago
    @fov6363 方便透露一下您被盗刷的 apikey 的前两位吗
    fov6363
        36
    fov6363  
       9 days ago
    @maomaosang #35 sk-f0e8e,一共是 32 位,还有一个也是 32 位的 key 没事
    realpg
        37
    realpg  
       9 days ago
    @maomaosang #33

    我不会给你解释能细的,如果相信我的经验,你就按照我的思路去查查到底什么东西漏了 api key

    只能说,我干缺德事儿干的多,见过并了解的黑产也多,我更熟悉罪犯思维 你后面对我提的这些问题都相当可笑,只能说你站在一个上帝视角去看有限访问权限
    maomaosang
        38
    maomaosang  
    OP
       9 days ago
    @fov6363 一定程度上排除了撞的嫌疑,至少不是顺序开撞的。老哥方便加个微信吗,想聊聊看看大家有什么相同的工具链,找找共同点 eHh5bWFvbWFv

    @realpg 发帖的时候已经把屋子翻了个底朝天了,人是有局限性的,一张卷子我自己翻来覆去的查,拿不了一百分就是拿不了,很遗憾你的“思路”确实是没有给我提供新的方向。
    realpg
        39
    realpg  
       8 days ago
    @maomaosang #38

    很简单,这些更详细的知识面是我能活下去有饭吃的资本


    我不愿意把话说太满,因为太容易引起争吵了,现在 V 站不像十几年前了,围观的全是杠精,最喜欢抓住你话里的一部分,然后往死你怼你,而我又不愿意隐藏自己的发帖和回帖记录,给自己声誉留一大堆还需要我解释的大坑


    如果你能接受我说一半话这种我自己都觉得烦人的行为,那就看这半句: 我连是谁偷的都知道,当然知道他不是撞库了。
    maomaosang
        40
    maomaosang  
    OP
       8 days ago
    @realpg 36 楼提供了 f 开头的 apikey 之后,我也同意撞库的概率非常低了。但是排查工具链的话,实在已经把卷子来回检查了,局限在这里了。我可以相信你有经验、就是我这里漏了、问题的答案巨简单、你知道是谁偷的,但是这并不能帮助我更容易的定位到泄露点。。。

    早上还想起一个工具站,可能我们往上贴过带 key 的 http 日志,抓包检查了以后发现它没有上传请求,前端演算的。后面会把这个日志里面的 key 也给脱敏掉。

    哦我还有一个疑问,如果这种盗取方式和用途如此流行(以至于你知道谁偷的|以至于帖子里面有相同受害者),为什么网上都搜不到这样的受害者呢,哎。

    我没有指望这些问题都得到回答,大家在网上萍水相逢。帖子和疑问放在这里,也许能有一天帮助到其他人。
    realpg
        41
    realpg  
       8 days ago
    @maomaosang #40
    因为人家偷的足够高级 99%都没发现 这就是技术含量 或者都没试图发现 反正公司掏钱 这些其实也是我的专长 也是我能在这个圈子里了解信息的原因

    而你这个属于比较例外的 平时没啥消费 就明显了

    而你提供了一个不知道真假的可能是被爆破的思路 厂商也全是傻叉 直接初步评估一下就信了 然后就改长了

    具体他怎么偷的我也不知道(是真不知道),我从经验角度告诉你,控制变量法
    你提到过 env env 里还有很多其他 key 如果其他没丢 那大概率不是 env 漏的


    我之前指出的,主要是你分析问题时,总是站在上帝视角,先入为主,这样非常不利于从事故障调试和运维类工作

    就好像看打麻将比赛,总是站在上帝视角看别人摸牌打牌认为人不对
    maomaosang
        42
    maomaosang  
    OP
       8 days ago
    @realpg 厂商没有信,改长在我反馈之前。他们为什么改长我就不知道了。

    自己的视角觉得能做的都做了,只能试图站在其他的视角了,楼上的 f key 已经击碎了我的梦。

    我明白应该先从自己身上找问题。那个工具站是我这么多天想到的唯一一个“只会偷到某一个平台的 key”的工具了,结果一查人家没有网络上传。
    Rorysky
        43
    Rorysky  
       8 days ago
    肯定是本地泄漏的不太可能碰撞
    jackhm18
        44
    jackhm18  
       4 days ago
    我被偷了 66 我日
    jrtzxh020
        45
    jrtzxh020  
       11h 51m ago
    猜是团队有人泄露了
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1270 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 80ms · UTC 17:37 · PVG 01:37 · LAX 10:37 · JFK 13:37
    ♥ Do have faith in what you're doing.