Sicurezza WordPress – Penetration test con Kali Linux

Gen19
on 19 Gennaio 2019 at 18:01
Posted In: Ethical Hacking / Penetration Testing, Sicurezza / Anonimato, WordPress

Guida in italiano sul come testare la sicurezza del proprio sito/server effettuando dei penetration test con Kali Linux.

Cos’è Kali Linux

Kali Linux è una distribuzione Linux per “penetration testers” e ethical hackers. Kali Linux, il successore di BackTrack Linux, è basato su Debian e viene fornito con tutti i programmi per testare la sicurezza ed effettuare dei penetration test preinstallati e preconfigurati.

Se si clicca in alto a sinistra su “Applications” appare un menu con tutti programmi che servono per testare la sicurezza in generale (la sicurezza di reti senza fili, siti, password eccetera) e nel menu numero 3, “Web Application Analysis”, ci sono tutti i programmi più conosciti per testare la sicurezza del proprio sito/server come per esempio wpscan e owasp-zap.

Kali Linux - Web ApplicationPer scaricare Kali Linux cliccare sul seguente link: Kali Linux ISO Download.

Testare la sicurezza di WordPress con WPScan

WPScan è un programma usato per rilevare vulnerabilità in siti WordPress e testare la sicurezza. Con WPScan è possibile scoprire quali plugins sono installati in modo da poterli “exploitare” se non sono aggiornati, si può scoprire il nome dell’amministratore del blog per poi tentare di “crackare” la password con un attacco “brute force”, si può scoprire il tema WordPress o/e la versione di WordPress in uso per poi cercare degli “exploits” e molto altro.

Ecco un semplice esempio:

:~ # wpscan --url https://christeninformatica.ch
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team
                       Version 3.4.3
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

Scan Aborted: The remote website is up, but does not seem to be running WordPress.
:~ #

Provando a testare il mio sito ho ricevuto un errore: “Scan Aborted: The remote website is up, but does not seem to be running WordPress“. Per vari motivi può essere che il sito sia WordPress ma risulti come se non lo sia. Se si dovesse essere sicuri – o per andare sul sicuro – che il sito in questione utilizzi WordPress, usare l’opzione –force che “forza” ad effettuare la scansione senza controllare se il sito è WordPress.

# wpscan --force --url https://christeninformatica.ch
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team
                       Version 3.4.3
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[+] URL: https://christeninformatica.ch/
[+] Started: Sat Jan 19 16:57:22 2019

Interesting Finding(s):

[+] https://christeninformatica.ch/
 | Interesting Entry: Server: Apache
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] https://christeninformatica.ch/robots.txt
 | Found By: Robots Txt (Aggressive Detection)
 | Confidence: 100%

[+] WordPress version 5.0.3 identified (Latest, released on 2019-01-09).
 | Detected By: Rss Generator (Aggressive Detection)
 |  - https://christeninformatica.ch/feed/, https://wordpress.org/?v=5.0.3
 |  - https://christeninformatica.ch/comments/feed/, https://wordpress.org/?v=5.0.3

[i] The main theme could not be detected.

[+] Enumerating All Plugins
[+] Checking Plugin Versions

[i] Plugin(s) Identified:

[+] wp-super-cache
 | Location: https://christeninformatica.ch/tag/plugins/wp-super-cache/
 | Latest Version: 1.6.4
 | Last Updated: 2018-12-20T09:36:00.000Z
 |
 | Detected By: Comment (Passive Detection)
 |
 | [!] 10 vulnerabilities identified:
 |
 | [!] Title: WP-Super-Cache 1.3 - Remote Code Execution
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6623
 |      - http://www.acunetix.com/blog/web-security-zone/wp-plugins-remote-code-execution/
 |      - http://wordpress.org/support/topic/pwn3d
 |      - http://blog.sucuri.net/2013/04/update-wp-super-cache-and-w3tc-immediately-remote-code-execution-vulnerability-disclosed.html
 |
 | [!] Title: WP Super Cache 1.3 - trunk/wp-cache.php wp_nonce_url Function URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6624
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/wptouch.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6625
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/searchengine.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6626
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/domain-mapping.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6627
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/badbehaviour.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6628
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/awaitingmoderation.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6629
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache <= 1.4.2 - Stored Cross-Site Scripting (XSS)
 |     Fixed in: 1.4.3
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/7889
 |      - http://blog.sucuri.net/2015/04/security-advisory-persistent-xss-in-wp-super-cache.html
 |
 | [!] Title: WP Super Cache <= 1.4.4 - Cross-Site Scripting (XSS)
 |     Fixed in: 1.4.5
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/8197
 |      - http://z9.io/2015/09/25/wp-super-cache-1-4-5/
 |
 | [!] Title: WP Super Cache <= 1.4.4 - PHP Object Injection
 |     Fixed in: 1.4.5
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/8198
 |      - http://z9.io/2015/09/25/wp-super-cache-1-4-5/
 |
 | The version could not be determined.

[+] Enumerating Config Backups
 Checking Config Backups - Time: 00:00:05 <==================================================================================================================================================================================================> (21 / 21) 100.00% Time: 00:00:05

[i] No Config Backups Found.

[+] Finished: Sat Jan 19 16:57:38 2019
[+] Requests Done: 50
[+] Cached Requests: 7
[+] Data Sent: 8.144 KB
[+] Data Received: 896.239 KB
[+] Memory used: 84.176 MB
[+] Elapsed time: 00:00:16
:~ #

Da come si può vedere dal risultato di questa prima “scansione” abbiamo un grave problema: WPScan a rilevato la versione di WordPress in uso. Per risolvere questo problema ho bloccato l’accesso a “christeninformatica.ch/feed” e disabilitato gli RSS Feed. Se si effettua un nuovo test per vedere se le modifiche apportate hanno avuto successo e si nota che WPScan usa altri metodi per determinare la versione di WordPress, scoprire come impedirlo e testare di nuovo.

Scoprire il nome dell’amministratore WordPress con WPScan

:~ # wpscan --force --url https://christeninformatica.ch --enumerate u
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team
                       Version 3.4.3
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[+] URL: https://christeninformatica.ch/
[+] Started: Sat Jan 19 17:02:11 2019

Interesting Finding(s):

[+] https://christeninformatica.ch/
 | Interesting Entry: Server: Apache
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] https://christeninformatica.ch/robots.txt
 | Found By: Robots Txt (Aggressive Detection)
 | Confidence: 100%

[+] WordPress version 5.0.3 identified (Latest, released on 2019-01-09).
 | Detected By: Rss Generator (Aggressive Detection)
 |  - https://christeninformatica.ch/feed/, https://wordpress.org/?v=5.0.3
 |  - https://christeninformatica.ch/comments/feed/, https://wordpress.org/?v=5.0.3

[i] The main theme could not be detected.

[+] Enumerating Users
 Brute Forcing Author IDs - Time: 00:00:02 <=================================================================================================================================================================================================> (10 / 10) 100.00% Time: 00:00:02

