Linuks I Maliciozni Programi

Total Page:16

File Type:pdf, Size:1020Kb

Linuks I Maliciozni Programi [0] Intro * Napomena: Ako pri čitanju članka nai ñete na neke nepoznate pojmove, preporu čujem čitanje Malog Re čnika Zaštite (http://www.mycity.rs/Zastita/Mali-recnik-zastite.html) kako bi se informisali o tim pojmovima ili možda rešili neke nedoumice po pitanju razgrani čavanja pojmova. Rešio sam da malo prou čim kakvo je stanje na Linuksu po pitanju malicioznih programa ( malware -a) i da ovim člankom utvrdim " malware scenu" Linuksa. Da bih to istražio morao sam da pose ćujem razli čite underground sajtove na kojima sam mogao da na ñem razne maliciozne programe. Kao što znamo, Linuks generalno važi za bezbedan operativni sistem, ali ipak nije u potpunosti imun na malware . U članku će biti opisani razlozi zašto je to tako, na čini zaštite, inficiranje u realnom vremenu, pokušaj dezinfekcije i neki generalni saveti i utisci. Kod pojedinih stvari će biti napravljena paralela sa operativnim sistemom Windows . Bobby me je, tako ñe, snabdeo sa razli čitim uzorcima malware -a za Linuks u vidu ELF datoteka, shell i perl skripti koje sam testirao na virtualnoj mašini, a neke na fizi čkoj mašini (testirani malware ne ću da imenujem, ve ć ću ga pomenuti u generi čkom smislu). Za svaki operativni sistem je mogu će napraviti malware koji će uništiti, tj. onesposobiti taj operativni sistem. Me ñutim, moderni malware ima tendenciju da preuzme kontrolu nad ra čunarom (tj. da napravi zombija) kako bi poslužio nekoj svrsi tvorcima malware-a ili kako bi se pokrali neki podaci. Što se ti če onesposobljavanja operativnog sistema, najlakše ga je onesposobiti tako što mu se zauzmu resursi. Na primer, pretpostavimo da operativni sistem ima više korisnika, i da korisnicima nije odre ñena quota za raspoloživ prostor na disku. Postoji PoF (proof of concept) malware koji prodire na sistem, i kreira izuzetno veliki broj malih fajlova, sve dok ne popuni File Alocation Table (FAT ili ekvivalentan na datoj particiji) čime prakti čno blokira mogu ćnost kreiranja datoteka ostalim korisnicima. Druga mogu ćnost je kreiranje ogromnog broja programskih niti (thread ova) ili procesa, sve dok se ne popuni limit broja procesa/ thread ova koje kernel može da kreira. Time se blokira rad gotovo svih aplikacija na ra čunaru. Ovaj napad se zove " Fork Bomb " ( Fork je isto što i Thread kod Windows a). Onda, postoje i bombe za antivirus programe. Jedna od najpoznatijih je ZIP bomb . Predstavlja posebno osmišljenu ZIP datoteku (veli čine svega par kB) kome je struktura direktorijuma tako napravljena da se vrti u krug, usled čega antivirus bude beskona čno dugo zaposlen skeniranjem te arhive. U slu čaju Linuksa - postoji TAR.GZ bomba . [1] Tvr ñava Linuks predstavlja tvr ñavu koju je, u principu, teško probiti iz slede ćih razloga: 1. postojanje velikog broja distribucija, forkova, derivata (recimo Debian --> Ubuntu --> Mint i sl.) koje, opet, imaju razli čite na čine instalacije paketa i softvera, dolaze sa razli čitim grafi čkim okruženjima, ... Dakle, razli čitost je jedna od linija odbrane. 2. *NIX operativni sistemi su "od starta" osmišljeni kao višekorisni čki i bezbedni operativni sistemi. Svaki korisnik ima svoje privilegije i može da manipuliše sa onim datotekama za koje ima privilegije. Da bi malware mogao da zarazi celokupan sistem, potrebna mu je privilegija root -a (privilegija najvišeg nivoa). Dakle, za pravljenje "ve će štete" je neophodan root pristup ra čunaru. U ve ćini slu čajeva malware ima opseg home particije teku ćeg korisnika i može da manipuliše (i pravi štetu) nad datotekama teku ćeg korisnika (korisnika koji je ulogovan). (zabranjeno)er ima je još uvek enigma kako pribaviti pristup root nalogu. 3. i Linuks ima svoje ranjivosti (recimo: postojanje neažurnih biblioteka), ali Linuksov mehanizam ažuriranja sistema i aplikacija (što zavisi od distribucije do distribucije) i aktivnosti zajednice doprinose da se neažurne datoteke brzo zamene novijim. Za razliku od Windows a, gde moramo ažurirati svaku aplikaciju pojedina čno, kod moje distribucije se ažuriranje svih aplikacija na najnovije verzije vrši samo uz par klikova mišem. Time se izbegavaju ranjivosti neažurne aplikacije, kriti čne za bezbednost sistema. 4. upotreba softverskih repozitorijuma zna čajno smanjuje opasnost od malicioznih programa. Stoga nema pojava rogue softvera niti trojanaca koje možemo "zaka čiti" na razli čitim mestima na Internetu jer se o repozitorijima stara tim održiva ča ( maintainers ), koji prakti čno garantuju da je softver legitiman. 5. što se ti če open source softvera i exploit a, primarna prednost open source modela je što kôd može pro čitati svako, tj. dostupan je svakome. A više pogleda na kôd može izna ći i potencijalne bezbednosne probleme. Zbog ovih razloga još uvek nema masovnih infekcija na Linuksu (za razliku od Windows a). [2] Napad na tvr ñavu! S obzirom na stavku 1.1 pisci malware -a su prinu ñeni da napišu takav malware koji će da funkcioniše na razli čitim distribucijama. Jedan od na čina je da se koristi kôd koji se pokre će sa nekim interpreterom (na primer Perl skripta) ili kôd koji treba kompajlirati. Iz ovoga vidimo da pisci malware -a pretpostavljaju da je instaliran Perl ili pak GCC (ili drugi), jer ako iste nemate instalirane, ne ćete mo ći pokrenuti malware . Tvr ñavu je još teže napasti ako imamo u vidu da Linuks skripte po defaultu nisu podešene kao executable (isto važi i za ELF datoteke). Po Wikipediji trebalo bi da do danas postoji oko 1000 uzoraka malware -a za Linuks. Dosta njih predstavlja samo " proof of concept ", dakle, malware samo pokazuje mogu ćnost da se nešto uradi ali ne pravi štetu. Ostali koje sam pokretao su relativno stari (najviše do 2008. godine) i ga ñaju rupe koje su odavno zakrpljene, ali ima tu i funkcionalnog malware -a. Recimo, virusi; na Internetu se mogu na ći izvorni kodovi virusa (pa čak i tutorijali) koji zaista mogu da rade u dozvoljenom opsegu, a ako dobiju root pristup mogu da zaraze sve izvršne datoteke na ra čunaru! Teoretski, poznavalac programskog jezika C može, uz minimalne modifikacije postoje ćih izvornih kodova za viruse, napisati svoj virus i dati mu ime (tako da je broj oko 1000 uzoraka, vrlo upitan ) Kao što rekoh, pisci malware se najviše bave pribavljanjem root privilegije. U "podzemlju" sam video da postoje tzv. local root exploits koji su posebna filozofija (svaka verzija kernela ima zasebnu temu) i koji se vezuju za specifi čne verzije Linuks kernela (recimo 2.2 ili 2.4). Dakle, ni ovde nema nekog univerzalnog pristupa jer su exploit i usko specifi čni za kernel. Pod pretpostavkom da je malware dobio sve neophodne privilegije, jedan od na čina pokretanja je kroz crontab . Susretao sam se i sa malicioznim screensaverim a koji su usput pokušavali da pokrenu malicioznu skriptu. Postoje i exploit i za aplikacije, recimo OpenOffice dokumenta sa makro kôdom ( Document malware ). Od 2007. godine su registrovani pokušaji da se napiše multipltformski malware . Jedan na koji sam naišao predstavlja proof of concept i teoretski se može izvršiti na Windows u, Linuks i MacOS-u (kažem teoretski jer i on pretpostavlja postojanje Perl a odnosno Ruby -ja. Za Windows je dovoljan samo dvostruki klik ) Na Internetu sam malo tražio i utiske napadnutih korisnika, kao i onih koji su pokušavani biti napadnuti. Obi čno je re č o nekom backdoor u ( perl trojancu, npr.) ili ranjivostima sistema ( ssh , telnet ) usled čega ra čunar treba da postane deo botnet mreže na IRC kanalu kako bi služio za DDoS napade ili kao server za pirateriju. Korisnici uglavnom otkriju čudno ponašanje računara - zakucavanje procesora na 100% (recimo iz foldera /tmp/ ), te pove ćana mrežna aktivnost. Za Linuks nije karakteristi čano širenje virusa, s obzirom na pomenuta ograni čenja ve ć su neki drugi tipovi malware -a zastupljeni na njemu, na primer trojanci, crvi i rootkit ovi. Posebnu pažnju sam posvetio rootkit ovima jer kod Unix ovih naslednika rootkit ovi uklju čuju i razli čite metode napada trojancima, sniffing a i drugo, pa je dobro ovako kumulativno obraditi ovu pri ču. Na Unix sistemima rootkit ovi se spominju od 1990-ih godina i ovaj naziv se preneo i na ostale operativne sisteme (dakle, prvi rootkit ovi su pisani za Unix ). Iako po svojoj definiciji nisu maliciozne prirode, ovde će biti razmatrani u zlonamernog kontekstu. Za Unix i naslednike postoje 3 klase rootkitova: 1) binarni rootkitovi - cilj im je da zamene odre ñene sistemske datoteke sa trojancima. Naime, kriti čne sistemske datoteke ( /bin/login i sl. ) se kompromituju kako bi se obezbedio udaljeni ili lokalni pristup mašini. Prvi rootkit ovi su bili binarni rootkit ovi koji su predstavljali tar arhive popularnih sistemskih datoteka koje admin koristi. Tako ñe, dizajnirani su tako da sakriju maliciozne procese od korisnika. Obi čno su prekompjalirani za odre ñenu arhitekturu (Intel i386, Sparc i sl.). Zamenom datoteka, rootkit ima cilj da: • Pribavi root pristup ra čunaru. Dakle, u prošlosti se ubacivao trojanac na poziciju /bin/login ili SUID datoteke (/bin/ping, /usr/sbin/traceroute, /bin/su i druge) kako bi se pribavile root privilegije • Omogu ći sakrivanje procesa. Ubacivanjem trojanca na /bin/ps (na primer). • Omogu ći sakrivanje konekcije. Ubacivanjem trojanca na /bin/netstat (primer) • Omogu ći sakrivanje datoteka. Trojanovani ls, dir ili cat, mogu da sakriju maliciozne datoteke. Rootkit ovi ovoga tipa uklju čuju i dodatne alate za modifikovanje atributa tipa datum kreiranja (tj. timestamp ) i veli čina datoteke. Na primer preko komande touch , timestamp jedne datoteke se može dodeliti drugoj (malicioznoj): touch -r prvobitna_datoteka trojan_datoteka 2) kernel rootkitovi - manipulišu sa modulima kernelima ili predstavljaju dodatne maliciozne module koji se zaka če (hook ) na kernel. Za razliku od binary rootkit ova koji zamenjuju legitimne sistemske izvršne datoteke, LKM ( Loadable Kernel Module ) rootkit ovi se zaka če ( hook uju) na kernel sistema i zamenjuju (remapiraju) ili izmene (tj. presre ću) pozive kernela. Na ovaj na čin, prakti čno celi operativni sistem postaje nepouzdan.
Recommended publications
  • Linux-Professional-Institute-LPI-303
    LPIC-3: Linux Enterprise Professional Certification LPIC-3 303: Security LPIC-3 is a professional certification program program that covers enterprise Linux specialties. LPIC-3 303 covers administering Linux enterprise-wide with an emphasis on Security. To become LPIC-3 certified, a candidate with an active LPIC-1 and LPIC-2 certification must pass at least one of the following specialty exams. Upon successful completion of the requirements, they will be entitled to the specialty designation: LPIC-3 Specialty Name. For example, LPIC-3 Virtualization & High Availability. Specialties: • 300: Mixed Environment • 303: Security • 304: Virtualization and High Availability TOPIC 325: CRYPTOGRAPHY • Configure Apache HTTPD with mod_ssl to that performs DNSSEC validation on behalf of 325.1 X.509 Certificates and Public Key provide HTTPS service, including SNI and its clients Infrastructures (5) HSTS • Key Signing Key, Zone Signing Key, Key Tag Candidates should understand X.509 certificates • Configure Apache HTTPD with mod_ssl to • Key generation, key storage, key management and public key infrastructures. They should know authenticate users using certificates and key rollover how to configure and use OpenSSL to implement • Configure Apache HTTPD with mod_ssl to • Maintenance and re-signing of zones certification authorities and issue SSL certificates provide OCSP stapling • Use DANE to publish X.509 certificate for various purposes. • Use OpenSSL for SSL/TLS client and server information in DNS Key knowledge areas: tests • Use TSIG for secure communication with BIND • Understand X.509 certificates, X.509 certificate 325.3 Encrypted File Systems (3) TOPIC 326: HOST SECURITY lifecycle, X.509 certificate fields and X.509v3 Candidates should be able to setup and 326.1 Host Hardening (3) certificate extensions configure encrypted file systems.
    [Show full text]
  • Hardening Debian Against Common Surveillance and Security Threats V18.11.10
    Hardening Debian Against Common Surveillance and Security Threats v18.11.10 Table of Contents Introduction...........................................................................................................................................2 Design Philosophy................................................................................................................................3 Threat Model.........................................................................................................................................5 Download and Verify Installation Image Signatures............................................................................8 Write Verified Image to Installation Media........................................................................................12 Protect Motherboard Firmware...........................................................................................................13 Operating System Installation Configuration.....................................................................................15 Default Deny Firewall.........................................................................................................................18 Kernel and Network Hardening..........................................................................................................21 Routing Package Management through Tor........................................................................................24 Minimizing your Software Attack Surface.........................................................................................26
    [Show full text]
  • Geek Guide > Self-Audit
    GEEK GUIDE SELF-AUDIT: CHECKING ASSUMPTIONS AT THE DOOR Table of Contents About the Sponsor .......................................................... 4 Introduction .................................................................... 5 Two Steps Necessary for Security ................................. 7 Verify Configurations ...................................................... 9 Assume Security Has Been Compromised .................. 10 Tools to Scan for Malware ............................................ 11 rkhunter �������������������������������������������������������������������������������������������������12 chkrootkit ����������������������������������������������������������������������������������������������13 LMD�������������������������������������������������������������������������������������������������������14 lynis �������������������������������������������������������������������������������������������������������19 Checking for Stealth Ports ........................................... 22 lsof ��������������������������������������������������������������������������������������������������������23 unhide ���������������������������������������������������������������������������������������������������24 Rootkits ......................................................................... 25 Conclusion .................................................................... 27 GREG BLEDSOE is VP of Operations at Personal, Inc. (http://www.personal.com). He is CEH and CPT certified and has 20 years of hard-fought experience
    [Show full text]
  • Blue Team Field Manual.Pdf
    BTFM Blue Team Field Manual ALAN WHITE BEN (LARK Version 1 Hacked to PDF by: 0E800 (2/13/2017) 1 BTFM. Copyright© 2017 by Alan White and Ben Clark All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, without prior written permission of the copyright owner. ISBN-13: 978-1541016361 ISBN-10: 154101636X Technical Editor: Matt Hulse Product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, the author uses the names only in an editorial fashion, with no intention of infringement of the trademark. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. The information in this book is distributed "as is". While every precaution was taken to ensure the accuracy of the material, the author assumes no responsibility or liability for errors or omissions, or for damages resulting from the use of the information contained herein. 2 PREFACE BTFM Command-Line Syntax: Notation Description Generic Linux/*nux shell prompt, sudo may also be used with $ Windows Prompt, may C:\> require Administrator CMD prompt PS C:\> Windows PowerShell > Generic prompt, multi OS <IP ADDRESS>, <PORT>, Requires user determined input and remove <> <USER>, <PASSWORD>, etc. brackets Caution use of copy/paste with dash/hyphens. - - en/em/dash I I hyphen - Ensure you check spaces spaces and no spaces in commands. Updates, Edits and Supplement Material: Ref. http://www.blueteamfieldmanual.com BTFM is based on the NIST Cybersecurity Framework: Ref.
    [Show full text]
  • Towards Non-Intrusive Software Introspection and Beyond
    Towards Non-Intrusive Software Introspection and Beyond Apoorve Mohan∗, Shripad Nadgowdaz, Bhautik Pipaliya∗, Sona Varma∗, Sahil Sunejaz, Canturk Isciz, Gene Cooperman∗, Peter Desnoyers∗, Orran Kriegery, Ata Turkx ∗Northeastern University, yBoston University, zIBM T.J. Watson Research Center xState Street Corporation Abstract—Continuous verification and security analysis of IAAS CLOUD Performance-Sensitive Interference Introspection Send Health software systems are of paramount importance to many orga- Workload Program Report Tenant A nizations. The state-of-the-art for such operations implements e.g. Apache Http Server e.g. Amazon Inspector Malicious Introspect Software Stack agent-based approaches to inspect the provisioned software stack Program Influence Provider-Controlled Tenant B for security and compliance issues. However, this approach, which e.g. User-Mode Rootkit Analysis Monitoring System Software Packages and Configurations runs agents on the systems being analyzed, is vulnerable to Software Tenant C At-Scale INTROSPECTED Stack some attacks, can incur substantial performance impact, and Operating System Introspection INSTANCE } can introduce significant complexity. In this paper, we present the design and prototype implementation of a general-purpose approach for Non-intrusive Software Introspection (NSI). By Fig. 1: Visualizing agent-based introspection. adhering to NSI, organizations hosting in the cloud can as well control the software introspection workflow with reduced trust in the provider. Experimental analysis of real-world applica- environment with 64 virtual machines per host would require tions demonstrates that NSI presents a lightweight and scalable 640K such agents. Third, while performing periodic security approach, and has a negligible impact on the performance of inspection, these agents consume system resources (e.g., CPU applications running on the instance being introspected.
    [Show full text]
  • Mastering Linux Security and Hardening
    Mastering Linux Security and Hardening Secure your Linux server and protect it from intruders, malware attacks, and other external threats Donald A. Tevault BIRMINGHAM - MUMBAI Mastering Linux Security and Hardening Copyright © 2018 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. Commissioning Editor: Vijin Boricha Acquisition Editor: Rohit Rajkumar Content Development Editor: Devika Battike Technical Editor: Mohd Riyan Khan Copy Editors: Safis Editing, Dipti Mankame Project Coordinator: Judie Jose Proofreader: Safis Editing Indexer: Pratik Shirodkar Graphics: Tania Dutta Production Coordinator: Deepika Naik First published: January 2018 Production reference: 1090118 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78862-030-7 www.packtpub.com mapt.io Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career.
    [Show full text]
  • Effectiveness of Linux Rootkit Detection Tools
    Effectiveness of Linux Rootkit Detection Tools University of Oulu Faculty of Information Technology and Electrical Engineering Degree Programme in Information Processing Sciences Master’s Thesis Juho Junnila 27.3.2020 2 Abstract Rootkits – a type of software that specializes in hiding entities in computer systems while enabling continuous control or access to it – are particularly difficult to detect compared to other kinds of software. Various tools exist for detecting rootkits, utilizing a wide variety of detection techniques and mechanisms. However, the effectiveness of such tools is not well established, especially in contemporary academic research and in the context of the Linux operating system. This study carried out an empirical evaluation of the effectiveness of five tools with capabilities to detect Linux rootkits: OSSEC, AIDE, Rootkit Hunter, Chkrootkit and LKRG. The effectiveness of each tool was tested by injecting 15 publicly available rootkits in individual detection tests in virtual machines running Ubuntu 16.04, executing the detection tool and capturing its results for analysis. A total of 75 detection tests were performed. The results showed that only 37.3% of the detection tests provided any indication of a rootkit infection or suspicious system behaviour, with the rest failing to provide any signs of anomalous behaviour. However, combining the findings of multiple detection tools increased the overall detection rate to 93.3%, as all but a single rootkit were discovered by at least one tool. Variation was observed in the effectiveness of the detection tools, with detection rates ranging from 13.3% to 53.3%. Variation in detection effectiveness was also found between categories of rootkits, as the overall detection rate was 46.7% for user mode rootkits and 31.1% for kernel mode rootkits.
    [Show full text]
  • How to Response Against Web Security Incident
    How to Response Against Web Security Incident Digit Oktavianto digit dot oktavianto at gmail dot com http://digitoktavianto.web.id BSSN – 11th August 2018 Agenda Incident Response Life Cycle Recap Incident Response Web Hacking PlayBook Incident Response Step for Web Hacking Security Incident What to Do After IR Step is Done. NIST SP 800-61rev2 Incident Response An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt. Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, etc. computer security incident is a violation or imminent threat of violation1 of computer security policies, acceptable use policies, or standard security practices. Incident Response Life Cycle (NIST) IR Life Cycle Recap Preparation: get ready to handle the incident Identification: detect the incident Containment: limit the impact of the incident Eradication: remove the threat Recovery: recover to a normal stage Lesson Learned: draw up and improve the process Tips for Building Effective Incident Handling Plan (Cont’d) Improve vulnerability management Program Learn from past incidents and breaches Improve incident handling workflow process Building centralized monitoring system to protect the infrastructure Web Hacking IR PlayBook Root Cause Web Security Incident Most Common
    [Show full text]