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

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

  •  3
     
  •   maomaosang · 3 days ago · 4942 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 ,又为什么要翻译那几亿文字。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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

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

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

    我明白应该先从自己身上找问题。那个工具站是我这么多天想到的唯一一个“只会偷到某一个平台的 key”的工具了,结果一查人家没有网络上传。
    Rorysky
        43
    Rorysky  
       18h 53m ago
    肯定是本地泄漏的不太可能碰撞
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5476 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 101ms · UTC 06:30 · PVG 14:30 · LAX 23:30 · JFK 02:30
    ♥ Do have faith in what you're doing.