Sprawdzenie czy program jest bezpieczny (VIM, antyriwus) ?

0

Gvim służy mi do tzw. danych wrażliwych, oprócz kodu często edytuję w nim też różne rzeczy związane np. z hasłami, kontami, etc.

Od dłuższego czasu szukałem wersji 64 bitowej dla Windowsa ale ze skompilowanymi wszystkimi funkcjami oraz prostym dołożeniem Perl/Python/Ruby/Lua. Ciężko było coś takiego znaleźć, bo każda wersja była albo 32bitowa/niepełna albo niepełna 64bitowa.

Wczoraj udało się znaleźć naprawdę dobrą wersję:
https://tuxproject.de/projects/vim/

Mamy tutaj aktualnego (16 marzec 2016 rok) Vima 64 bitowego dla Windowsa (w tym i 10) - włącznie ze wszystkimi skompilowanymi językami: (Perl 5.22.1, Python 2.7.11, Python 3.5.1, Racket 6.4.0.4, Ruby 2.3.0, Lua 5.3.2, Tcl 8.6.4, libXpm). Wersja "full wypas" - bardzo ciężko znaleźć coś podobnego i aktualnego, a ręczna kompilacja jest mordęgą (trzeba użerać się ze zmiennymi środowiskowymi %PATH%, a i tak często nie działa chociaż wszystkie opcje się zgadzają).
Problem polega na tym, że jest to jakaś "dzika" strona, którą wypadałoby sprawdzić - już raz złapałem jakieś malware ukryte właśnie w vimie.

Ściągamy plik : http://tuxproject.de/projects/vim/complete-x64.7z
complete-x64.7z
...i sprawdzamy:

  1. Avast nic nie wykrył
  2. https://www.virustotal.com - nic nie wykrył:
    https://www.virustotal.com/en/file/a1225023a4608c9554e5c5a36dedd7c7164983f8f579011337364fa632996356/analysis/1457953693/
  3. www.metadefender.com --> nie przyjął tego archiwum, bo za dużo w środku (więcej niż 100).

A) ma ktoś pomysł jak to jeszcze sprawdzić pod względem bezpieczeństwa?
B) topic założyłem też dlatego żeby zapytać czy macie jakieś swoje sposoby na sprawdzanie czy dany plik jest bezpieczny?
C) np. czy te skanery online wystarczą do wszystkiego?

2

Tak na szybko: wszystko się sprowadza w zasadzie do pytania przed czym próbujesz się bronić, lub inaczej, jak bardzo zaawansowany technicznie jest Twój adwersarz.

Mniej więcej wygląda to tak, że to co już zrobiłeś wystarczy w przypadku atakujących, którym nie zależy konkretnie na Tobie, i którzy nie starają się zbytnio podczas umieszczania wszelkiej maści backdoorów w binarkach (a raczej w kodzie, który następnie kompilują do binarki). Jeśli ich backdoor nie jest specjalnie pomysłowy/customowy, to albo sygnatury już są w bazie, albo heurystyka stosowana w AV to wykryje.

Gorzej jest jeśli ktoś się bardziej postara - wtedy poziom wykrycia przez AV spada do poziomu szumu (tj. żaden AV nic konkretnego nie wskaże).

Wtedy można zastosować dwa podejścia:

  1. Skompilować samemu dane źródła (oczywiście w tym wypadku zakładamy, że źródła są zaufane), najlepiej tym samym kompilatorem / z tymi samymi opcjami z którymi kompilowała osoba, od której mamy binarke.
    Jak już to zrobimy, stosujemy techniki znane z inżynierii wstecznej do porównania różnic (patrz: patch diffing). Samo istnienie różnic nic jeszcze nie mówi - trzeba sprawdzić z czego wynikają.
    Przykład: https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/

  2. Jeśli nie mamy źródeł, możemy sami postarać się przeanalizować binarkę.
    W praktyce jednak wszystko co ma sekcje text powyżej 1000 instrukcji assemblera jest raczej trudne do czytania i łatwo na chwilę stracić uwagę i nie zauważyć pomysłowo ukrytego backdoora - więc tego podejścia się raczej nie stosuje na dużą skalę.

Oczywiście cała analiza o której piszę wyżej ma sens jedynie gdy:

Podsumowując: najbezpieczniej jest założyć, że dany program ma jakiś backdoor i ograniczyć mu uprawnienia; w końcu backdoor w gvim zda się atakującemu na niewiele, jeśli nie będzie mógł eksfiltrować danych na zewnątrz (w pośredni lub bezpośredni sposób), ani posłużyć do podniesienia uprawnień, etc.

0

Dziękuję za tak długą odp.
Przy okazji oglądałem ten filmik:
który jest świetną odpowiedzią na inny mój topic:
https://forum.dobreprogramy.pl/windows7-jakis-prosty-skrypt-do-ustawienia-zmiennych-path-526372t.html
więc podwójnie dziękuję.

Natomiast z odp postu wynika, że do takich plików virus tutal niby wystarczy, a jak nie to trzeba dekompilować i porównać ze źródłami producenta (jeżeli jest open source). A w ogóle to dobry przykład, że najlepiej wybierać oprogramowanie od znanych developerów/dystrybutorów - a wszelkie mody z dawką ostrożności. No i w ramach możliwości kompilować we własnym zakresie. Też cała sprawa uprawnień... od kiedy grzebię w serwerze, to mam ciągle wątpliwości czy nie ustawiłem zbyt liberalnego jakiegoś chown/chmod ;)
Przyznam się, że kwestia uprawnień na laptopie-kliencie (Windows) mnie nie interesuje (wszystko defaultowo), bo to raczej problem serwerowy. W ogóle z uprawnieniami to jest inna bajka - jak są za bardzo rygorystyczne to nic nie działa, a jak zbyt liberalne go wszystko działa ale pytanie czy bezpiecznie.

Na Windows i Linux zauważyłem też taką prostą zależność: bardzo dużo zależy jakie miejsca się odwiedza w sieci. Jak ktoś przebywa na stronach porno/hazard/torrenty/emulatory/zły-hacking/piractwo/darmowe-filmy/podejrzane-zarabianie , to wtedy wcześniej czy później coś może złapać.
Dlatego prostym sposobem jest omijanie "złych stron" - szczególnie na laptopie na którym się wykonuje działania programistyczno-biznesowe. Tak samo z pirackim oprogramowaniem - oszczędności są tylko pozorne. Taki system też jest Qubes OS , który izoluje procesy od siebie dzięki wirtualizacji: https://www.qubes-os.org/ ,notabene ten system świetnie się nadaje właśnie do piractwa.

Siedzę ostatnio u pewnej osoby, z najnowszą przeglądarką (ostanim Google Chrome) weszła na jakąś "podejrzaną" stronę i momentalnie antywirus zabuczał i wykrył jakiś agresywny JavaScript. Tak się zastanawiam co by się stało, gdyby nie było antywirusa... i najlepsze, że był to zaktualizowany Windows 8.1 oraz najnowszy Google Chrome - a i tak JavaScript już się usadowił w cookie/temp, ale AV to wykrył.
Jak piszę te swoje JS, to tak się czasami zastanawiam co można umieścić w <script src=""></script> , ale w sumie po co schodzić na złą drogę...

1 użytkowników online, w tym zalogowanych: 0, gości: 1