[i] User(s) Identified:

[+] chituser
 | Detected By: Author Posts - Author Pattern (Passive Detection)
 | Confirmed By: Wp Json Api (Aggressive Detection)
 |  - https://christeninformatica.ch/wp-json/wp/v2/users/

[+] chitadmin
 | Detected By: Rss Generator (Aggressive Detection)

[+] Finished: Sat Jan 19 17:02:16 2019
[+] Requests Done: 18
[+] Cached Requests: 28
[+] Data Sent: 3.107 KB
[+] Data Received: 482.021 KB
[+] Memory used: 24.863 MB
[+] Elapsed time: 00:00:04
:~ #

Con l’opzione “–enumerate” u (users) si controlla se informazioni come il nome dell’amministratore e di altri utenti, sono protette o meno. E anche qui WPScan ha rilevato un problema, ha scoperto il nome dell’amministratore e di un altro utente. Un malintenzionato potrebbe ora provare a crackare la password e ottenere diritti d’amministratore sul sito WordPress. Per risolvere questo problema disabilitare Wp Json Api e configurare il tema WordPress in uso in modo da non mostrare l’autore.

Disabilitare le Rest API in WordPress con Ithemes Security

Per disabilitare WP Json API andare nella sezione “WordPress Tweaks” di Ithemes Security e poi in REST API scegliere “Restricted Access”.

Kali Linux - Web Application

Scoprire i plugin WordPress in uso con WPScan

:~ # wpscan --force --url https://christeninformatica.ch --enumerate p
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team
                       Version 3.4.3
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[+] URL: https://christeninformatica.ch/
[+] Started: Sat Jan 19 17:10:51 2019

Interesting Finding(s):

[+] https://christeninformatica.ch/
 | Interesting Entry: Server: Apache
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] https://christeninformatica.ch/robots.txt
 | Found By: Robots Txt (Aggressive Detection)
 | Confidence: 100%

[+] WordPress version 5.0.3 identified (Latest, released on 2019-01-09).
 | Detected By: Rss Generator (Aggressive Detection)
 |  - https://christeninformatica.ch/feed/, https://wordpress.org/?v=5.0.3
 |  - https://christeninformatica.ch/comments/feed/, https://wordpress.org/?v=5.0.3

[i] The main theme could not be detected.

[+] Enumerating Most Popular Plugins
[+] Checking Plugin Versions

[i] Plugin(s) Identified:

[+] wp-super-cache
 | Location: https://christeninformatica.ch/tag/plugins/wp-super-cache/
 | Latest Version: 1.6.4
 | Last Updated: 2018-12-20T09:36:00.000Z
 |
 | Detected By: Comment (Passive Detection)
 |
 | [!] 10 vulnerabilities identified:
 |
 | [!] Title: WP-Super-Cache 1.3 - Remote Code Execution
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6623
 |      - http://www.acunetix.com/blog/web-security-zone/wp-plugins-remote-code-execution/
 |      - http://wordpress.org/support/topic/pwn3d
 |      - http://blog.sucuri.net/2013/04/update-wp-super-cache-and-w3tc-immediately-remote-code-execution-vulnerability-disclosed.html
 |
 | [!] Title: WP Super Cache 1.3 - trunk/wp-cache.php wp_nonce_url Function URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6624
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/wptouch.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6625
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/searchengine.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6626
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/domain-mapping.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6627
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/badbehaviour.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6628
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache 1.3 - trunk/plugins/awaitingmoderation.php URI XSS
 |     Fixed in: 1.3.1
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/6629
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2008
 |
 | [!] Title: WP Super Cache <= 1.4.2 - Stored Cross-Site Scripting (XSS)
 |     Fixed in: 1.4.3
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/7889
 |      - http://blog.sucuri.net/2015/04/security-advisory-persistent-xss-in-wp-super-cache.html
 |
 | [!] Title: WP Super Cache <= 1.4.4 - Cross-Site Scripting (XSS)
 |     Fixed in: 1.4.5
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/8197
 |      - http://z9.io/2015/09/25/wp-super-cache-1-4-5/
 |
 | [!] Title: WP Super Cache <= 1.4.4 - PHP Object Injection
 |     Fixed in: 1.4.5
 |     References:
 |      - https://wpvulndb.com/vulnerabilities/8198
 |      - http://z9.io/2015/09/25/wp-super-cache-1-4-5/
 |
 | The version could not be determined.

[+] Finished: Sat Jan 19 17:11:02 2019
[+] Requests Done: 28
[+] Cached Requests: 6
[+] Data Sent: 4.73 KB
[+] Data Received: 679.634 KB
[+] Memory used: 67.156 MB
[+] Elapsed time: 00:00:10
:~ #

Enumerate p serve per vedere i plugin installati. La soluzione è nascondere le traccie dei plugin dal codice HTML, cambiare il nome della cartella wp-content, usarne il meno possibile e aggiornarli regolarmente.

Scoprire il tema WordPress in uso con WPScan

# wpscan --force --url https://christeninformatica.ch --enumerate t
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team
                       Version 3.4.3
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[+] URL: https://christeninformatica.ch/
[+] Started: Sat Jan 19 17:26:06 2019

Interesting Finding(s):

[+] https://christeninformatica.ch/
 | Interesting Entry: Server: Apache
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] https://christeninformatica.ch/robots.txt
 | Found By: Robots Txt (Aggressive Detection)
 | Confidence: 100%

[+] WordPress version 5.0.3 identified (Latest, released on 2019-01-09).
 | Detected By: Rss Generator (Aggressive Detection)
 |  - https://christeninformatica.ch/feed/, https://wordpress.org/?v=5.0.3
 |  - https://christeninformatica.ch/comments/feed/, https://wordpress.org/?v=5.0.3

[i] The main theme could not be detected.

[+] Enumerating Most Popular Themes
 Checking Known Locations - Time: 00:01:31 <===============================================================================================================================================================================================> (411 / 411) 100.00% Time: 00:01:31

[i] No themes Found.

[+] Finished: Sat Jan 19 17:27:45 2019
[+] Requests Done: 438
[+] Cached Requests: 4
[+] Data Sent: 70.294 KB
[+] Data Received: 4.764 MB
[+] Memory used: 47.598 MB
[+] Elapsed time: 00:01:39
:~ #

Da questo esempio si nota l'importanza di non usare temi troppo popolari e se si usano, di aggiornarli il più spesso possibile.

Testare la sicurezza del proprio sito/sever con Owasp ZAP

Owasp ZAP è un programma per testare la sicurezza del proprio server/sito. È semplice da usare basta inserire la URL della propria pagina nel campo “URL to attack” e cliccare su Attack.

Una volta finito controllare sotto “Avvisi” per vedere che falle della sicurezza sono state trovate, fare ricerche sul come risolvere i problemi e poi rimediare.

OWASP ZAP - Sicurezza WordPress Penetration testing

└ Tags: , , , , , , , , , , , , ,
 Comment 

