Tag Archives: Linux

[iPhone] XPwn Command Line Utility released

As member of the iPhone Dev Team, planetbeing today released “XPwn”. He describes “XPwn” as an experimental pwnage tool for Linux. Although XPwn was proposedly developed for Linux users, it actually is a cross-platform tool for command line users. Update: It does not support firmware 2.0 yet.

Warning

The XPwn tool is not intended to be used by newbies. That’s why it’s called experimental pwnage tool. It provides a command line interface only, what means you can dreadfully screw up your iPhones using it. The first version of XPwn seemed to have issues when writing the NOR firmware. Although planetbeing has obviously fixed this problem, we really recommend to wait for Pwnage 2.0.

XPwn’s versions

Experimental Pwnage comes in different flavours:

XPwn’s features

Experimental Pwnage implements many of Apple’s proprietary container formats: img2, 8900, complzss, iBootIm, dmg, HFS+/HFSX.

Nice work. Congrats to planetbeing. See XPwn hackint0sh thread here.

[MultiPlatform] TrueCrypt 6.0 released

TrueCrypt is the leading open-source software to encrypt drive volumes. It supports Windows, MacOS X, and Linux. Version 5.1 has been released just 3.5 months ago in march. Now the Truecrypt team has released version 6.0 with the following features:

  • Parallelized encryption/decryption on multi-core/multi-cpu systems – thus demanding less time for the en- and decryption operations
  • Windows Vista, XP, 2003, 2008: run encrypted operating systems from hidden volumes (!)
  • Windows Vista, 2008: encrypt whole drives (incl. extended/logical partitions)
  • MacOS X: Create hidden volumes

Anyway: Permanent decryption has been removed from TrueCrypt’s bootloader, in order to support hidden operating system volumes. Permanent decryption now has to be done using the boot disk.

Enjoy a major step in to more privacy and download TrueCrypt 6.0 here.

[Linux] WINE 1.0 and Crossover 7 released

“WINE Is Not An Emulator” has been released in version 1.0. Since the first release of a 16bit version in 1993 it only took 15 years to eventually bring version 1.0 to the world. Since 1993 the development was an ongoing process with the help of a large community of volontarily testers.

In a Linux environment WINE basically hooks Microsoft’s Win32 APIs and translates them to Linux APIs – as good as possible, because Microsoft does not provide documentation for all of their APIs. Getting a program like Adobe’s Photoshop to work seemed not to be a hard issue. This is because Adobe uses an own API for many things like windows and their well known tool boxes. The main problem are programs like Microsoft’s Office. Microsoft makes heavy use of implementing undocumented APIs into their own products. Anyway this is a large milestone into a world that allows to choose which operating system fits your needs best, but without the disadvantage of having not all the standard software available.

While WINE is intended for Linux users, Crossover – a commercial version of WINE developed by Codeweavers -is available aswell for Linux as for MacOS X. Crossover allows user friendly GUI based installation of many Win32 programs and has been released at the same time in version 7.

Moreover we will see the impact of WINE 1.0 also in our beloved ReactOS project – which is a free and open source implementation of a Microsoft Windows 32 bit operating system that aims at complete binary compatibility.

Congratulations to the WINE team. Keep up your great work.

[Linux] Securing a Debian server by Enabling passwordless Login

I. Abstract

All of us know, there are lots of bad guys out there just trying to brute force our ssh ports. The following article provides information about the first steps to be performed when setting up a new webserver running Debian Etch.

For security reasons we recommend applying these how to’s before proceeding

  • Mandatory: How to secure your Debian server by updating the buggy openSSH Debian package (read tutorial here)
  • Optional: How to secure your Debian server by changing the SSH port number (read tutorial here)

The following howto will show you how to enable SSH login without a server based password (passwordless login) and how to disable password login in general on your server.

II. Generate SSH public- private-key pair

  • Generate keypair on your Linux client machine (works on Cygwin and Mac OS X as well!)
    client$ mkdir ~/.ssh
    client$ chmod 700 ~/.ssh
    client$ cd .ssh
    client$ ssh-keygen -q -f id_rsa -t rsa
  • You will be asked to provide a passphrase to encrypt your private key. Although you might leave this empty, we strongly recommend to provide it – for you own safety
  • In the folder called .ssh you will then find those two files:
    id_rsa > contains private-key (encrypted with your passphrase)
    id_rsa.pub > contains public-key (to be put on your Etch Webserver)

III. Upload public-key to server

  • In detail: the output of id_rsa.pub (which in fact is a textfile) is pushed via ssh on your root’s homefolder and being saved there as id_rsa.remote:
    client$ cat id_rsa.pub | ssh root@yourdomain.net cat “>“ id_rsa.remote

