Podatności Heym

Heym przed wersją v0.0.112 zawiera podatność na wyciek tokenów w funkcji build_public_base_url(), która umożliwia nieuwierzytelnionym atakującym przekierowanie linków przeglądu HITL poprzez sfałszowanie nagłówków Origin lub X-Forwarded-Host. Atakujący mogą wywołać anonimowe przepływy pracy ze sfałszowanymi nagłówkami, aby powiadomienia recenzentów wskazywały na domeny atakującego, przechwytując tokeny uprawnień do podejmowania decyzji wykonywanych z poświadczeniami właściciela.

Heym w wersjach od 0.0.55 do 0.0.121 zawiera podatność eskalacji uprawnień pozwalającą współpracownikom nadpisać pole error_workflow_id, ponieważ brakuje go na liście OWNER_ONLY_EXECUTION_FIELDS. Atakujący może wskazać własny workflow z węzłem HTTP, a gdy workflow właściciela zgłosi błąd, odszyfrowane poświadczenia właściciela zostaną wstrzyknięte i wykradzione.

Podatność w Heym przed wersją 0.0.40 pozwala uwierzytelnionemu użytkownikowi, który może tworzyć lub edytować workflow z niestandardowym narzędziem Python, na obejście sandboxa opartego na czarnej liście. Biblioteki standardowe Pythona udostępniają funkcje systemowe, które przechodzą walidację, a narzędzie jest wykonywane przez exec(), umożliwiając wykonywanie poleceń i operacji na plikach jako użytkownik aplikacji backendowej. Problem naprawiono w wersji 0.0.40.

Heym w wersji v0.0.5 przed v0.0.113 zawiera podatność związaną z nieskuteczną kontrolą dostępu, która umożliwia byłym współpracownikom dalsze wykonywanie przepływów pracy JWT poprzez ponowne użycie tokenów workflow:execute o zawężonym zakresie po usunięciu udostępnienia. Atakujący może wygenerować token z TTL do 10 lat, którego właściciel nie może wylistować ani cofnąć, i wielokrotnie uruchamiać przepływ pracy, zużywając wspólne poświadczenia.

Heym przed wersją 0.0.53 nie weryfikuje nagłówka X-Telegram-Bot-Api-Secret-Token na punktach końcowych webhooków Telegrama, gdy credential_id jest nieobecne lub secret_token jest pusty. Zdalni nieuwierzytelnieni atakujący mogą wysyłać sfałszowane aktualizacje Telegrama, aby wyzwalać przepływy pracy z skonfigurowanymi poświadczeniami właściciela i wykonywać akcje na danych dostarczonych przez atakującego.

Heym przed wersją 0.0.53 nie weryfikuje podpisów żądań Slacka, gdy węzły wyzwalające nie mają identyfikatorów poświadczeń lub mają puste sekrety podpisywania. Zdalni nieuwierzytelnieni atakujący mogą wysyłać sfałszowane zdarzenia Slacka na znane adresy URL webhooków, aby wyzwalać przepływy pracy z poświadczeniami właściciela.

Podatność w Heym przed wersją 0.0.53, polegająca na ewaluacji wyrażeń warunków przepływu pracy za pomocą eval() w Pythonie z niewystarczającym sandboxingiem w usłudze wykonawczej przepływów pracy.

heym przed wersją 0.0.91 zawiera podatność ucieczki z sandboxa w silniku wyrażeń (DotList map/filter i fallback resolver), która umożliwia uwierzytelnionym użytkownikom wykonanie dowolnego kodu Python. Atakujący mogą tworzyć wyrażenia workflow z dostępem do atrybutów dunder, aby uzyskać dostęp do os.system i wykonać komendy jako proces backendu.

Heym w wersjach 0.0.90 i wcześniejszych zawiera dwie luki w zabezpieczeniach egress SSRF, obie naprawione w app/services/ssrf_guard.py w wersji 0.0.91. Po pierwsze, loader obrazów LLM (_load_image_bytes) pobierał kontrolowane przez wywołującego adresy URL HTTP/HTTPS za pomocą zwykłego httpx.get, stosując tylko sprawdzenie schematu i omijając klienta HTTP z przypiętym egress. Po drugie, _is_public_address odpakowywał tylko adresy IPv6 mapowane na IPv4, więc formy przejściowe IPv6 — prefiks NAT64 64:ff9b::/96, przestarzałe adresy IPv4-compatible ::x.x.x.x oraz 6to4 (2002::/16) — mogły przenosić adresy loopback, RFC1918, link-local lub cloud-metadata IPv4 poza walidację URL i przypięcie IP przy połączeniu.