Craccare password con Hashcat Brute Force

Gen16
on 16 Gennaio 2019 at 18:31
Posted In: Ethical Hacking / Penetration Testing, Sicurezza / Anonimato

Guida in italiano sul come “craccare” password con Hashcat usando un attacco Brute Force. Hashcat è un tool molto sofisticato che viene usato per decriptare hashes. È il password cracker più veloce in circolazione anche per via del fatto che sfrutta il GPU della scheda grafica per velocizzare il processo. Con Hashcat si può “crackare” qualsiasi password, anche di WordPress per esempio, basta procurarsi l’hash file per poi “craccarlo” tranquillamente offline.

Chiaramente tool del genere possono venire usati in modo legittimo per testare la sicurezza delle password o recuperare una password come anche no.

Identificare un algoritmo hashing

Per “crackare” un hash file bisogna prima sapere che tipo di Algoritmo Hashing è stato usato. Per capirlo è facile, basta osservare i primi due caratteri del codice, vedi tabella sottostante.

SimboloAlgoritmo Hashing
$0DES
$1MD5 Hashing
$2Blowfish
$2AEksblowfish
$5SHA256
$6SHA512

Se il codice inizia con $6 vuol dire che l’algoritmo usato è SHA512. Ci sono anche dei programmi come per esempio hashid che possono essere utili nell’identificare il tipo di “algoritmo hashing”.

Eseguire il comando “hashcat –help” e dare un occhiata sotto “Hash modes“, c’è un lista di numeri di identificazione da usare. Nel nostro esempio – craccare password di sistema Linux con Hashcat – il numero da usare è 1800.

  15900 | DPAPI masterkey file v2                          | Operating Systems
  12800 | MS-AzureSync  PBKDF2-HMAC-SHA256                 | Operating Systems
   1500 | descrypt, DES (Unix), Traditional DES            | Operating Systems
  12400 | BSDi Crypt, Extended DES                         | Operating Systems
    500 | md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)        | Operating Systems
   3200 | bcrypt $2*$, Blowfish (Unix)                     | Operating Systems
   7400 | sha256crypt $5$, SHA256 (Unix)                   | Operating Systems
   1800 | sha512crypt $6$, SHA512 (Unix)                   | Operating Systems
    122 | macOS v10.4, MacOS v10.5, MacOS v10.6            | Operating Systems
   1722 | macOS v10.7                                      | Operating Systems
   7100 | macOS v10.8+ (PBKDF2-SHA512)                     | Operating Systems
   6300 | AIX {smd5}                                       | Operating Systems
   6700 | AIX {ssha1}                                      | Operating Systems

Modalità di attacco di Hashcat

NumeroDescrizione modalità attacco
0Attacco a vocabolario
1Combinazione
3Attacco Brute Force
6Attacco ibrido

Set di caratteri e maschera

Set di caratteri per Hashcat

Il set di caratteri da usare comprende lettere minuscole, lettere maiuscole, numeri e simboli. Vedi tabella sottostante:

  ? | Charset
 ===+=========
  l | abcdefghijklmnopqrstuvwxyz
  u | ABCDEFGHIJKLMNOPQRSTUVWXYZ
  d | 0123456789
  s |  !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
  a | ?l?u?d?s
  b | 0x00 - 0xff

Quindi per “crackare” una password che si sospetta sia composta da sole lettere minuscole, usare ?l, per lettere maiuscole ?u, per i numeri ?d eccetera. Se si vuole “craccare” una password composta da lettere minuscole, lettere maiuscole e numeri usare per esempio “-1 ?l?u?d ?1?1?1?1”. Se si vuole usare tutti i caratteri possibili usare ?a.

Maschera Hashcat

La maschera serve per definire il numero di caratteri della password da “craccare” come anche il tipo di caratteri da usare.

Un esempio di maschera per una password composta da 4 lettere minuscole potrebbe essere questo: ?l?l?l?l.

Craccare password di sistema Linux con Hashcat

In questo esempio sul come “crackare” password di sistema Linux con Hashcat come prima cosa creo un utente test.

:~ # useradd testuser
:~ # passwd testuser
Nuova password: 
PASSWORD ERRATA: è troppo corta
PASSWORD ERRATA: è troppo semplice
Reimmettere la nuova password: 
passwd: password aggiornata correttamente
:~ #

Il prossimo passo e creare un “hash file”. Le password in sistemi Linux sono contenute in modo criptato nel file /etc/shadow, nei sistemi moderni usando l’Hashing Algorithm” SHA512.

Ora per creare il file che ci serve dobbiamo estrarre questa informazione – la hash della password – dal file /etc/shadow con il seguente comando:

:~ # tail -n1 /etc/shadow 
testuser:$6$3jszVVeWR0jP6Bpr$eVtWKvj3KjQXUvIpz286QNRl1bs5EAcq6gBG.z.TvbJVjYetM0byqyb7rwFKQwkYnIag80QF4HqUBreIhY0Mz1:17911:0:99999:7:::
:~ # tail -n1 /etc/shadow > testuser.hash

Una volta creato l'”hash file” si può procedere. Per craccare la password contenuta nel file eseguire il seguente comando:

:~ # hashcat -m 1800 -a 3 testuser.hash ?l?l?l?l?l
hashcat (v3.00) starting...

OpenCL Platform #1: NVIDIA Corporation  
======================================
- Device #1: GeForce GTX 460, 240/963 MB allocatable, 7MCU

Hashes: 1 hashes; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Applicable Optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Uses-64-Bit
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 75c

