Ilumínalo Actualizado a Pligg 9.9.5

4 conversaciones

1. salsa malaga
   Escrito el 15 de Septiembre de 2008 a las 15:28 | Enlace

   Probablemente hayan entrado a través de esta vulnerabilidad: http://www.frsirt.com/english/advisories/2008/2214

   Pligg “id” Parameter Handling Remote SQL Injection Vulnerability

   Title : Pligg “id” Parameter Handling Remote SQL Injection Vulnerability
   Advisory ID : FrSIRT/ADV-2008-2214
   CVE ID : CVE-2008-3366
   Rated as : Moderate Risk
   Remotely Exploitable : Yes
   Locally Exploitable : Yes
   Release Date : 2008-07-29

   Advisory Details

   Description
   Affected Products
   Solution

   Technical Description Receive FrSIRT alerts in a Text format Receive FrSIRT alerts in a PDF format Receive FrSIRT alerts in an XML format Receive FrSIRT notifications by SMS

   A vulnerability has been identified in Pligg, which could be exploited by attackers to manipulate and inject SQL queries. This issue is caused by an input validation error in the “story.php” script when processing the “id” parameter, which could be exploited by malicious people to conduct SQL injection attacks and gain knowledge of sensitive information.

   Credits

   Vulnerability reported by Hussin X.

   ChangeLog

   2008-07-29 : Initial release

   Vulnerability Management

   Subscribe to FrSIRT VNS and receive real-time e-mail and SMS alerts when new vulnerabilities, exploits, or patches relevant to your systems and network configurations are available.

   Feedback

   If you have additional information or corrections for this security advisory please submit them via our contact form or by email to updates@frsirt.com.

   ****

   Es muy reciente y es probable que aún no se haya parcheado. Yo miraría/preguntaría primero en los foros de desarrollo de Pligg.

   Ya nos contarás.

   

   Un saludo, Antonio.

   [Responde a este comentario]

   JorgeContestó el 15 de Septiembre del 2008 a las 16:22
   
   

   Muchas gracias Antonio, desde luego podría ser. He estado instalando algún parche y algún módulo de seguridad adicional. En breve explicaré las mejoras en el blog.

   [Responde a este comentario]