IV. Activate public- private-key authentication

  • log in to your server
    client$ ssh root@yourdomain.net (provide your password)
  • you may install nano (if you like vim, stay with vim), imho nano is faster for simpler tasks, but vim is much more powerful, so having both is no loss ;-)
    server$ apt-get install nano
  • Edit SSH configuration to allow public-key login
    server$ nano /etc/ssh/sshd_config
  • Allow AuthorizedKeysFile only (still in sshd_config)
    AuthorizedKeysFile %h/.ssh/authorized_keys
  • Disallow Password driven login (still in sshd_config)
    # Change to no to disable tunnelled clear text passwords
    PasswordAuthentication no
  • Save and exit (in nano: ctrl + x)
  • restart ssh deamon
    server$ /etc/init.d/ssh restart
  • Go back to your root’s home folder
    server$ cd
  • Makedir .ssh
    server$ mkdir .ssh
  • Copy uploaded id_rsa.remote to .ssh folder
    server$ cp id_rsa.remote .ssh/authorized_keys

V. Test your configuration

  • Don’t log out of your server, instead open a second terminal on your client machine to test your new configuration:
    client2$ ssh root@yourdomain.net
    (provide the passphrase for your private-key)
  • If everything works well, congratulations you’re done, consider clicking our sponsor (non offensive Google Adsense) to help maintaining this project free for all of you…

VI. Kindly Sponsored by


VII. Further steps

If you didn’t already do it. For further improving your server’s security you probably want to change ssh port address from 22 to anything else? Read here, how to do that…

[Linux] Change Standard SSH Ports

“and first for something complete different”: Muzaq… coding or administrating system can’t do without gooood muzaq. Check our latest tunes here :-)

Are you also tired of those weird guys, script kiddies and wanna-be-hackers, who are trying to ssh your server on port 22? All those connection attempts cost your server time and in the end your money.

I. Abstract:

By just changing the standard ssh port of your server you can reduce the amount of unwanted login attempts quite effectivly. Simply because it would take too much time for these ugly guys to find out about your specific configuration. Although this is just a basic proactive measure, it is statistically proven that a significant amount of these kiddies do decide to move on to try to hack another server.

II. Requirements

The following lines are being applied to a Debian Etch based box. Other distros should work similar, but I am not experienced with them. Moreover there is no specific knowledge required.

III. Edit sshd_config

  • get your favourite editor by hand (no matter if this is vi, vim, nano, joe or any other thing), here nano is sufficient. Btw: nano comes preinstalled on Mac OS boxes. In case it is absent I am quite familiar with vim aswell, but imho nano is much faster for simpler tasks like the one we’re going to solve and vim is much more powerful for complex operations.
  • nano /etc/ssh/sshd_config
  • see the line, where that code is written:
    # What ports, IPs and protocols we listen for
    Port 22
  • change this port to whatever port you like. May I suggest 8722 ?

IV. Recommendations for testing

  • If you are using a firewall (you should!!) don’t forget to open that port! Otherwise you won’t be able to login on that port ;-)
  • For testing purposes (like when you don’t have physical access to that server) I would really recommend to not edit the sshd_config by just changing that line:
  • # What ports, IPs and protocols we listen for
    Port 22

    I’d rather recommend to add a second port, like that:
    # What ports, IPs and protocols we listen for
    Port 22
    Port 8722
  • Your server will then listen on two ssh ports!
  • The advantage is: if anything (like) firewall doesn’t work you are not locked out of your box and won’t have to much hazzle with running a recovery console and so on.

V. Restart ssh deamon to apply changes

  • Ok let’s get our new (added or changed) ssh port running:
    /etc/init.d/ssh restart

VI. Login again

  • then open a new terminal and try to connect with the switch “-p” (port)
    ssh myuser@mydomain.com -p 8722
  • if the login attempt works on port 8722, you can remove “Port 22” from your sshd_config (restart ssh deamon then again)
  • otherwise login on port 22 as usual and fix your firewall settings

Don’t hesitate to leave a comment. In case that explanations where helpful do us the favor and visit our sponsor (Google). Thanks…

Sponsor:

[Linux] Workaround for SSH buffer error

I. Abstract
Some of you may already have experienced the same phenomenon. We wanted to secure one of our servers and disallow any password login. We configured the passwordless login to use ssh and use public-, private-key mode (see here) instead. But after having saved the sshd_config file, we eventually couldn’t reconnect to our Debian server from our Cygwin console. Instead we received a buffer error. The following lines show what we did and a somewhat not 100% clean workaround.

II. What did we do?

  • we set up a Debian Etch server to use Public and Private Key authentication only (see here how to do it)
  • we edited the sshd_config
    server$ nano /etc/ssh/sshd_config
  • we set
    PasswordAuthentication No
  • we saved sshd_config and quit vim
  • we restarted out beloved ssh deamon
    server$ /etc/init.d/ssh restart
  • we then logged out and found that we cannot login by entering
    client$ ssh -o PreferredAuthentications=publickey root@somedomain.com
  • arghhhhh…

III. Workaround

  • we examined the errors:
    buffer_get_ret: trying to get more bytes 4 than in buffer 0
    buffer_get_int: buffer error
  • After fumbling here and there we just removed the known_hosts file on the local client
    client$ rm ~/.ssh/known_hosts
  • we reauthorized the domain and guess what?
  • The error vanished
  • obviously the known_hosts was modified to have a line break somewhere in the middle of the public-key. I suspect openSSHp to have caused this incident

If the above solved your problem aswell, please help us maintaining this site by visiting our sponsors:

IV. Sponsored by