06 December 2011

New Image!!! / Nueva Imagen!!!

Tengo el agrado de informarles que Hacking Australia tiene nueva Imagen. Actualmente me encuentro preparando mi persona para la Certificación CEH v7. Pero les prometo que  el 2012 será un año lleno de Información.

I have the pleasure to announce that Hacking Australia has a new image. Currently I am preparing myself for  CEH v7. But I promise you that 2012 will be a year full of information.

Cheers...

Alfredo.

15 September 2011

Windows 8 Has A Friendlier Blue Screen Of Death


While Windows 8 was widely expected to have a black screen of death, the developer build released yesterday has revealed that Redmond has opted to stick with the historic blue. It does, however, come with a peculiar twist. Rather than inundate people (who hopefully remembered to save their work) with a breakdown of why their computer stopped working, it seems Microsoft has chosen to take things in a more compassionate direction.

Unlike the classic, wordy blue screen of yore, the latest version instead makes a sad face at the user. In addition to flashing that large frown, the new BSoD also provides some key search terms just in case the user feel likes digging into what just happened. Users are given a few seconds to write it down or commit it to memory before before the PC automatically restarts, and voila: it’s back to business.

It’s a step in the right direction, as the classic blue screen was nigh unintelligible to most users. This latest version manages to make the process a little less headache-inducing, but I (perhaps naively) long for the day when Microsoft can tell me in plain English why my computer just failed.

Source: http://techcrunch.com/2011/09/14/windows-8-has-a-friendlier-blue-screen-of-death/

Book: Backtrack 5 Wireless Pentesting

Book : Backtrack 5 Wireless Penetration Testing by Vivek Ramachandran This book will provide a highly technical and in-depth treatment of Wi-Fi security. The emphasis will be to provide the readers with a deep understanding of the principles behind various attacks and not just a quick how-to guide on publicly available tools. We will start our journey with the very basics by dissecting WLAN

Original Page: http://feedproxy.google.com/~r/TheHackersNews/~3/66tE00u68mE/book-backtrack-5-wireless-penetration.html

Android malware outsmarts bank security.

By Greg Masters
Anti-virus won't detect it.

A variant of the SpyEye trojan dubbed SpitMo can steal bank account details and redirect transaction validation SMSes from Android phones.

SpitMo, or SpyEye for mobile, imposed templated fields on targeted banks' web pages requesting that customers fill in a mobile phone number and the international mobile equipment identity (IMEI) number of the device, a unique signature for a specific phone.

It meant criminals no longer needed to generate a certificate and issue an updated installer to snag the IMEI number, saving them up to three days.

The latest iteration of the trojan injected a message that dupes bank customers into clicking on a phony app download.

By clicking on the installer labelled "set the application," users are walked through steps that download and install the malware.

A user is then instructed to dial a number, which provides an alleged activation code to access the bank's site. In reality, that call is rerouted by the Android malware and a fake activation code is issued.

At this point, all incoming SMS messages will be intercepted and transferred to the attacker's command-and-control server.

What makes the new variant particularly meddlesome is the fact that it is unlikely to be detected as there is no visual evidence of it on the dashboard.

Users are not aware that they have been infected and that their text messages are being hijacked.

SpyEye trojan was found by Trusteer researchers in July when it was stealing troves of personal information and bank accounts. At the time, researchers said the malware was capable of evading transaction monitoring systems that look for anomalies, and observed new variants appearing frequently.

SpitMo was first detected in April by security firm F-Secure and was this week found by Trusteer researchers to be attacking the Android mobile operating system.

While the infection rate at this point is yet to snowball into a major epidemic, Trusteer researchers are advising organisations to "act now and install a desktop browser security solution as part of a multilayered security profile."

Copyright © 2011 Haymarket Media. All rights reserved. This material may not be published, broadcast, rewritten or redistributed in any form without prior authorisation.
Your use of this website constitutes acceptance of Haymarket Media's Privacy Policy and Terms & Conditions.

RedHat jakarta: Increased privileges

(15/09/2011) ESB-2011.0943 - [RedHat] jakarta-commons-daemon-jsvc: Increased privileges - Existing account

===========================================================================
AUSCERT External Security Bulletin Redistribution

ESB-2011.0943
Important: jakarta-commons-daemon-jsvc security update
15 September 2011

===========================================================================

AusCERT Security Bulletin Summary
---------------------------------

Product: jakarta-commons-daemon-jsvc
Publisher: Red Hat
Operating System: Red Hat Enterprise Linux AS/ES/WS 4
Red Hat Enterprise Linux Desktop 4
Impact/Access: Increased Privileges -- Existing Account
Resolution: Patch/Upgrade
CVE Names: CVE-2011-2729

Reference: ASB-2011.0064.2

Original Bulletin:
https://rhn.redhat.com/errata/RHSA-2011-1291.html

--------------------------BEGIN INCLUDED TEXT--------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=====================================================================
Red Hat Security Advisory

Synopsis: Important: jakarta-commons-daemon-jsvc security update
Advisory ID: RHSA-2011:1291-01
Product: JBoss Enterprise Web Server
Advisory URL: https://rhn.redhat.com/errata/RHSA-2011-1291.html
Issue date: 2011-09-14
CVE Names: CVE-2011-2729
=====================================================================

1. Summary:

A jsvc update for JBoss Enterprise Web Server 1.0.2 on Red Hat Enterprise
Linux 4 that fixes one security issue is now available from the Red Hat
Customer Portal.

The Red Hat Security Response Team has rated this update as having
important security impact. A Common Vulnerability Scoring System (CVSS)
base score, which gives a detailed severity rating, is available from the
CVE link in the References section.

2. Description:

jsvc is a service wrapper that allows Java applications to be run as
daemons.

It was found that jsvc did not correctly drop capabilities after starting
an application. If an administrator used jsvc to run an application, and
also used the "-user" option to specify a user for it to run as, the
application correctly ran as that user but did not drop its increased
capabilities, allowing it access to all files and directories accessible to
the root user. (CVE-2011-2729)

Note: This flaw only affected users running JBoss Enterprise Web Server
1.0.2 from jboss-ews-1.0.2-RHEL4-[arch].zip as provided from the Red Hat
Customer Portal, as versions for other products are not built with
capabilities support.

All users running JBoss Enterprise Web Server 1.0.2 as provided from the
Red Hat Customer Portal on Red Hat Enterprise Linux 4 are advised to apply
this update.

3. Solution:

The References section of this erratum contains a download link (you must
log in to download the update). Before applying the update, backup your
existing JBoss Enterprise Web Server installation (including all
applications and configuration files). After applying the update, if jsvc
is started, it must be restarted for this update to take effect.