[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit => s

Session.Name...: hashcat
Status.........: Running
Input.Mode.....: Mask (?l?l?l?l?l) [5]
Hash.Target....: $6$3jszVVeWR0jP6Bpr$eVtWKvj3KjQXUvIpz286Q...
Hash.Type......: sha512crypt, SHA512(Unix)
Time.Started...: Tue Jan 15 21:02:08 2019 (29 secs)
Time.Estimated.: Tue Jan 15 21:28:50 2019 (26 mins, 7 secs)
Speed.Dev.#1...:     7444 H/s (11.61ms)
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 215040/11881376 (1.81%)
Rejected.......: 0/215040 (0.00%)
Restore.Point..: 0/456976 (0.00%)
HWMon.Dev.#1...: Temp: 60c Fan: 39%

$6$3jszVVeWR0jP6Bpr$eVtWKvj3KjQXUvIpz286QNRl1bs5EAcq6gBG.z.TvbJVjYetM0byqyb7rwFKQwkYnIag80QF4HqUBreIhY0Mz1:prova
                                                          
Session.Name...: hashcat
Status.........: Cracked
Input.Mode.....: Mask (?l?l?l?l?l) [5]
Hash.Target....: $6$3jszVVeWR0jP6Bpr$eVtWKvj3KjQXUvIpz286Q...
Hash.Type......: sha512crypt, SHA512(Unix)
Time.Started...: Tue Jan 15 21:02:08 2019 (2 mins, 23 secs)
Speed.Dev.#1...:     7469 H/s (11.59ms)
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 1075200/11881376 (9.05%)
Rejected.......: 0/1075200 (0.00%)
Restore.Point..: 35840/456976 (7.84%)

Started: Tue Jan 15 21:02:08 2019
Stopped: Tue Jan 15 21:04:38 2019 
:~ #
└ Tags: , , , , , , , , , , ,
 Comment 

La perfetta installazione WordPress – Velocizzare

Giu30
on 30 Giugno 2018 at 23:10
Posted In: WordPress

1. Dare più memoria a WordPress

Per dar più memoria a WordPress – per eseguire gli script PHP – editare il file wp-config.php.

# vi wp-config.php

Poi aggiungere la seguente riga all’inizio del file.

define('WP_MEMORY_LIMIT', '128M');

In questo modo WordPress avrà più memoria a disposizione per eseguire gli script. Una cosa da tener conto è quanta memoria viene collocata a PHP sul server, se la memoria è inferiore a quella impostata in WordPress, si riceverà un errore (una pagina bianca).

2. Comprimere JavaScript ed eliminare eventuali risorse inutili

Per velocizzare WordPress è importante diminuire i requests (le risorse esterne che una pagina richiede) e comprimere (minify) gli script, i file CSS e i file HTML. Come prima cosa dare un occhiata al codice HTML ed eliminare tutto quello che non serve o che potrebbe rallentare e rendere insicura l’applicazione.

2.1 Eliminare gli script non usati

Con il mio tema WordPress mi carica tre script dal wp_head che servono per la corretta funzionalità di alcune funzioni incluse. Se non si usano queste funzioni si può tranquillamente rimuoverle.

<script type='text/javascript' src='../../wp-content/themes/temascelto/js/ddsmoothmenu.js'> 
<script type='text/javascript' src='../../wp-content/themes/temascelto/js/menubar.js'>
<script type='text/javascript' src='../../wp-content/themes/temascelto/js/googletranslate.js'>

Un altro problema in relazione al fare inserire automaticamente gli script da WordPress è che si trovano nella cartella “wp-content“, cosa che rivelerebbe il nome della cartella usata che è stato cambiato per motivi di sicurezza (vedi guida sulla sicurezza WordPress). Quindi nel caso si avesse bisogno di un qualche script creare per esempio una cartella “js”, spostare nel suo interno tutti gli script, rimuovere gli script dal file default-filter.php e infine aggiungere manualmente gli script nel file header.php o footer.php.

Per rimouovere gli script editare il file wp-includes/default-filters.php.

default-filters.php wp_head

Cancellare o commentare nella parte “Actions” i wp_head che finiscono con scripts come wp_enqueue_scripts, wp_print_footer_scripts, wp_print_head_scripts e wp_footer_scripts. Fatto ciò gli script non verranno più aggiunti e non ve ne sarà più alcuna traccia nel codice della pagina.

2.2 Comprimere i JavaScript

Nel caso si dovessero usare dei JavaScript comprimerli e, se possibile, creare un file solo che contiene il codice – per diminuire i requests – di più script in uno. Per fare ciò creare uno script che si chiama script.js e copiare il contenuto dei tre script in esso.

Per comprimere gli script visitare www.shrinker.ch, copiare ed incollare il testo contenuto nello script e cliccare su Shrink. Infine copiare il codice generato e inserirlo con un editore di testo nello script.

Una volta compressi gli script aggiungerli manualmente in header.php o footer.php vedi esempio sottostante.

<script type='text/javascript' src='https://christeninformatica.ch/js/script.js'>

3. Comprimere i file CSS

Ora comprimere tutti i file CSS e se possibile unire i diversi file in uno. Andare su www.shrinker.ch, copiare il testo del file CSS nella campo apposito e cliccare su “Shrink!”.

4. Installare WP-SUPER-CACHE

È anche molto importante per una buona performance di servire le pagine dalla cache così da diminuire gli accessi alla banca dati e l’esecuzione di script PHP. Per fare ciò usare un cache plugin come wp-super-cache.

Scaricare wp-super-cache su wp-super-cache e copiare il contenuto del zip nella cartella plugins. Una volta copiato wp-super-cache nella cartella apparirà sotto plugins installati in WordPress. Cliccare su attiva.

Ora andare alla pagina di amministrazione del plugin per attivare la funzione di caching. Nella scheda advanced settings mettere il visto nei seguenti quadratini:

  1. Utilizza mod_rewrite per servire i file in cache.
  2. Non servire pagine cache per gli utenti conosciuto (Raccomandato)
  3. Don’t cache pages with GET parameters. (?x=y at the end of a url)
  4. Rigenerazione cache. Serve un file supercache agli utenti anonimi quando un nuovo file é stato generato. (Raccomandato)
  5. Clear all cache files when a post or page is published or updated.
  6. Ricarica la sola pagina in uso quando vengono effettuati dei commenti.

Poi più in basso scegliere di cancellare la cache una volta al giorno e quando si pubblica un nuovo articolo o si effettua una modifica. Una volta fatto ciò premere su aggiorna stato.

Ora appare un messaggio che ci informa che le regole mod_rewrite devono essere aggiornate, se Apache può scrivere e il nome del file è .htaccess, il cambiamento avverrà automaticamente una volta cliccato su aggiorna, ma se per motivi di sicurezza il file è stato rinominato, editare il file e aggiungere le righe generate dal plugin. Le regole generate si trovano in fondo alla pagina nella sezione avanzate.

Ecco le regole rewrite da usare:

# BEGIN WPSuperCache

RewriteEngine On
RewriteBase /
#If you serve pages from behind a proxy you may want to change 'RewriteCond %{HTTPS} on' to something more sensible
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f
RewriteRule ^(.*) "/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f
RewriteRule ^(.*) "/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f
RewriteRule ^(.*) "/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/chitblog_contenuto/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]

# END WPSuperCache

Copiare e incollare il primo pezzo senza i commenti e tutto quello che non serve nel file .htaccess.

Per il resto delle impostazioni usare il file httpd.conf.

<Directory /unacartella/chitblog/>
Options -ExecCGI -Indexes +FollowSymLinks -Includes
DirectoryIndex index.php /index.php
AllowOverride FileInfo
Order Allow,Deny
Allow from all
<FilesMatch "\.html\.gz$">
 ForceType text/html
 FileETag None
</FilesMatch>
AddEncoding gzip .gz
AddType text/html .gz
Header set Vary "Accept-Encoding, Cookie"
Header set Cache-Control 'max-age=3, must-revalidate'
SetEnvIfNoCase Request_URI \.gz$ no-gzip
ExpiresActive On
ExpiresByType text/html A3
</Directory>

Se si osserva il codice HTML in fondo alla pagina apparirà il seguente messaggio:

<!– Dynamic page generated in 0.278 seconds. –>
<!– Cached page generated by WP-Super-Cache on 2013-02-16 08:32:55 –>

Un ulteriore test possiamo effettuarlo usando il wp-supercache. Andare nella scheda “facile” del menu di wp-super-cache e testare la cache cliccando su “Test cache”. Aspettare un attimino e se si ottiene un risultato positivo abbiamo finito.

Con wp-supercache si ha la possibilità di installare dei plugins, un plugin molto utile è minify. Per installare il plugin aggiuntivo per wp-super-cache e attivarlo seguire i seguenti passi.

1.Download the current version and unzip. Move WPSCMin.php into the plugins subdirectory of WP Super Cache. If yours is a standard WordPress install, this will be wp-content/plugins/wp-super-cache/plugins/.

Scarica l’attuale versione del plugin: Minify. “Unzippa” e sposta il file WPSCMIN.php nella cartella wp-content/plugins/wp-super-cache/plugins/. Se si ha cambiato la cartella wp-content avrà un altro nome.

2.Download the current version of Minify and unzip. Move the min directory into the plugins subdirectory of WP Super Cache, right next to WPSCMin.php.

3.Log into your site, go to the WP Super Cache config page, and scroll to the bottom. Enable HTML Minify, and you’re done!

Una volta installato il plugin aggiuntivo apparirà nel submenu plugins di wp-super-cache, HTML Minify, selezionare Enabled e cliccare su update. Ora se guardiamo il codice della pagina vediamo che è tutto ordinato e non vi sono più spazi.

5. Laverage browser caching

Aggiungere il seguente codice nel file di configurazione di Apache (httpd.conf).

<filesMatch ".(ico|pdf|jpg|jpeg|png|gif|js|css)$">
   Header set Cache-Control "max-age=16000000, public"
</filesMatch>

6. Comprimere le immagini

Consiglio di impostare la grandezza e la posizione delle immagini nel file CSS e di ridurre eventualmente le dimensioni delle immagini se sono troppo larghe con un tool come per esempio Gimp o Photoshop.

Nel mio caso utilizzo le classi left e right con un larghezza di 310px e modifico le dimensioni delle immagini a 310px di larghezza, in caso contrario il server dovrebbe scaricare un file molto più grande del necessario per modificarne poi le dimensioni. Se volessi invece un immagine grande la larghezza del blog ne userei una di 730px di larghezza.

Per comprimere le immagini si potrebbe usare Photoshop, è facile, basta aggiungere l’immagine che si vuole comprime e poi nel menu “file” scegliere “Save for Web“.

Photoshop Save for Web

7. Enable compression

Un altra cosa da fare e comprimere i file serviti dal server, per ancora diminuire la dimensione dei dati che un client deve scaricare. Per fare ciò bisogna impostare max-age e attivare deflate. Aggiungere le seguenti righe nel file di configurazione di Apache (httpd.conf):

SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

8. Specificare un Character Set

Aggiungere il seguente codice nel file di configurazione di Apache (httpd.conf):

AddDefaultCharset UTF-8

9. Test finale

Per testare la velocità usare il “Google Online Page Speed Test Insights“: Google Online Page Speed Test Insights. Inserire la URL del sito o blog che si vuole velocizzare e cliccare su analyze. Come si puoi vedere dall’immagine sottostante il mio blog ha ottenuto 93 punti su 100 che è già un buon punteggio.

Google Online Page Speed Test

Se testando il vosto blog o sito non doveste ottenere un buon risultato seguire le istruzioni del Page Speed Test insights di Google.

└ Tags: , , , , , , , , , , , , , ,
 Comment 

Port Scanning – Il prodigioso NSE di Nmap

Mag20
on 20 Maggio 2018 at 17:43
Posted In: Ethical Hacking / Penetration Testing, Sicurezza / Anonimato

Perfino un amministratore di sistema principiante avrà probabilmente già sentito parlare e avrà già usato un port scanner. Sicuramente avrà anche sentito parlare di Nmap, un port scanner molto usato e conosciuto, creato dal Progetto Nmap. Nmap sta per “Mapper di rete” (Networkmapper) e oltre ad essere super rapido, sofisticato ed efficiente, ha molte funzioni.

Tra le sue molte funzionalità è in grado di rilevare il sistema operativo di un server remoto, testare la sicurezza sia di server locali che remoti e creare un inventario dei server e dei servizi attivi in una rete.

Può essere che hai già usato Nmap per fare un semplice port scan nel passato ma è molto improbabile che tu abbia realizzato che Nmap è uno strumento molto potente per testare la sicurezza. Questo è dovuto in parte ai sofisticati script aggiuntivi incorporati. Prima di dare un occhiata a questi script aggiuntivi è meglio fare una breve ripetizione sulle funzionalità di base di Nmap. In questo modo apprenderai che Nmap può essere usato per attività White Hat avanzate.

Le basi del port scanning con Nmap

Anche le funzioni di base (port scanning) di Nmap includono opzioni avanzate come l’IP Spoofing (usando l’opzione -S). Una magnifica selezione di funzionalità è disponibile.

Cosa ne dite di “chiedere” a Nmap di eseguire un semplice port scan su un server? Vediamo ora di effettuare una scansione di base con Nmap su uno specifico indirizzo IP. In questo esempio viene usata l’opzione “-PN” in modo da escludere un ping test.

# nmap -PN 123.123.123.123

Il risultato sarà qualcosa del genere:

Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-16 11:16 GMT Nmap scan report for www.chrisbinnie.tld (123.123.123.123) 
Host is up (0.00051s latency).
Not shown: 999 closed ports
PORT	STATE   SERVICE
22/tcp	open	ssh
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

Come si può osservare dal risultato della scansione, il Nmap ha testato 999 porte – quelle di default – senza controllare le altre porte rilevando una porta aperta, la 22, SSHD.

Come si può vedere dall’esempio sottostante Nmap è in grado di scansionare intere reti.

# nmap -PN 123.123.123.0/24

Aggiungendo l’opzione “-n” si possono disabilitare i “DNS lookups” in modo da aumentare la velocità e da evitare di venire scoperti da un DNS server.

Se si è interessati a TCP allora ci si può connettere a porte TCP usando Nmap come segue:

# nmap -sT www.chrisbinnie.tld

Se si ha di bisogno di connettersi a porte UDP usare l’opzione “-sU” invece che “-sT”.

Come detto in precedenza, ci sono moltissime opzioni ma al momento, prima di passare al meglio, ecco alcune altre opzioni che ritengo siano molto utili.

Per esempio, se si sta effettuando un “port/ip scan” nella propria rete locale ma si vogliono escludere alcuni host, si può fare uso dell’opzione “exclude file” (escludere file) in questo modo:

# nmap 10.10.10.0/24 --excludefile /home/chrisbinnie/exclusions.txt

Se i server da escludere durante lo scan sono pochi opterei per la seguente sintassi:

# nmap 10.10.10.0/24 --exclude 10.10.10.1,10.10.10.10,10.10.10.100

Per controllare solo specifiche porte usare la “U” per UDP e la T per TCP come segue:

# nmap -p U:53,T:0-1024,8080 10.10.10.111

E infine, se si vuole controllare quali server sono raggiungibili nella propria rete locale, il comando che fa per noi è il seguente (usa “discovery” o un ping scan, l’opzione “-sP”):

# nmap -sP 10.10.10.0/24

Come risultato si potrebbe ottenere un output simile a questo:

Nmap scan report for mail.chrisbinnie.tld (10.10.10.10) Host is up (0.028s latency).
Nmap scan report for smtp.chrisbinnie.tld (10.10.10.11) Host is up (0.029s latency).

L’output di questo comando sarà un host per riga.

Lo Scripting Engine di Nmap (NSE)

Nmap offre una serie di funzioni estremamente sofisticate. Queste funzionalità aggiuntive vengono chiamate NSE (Nmap Scripting Engine). Ora daremo un occhiata ad alcuni soggetti trattati nella documentazione di Nmap indicando quando usare quale funzionalità aggiuntiva.

Lo straordinario NSE fu creato tenendo in mente qualche funzione base. Queste funzioni includono network discovery usando il port scan, un metodo avanzato per rilevare i servizi in uso usando una varietà di “signatures” predefinite, testare le vulnerabilità – e “exploitarle” – e infine un metodo per rilevare delle backdoor.

Il punto forte di NSE è la sua versatilità e estende questa qualità offrendo in aggiunta, come si può capire dal nome, la possibilità di creare nuovi script che possono venire scritti da chiunque usando la lingua di programmazione “Lua”. Per usare NSE dalla linea di comando eseguire Nmap con l’opzione “–script” o in alternativa l’opzione “-sC”.

Quelli che seguono sono due esempi di port scanning effettuarti con Nmap. Il primo senza usare NSE e il secondo esempio facendone uso. Questi esempi sono utili perché danno la possibilità di potere osservare la differenza tra i due risultati. Nell’esempio sottostante si può notare il risultato del primo comando senza usare NSE. I comandi vengono eseguiti in questo esempio da un utente normale, non root.

$ nmap -p0-1024 -T4 localhost
Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-16 11:16 GMT Nmap scan report for localhost (127.0.0.1)
Host is up (0.00049s latency). Not shown: 1021 closed ports
PORT	STATE SERVICE
22/tcp  open  ssh 
25/tcp  open  smtp 
80/tcp  open  http 
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Nel prossimo esempio invece, si può notare che NSE viene usato cosa che aggiunge diverse informazioni aggiuntive al risultato.

$ nmap -sC -p0-1024 -T4 localhost
Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-16 11:16 GMT Nmap scan report for localhost (127.0.0.1)
Host is up (0.00054s latency). Not shown: 1021 closed ports 
PORT	STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey: 1024 d7:46:46:2d:fc:ad:9e:c7:25:d3:a1:96:45:4f:59:d9 (DSA)
|_2048 80:f2:29:c0:ee:a1:80:99:2e:7f:26:c3:b1:2d:c4:37 (RSA)
25/tcp  open  smtp 
80/tcp  open  http
| http-methods: Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-title: Site doesn't have a title (text/html; charset=UTF-8). 
111/tcp open  rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds

Come si può notare dall’output, nel secondo comando che usa NSE si possono trovare informazioni in più. Con NSE vengono mostrate anche delle URLs utili per fare ricerche riguardo al risultato ottenuto, vengono mostrati più dettagli (come per esempio la SSH host key) e anche commenti riguardo al fatto che Nmap crede che il codice HTML non sia valido.

I Timing Templates di Nmap

Nel precedente esempio abbiamo richiesto informazioni riguardo le porte 0-1024 (le porte privilegiate, raw, o porte superuser in sistemi Unix o Unix-like) usando l’opzione “-p0-1024”. L’opzione “-T4” non è una sorta di timeout in cui si aspettano 4 secondi, è un metodo in cui si usano dei “time templates” di NSE. Più è alto il numero e più Nmap scansiona in modo veloce, i valori variano da 0 a 5. I valori del “timing template” sono molto importanti e fanno anche una differenza per quanto riguarda il proprio “benessere emotivo”. Questi valori da 0 a 5 stanno per: paranoico (paranoid), subdolo (sneaky), corretto (polite), normale (normal), aggressivo (aggressive) e malsano (insane). Le parole – in inglese – possono venire anche usate come opzione al posto dei numeri se per qualcuno è più comodo e facile da ricordare.

Per via del fatto che con Nmap NSE si hanno a disposizione moltissime funzionalità aggiuntive, i programmatori si sono resi conto che gli utenti si sarebbero potuti “perdere” in tutta quella complessità e così hanno creato dei templates molto utili. La ragione principale per la quale i templates sono così importanti da usare con Nmap, è che se si usa NSE per analizzare molti host alla volta o una grande rete, il processo di scansione può metterci molto tempo per finire. È anche possibile di trovare pochissime informazioni (per via di firewalls configurati come si deve) investendo molto tempo.

Quali differenze esistono nei vari templates ci si può chiedere? Entrambi, il template paranoid e il template sneaky, offrono un certo livello di sicurezza per quanto riguarda l’evitare di venire scoperti da un “intrusion detection system” (IDS).

Il template polite rallenta il port scanner in modo da limitare la banda usata ad entrambi le parti della connessione come anche le risorse del server preso di mira. L’opzione “-T3” non apporta nessun cambiamento per via del fatto che viene usata di default. Il template aggressive che abbiamo usato nel precedente esempio usando l’opzione “-T4” velocizza il processo di scan e testa una rete con molta banda in modo più rigoroso. L’ultimo template, insane, assume che si è contenti del fatto di metterci meno tempo a scapito dell’accuratezza. Per usare questo template bisogna avere una connessione veloce e stabile.

Le categorie di script di Nmap NSE

Nonostante l’utilizzo di un mezzo altamente sofisticato, NSE è stato progettato in modo tale che persino un utente novizio è in grado di capire come usarlo con relativa facilità. È quindi possibile iniziare ad usare NSE in modo rapido e senza il bisogno di avere studiato la cosa in anticipo.

È utile sapere in che modo NSE fa riferimento ai diversi script che utilizza. Quando si esegue uno script tramite NSE viene eseguita una scansione delle porte prima o durante la sua esecuzione al fine di verificarne lo stato della disponibilità di rete di un server remoto. Esistono anche altre somiglianze tra i molti script NSE come per esempio i DNS lookup e i traceroute.

CategoriaDescrizione
authQuesti script analizzano i metodi di autenticazione e cercano possibili modi per bypassarli – per esempio X11-access, ftp-anon e oracle-enum-users. La categoria brute serve per testare le password con un attacco brute force.
BroadcastSe si ha bisogno di inviare pacchetti via broadcast nella rete locale, usare questi script.
brutePer testare la sicurezza delle password di un server remoto con attacchi di tipo brute force usare questa collezione di script. Ce ne sono tanti per i diversi protocolli.
DefaultGli script default vengono eseguiti usando l’opzione “-sC” o “-A”. Per usare altri script non default usare l’opzione “–script=”.
DiscoveryPer controllare chi e cosa è connesso a una rete usare questi script. Si tratta di esaminare per esempio registri pubblici (public registries), dispositivi con SNMP attivato e “directory services”.
DosSe si vuole testare se si è vulnerabili ad attacchi di tipo DOS o (fare attenzione) eseguire script che sono in grado di far “crashare” servizi, questi script fanno al caso giusto.
ExploitQuesti script servono per testare degli exploits.
ExternalFare attenzione ad eseguire questi script visto che le proprie azioni verranno notate da terze parti. Questo perché questi script eseguono dei WHOIS Lookup cosa visibile al servizio WHOIS.
fuzzerQuesti script testano i bug e le falle nella sicurezza dei programmi. Ci mettono molto di più rispetto ad altre tecniche per trovare informazioni interessanti o rendere un server non raggiungibile.
IntrusiveQuesti script sono molto rischiosi da usare. Alcuni dei rischi includono crash, saturazione di banda e venire scoperti dall’amministratore del server preso di mira.
MalwareI malware conosciuti lasciano tracce nel sistema come delle backdoor e altri segni. Questi script controllano porte aperte e servizi sospetti per determinare se si è infetti.
SafeQuesti script non offendono l’amministratore del sistema preso di mira. Nonostante questo non si dovrebbe contare completamente sul fatto che non causino problemi.
VersionQuesti script sono un estensione della funzione di NSE che serve per rilevare la versione in uso. Per usare questi script usare l’opzione “-sV”.
VulnSe vengono trovate delle vulnerabilità si riceve un avvertimento.

Trovare falle nella sicurezza con Nmap

Ora che abbiamo dato un occhiata alle categorie di script NSE di Nmap iniziamo con l’effettuare un penetration test utilizzando il sapere appena acquisito e il vasto numero di script che vengono forniti con Nmap.

Effettuare un test delle vulnerabilità sul server locale come segue:

# nmap --script vuln localhost
Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-16 11:16 GMT Nmap scan report for localhost (127.0.0.1)
Host is up (0.00090s latency). Not shown: 996 closed ports 
PORT	STATE  SERVICE
22/tcp  open   ssh 
25/tcp  open   smtp 
80/tcp  open   http
| http-enum:
|_ /icons/: Potentially interesting folder w/ directory listing 111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds

Il risultato ha immediatamente attirato la mia attenzione quando ho visto “Potentially interesting folder” per il servizio RPC. Chiaro, è probabile che l’accesso alla cartella /icons/ è permesso solo da locale ma dare comunque un occhiata (e anche urgentemente). Si potrebbe bloccare la porta TCP 111 con un firewall o disabilitare il servizio per rimediare al problema a meno che non si configuri RPC in modo da limitarne l’accesso.

Se NSE identifica una vulnerabilità conosciuta mostra nell’output informazioni come una patch ID per un server Windows o qualche URL utile in modo da potere fare ricerche a riguardo. Questo ci può in alcuni casi fare risparmiare del tempo visto che non si devono cercare gli exploits online. Ci sono buone probabilità che se NSE trova qualcosa non si tratta di un falso allarme visto che differenti test sono stati effettuati per arrivare a tale conclusione, e al contrario di certi altri programmi, bisognerebbe prendere gli avvertimenti sul serio e effettuare dei controlli.

La categoria NSE discovery di Nmap

Considera di utilizzare il seguente commando per ottenere maggiori informazioni su un host.

# nmap --script discovery localhost
Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-16 11:16 GMT Nmap scan report for localhost (127.0.0.1)
Host is up (0.00070s latency). Not shown: 996 closed ports 
PORT	STATE SERVICE
22/tcp  open  ssh
|_banner: SSH-2.0-OpenSSH_5.3
| ssh-hostkey: 1024 d7:46:46:2d:fc:ad:9e:c7:25:d3:a1:96:45:4f:59:d9 (DSA)
|_2048 80:f2:29:c0:ee:a1:80:99:2e:7f:26:c3:b1:2d:c4:37 (RSA)
25/tcp  open  smtp
|_banner: 220 mail.chrisbinnie.tld ESMTP Postfix
| smtp-enum-users:
|	root
|	admin
|_ Method RCPT returned a unhandled status code.
|_smtp-open-relay: Server is an open relay (16/16 tests) 80/tcp open http
| http-headers:
|	Date: Mon, 16 Nov 2015 11:37:52 GMT
|	Server: Apache/2.2.15 (Red Hat)
|	Last-Modified: Mon, 15 Jun 2015 13:57:09 GMT
|	ETag: "4bc-61-5188ed5743e6a"
|	Accept-Ranges: bytes
|	Content-Length: 97
|	Connection: close
|	Content-Type: text/html; charset=UTF-8
|
|_ (Request type: HEAD)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-date: Mon, 16 Nov 2015 11:37:52 GMT; 0s from local time.
| http-vhosts:
|_393 names had status 200
| http-enum:
|_ /icons/: Potentially interesting folder w/ directory listing
111/tcp open  rpcbind
| rpcinfo:
|	100000 2,3,4	111/tcp rpcbind
|_ 100000 2,3,4	111/udp rpcbind
Nmap done: 1 IP address (1 host up) scanned in 11.51 seconds

Come si può vedere dall’output del comando, usando discovery vengono mostrate diverse informazioni come gli HTTP headers, i banner SMTP, rcpinfo e altro. Anche se l’errore SMTP “Server is an open relay (16/16 tests)” è molto probabilmente un falso positivo (false positive), vale comunque la pena di controllare per esserne sicuri.

Con tutte queste funzionalità questa modalità è estremamente utile e rappresenta la parte chiave di NSE. Dopo tutto si può “exploitare” servizi senza essere a conoscenza della loro esistenza. Osservando i risultati generati da NSE è facile constatare che quando si tratta di scoprire servizi e server le informazioni ottenute sono molto utili. NSE non ti bombarda di dettagli, ti fornisce comunque abbastanza informazioni per essere estremamente utile.

L’impatto negativo che si può avere usando le categorie di script è che la performance viene ridotta se si usano tutti gli script di una categoria.

Nmap NSE – Espressioni regolari

Con NSE si possono usare le espressioni regolari (regular expressions). Per esempio ho menzionato i 15 script HTTP, per utilizzarli tutti assieme eseguire il seguente comando:

# nmap --script "http-*"

Si possono usare anche le decisioni booleane come segue:

# nmap --script "default or safe"

Nella documentazione si possono trovare anche esempi più complessi:

# nmap --script "(default or safe or intrusive) and not http-*"

In questo esempio vengono usate le categorie default, safe o intrusive ma non quelle che hanno a che fare con i web server.

Zenmap – Nmap con interfaccia grafica

Zenmap, la versione con interfaccia grafica di Nmap
Ci sono circostanze, specialmente se si ha a che fare con molti “target” (obbiettivi) in differenti reti, in cui si ha bisogno di aiuto per quanto riguarda l’analizzare i risultati. Immagina di essere in grado di aggiungere i risultati delle varie scansioni in una banca dati in modo da poterle analizzare e comparare tra di loro.

A questo scopo si può usare Zenmap (https://nmap.org/zenmap/). La versione ufficiale GUI dello scanner Nmap, il ben progettato Zenmap, è free e appropriato per utenti di ogni livello. Zenmap ha un generatore di comandi per assistere l’utente nel creare comandi complessi e ha anche l’abilità di poter fare ricerche riguardo alle scansioni effettuate in passato usando un database. È anche possibile crearsi un profilo per i comandi più comuni in modo da non doverli inserire ogni volta.

Questo programma con una molto utile interfaccia grafica e disponibile per Linux, BSD, Mac OS, e Windows.

Per utenti che eseguono delle scansioni frequentemente e qualunque novizio, Zenmap è il tool perfetto.

Fonte: Linux Server Security – Hack and Defend by Chris Binnie

Traduzione: christeninformatica.ch

└ Tags: , , , , , , , , , , , , , ,
 Comment 

Sicurezza SUSE Linux Server – Rilevare intrusioni con AIDE

Apr05
on 5 Aprile 2018 at 19:50
Posted In: LINUX SERVER, Sicurezza / Anonimato

La sicurezza del sistema è un compito obbligatorio per qualsiasi amministratore. Poiché è quasi impossibile garantire che il sistema non venga compromesso, è molto importante eseguire controlli regolarmente (ad esempio usando cron) per assicurarsi che sia – il sistema – ancora sotto il proprio controllo. Ed è qui che entra in gioco AIDE, l’Advanced Intrusion Detection Environment.

Perché usare AIDE

Un semplice controllo in grado di rilevare modifiche indesiderate può essere fatto tramite RPM. Il gestore di pacchetti ha una funzione di verifica integrata che controlla tutti i file gestiti nel sistema per vedere se sono state effettuate delle modifiche. Per verificare i file eseguire il comando rpm -Va. Tuttavia, questo comando mostrerà anche le modifiche nei file di configurazione e sarà necessario creare alcuni filtri per rilevare importanti cambiamenti.

Un ulteriore problema riguardo all’usare RPM per tale scopo è che un utente malintenzionato intelligente sarà in grado di modificare l’rpm in modo da nascondere eventuali modifiche che potrebbero essere state apportate da un rootkit. Un rootkit è un programma che consente a un utente malintenzionato di mascherare la sua intrusione e ottenere privilegi da root. Per risolvere questo problema è necessario implementare un controllo secondario che può anche essere eseguito in modo completamente indipendente dal sistema installato.

Installazione AIDE

AIDE non è installato di default su SUSE Linux Enterprise Server. Per installare AIDE utilizzare il software di installazione Yast o eseguire il seguente commando da root:

# zypper install aide

Esempi di configurazione AIDE

Per comunicare a AIDE (Advanced Intrusion Detection Environment) quali attributi di quali file devono essere controllati, utilizzare il file di configurazione /etc/aide.conf. Questo file deve in alcuni casi venire modificato per rispondere ai requisiti della configurazione in uso. La prima sezione gestisce i parametri generali come la posizione del database di AIDE. Le configurazioni locali più rilevanti sono le regole personalizzate e le sezioni Directory e File.

Quello che segue è un esempio di una tipica regola:

Binlib	= p+i+n+u+g+s+b+m+c+md5+sha1

Dopo aver definito la variabile Binlib, le rispettive caselle di controllo vengono utilizzate nella sezione file.

Lista delle opzioni più importanti:

OpzioneDescrizione
pControlla i permessi di file o cartelle selezionate.
iFa un controllo del numero inode. Ogni file ha un unico numero inode che non dovrebbe cambiare.
nControlla quanti links puntano a un file.
uControlla se il proprietario di un file è cambiato.
gControlla se il gruppo di un file è cambiato.
sControlla se le dimensioni di un file sono cambiate.
bControlla se il “block count” usato dal file è cambiato.
mControlla se la data di modifica (mtime) di un file è cambiata.
cControlla se la data di accesso (atime) di un file è cambiata.

Quello che segue è un esempio di configurazione in cui AIDE controlla ogni file nella cartella /sbin con le opzioni definite in Binlib omettendo pero dal controllo la cartella /sbin/conf.d/.

/sbin	Binlib
!/sbin/conf.d

Creare un database AIDE

1. Editare il file di configurazione di AIDE (/etc/aide.conf) e apportare delle modifiche se necessario. Per ulteriori informazioni e una lista completa di opzioni dare un occhiata al manuale AIDE: /usr/share/doc/packages/aide/manual.html.
2. Controllare se le modifiche apportate al file di configurazione di AIDE sono corrette con il seguente comando:

# aide --config-check

Se ci sono degli errori di sintassi o altro nel file di configurazione si riceverà un messaggio di errore del genere:

aide --config-check 35:syntax error:!
35:Error while reading configuration:! Configuration error

3. Inizializzare il database di AIDE con il seguente comando:

# aide -i

4. Copiare il database (/var/lib/aide/aide.db.new) in un posto sicuro come un CD/DVD, un Server remoto o un USB stick. Importante: Questo passo è importante per assicurarsi che il database AIDE non venga compromesso. È consigliato di salvare una copia del database su un CD/DVD – in modo che può venire scritto solo una volta e non più venire modificato – per evitare che il database di AIDE venga modificato. Non lasciare il database sul computer che si vuole monitorare.

Effettuare un controllo locale con AIDE

1. Rinominare il database di AIDE con il seguente comando:

# mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Dopo ogni cambiamento di configurazione bisogna inizializzare nuovamente il database e rinominarlo come sopra. È consigliato di fare un backup del database.
2. Avviare un controllo del sistema con il seguente comando:

# aide --check
#

Se il comando viene eseguito senza dare un output vuole dire che è tutto a posto. Se invece AIDE rileva dei cambiamenti mostra un sommario vedi esempio sottostante:

# aide --check
AIDE found differences between database and filesystem!!

Summary:
  Total number of files:        1992
  Added files:                  0
  Removed files:                0
  Changed files:                1
#

Per ottenere più informazioni aggiungere -V.

# aide --check -V
AIDE found differences between database and filesystem!!
Start timestamp: 2018-02-18 15:14:10

Summary:
  Total number of files:        1992
  Added files:                  0
  Removed files:                0
  Changed files:                1


---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /etc/passwd

--------------------------------------------------
Detailed information about changes:
---------------------------------------------------


File: /etc/passwd
  Mtime    : 2018-02-18 15:11:02              , 2018-02-18 15:11:47
  Ctime    : 2018-02-18 15:11:02              , 2018-02-18 15:11:47
#

Fonte: Security Guide – SUSE Linux Enterprise Server 12 SP3

└ Tags: , , , , , , , , , , ,
 Comment