Platforma automatyzacji przepływów pracy heym przed wersją 0.0.91 przechowuje i zwraca wiele sekretów w postaci zwykłego tekstu, w tym wartości nagłówków webhook, klucze API MCP, tokeny sesji portalu, tokeny JWT wykonań, tokeny interakcji Discord oraz zmienne globalne. Użytkownik z dostępem do odczytu przepływu pracy, członek zespołu lub osoba mająca dostęp do bazy danych, kopii zapasowej lub logów może odzyskać te sekrety i wykorzystać je do wykonywania przepływów pracy lub podszywania się pod właściciela sekretu.

heym przed wersją 0.0.105 nie stosuje zabezpieczeń egress do usług integracyjnych, które używają adresów bazowych dostarczanych z poświadczeniami, co pozwala uwierzytelnionym użytkownikom na obejście ochrony SSRF. Atakujący mogą skonfigurować poświadczenia wskazujące na adresy loopback, prywatne lub metadane chmury i odczytać odpowiedzi wewnętrznych usług zwracane jako wynik węzła przepływu pracy.

heym przed wersją 0.0.105 nie uwzględnia wyniku wyszukiwania autoryzacji poświadczeń w węźle Redis. Gdy _get_accessible_credential zwraca None, węzeł traktuje to jako pustą konfigurację i łączy się z localhost:6379 bez hasła, wykonując żądaną operację. Uwierzytelniony autor przepływu pracy, podając identyfikator poświadczenia, którego nie posiada lub które zostało usunięte, uzyskuje połączenie odczytu/zapisu z Redisem na interfejsie loopback.

Heym przed wersją 0.0.106 zawiera podatność na eksfiltrację poświadczeń w punkcie końcowym POST /api/credentials/test, która pozwala współpracownikom z dostępem do współdzielonych poświadczeń na wyeksfiltrowanie sekretu właściciela poświadczeń. Atakujący mogą nadpisać docelowy URL w parametrze config, aby serwer wysyłał odszyfrowane sekrety uwierzytelniające do kontrolowanych przez atakującego punktów końcowych.

heym przed wersją 0.0.109 zawiera podatność na SSRF w węzłach Slack, Discord i Crawler. Węzły te wysyłają żądania HTTP do adresów URL pochodzących z poświadczeń użytkownika (webhook_url / flaresolverr_url) za pomocą niechronionego klienta HTTP, omijając zabezpieczenia egress. Każdy zarejestrowany użytkownik może utworzyć poświadczenie wskazujące na wewnętrzny adres i wykonać przepływ pracy, powodując dostęp do punktów końcowych loopback, prywatnych, link-local lub metadanych chmury i zwrócenie pełnej treści odpowiedzi w wyniku węzła.

Heym przed wersją 0.0.98 nie stosuje zabezpieczeń SSRF (Server-Side Request Forgery) do węzłów WebSocket Send i WebSocket Trigger, co pozwala uwierzytelnionym użytkownikom na łączenie się z wewnętrznymi usługami. Atakujący mogą tworzyć węzły przepływu pracy z dowolnymi URL-ami i nagłówkami, aby dotrzeć do wewnętrznych usług i odczytać odpowiedzi z węzła WebSocket Trigger.

Heym przed wersją 0.0.21 zawiera podatność umożliwiającą ucieczkę z piaskownicy w niestandardowym wykonawcy narzędzi Python. Uwierzytelnieni autorzy przepływów pracy mogą ominąć ograniczenia piaskownicy, używając prymitywów introspekcji grafu obiektów.

Heym przed wersją 0.0.21 zawiera podatność polegającą na obejściu autoryzacji w wykonywaniu przepływów pracy. Uwierzytelniony atakujący może wykonać dowolne przepływy pracy, odwołując się do identyfikatorów UUID ofiary bez odpowiedniej walidacji dostępu.

Podatność typu path traversal w Heym przed wersją 0.0.21 pozwala uwierzytelnionym użytkownikom na zapisywanie plików w dowolnych lokalizacjach poprzez spreparowaną nazwę pliku zawierającą sekwencje nawigacyjne. Luka występuje w punkcie końcowym przesyłania plików, gdzie parametr filename nie jest odpowiednio walidowany.