4. Bugs fixed (http://bugzilla.redhat.com/):

730400 - CVE-2011-2729 jakarta-commons-daemon: jsvc does not drop capabilities allowing access to files and directories owned by the superuser

5. References:

https://www.redhat.com/security/data/cve/CVE-2011-2729.html
https://access.redhat.com/security/updates/classification/#important
https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?downloadType=securityPatches&product=webserver&version=1.0.2

6. Contact:

The Red Hat security contact is . More contact
details at https://access.redhat.com/security/team/contact/

Copyright 2011 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFOcPpnXlSAg2UNWIIRAirlAJ4lBRq346PVsFGsMcWpMQzItIGl0ACdHZ7S
tGPG1qJiNQoSqyFzYh/2DIA=
=0din
-----END PGP SIGNATURE-----

--------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

http://www.auscert.org.au/render.html?cid=1980

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQIVAwUBTnE7Te4yVqjM2NGpAQKn7Q//agvJ6JgIcv1RNd+y/2MrMeGnDE6V700Q
E5vgyBuGz1jtVFsbmUd4HcjfwFJ+n75lrin0FHvHWR1fMy8NlbuXKUe7RBPPI5+B
8RFmkiTl5+kYMlOytmDkcIM/fswi/bBG8y9C363s94+Wm/27Q4uWFZs4tWmB22p1
3zHCMfDosnGC+3lv/iI7tS6xoBohpbrz5qhq2kU8FNmE15pCi6QmBW4ctanjp/3b
kvVUAvdnA/4qOLDba3EkAHmWS7W/nFA2Rb2OhsViY9QASIhFXDMCWnqTmNBCIQxS
eWyK8OaxKdIWYQJQFVZylP6SCBu6gPlAy683V7xJbGBh4JpqdulzNQx5PoNPqXlf
TPBtr8IZ1CrnH+FeLpYLSe9FBBJ0nPg03j3TWvOkCitmOJGSoilJhxpIT0lF/wdV
cIBa/lm/LwrQO4k0wZMl5pgagoJb/QECqYLbJblWRsE6q+Yr4+ihqf4P/maOS/T2
7za7RbKZTpM7RqIiM5qJ1SdOBk5HOK6a

Original Page: http://www.auscert.org.au/render.html?it=14836

RedHat squid: Execute arbitrary code

(15/09/2011) ESB-2011.0944 - [RedHat] squid: Execute arbitrary code/commands - Remote/unauthenticated

===========================================================================
AUSCERT External Security Bulletin Redistribution

ESB-2011.0944
Moderate: squid security update
15 September 2011

===========================================================================

AusCERT Security Bulletin Summary
---------------------------------

Product: squid
Publisher: Red Hat
Operating System: Red Hat Enterprise Linux Server 6
Red Hat Enterprise Linux WS/Desktop 6
Impact/Access: Execute Arbitrary Code/Commands -- Remote/Unauthenticated
Denial of Service -- Remote/Unauthenticated
Resolution: Patch/Upgrade
CVE Names: CVE-2011-3205

Reference: ESB-2011.0882.2

Original Bulletin:
https://rhn.redhat.com/errata/RHSA-2011-1293.html

--------------------------BEGIN INCLUDED TEXT--------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=====================================================================
Red Hat Security Advisory

Synopsis: Moderate: squid security update
Advisory ID: RHSA-2011:1293-01
Product: Red Hat Enterprise Linux
Advisory URL: https://rhn.redhat.com/errata/RHSA-2011-1293.html
Issue date: 2011-09-14
CVE Names: CVE-2011-3205
=====================================================================

1. Summary:

An updated squid package that fixes one security issue is now available for
Red Hat Enterprise Linux 6.

The Red Hat Security Response Team has rated this update as having moderate
security impact. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available from the CVE link in
the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux Server (v. 6) - i386, ppc64, s390x, x86_64
Red Hat Enterprise Linux Workstation (v. 6) - i386, x86_64

3. Description:

Squid is a high-performance proxy caching server for web clients,
supporting FTP, Gopher, and HTTP data objects.

A buffer overflow flaw was found in the way Squid parsed replies from
remote Gopher servers. A remote user allowed to send Gopher requests to a
Squid proxy could possibly use this flaw to cause the squid child process
to crash or execute arbitrary code with the privileges of the squid user,
by making Squid perform a request to an attacker-controlled Gopher server.
(CVE-2011-3205)

Users of squid should upgrade to this updated package, which contains a
backported patch to correct this issue. After installing this update, the
squid service will be restarted automatically.

4. Solution:

Before applying this update, make sure all previously-released errata
relevant to your system have been applied.

This update is available via the Red Hat Network. Details on how to
use the Red Hat Network to apply this update are available at
https://access.redhat.com/kb/docs/DOC-11259

5. Bugs fixed (http://bugzilla.redhat.com/):

734583 - CVE-2011-3205 squid: buffer overflow flaw in Squid's Gopher reply parser (SQUID-2011:3)

6. Package List:

Red Hat Enterprise Linux Server (v. 6):

Source:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/squid-3.1.10-1.el6_1.1.src.rpm

i386:
squid-3.1.10-1.el6_1.1.i686.rpm
squid-debuginfo-3.1.10-1.el6_1.1.i686.rpm

ppc64:
squid-3.1.10-1.el6_1.1.ppc64.rpm
squid-debuginfo-3.1.10-1.el6_1.1.ppc64.rpm

s390x:
squid-3.1.10-1.el6_1.1.s390x.rpm
squid-debuginfo-3.1.10-1.el6_1.1.s390x.rpm

x86_64:
squid-3.1.10-1.el6_1.1.x86_64.rpm
squid-debuginfo-3.1.10-1.el6_1.1.x86_64.rpm

Red Hat Enterprise Linux Workstation (v. 6):

Source:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/squid-3.1.10-1.el6_1.1.src.rpm

i386:
squid-3.1.10-1.el6_1.1.i686.rpm
squid-debuginfo-3.1.10-1.el6_1.1.i686.rpm

x86_64:
squid-3.1.10-1.el6_1.1.x86_64.rpm
squid-debuginfo-3.1.10-1.el6_1.1.x86_64.rpm

These packages are GPG signed by Red Hat for security. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/#package

7. References:

https://www.redhat.com/security/data/cve/CVE-2011-3205.html
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is . More contact
details at https://access.redhat.com/security/team/contact/

Copyright 2011 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFOcPqzXlSAg2UNWIIRAutlAJ9nlG0w3FNBVqFtxSNe10FKir/WkACeNQAA
rDOr/svPTfi23jLvkODeYbk=
=0hIH
-----END PGP SIGNATURE-----

--------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

http://www.auscert.org.au/render.html?cid=1980

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQIVAwUBTnE7XO4yVqjM2NGpAQJBUg/9HBkNpV+ASPWak3lQuRHjKxWks0HLZ5cU
eJaL78jwsL0JKTiRBoqe6eaCfzjHRAV7imnUbg1Q4xd+wMdukpU7ZbUSz2kvUeRw
icEkSpkKut8+LAzWHdkW80cks6C3rGmOaO7zEXcGjGe/9MeeaojdWYbFQII+IN1g
z3fz9bOTKSZOcHg3MB80zRafHxOuBUyJaqsOa93kEhd4gG8uJA8KzeXh6hJtrTsZ
vfrQsDJ2e46Ruxj4x8gTpw1hkKBU5XAaqR1iD7ijSaBLd0bAxkJckj2WsCxHodU8
/A1rgv5PxfsLA+4gli3p5Ua1PVqzs/ud/HpafOkyF+SE46je7E1S+HgYY45+CP3V
oZiDyjl+9q+FVpc/r5NmtzHHB9j1knKo8jJFMsi13diSdXp9AvD2ERhVF8gTnvGW
5kwZjLCcLgsPM+RtKw4X0Klla4/T4kvbWr6Y87x7/V84nx0sY+roCzV6yePI6j4u
z6JDXagOyg0QlOA0NYstxYeVqIRH3XJP

Original Page: http://www.auscert.org.au/render.html?it=14837

RedHat httpd: Denial of service

(15/09/2011) ESB-2011.0945 - [RedHat] httpd: Denial of service - Remote/unauthenticated

===========================================================================
AUSCERT External Security Bulletin Redistribution

ESB-2011.0945
Important: httpd security update
15 September 2011

===========================================================================

AusCERT Security Bulletin Summary
---------------------------------

Product: httpd
Publisher: Red Hat
Operating System: Red Hat Enterprise Linux Server 5
Red Hat Enterprise Linux Server 6
Impact/Access: Denial of Service -- Remote/Unauthenticated
Resolution: Patch/Upgrade
CVE Names: CVE-2011-3192

Reference: ESB-2011.0896
ESB-2011.0870.2

Original Bulletin:
https://rhn.redhat.com/errata/RHSA-2011-1294.html

--------------------------BEGIN INCLUDED TEXT--------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=====================================================================
Red Hat Security Advisory

Synopsis: Important: httpd security update
Advisory ID: RHSA-2011:1294-01
Product: Red Hat Enterprise Linux
Advisory URL: https://rhn.redhat.com/errata/RHSA-2011-1294.html
Issue date: 2011-09-14
CVE Names: CVE-2011-3192
=====================================================================

1. Summary:

Updated httpd packages that fix one security issue are now available for
Red Hat Enterprise Linux 5.3 Long Life, 5.6 Extended Update Support, and
6.0 Extended Update Support.

The Red Hat Security Response Team has rated this update as having
important security impact. A Common Vulnerability Scoring System (CVSS)
base score, which gives a detailed severity rating, is available from the
CVE link in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux (v. 5 server) - i386, ia64, ppc, s390x, x86_64
Red Hat Enterprise Linux (v. 5.3.LL server) - i386, ia64, x86_64
Red Hat Enterprise Linux Server (v. 6.0.z) - i386, noarch, ppc64, s390x, x86_64

3. Description:

The Apache HTTP Server is a popular web server.

A flaw was found in the way the Apache HTTP Server handled Range HTTP
headers. A remote attacker could use this flaw to cause httpd to use an
excessive amount of memory and CPU time via HTTP requests with a
specially-crafted Range header. (CVE-2011-3192)

All httpd users should upgrade to these updated packages, which contain a
backported patch to correct this issue. After installing the updated
packages, the httpd daemon must be restarted for the update to take effect.

4. Solution:

Before applying this update, make sure all previously-released errata
relevant to your system have been applied.

This update is available via the Red Hat Network. Details on how to
use the Red Hat Network to apply this update are available at
https://access.redhat.com/kb/docs/DOC-11259

5. Bugs fixed (http://bugzilla.redhat.com/):

732928 - CVE-2011-3192 httpd: multiple ranges DoS

6. Package List:

Red Hat Enterprise Linux (v. 5.3.LL server):

Source:
httpd-2.2.3-22.el5_3.3.src.rpm

i386:
httpd-2.2.3-22.el5_3.3.i386.rpm
httpd-debuginfo-2.2.3-22.el5_3.3.i386.rpm
httpd-devel-2.2.3-22.el5_3.3.i386.rpm
httpd-manual-2.2.3-22.el5_3.3.i386.rpm
mod_ssl-2.2.3-22.el5_3.3.i386.rpm

ia64:
httpd-2.2.3-22.el5_3.3.ia64.rpm
httpd-debuginfo-2.2.3-22.el5_3.3.ia64.rpm
httpd-devel-2.2.3-22.el5_3.3.ia64.rpm
httpd-manual-2.2.3-22.el5_3.3.ia64.rpm
mod_ssl-2.2.3-22.el5_3.3.ia64.rpm

x86_64:
httpd-2.2.3-22.el5_3.3.x86_64.rpm
httpd-debuginfo-2.2.3-22.el5_3.3.i386.rpm
httpd-debuginfo-2.2.3-22.el5_3.3.x86_64.rpm
httpd-devel-2.2.3-22.el5_3.3.i386.rpm
httpd-devel-2.2.3-22.el5_3.3.x86_64.rpm
httpd-manual-2.2.3-22.el5_3.3.x86_64.rpm
mod_ssl-2.2.3-22.el5_3.3.x86_64.rpm

Red Hat Enterprise Linux (v. 5 server):

Source:
httpd-2.2.3-45.el5_6.2.src.rpm

i386:
httpd-2.2.3-45.el5_6.2.i386.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.i386.rpm
httpd-devel-2.2.3-45.el5_6.2.i386.rpm
httpd-manual-2.2.3-45.el5_6.2.i386.rpm
mod_ssl-2.2.3-45.el5_6.2.i386.rpm

ia64:
httpd-2.2.3-45.el5_6.2.ia64.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.ia64.rpm
httpd-devel-2.2.3-45.el5_6.2.ia64.rpm
httpd-manual-2.2.3-45.el5_6.2.ia64.rpm
mod_ssl-2.2.3-45.el5_6.2.ia64.rpm

ppc:
httpd-2.2.3-45.el5_6.2.ppc.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.ppc.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.ppc64.rpm
httpd-devel-2.2.3-45.el5_6.2.ppc.rpm
httpd-devel-2.2.3-45.el5_6.2.ppc64.rpm
httpd-manual-2.2.3-45.el5_6.2.ppc.rpm
mod_ssl-2.2.3-45.el5_6.2.ppc.rpm

s390x:
httpd-2.2.3-45.el5_6.2.s390x.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.s390.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.s390x.rpm
httpd-devel-2.2.3-45.el5_6.2.s390.rpm
httpd-devel-2.2.3-45.el5_6.2.s390x.rpm
httpd-manual-2.2.3-45.el5_6.2.s390x.rpm
mod_ssl-2.2.3-45.el5_6.2.s390x.rpm

x86_64:
httpd-2.2.3-45.el5_6.2.x86_64.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.i386.rpm
httpd-debuginfo-2.2.3-45.el5_6.2.x86_64.rpm
httpd-devel-2.2.3-45.el5_6.2.i386.rpm
httpd-devel-2.2.3-45.el5_6.2.x86_64.rpm
httpd-manual-2.2.3-45.el5_6.2.x86_64.rpm
mod_ssl-2.2.3-45.el5_6.2.x86_64.rpm

Red Hat Enterprise Linux Server (v. 6.0.z):

Source:
httpd-2.2.15-5.el6_0.1.src.rpm

i386:
httpd-2.2.15-5.el6_0.1.i686.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.i686.rpm
httpd-devel-2.2.15-5.el6_0.1.i686.rpm
httpd-tools-2.2.15-5.el6_0.1.i686.rpm
mod_ssl-2.2.15-5.el6_0.1.i686.rpm

noarch:
httpd-manual-2.2.15-5.el6_0.1.noarch.rpm

ppc64:
httpd-2.2.15-5.el6_0.1.ppc64.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.ppc.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.ppc64.rpm
httpd-devel-2.2.15-5.el6_0.1.ppc.rpm
httpd-devel-2.2.15-5.el6_0.1.ppc64.rpm
httpd-tools-2.2.15-5.el6_0.1.ppc64.rpm
mod_ssl-2.2.15-5.el6_0.1.ppc64.rpm

s390x:
httpd-2.2.15-5.el6_0.1.s390x.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.s390.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.s390x.rpm
httpd-devel-2.2.15-5.el6_0.1.s390.rpm
httpd-devel-2.2.15-5.el6_0.1.s390x.rpm
httpd-tools-2.2.15-5.el6_0.1.s390x.rpm
mod_ssl-2.2.15-5.el6_0.1.s390x.rpm

x86_64:
httpd-2.2.15-5.el6_0.1.x86_64.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.i686.rpm
httpd-debuginfo-2.2.15-5.el6_0.1.x86_64.rpm
httpd-devel-2.2.15-5.el6_0.1.i686.rpm
httpd-devel-2.2.15-5.el6_0.1.x86_64.rpm
httpd-tools-2.2.15-5.el6_0.1.x86_64.rpm
mod_ssl-2.2.15-5.el6_0.1.x86_64.rpm

These packages are GPG signed by Red Hat for security. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/#package

7. References:

https://www.redhat.com/security/data/cve/CVE-2011-3192.html
https://access.redhat.com/security/updates/classification/#important

8. Contact:

The Red Hat security contact is . More contact
details at https://access.redhat.com/security/team/contact/

Copyright 2011 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFOcPvoXlSAg2UNWIIRAmGBAJwI2Fw6a21y6sQIufKOTMSqJsa8iwCghpOw
pVtt5SPsKbyHm0L/nXt0ZQM=
=shA7
-----END PGP SIGNATURE-----

--------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

http://www.auscert.org.au/render.html?cid=1980

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQIVAwUBTnE7Yu4yVqjM2NGpAQKEJQ/8D4uV4WFTPhfuMslvWq0HB2ZnQJEpLT9J
89hOtZ89f8x20zqosJcKk7QqqCfOtPAct9JnzxPsSVqGJxrQc/ViplkbNFzhe63o
hIZp5BT6XP1UWiSlFqnpbxBjxRhC0if6G/wH3/n9jGVRnJnnBENxScB3wftmcubQ
KYqXOMGXDE9LvJ1hf8Y5erYs5e5I74ixEIKMrNjwGgrYSdukKZBVmNwAu77DQCIZ
braEYMN8R3a/wOmMJUKueClMwjsbeQNNUsBA+0C54sPF4jFf6f/Evpb8bHs/8zZj
TYWFcvVZn/1o/lOx3B5YODYGWVEDvDPX/gTmw6J4Hp6OOnkbdwKngEVlsJcdA6IS
xFbLreHoGoAjxDqe223ISqDFJkrQFW2NZM9dwZxEveI1LE7L+JgM/wN13IYoZuRs
v9l21ss0/yXBwF7IIa8UmoRjR/NAN2wwPjb960TZ09O+rs9wIpzECQ8GyFxQpUEC
Op0jD3dJNpjZvnVcK4YPc4+DO2xvkPaW

Original Page: http://www.auscert.org.au/render.html?it=14838

Cisco Systems: Execute arbitrary code/commands

This summary is not available. Please click here to view the post.

23 August 2011

Anonymous dice que destruirá Facebook el 5 de noviembre


Anonymous, el mayor grupo de hackers en activo en la actualidad, y que ha llevado al caos a páginas como las de Apple, Telefónica y más de 70 organismos oficiales en todo el mundo, ha puesto fecha y nombre para un nuevo objetivo: Facebook.

Pero en esta ocasión no quiere bloquear el site, tirarlo durante unos minutos… como en el resto de sus ataques. En este caso, su objetivo es la destrucción total de la red social.

Así lo ha comunicado Anonymous en un vídeo oficial que ha subido a YouTube, en la que habla de la “Facebook OP”, (la Operación Facebook), que tendrá lugar el 5 de noviembre y que acabará con Facebook por la violación constante de la privacidad de los usuarios, y el hecho de que comercialice con los datos de los mismos hasta el punto de venderlos a los gobiernos que deseen vigilarles, según ha dicho el grupo de hacktivistas.

Facebook ha estado vendiendo información a las agencias de gobiernos, y ofreciendo acceso clandestino a los datos de los usuarios, por lo que permite espiar a gente de todo el mundo”, advierte en el vídeo. “Facebook sabe más sobre usted que su propia familia”, puntualiza.

Anonymous también acusa a Facebook de haber censurado sus cuentas sin motivo, y avisa “Facebook, prepárate para la batalla”. El grupo además ha creado una cuenta en Twitter y el ‘hashtag’ #opfacebook para dar más popularidad a su supuesto ataque.

Habrá que esperar cuatro meses para ver si se materializa la amenaza. Hasta ahora Anonymous no había avisado con tanta antelación, pero tampoco se había fijado como objetivo la destrucción total de un site. Veremos qué pasa.

La niña de 10 años que da 'clases' a los hackers

Defcon, la conferencia de seguridad que hackers benevolentes, sin ánimo de hacer estropicios, celebran en Las Vegas, ha tenido una ponente inédita.

Se trata de una niña de 10 años, cuyo alias en CyFi, que ha descubierto una vulnerabilidad en juegos para móviles con los sistemas operativos iOs y Android. Investigadores independientes han confirmado la veracidad del hallazgo.


Era duro, explica la niña, progresar en este tipo de juegos porque se hacía muy largo esperar a que crecieran las cosechas. Entonces pensó en alterar el tiempo.

Sacar provecho de una siembra de maíz puede suponer 10 horas. Pensó que una solución era forzar el reloj del móvil o tableta y fue en esta indagación cuando descubrió una vulnerabilidad que permitía hacerlo.

CyFi no ha dado los nombres de los juegos afectados. La niña detectó sistemas de prevención de estas manipulaciones pero también descubrió atajos para obviarlas, como desconectar el wifi del móvil.

La sesión se celebró en el marco de la conferencia que, por primera vez, ha abierto una sección para niños, DefCon Kids, ante la evidencia de la comunidad hacker es cada vez más joven. Una compañía, AllCrealID ofrece premios en este apartado.

Pirateo por engaño

En la misma conferencia, pero con protagonistas adultos, se realizó un experimento para demostrar la vulnerabilidad de las grandes compañías debido a la deficiente información sobre seguridad informática de sus empleados.

En la prueba se demostró lo ridículamente fácil que era engañar a empleados de una empresa para que suministraran información que comprometía la seguridad de sus equipos.

En un caso, se convenció a un trabajador para que diera datos sobre la configuración de su ordenador, lo que puede ayudar a escoger el programa malicioso más apropiado para realizar una intrusión.

Este mecanismo tiene incluso un nombre: ingeniería social. El conocido ex hacker Kevin Mitnick, por ejemplo, la considera una de las principales armas para el asalto informático.

Se trata de engañar a un empleado para que suministre datos importantes sobre el sistema informático.

Un ejemplo clásico es llamar a una secretaria en nombre del supuesto equipo de informática de la compañía, explicar que se está procediendo a cambiar las contraseñas para reforzar la seguridad del sistema y solicitar la de su jefe para tal supuesto propósito.

Con increíble facilidad se obtiene la información buscada.

Entre las compañías en las que se hizo la prueba figuran Oracle, Apple, AT&T Delta Air Lines, Symantec y Verizon.

Agencias, 09 de agosto de 2011 a las 10:18

22 August 2011

Kaspersky disputes McAfee's Shady Rat report

Last week, Congresswoman Mary Bono Mack (CA-45), Chairman of the House Subcommittee on Commerce, Manufacturing and Trade, sent a letter to Dmitri Alperovitch, Vice President of Threat Research at McAfee, requesting further information on his recently published report “Revealed: Operation Shady RAT.”

First of all I’d like to say straight out that we do not share the concerns surrounding the intrusion described in the report, which intrusion the report claims has resulted in the theft of sensitive information of multiple governments, corporations and non-profit organizations.

We conducted detailed analysis of the Shady RAT botnet and its related malware, and can conclude that the reality of the matter (especially the technical specifics) differs greatly from the conclusions made by Mr. Alperovitch.

We consider those conclusions to be largely unfounded and not a good measure of the real threat level. Also, we cannot concede that the McAfee analyst was not aware of the groundlessness of the conclusions, leading us to being able to flag the report as alarmist due to its deliberately spreading misrepresented information.

I’d like to give my own answers to the key questions posed in the letter, to firmly establish the assessment of the situation by Kaspersky Lab as global security researchers – not only for the US, but for all nations concerned with cybercrime and advanced threats.

The report suggests the high-profile intrusions of recent months are neither sophisticated nor novel. How do these unsophisticated intrusions differ from the intrusions that were the focus of your report?

Many of the so-called “unsophisticated” intrusions that the IT security industry has discovered recently and which have been so prominent in the news should in fact be labeled just the opposite: “sophisticated”.

These sophisticated threats – such as TDSS, Zeus, Conficker, Bredolab, Stuxnet, Sinowal and Rustock – pose a much greater risk to governments, corporations and non-profit organizations than Shady RAT.

For example, TDSS controls one of the world’s largest zombie networks, made up of more than 4.5 million computers worldwide. It contains extremely sophisticated techniques and implements a whole range of risky payloads that can lead to the theft of sensitive information and even funds in bank accounts, to spam distribution, DDoS attacks and much more.

On the other hand, most security vendors did not even bother assigning a name to Shady RAT’s malware family, due to its being rather primitive.

Are such intrusions something the government and private sector can effectively prevent or mitigate on a continuing basis?

Most commercially-available anti-virus software is capable of preventing infection by the malware involved in Operation Shady RAT; most doesn’t require a special update to do so either, capable of detecting the malware generically.

Did the logs analyzed by McAfee reveal novel techniques or patterns that would be helpful in our efforts to combat cybercrime?

We are fairly sure that the logs that McAfee analyzed did not differ from the logs all the other security vendors analyzed.

Here are our findings: unlike malware from the abovementioned sophisticated samples, we found no novel techniques or patterns used in this malware. What we did find were striking shortcomings that reveal the authors’ low level of programming skill and lack of basic web security knowledge.

In addition, the way the malware spread – via masses of spam messages with infected files attached – is now considered to be old hat; most modern malware uses web attacks to get to target computers. Shady RAT also never used any advanced or previously unknown technologies for hiding itself in the system, any countermeasures against anti-viruses, or any encryption to protect the traffic between the servers and infected computers. Needless to say, these are features inherent only in sophisticated malware.

What is the greater target: intellectual property and national security information, or consumer information that can be used to perpetrate identity theft?

There is no evidence showing what sort of data has been acquired from infected computers, or if any data has been acquired at all.

We can only understand what data (if any) has been stolen by conducting an in-depth investigation within an affected organization to examine the actual access rights of the infected computers.

The report suggests that the more insidious intrusions are more likely to occur without public disclosure. Would more public disclosure help or harm industry efforts to fight this type of cybercrime?

Some of the more insidious intrusions take place without the general public becoming aware of them. What’s more, they can go undetected for some time before being discovered by the IT security industry, and this is likely to continue due to the nature of the architecture of modern software and the Internet.

However, regarding Shady RAT, the IT security industry did know about this botnet, but decided not to ring any alarm bells due to its very low proliferation – as confirmed by our cloud-based cyber-threat monitoring system and by other security vendors. It has never been on the list of the most widespread threats.

For years now the industry has adopted the simple and helpful rule of not crying wolf.

A very important question that has slipped off the radar is what state is behind this intrusion?

It’s not possible to give a straight and clear answer to this question; however, it looks overwhelmingly likely that no state is behind the Shady RAT botnet. How the botnet operates and the way the related malware is designed reveals startling fundamental defects hardly indicative of a well-funded cyber-attack backed up by a nation state.

A good example of a cyber-attack most likely backed by a nation state is Stuxnet. Just compare the number of vulnerabilities used, special techniques, and the various assessments of the development cost. With Shady RAT we are dealing with a lame piece of homebrew code that could have been written by a beginner.

On the black market the Shady RAT malware would be valued at not much more than a couple hundred dollars. Even if an “evil” state were to decide to launch a targeted attack, it could buy much more sophisticated malware for just $2,000 – $3,000. And most certainly the evil state wouldn’t use the same command and control server for five years, and then keep it operating after it was revealed in the world media that it had been exposed – allowing security researchers to conduct in-depth analysis of the botnet.

We believe that this act was performed by rather novice criminals who were testing the ground, but who didn’t improve their skills much at all since the date they started the botnet.

To summarize the Shady RAT report:

Was it the most sophisticated attack ever?

No.

Was it the longest-lasting attack ever?

No.

Was it a historically unprecedented transfer of wealth?

No.

Is there proof that 71 organizations were compromised and had data leaked?

No.

Was it backed up by a state?

No.

Does Shady RAT deserve much attention?

No.

Send to you via TechRepublic for iOS

01 July 2011

New Desktop Blogging for Linux


GNOME blog is a desktop blogging application for Linux and Unix. Easy and quick to use to help you writing your great blog posts.


Features


- Simple to use interface


- WYSIWYG styled text support


- Panel popup allows entries can be written gradually over the course of a day


- Spell checking


- Drag and drop support for images


Download


Latest stable release is 0.9.2


Packaged stable releases should be available through your distribution.


Sources are available at ftp.gnome.org.


29 April 2011

Epsilon: Mayor robo de datos online de la historia

La empresa Online Epsilon sufrió lo que los expertos consideran como uno de los mayores ataques informáticos hasta la fecha. Epsilon es una empresa que ofrece servicios de Marketing Online que gestiona aproximadamente 400,000 millones de anuncios y ofertas por email al año, esta ha sufrido el ataque de un hacker que habría logrado robar archivos de información privada de sus consumidores.
La verdad es que a pesar de la magnitud de este ciberataque, la evidencia apunta a que el cibercriminal no llegó a acceder a los números de tarjeta de crédito, passwords o números de seguridad social. Actualmente la policia esta tratando de esclarecer las causas de este atentado, mientras la empresa Epsilon no ha proporcionado datos concretos sobre las empresas afectadas. (¡Hola RSA!)
También se dice que entre los afectados podría encontrarse la cadena hotelera Marriot y Kroger, que es la segunda cadena de supermercados de Estados Unidos.
Algunas compañias que trabajan con Epsilon, como es el caso de importantes entidades financieras como: Bancorp & Citigroup, JPMorgan Chase, Bestu Buy, TiVo, Kroger, las farmacias Walgreen, Barclays Bank, la firma de tarjetas de crédito Capital One Financial, ya han avisado a sus clientes del incidente para prevenirles de posibles ataques de Phishing, con el fin de obtener datos de sus cuentas corrientes.
“Nuestros proveedor de correo electrónico, Epsilon, nos ha informado que un individuo o individuos tuvieron acceso de forma no autorizada a información limitada sobre usted”, aseguró HSN, operador de e-commerce, en un correo enviado el domingo a sus clientes.
  • Los nombres y correos electrónicos de clientes de Citigroup y de otras grandes compañías estadounidenses fueron expuestos en una gigantesca violación de datos, después de que un pirata informático se coló en la empresa de marketing online Epsilon.
  • Los nombres y contactos electrónicos de algunos estudiantes afiliados al College Board -que representa a unas 5 mil 900 facultades, universidades y colegios- también estaban potencialmente comprometidos.
  • Epsilon contactó durante el fin de semana a sus clientes para advertirles que parte de su información electrónica podría haber sido expuesta.
  • No parecía que se hubiera expuesto información financiera como tarjetas de crédito o números de seguridad social, según los comunicados de las compañías y correos electrónicos enviados a clientes.
  • La firma, con más de 2.500 clientes, envía más de 40 mil millones de anuncios y ofertas por correo electrónico cada año, normalmente para gente que se registra en una página de una compañía o da su dirección de e-mail mientras compra.
“Esta información incluía su nombre y dirección de correo electrónico y no incluía ninguna información financiera o sensible. Consideramos que era importante notificarle este incidente lo antes posible”, añadió.

abril 5th, 2011

28 April 2011

De la C, la E y la H


CEH. Certified Ethical Hacker. Tomé el curso recientemente. Los que ya lo han tomado, sabrán que se trata de que uno entienda en general las técnicas usadas por “los malos” para penetrar sistemas/redes y poder así lograr sus fines.

La idea es que si no sabes las técnicas de ataque, difícilmente sabrás cómo defenderte.  En el curso te dan un “overview” de las fases del hackeo que básicamente son: Reconocimiento, Escaneo, Obtención de accesos (a nivel sistema y/o red), Mantenimiento del acceso y el Borrado de huellas.

Para cada una de las fases te dicen de qué se trata y qué herramientas (aplicaciones) usan “los malos” para completar esa fase. Recordemos que la diferencia entre un hacker y un profesional de seguridad es la intención y los objetivos perseguidos; las herramientas y técnicas son las mismas pero unos las usan para atacar y otros las prueban (sin daño) para entenderlas y poder defenderse.

El curso tiene una duración de 5 días donde se introduce al asistente en el mundo del hackeo, se muestran técnicas y herramientas usando no sólo PowerPoint sino también laboratorios en ambientes controlados para hacer prácticas.
Ahora bien, algunas opiniones respecto al curso:

+ Mil y un herramientas. Lo cierto es que la cantidad de herramientas que el curso pretende que “veas” es considerable y si sigues tal cual lo que indica el curso no acabas de dominar ni una sola. Tal vez esa es la intención, pero caramba, en unas cuantas semanas apenas y recordarás el nombre de los cientos de programas que se pretenden ejecutar y conocer.

+Leyes de EUA. El curso toca el tema de leyes, pero centrado en EUA. Afortunadamente fue breve, ya que en lo particular confieso que me aburren las leyes y en todo caso el material debería de “tropicalizarse” para incluir leyes de otros países.

+Herramientas desactualizadas. No todas las herramientas incluidas en el material del curso fueron “del 2010” o recientes. No puedo decir un porcentaje, pero por ejemplo el libro incluye Smurf que fue un ataque de finales de los noventa, el POD (Ping of Death) que explotaba una debilidad de la pila TCP/IP en varios sistemas existentes en 1996 (al menos esa es la fecha del aviso del CERT). También el material incluye el NetBus que algunos de mis compañeros en la Universidad llegaron a usar para gastarle bromas a otros estudiantes (estoy hablando de 1998-1999). Parecía un desfile retro de viejos ataques que llegué a ver o escuchar cuando estaba estudiando la ingeniería.  Algunas otras herramientas son viejitas pero vigentes, como por ejemplo nmap. Conclusión: está bien ver algunos ejemplos pasados de viejos ataques como que para saber “lo que existió”, pero vaya, yo sí le daría una actualizada al material del curso para ponerlo más 2010 y menos noventero (verdad, “wardialing”?).

+Instructor. Qué tanto te guste el curso y qué tanto te hayan quedado ganas de que pudo haber sido un poco mejor depende (en mi opinión) en gran medida del instructor. En mi caso el curso me gustó, David (Twitter @codigoverde) le dio un giro interesante y supo mantener mi atención con técnicas vigentes y herramientas usadas por “los malos” en el 2010 y aún así manteniendo el balance con los puntos importantes del material del curso. Sí se despegó -lo suficiente- del PowerPoint y de lo que decía el “manual” que se tenía que ver en cuestión de herramientas, y gracias al Dios Todopoderoso que lo hizo. Asimismo vimos herramientas a una profundidad adecuada. Es decir, la dinámica impuesta por mi instructor fue determinante para que el curso en general valiera bastante la pena y he de confesar que superó mis expectativas.

+ ¿Ya soy pentester si curso el CEH? En mi opinión, no. Tampoco si te certificas. Si a mí me viene un fulanito a decir que puede hacer un pentest a mi empresa porque tomó el curso y posteriormente se certificó CEH sin más credenciales y/o justificaciones, le diría que no gracias y seguiría buscando. Sólo tomar el curso y/o certificarte no te hace pentester, o al menos uno que haga un buen trabajo. Recordemos que un buen pentester domina a profundidad las técnicas y herramientas de hackeo para que con tu aval, lleve a cabo pruebas de hackeo controladas que muestren tus debilidades para que mejores. En mi opinión, el curso CEH es introductorio y (si aún no las tienes) tendrás que adquirir los conocimientos y técnicas -a profundidad- por otros medios.

+ Certificación vs Utilidad. ¿Quieres tomar el curso para certificarte CEH o para aplicar lo aprendido en tu trabajo? ¿Yo? Para las dos cosas. Aunque sinceramente me interesa más lo aprendido en esos 5 días. Hay varias cosas que me latería incorporar en lo que hago porque aumentará el valor de mi trabajo. ¿Me faltará tiempo para hacerlo? Tal vez, pero habrá que buscarlo  e incorporar técnicas de ahorro de tiempo, no?

¿Vale la pena el curso? Yo pienso que sí, opino que vas a aprender y de paso (estudiando) te certificas. Pero insisto de  nueva cuenta en que el instructor hace La diferencia.

En fin, ahora empezaré a buscar tiempos para estudiar y hacer el examen de certificación. Ya que lo haga les estaré contando de cómo me fue y cómo es el examen. Mientras tanto, nos vemos en Twitter: @FaustoCepeda


 Fuente | Hacking-mx

6 Easy Steps To Increase Your Privacy On Facebook

Organizing all of your Facebook friends into separate lists can help save you time and enhance the privacy of your posts and profile information.


You can set up friend lists for family, close friends, college pals, coworkers, industry friends, exes, and, well, whatever else you like. Then you will able to selectively share information using your Facebook account.



For starters, you’ll be able to post messages that are viewable only to the lists you designate. What’s more, you’ll be able to adjust your privacy settings so that your profile details are accessible only to your chosen friend lists.

Six Really Easy Steps

Follow these six simple steps to create a friend list on Facebook. You can create up to 100 friend lists and each list can contain up to 1,000 friends. If you like, friends can appear on multiple lists.
  1. On your Facebook homepage, click on the friends icon  in the navigation bar running down the left column.
  2. At the top right of the page, click on the icon with the pencil that reads “Edit Friends.”
  3. At the top right of the page, click on the icon with the plus sign that reads “Create A List.”
  4. A box will appear that reads “Create New List.” In the text box below this, that reads, “Enter A Name,” type in the name of the friend list you want to make, for example, “Industry”.
  5. You will see all of your friends appear in this box. Click on the names of the people you would like to add to the list you just made. Once you select a name, a check box will appear and the name and photo of the person you selected will be highlighted in blue. As you view all of your friends using the scroll bar at right, you can toggle at the top left of the box between “All” (which shows your entire friend network) and “Selected” (which shows the friends you have chosen to be to part of the list).
  6. Click on the link labeled “Create List” to save the changes you made

Modifying Friend Lists

At any time, you can change the name of the list or change the people on the list by selecting the “Edit” link that appears to the right of the list name.
To view, add or delete friend lists, go to your friends page and click on the “Edit Friends” button. Your friend lists will appear in the column at left. Click on each list to modify or delete it.

Limiting Who Sees What

When you post a status update, you can make it visible only to a selected friend list. To do this, after you type your message into the status update box, click on the lock icon. Scroll down and select “Customize.” Click on the drop-down menu under “Make This Visible To.” Select “Specific People.” Type in the name of the list you want to be able to see the status update.

To limit the people who can view your profile information to a friend list, click on “Account” at the top right of your screen.
Click on “Privacy Settings.” Then click on “Customize Settings” at the bottom left of the main text box.

For each option listed at left you can select from the drop-down menu at right “Customize.” Then, where you see “Make This Visible To”, click the drop-down menu and select “Specific People.” Type in the name of the selected friend list that you want to be able to view your profile.

Keep in mind that Facebook may continue to change its friend list interface in future. In the meantime, we suggest you forward this post to people you know who don’t have any lists set up yet — this might help get them started.

Posted by Julie D. Andrews on April 26th, 2011 1:00 PM

Consejos para Navegar Seguro

Me encontré con una lista de consejos del nic para navegar seguro en Internet donde varios de ellos lejos de ayudarme me hicieron quedar con cara de “what?”. Analicemos algunos de ellos con la intención de criticarlos constructivamente.
Respecto a las contraseñas nos dicen: “Se recomienda hacer uso de contraseñas largas, con diferentes letras, números y símbolos que al mismo tiempo sean fáciles de recordar”. Por “largas” creo que podemos decir que 8 caracteres puede ser suficiente (el nic no lo especifica). Sin mencionar que cuando tenemos 10, 15 ó 20 sitios a los que entramos seguido, acordarnos de “n” contraseñas complejas, diferentes pero fáciles de recordar es algo que pocos hacemos y que el nic no toma en cuenta. Lo que yo hago es usar LastPass que me ayuda a “recordar” estos passwords; así podemos cumplir con eso de que sean diferentes para cada sitio y complejas (y sin necesidad de tenerlas en la mente).

De los sitios nos dicen: “Evitar sitios de origen dudoso. Es importante pensar dos veces antes de hacer click en uno de estos anuncios, pues pueden ser causa de virus o spam”. En su consejo no nos dicen qué es un “sitio de origen dudoso” y nos recomiendan que pensemos dos veces antes de hacer click en “uno de estos anuncios”. Es ambiguo y no del todo cierto: hoy en día hasta sitios legítimos pueden contener contenido malicioso en frames, por ejemplo. No sé cómo definir un “sitio de origen dudoso”, ya que hay unos que ciertamente intuimos que lo pueden ser (por ejemplo pornográficos) pero otros ni idea (como el malware que apareció en el sitio del New York Times). Yo uso NoScript en los sitios que visito para dejar de pensar en si es dudoso o no; puede ser una verdadera lata pero hace su trabajo…pruébenlo y me dicen qué les pareció.

Pongamos el extracto completo que nos ofrece el nic para que vean que no ando intencionalmente seleccionando extractos incompletos: “Cuidar datos personales: El mal uso de los datos personales no sólo se remite a lo que el usuario comparte en sus redes sociales, pues también es importante considerar que nunca hay que escribir nombres, apellidos, direcciones, teléfonos o cuentas bancarias en sitios que no sean seguros. Para saber si un sitio es seguro, basta con revisar que el inicio de su dirección incluya una letra s (https://)”.
Me llama la atención la última parte en donde dicen que para saber si un sitio es seguro debemos de revisar que tenga “https” porque me es difícil ligar el tema de “datos personales” con el de TLS (https). Cuando un sitio cambia a https, lo que nos dice es que tiene un certificado válido; pero NO nos dice nada de qué harán con nuestros datos ni del cuidado de los mismos. El “https” crea un canal cifrado entre tú y el sitio, quien quiera que el sitio sea o pretenda ser. Nada más. Pueden intentar https://www.RoboTarjetasDeCredito.com y estarán tranquilos de saber que usa “https” y que aparece un candadito en su navegador, cierto?
Nos dicen: “No ejecutar archivos sospechosos” comentando que al navegar algunos sitios mal-intencionados nos pedirán descargar algún archivo aparentemente necesario. De nueva cuenta, eso de “archivos sospechosos” es ambiguo y poco claro, y por lo tanto poco útil. Sitios legítimos me piden también que descargue algún software (quítenle flash a su navegador y se sorprenderán) y me piden que habilite ActiveX o JavaScript (con NoScript se darán cuenta de esto último). ¿Entonces qué hacemos? Podemos usar un Sandbox, un firewall personal u otros controles (de preferencia preventivos como los ofrecidos) que le permitan al usuario común dejar de decidir si un archivo es “sospechoso”.

En fin, estos fueron algunos de los consejos que llamaron mi atención. La lección –creo- es que no debemos de aventar consejos ambiguos a los usuarios y sí usar nuestro sentido común para revisar bien lo que estamos diciendo; yo mismo he caído en esta trampa al asumir que el usuario a quien me dirijo es un CISSP.
Por otro lado, a algunos no les late poner “marcas” en su blog o artículo, pero las “marcas” pueden apoyar nuestras ideas o consejos. Tal vez se valga decir que no navegues en sitios inseguros y que puedes usar NoScript, por ejemplo. Así si no queda claro lo de “sitios inseguros”, al menos le estás dando un consejo claro y preciso de usar una herramienta. En fin, aquí siempre está el tema de “me pagan para poner marcas” que yo simplemente ignoro.

Si te das un tiempo de leer los consejos del nic, creo que coincidirás conmigo en que su concepto o lo que quisieron transmitir es valioso. Pero la ambigüedad y no ponerse en el lugar del usuario promedio a quien supuestamente van dirigidos los consejos, no fue muy atinado. ¿Tú qué opinas?

Fuente |  Hacking-MX

Conoce OWASP, una excelente iniciativa de Seguridad



Existen métricas para casi todo a nivel de proyectos de desarrollo de software, sin embargo, en temas de seguridad hasta hace unos años era un territorio virgen, no había gran avance en el tema, ya que la seguridad no era tenida en cuenta en los procesos de desarrollo o tal vez no pasaba de un checklist pequeño que revisaba posibles fallas de seguridad presentes en las aplicaciones.


En el año 2001, en Diciembre para ser más exactos, nace la iniciativa de OWASP, Open Web Application Security Project, como un grupo de expertos en temas de desarrollo y seguridad con las intensiones de plantear proyectos que a su vez trabajaran en temas de seguridad de aplicaciones, buenas prácticas para desarrollo seguro, pruebas de seguridad para software entre otros. Hoy en día OWASP cerca de sus primeros 10 años, plantea una organización sin ánimo de lucro conformada por un excelente grupo de profesionales de todo el mundo involucrados en varios proyectos desde la sensibilización hasta lo técnico trabajando en tres frentes (Entender como categorías): Detección, Protección y Ciclo de Vida.

A nivel corporativo, el requerimiento de implementar estándares como PCI (a nivel de transacciones de pago a través de medios electrónicos), hablan de la necesidad de implementar controles y ataques orientados al uso de OWASP, esto ofrece un marco de confianza y respaldo al trabajo en este gran proyecto.
Dentro de los frentes mencionados anteriormente, se encuentran proyectos que aportan sustancialmente a los equipos de desarrollo al hablar de código seguro, veamos algunos de ellos:

Proyecto Top Ten

Este proyecto consiste en la investigación y el respectivo análisis de las vulnerabilidades más presentadas a nivel de aplicaciones, una clasificación por criticidad, el tratamiento y presentación de soluciones para implementar. Se genera un documento anualmente y busca generar un estado del arte en temas de seguridad de aplicaciones, útil para evaluar y tomar medidas reactivas a posibles fallos de seguridad.

Proyecto Application Security Verification Standard (ASVS)

A través de este proyecto se propone un estándar o marco de referencia a través del cual se deben implementar los análisis de seguridad a aplicaciones web. Empleando el estándar como marco de referencia es posible el desarrollo de pruebas de seguridad y validación que las vulnerabilidades propuestas a través del Top Ten no se encuentren en las aplicaciones web analizadas además de otros tipos de análisis contra otros tipos de ataques.

Proyecto WebScarab

Se trata del proyecto en torno a un framework a través del cual se pueden analizar aplicaciones que se comunican a través de los protocolos HTTP y HTTPS. Su funcionamiento es similar al de un sistemas proxy de interceptación, permitiendo observar, editar y reenviar solicitudes creadas a nivel del navegador antes de ser enviadas al servidor. Su potencial es muy grande ya que cumple una función similar a aplicaciones como Tamper Data, permitiendo realizar ataques de Cross-Site Request Forgery (CSRF).

Proyecto Secure Coding Practices

Por medio de un documento que aborda las buenas prácticas para desarrollo seguro, un equipo de investigación dentro del proyecto OWASP, propone lineamientos, recomendaciones y referencias para aplicar en procesos de desarrollo de software totalmente adaptable al proceso llevado a cabo dentro del ciclo de vida del software a construir o en proceso.

Proyecto Enterprise Security API (ESAPI)




Por medio de Top Ten se identificaron las vulnerabilidades que se encuentran presentes con mayor frecuencia en proyectos de software. Por medio de herramientas como WebScarab se hace explotación de estas vulnerabilidades. Haciendo revisión de las buenas prácticas de desarrollo de software seguro se cuentan con lineamientos para involucrar buenas prácticas al proceso de codificación. Ahora es necesario implementar controles para evitar que el software desarrollado sea vulnerable a ataques conocidos. Es aquí cuando podemos hablar del proyecto Enterprise Security API, mejor conocido como ESAPI.

Un grupo de expertos en seguridad y desarrollo, ha puesto a disposición de todos una API para canocalización y sanitización (no recibir o enviar información que contenga caracteres o información que se pueda traducir en ataques) de entradas y salidas de información desde y hacia nuestras aplicaciones, ofreciendo controles estandarizados para las vulnerabilidades presentadas en el OWASP Top Ten.

ESAPI se encuentra disponible para lenguajes como PHP, JAVA, Python, .NET, ASP, Ruby, entre otros, además de ofrecer documentación para su implementación a través del uso de patrones de software.
El uso de ESAPI como API de control de ataques ofrece múltiples beneficios a equipos de desarrollo:
  • Facilidades de implementación en diversos lenguajes y tecnologías
  • Capacidad de transformación de acuerdo a las necesidades cambiantes del área de seguridad y especialización de ataques, similar a la frase: “No reinventar la rueda, sólo optimizarla“
  • Ofrecer calidad en los procesos de desarrollo a través de el cumplimiento de buenas prácticas y estandarización de codificación.
Para finalizar esta revisión del proyecto OWASP, una invitación a participar en los capítulos locales en cada país o formar uno, de la misma forma, acercarse a este tipo de proyectos que similares a proyectos de software libre, aportan en gran medida a procesos de mejoramiento continuo y estandarización, algo necesario en el mundo empresarial actual y asociado a ese tema que tanto nos apasiona, la seguridad de la información.

Fuente | Hacking-MX