2. salsa malaga
   Escrito el 15 de Septiembre de 2008 a las 16:06 | Enlace

   y ya por último unos cuantos consejos para que vayas haciendo los deberes.
   http://www.cert.org/tech_tips/intruder_detection_checklist.html
   CERT® Coordination Center
   Intruder Detection Checklist
   Introduction

   1. Look for Signs That Your System May Have Been Compromised
   1. Examine log files
   2. Look for setuid and setgid Files
   3. Check system binaries
   4. Check for packet sniffers
   5. Examine files run by ‘cron’ and ‘at’.
   6. Check for unauthorized services
   7. Examine /etc/passwd file
   8. Check system and network configuration
   9. Look everywhere for unusual or hidden files
   10. Examine all machines on the local network
   2. Review Other CERT Documents
   1. “Steps for Recovering from a UNIX Root Compromise”
   2. Contacting CERT/CC

   Revision History

   This document outlines suggested steps for determining if your system has been compromised. System administrators can use this information to look for several types of break-ins. We encourage you to review all sections of this document and modify your systems to close potential weaknesses.

   In addition to the information in this document, we provide companion documents that may help you:

   * http://www.cert.org/tech_tips/unix_configuration_guidelines.html
   contains suggestions for avoiding common UNIX system configuration problems that have been exploited
   * http://www.cert.org/tech_tips/root_compromise.html
   contains suggested steps for recovering from a root compromise on a UNIX system

   We also encourage you to check with your vendor(s) regularly for any updates or new patches that relate to your systems.

   1. Look For Signs That Your System May Have Been Compromised

   Note that all action taken during the course of an investigation should be in accordance with your organization’s policies and procedures.
   1. Examine log files for connections from unusual locations or other unusual activity. For example, look at your ‘last’ log, process accounting, all logs created by syslog, and other security logs. If your firewall or router writes logs to a different location than the compromised system, remember to check these logs also. Note that this is not foolproof unless you log to append-only media; many intruders edit log files in an attempt to hide their activity.
   2. Look for setuid and setgid files (especially setuid root files) everywhere on your system. Intruders often leave setuid copies of /bin/sh or /bin/time around to allow them root access at a late time. The UNIX find(1) program can be used to hunt for setuid and/or setgid files. For example, you can use the following commands to find setuid root files and setgid kmem files on the entire file system:

   find / -user root -perm -4000 -print
   find / -group kmem -perm -2000 -print

   Note that the above examples search the entire directory tree, including NFS/AFS mounted file systems. Some find(1) commands support an “-xdev” option to avoid searching those hierarchies. For example:

   find / -user root -perm -4000 -print -xdev

   Another way to search for setuid files is to use the ncheck(8) command on each disk partition. For example, use the following command to search for setuid files and special devices on the disk partition /dev/rsd0g:

   ncheck -s /dev/rsd0g

   3. Check your system binaries to make sure that they haven’t been altered. We’ve seen intruders change programs on UNIX systems such as login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync, any binaries referenced in /etc/inetd.conf, and other critical network and system programs and shared object libraries. Compare the versions on your systems with known good copies, such as those from your initial installation media. Be careful of trusting backups; your backups could also contain Trojan horses.

   Trojan horse programs may produce the same standard checksum and timestamp as the legitimate version. Because of this, the standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced. The use of cmp(1), MD5, Tripwire, and other cryptographic checksum tools is sufficient to detect these Trojan horse programs, provided the checksum tools themselves are kept secure and are not available for modification by the intruder. Additionally, you may want to consider using a tool (PGP, for example) to “sign” the output generated by MD5 or Tripwire, for future reference.
   4. Check your systems for unauthorized use of a network monitoring program, commonly called a sniffer or packet sniffer. Intruders may use a sniffer to capture user account and password information. For related information, see CERT advisory CA-94:01 available in http://www.cert.org/advisories/CA-94.01.ongoing.network.monitoring.attacks.html
   5. Examine all the files that are run by ‘cron’ and ‘at.’ We’ve seen intruders leave back doors in files run from ‘cron’ or submitted to ‘at.’ These techniques can let an intruder back on the system (even after you believe you had addressed the original compromise). Also, verify that all files/programs referenced (directly or indirectly) by the ‘cron’ and ‘at’ jobs, and the job files themselves, are not world-writable.
   6. Check for unauthorized services. Inspect /etc/inetd.conf for unauthorized additions or changes. In particular, search for entries that execute a shell program (for example, /bin/sh or /bin/csh) and check all programs that are specified in /etc/inetd.conf to verify that they are correct and haven’t been replaced by Trojan horse programs.

   Also check for legitimate services that you have commented out in your /etc/inetd.conf. Intruders may turn on a service that you previously thought you had turned off, or replace the inetd program with a Trojan horse program.
   7. Examine the /etc/passwd file on the system and check for modifications to that file. In particular, look for the unauthorized creation of new accounts, accounts with no passwords, or UID changes (especially UID 0) to existing accounts.
   8. Check your system and network configuration files for unauthorized entries. In particular, look for ‘+’ (plus sign) entries and inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd, and in all .rhosts files (especially root, uucp, ftp, and other system accounts) on the system. These files should not be world-writable. Furthermore, confirm that these files existed prior to any intrusion and were not created by the intruder.
   9. Look everywhere on the system for unusual or hidden files (files that start with a period and are normally not shown by ‘ls’), as these can be used to hide tools and information (password cracking programs, password files from other systems, etc.). A common technique on UNIX systems is to put a hidden directory in a user’s account with an unusual name, something like ‘…’ or ‘.. ‘ (dot dot space) or ‘..^G’ (dot dot control-G). Again, the find(1) program can be used to look for hidden files, for example:

   find / -name “.. ” -print -xdev

   find / -name “.*” -print -xdev | cat -v

   Also, files with names such as ‘.xx’ and ‘.mail’ have been used (that is, files that might appear to be normal).
   10. Examine all machines on the local network when searching for signs of intrusion. Most of the time, if one host has been compromised, others on the network have been, too. This is especially true for networks where NIS is running or where hosts trust each other through the use of .rhosts files and/or /etc/hosts.equiv files. Also, check hosts for which your users share .rhosts access.

   2. Review Other CERT Documents
   1. If you suspect that your system has been compromised, please review the suggested steps in “Steps for Recovering from a UNIX Root Compromise,” available from

   http://www.cert.org/tech_tips/root_compromise.html

   Also review other appropriate files in our tech_tips directory.
   2. To report a computer security incident to the CERT Coordination Center, please complete and return a copy of our Incident Reporting Form, available from

   http://www.cert.org/ftp/incident_reporting_form

   The information on the form helps us provide the best assistance, as it enables us to understand the scope of the incident, to determine if your incident may be related to any other incidents that have been reported to us, and to identify trends in intruder activities.

   This document is available from: http://www.cert.org/tech_tips/intruder_detection_checklist.html
   CERT/CC Contact Information

   Email: cert@cert.org
   Phone: +1 412-268-7090 (24-hour hotline)
   Fax: +1 412-268-6989
   Postal address:
   CERT Coordination Center
   Software Engineering Institute
   Carnegie Mellon University
   Pittsburgh PA 15213-3890
   U.S.A.

   CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends.
   Using encryption

   We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from

   http://www.cert.org/CERT_PGP.key

   If you prefer to use DES, please call the CERT hotline for more information.
   Getting security information

   CERT publications and other security information are available from our web site

   http://www.cert.org/

   * “CERT” and “CERT Coordination Center” are registered in the U.S. Patent and Trademark Office.

   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an “as is” basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.
   Conditions for use, disclaimers, and sponsorship information

   Copyright Carnegie Mellon University 1999
   Revision History
   Oct 03, 1997
   Feb 12, 1999
   Jul 20, 1999
   Initial Release
   Converted to new web format
   Converted ftp:// URL’s to http:// URL’s

   ****

   Espero no haberte molestado con comentarios tan largos
   
   Antonio

   [Responde a este comentario]

   JorgeContestó el 15 de Septiembre del 2008 a las 16:25
   
   

   No me molesta para nada. Al revés… lo agradezco enormemente sobre todo en temas de seguridad… Con todo este material me estoy pensando si no convendría elaborar una o dos entradas de seguridad en proyectos web. ¿Qué te parece?

   [Responde a este comentario]

3. salsa malaga
   Escrito el 15 de Septiembre de 2008 a las 16:42 | Enlace

   Avanti. Yo la resumiría en 6 puntos:

   1. Ultima versión de todo
   2. Redundancia
   3. Estar al día en los exploits
   4. Atacarme yo a mi mismo
   5. Copias de seguridad 2 veces diarias
   6. Rezar
   
   Y lo dicho, que no te olvides de http://socialcmsbuzz.com/tag/pligg-exploit/ Si tu no la visitas, lo harán tus enemigos.

   Un abrazo.

   [Responde a este comentario]

4. Carlos Soler
   Escrito el 16 de Septiembre de 2008 a las 18:06 | Enlace

   Nadie esta a salvo, espero lo resuelvas pronto, y como han dicho, ¡a rezar!, cualquiera puede ser el próximo. Salud!

   [Responde a este comentario]