Discussion on:
View:
Show:
I'd have Hermey and Rudolph trace to the source and then order a large load of coal to be dumped on them from, oh, 10,000 feet or so.
Not being big on Web Apps or needing to secure them, I am not sure as to how the app server needs to be patched.
The first message seems to connect to http://www.bumblesnowmonster.com and downloads a small (0X0) jpeg from the snowmonster webpage.
The second script looks for the first script and then the CGI bin in the web app? Form here it looks as if it is grabbing the stored cookie and possibly the users login info to be returned to the bumblesnowmonsterpage?
Turning UP your IE security settings would disable the cookie from being stored in the first place, therefore nothing for the script to return.
Also, turning off the preview pane in your mail window would stop the script from downloading automatically as you browse your mail.
The web app side I have no clue about.
P.S. I only rated your article a 2 due to your hat, you don't have a beard and therefore are NOT the REAL Santa, you lost credibility and therefore so did your article.
I will be interested in seeing the correct answers though!
The first message seems to connect to http://www.bumblesnowmonster.com and downloads a small (0X0) jpeg from the snowmonster webpage.
The second script looks for the first script and then the CGI bin in the web app? Form here it looks as if it is grabbing the stored cookie and possibly the users login info to be returned to the bumblesnowmonsterpage?
Turning UP your IE security settings would disable the cookie from being stored in the first place, therefore nothing for the script to return.
Also, turning off the preview pane in your mail window would stop the script from downloading automatically as you browse your mail.
The web app side I have no clue about.
P.S. I only rated your article a 2 due to your hat, you don't have a beard and therefore are NOT the REAL Santa, you lost credibility and therefore so did your article.
I will be interested in seeing the correct answers though!
The 1st entry into the form was just a harmless probe to see if there was any form validation being performed or if it would just accept anything.
This keeps it under the radar of any application level filters that may be running, since a jpg is a commonly accepted extension.
Since the attacker found that the form did not do any form validation, it was time to exploit the application.
The exploit that they used, which is really unknown at this point, makes a call back to the maclicious website and runs the cgi script. Which in turns performs the actual exploit against the application. If I had to guess it was probable a sql exploit.
To prevent such attacks there is a multitude of ways to do so.
1. The programmers should of have made better use of/used form input validation. This simple measure would thwart most input validation attacks.
2. Use an application level filter such as URLScan if this is running on IIS.
3. Using SSL will help in preventing sniffed sessions on that site. You can also make it so that the pvt side site (naughty/nice db) is only accepting requests from certain networks.
E-mail on the client side
1. Virus Protection Software should be running not only on the desktop but at the mail gateway.
2. If using outlook, all e-mail should be read in the restricted zone.
3. To further mitigate it, you can have that network in a dmz where there is no web access allowed. That way if a url is embedded in a message body, the end user would never be able to retrieve it.
LordInfidel
This keeps it under the radar of any application level filters that may be running, since a jpg is a commonly accepted extension.
Since the attacker found that the form did not do any form validation, it was time to exploit the application.
The exploit that they used, which is really unknown at this point, makes a call back to the maclicious website and runs the cgi script. Which in turns performs the actual exploit against the application. If I had to guess it was probable a sql exploit.
To prevent such attacks there is a multitude of ways to do so.
1. The programmers should of have made better use of/used form input validation. This simple measure would thwart most input validation attacks.
2. Use an application level filter such as URLScan if this is running on IIS.
3. Using SSL will help in preventing sniffed sessions on that site. You can also make it so that the pvt side site (naughty/nice db) is only accepting requests from certain networks.
E-mail on the client side
1. Virus Protection Software should be running not only on the desktop but at the mail gateway.
2. If using outlook, all e-mail should be read in the restricted zone.
3. To further mitigate it, you can have that network in a dmz where there is no web access allowed. That way if a url is embedded in a message body, the end user would never be able to retrieve it.
LordInfidel
Members, remember to submit your answers to rudolph@counterhack.net by Wednesday, Dec. 17, 2003 to be in the running for a copy of Ed's new book.
Thanks,
Kimberly Henderson, Member Engagement
Thanks,
Kimberly Henderson, Member Engagement
I'm glad you sent the response to Ed and posted it on the site. We didn't want you to miss out on the contest.
I admit, I flubbed the 2nd question! The rest, I think I did OK on....
Fun, though.
Merry Xmas!
Fun, though.
Merry Xmas!
LordInfidel, this type of stuff is just not my strong suit.
But, it was fun to think about what was going on.
Here is a question: should I post my answers that I e-mailed to Ed?
But, it was fun to think about what was going on.
Here is a question: should I post my answers that I e-mailed to Ed?
it in that way...
I was just saying it was basically from a chapter in HE.
I would post it, if nothing more for sh*t's and giggles. I personally like to see how other people approach the same problem, which is why I posted mine.
I was just saying it was basically from a chapter in HE.
I would post it, if nothing more for sh*t's and giggles. I personally like to see how other people approach the same problem, which is why I posted mine.
Ok, here is my e-mail to Ed on this.
==============
1) The .JPG is being used as a tracer. The "child" is the owner of the bumblesnowmonster.com website (or he r00ted it, but that is another story!) and he can check the website usage logs. He posted an IMG image link, so that anyone who reads that link from an HTML-enabled program (like a web browser, e-mail client, and/or Santa's inhouse application), will actually call that .JPG file from the www.bumblesnowmonster.com web server. And giving the Height and Width a 0 means the picture would be, in effect, invisible. But, for the owner of the bumblesnowmonster.com web server, in their server logs, they would have the IP address of the machine that read the "childs" wish list. That public IP would then be used as the place to attack! Obviously, the "child" only wants the IP addresses for Santa and his elves, so as to attack their machines to try and get into them to change their status from Bad to Good. So, the first thing you need to do is recon nascence. Find out what IP range Santa has, to then probe for machines that could be attacked to gain access to the internal DB. Start port scanning the IPs you get for open ports to then try and exploit.
2) I am not a programmer, so I don?t quite know the reason for the 2nd attack, but I will guess here. Document.location says that this is where the .CGI file is located, again at the www.bumblesnowmonster.com domain. And document.cookie says that this file is a cookie file, the kind of file that stores username, date, time, domain, website hit count, password, and many other personal items on the user machine. So, I guess that this SCRIPT command is pulling the GRAB.CGI file, and probably querying the elf workstation for the information in the CGI file. Maybe it is trying to get the logged on username of the elf, and their OS version, and browser version. Now, normally cookies are stored on the user workstation, not on the server (only in server memory, not physically written), so I don?t understand why this would be good for the ?child? to have the elves trigger the .CGI file. Maybe the cookie file that will be written will be put on the web server instead of the elf workstation. If so, then the ?child? could have all kinds of useful hacking information. But like I said, I am not sure if a cookie can work in reverse like this.
3) Altering the web application: 1- by using some form validation to not allow hypertext tags and/or script commands like <SCRIPT> or or . 2 ? make sure that local scripts on the website cannot be exploited and that their security is correct and not lax, like disabling FrontPage extensions (in case Santa had them put on on accident!) Altering the elf browsers: 1 ? change the ActiveX scripting permissions, setting them on Prompt to run, not on the default Enabled. Same for Java Scripting. Make them ask you to run; don?t let them run by default. That way, if something strange pops up asking you to let the script run, you can click No to prevent it. 2 ? Set the Internet Security Zone settings to High, instead of the Medium that it is on by default. High zone does not let scripts run at all; I don?t even think they can ask you to run if you set the zone to High for the Internet zone. That would just not let any scripts like these to run at all.
4) E-mail configuration: 1 ? set the e-mail clients to read e-mail in Plain Text only, not HTML formatted text. With a plain text e-mail client, you would read the HTML commands, not just the results of HTML. This way, you would open an e-mail, see all of the HTML formatting, and it would NOT run. It would all just be harmless text, like when we read the 2 commands on the Techrepublic.com web page. They did not harm us. 2 ? go to the Secure Content section in Outlook (if the elves use Outlook to read their e-mail), click the Internet zone, and click the Zone Settings button, then change the Security level to High. This is the same as the 2nd option for the elves browser windows. Set the security to High so scripts cannot run. So, if the e-mail client still was able to display HTML-formatted e-mail, this way the scripts from the Internet zone could not launch.
==============
1) The .JPG is being used as a tracer. The "child" is the owner of the bumblesnowmonster.com website (or he r00ted it, but that is another story!) and he can check the website usage logs. He posted an IMG image link, so that anyone who reads that link from an HTML-enabled program (like a web browser, e-mail client, and/or Santa's inhouse application), will actually call that .JPG file from the www.bumblesnowmonster.com web server. And giving the Height and Width a 0 means the picture would be, in effect, invisible. But, for the owner of the bumblesnowmonster.com web server, in their server logs, they would have the IP address of the machine that read the "childs" wish list. That public IP would then be used as the place to attack! Obviously, the "child" only wants the IP addresses for Santa and his elves, so as to attack their machines to try and get into them to change their status from Bad to Good. So, the first thing you need to do is recon nascence. Find out what IP range Santa has, to then probe for machines that could be attacked to gain access to the internal DB. Start port scanning the IPs you get for open ports to then try and exploit.
2) I am not a programmer, so I don?t quite know the reason for the 2nd attack, but I will guess here. Document.location says that this is where the .CGI file is located, again at the www.bumblesnowmonster.com domain. And document.cookie says that this file is a cookie file, the kind of file that stores username, date, time, domain, website hit count, password, and many other personal items on the user machine. So, I guess that this SCRIPT command is pulling the GRAB.CGI file, and probably querying the elf workstation for the information in the CGI file. Maybe it is trying to get the logged on username of the elf, and their OS version, and browser version. Now, normally cookies are stored on the user workstation, not on the server (only in server memory, not physically written), so I don?t understand why this would be good for the ?child? to have the elves trigger the .CGI file. Maybe the cookie file that will be written will be put on the web server instead of the elf workstation. If so, then the ?child? could have all kinds of useful hacking information. But like I said, I am not sure if a cookie can work in reverse like this.
3) Altering the web application: 1- by using some form validation to not allow hypertext tags and/or script commands like <SCRIPT> or or . 2 ? make sure that local scripts on the website cannot be exploited and that their security is correct and not lax, like disabling FrontPage extensions (in case Santa had them put on on accident!) Altering the elf browsers: 1 ? change the ActiveX scripting permissions, setting them on Prompt to run, not on the default Enabled. Same for Java Scripting. Make them ask you to run; don?t let them run by default. That way, if something strange pops up asking you to let the script run, you can click No to prevent it. 2 ? Set the Internet Security Zone settings to High, instead of the Medium that it is on by default. High zone does not let scripts run at all; I don?t even think they can ask you to run if you set the zone to High for the Internet zone. That would just not let any scripts like these to run at all.
4) E-mail configuration: 1 ? set the e-mail clients to read e-mail in Plain Text only, not HTML formatted text. With a plain text e-mail client, you would read the HTML commands, not just the results of HTML. This way, you would open an e-mail, see all of the HTML formatting, and it would NOT run. It would all just be harmless text, like when we read the 2 commands on the Techrepublic.com web page. They did not harm us. 2 ? go to the Secure Content section in Outlook (if the elves use Outlook to read their e-mail), click the Internet zone, and click the Zone Settings button, then change the Security level to High. This is the same as the 2nd option for the elves browser windows. Set the security to High so scripts cannot run. So, if the e-mail client still was able to display HTML-formatted e-mail, this way the scripts from the Internet zone could not launch.
My solution I emailed to the sponsor was quite lengthy, so I'll try to condense it here.
The JPG is for logging the victim's IP address.
The "document.location" script function hijacks the browser session; the "document.cookie" object compromises the session information, and the "Grab" program assumes control.
"Grab" at a minimum will log the cookie info in preparation for a future attack.
Most likely "Grab" will simply copy the cookies and act as a Doppleganger of the victim, allowing the hacker to resume the session in progress as if he were the victim.
Worse still "Grab" might prompt the victim as if the password had been entered incorrectly, with an identically forumlated dialog to the real one (which the hacker could have seen and thus duplicated), and the victim will be fooled into handing over the password.
Lastly, and worst of all, "Grab" might try to trick the user into installing executables under the guise of an update of some sort. The user, believing he is logged in to the company website, might just be fooled into doing it.
Central to the hack however it is exploited is the hijacking of the browser away from the company server and into the clutches of the hacker's "Grab" program.
The solutions for fixing this hack are, on the server side, escape-sequencing all control characters from user-entered text, so that if the user enters, "<script>document.gotcha()</script>" what the data entry clerk sees is, "<script>document.gotcha()</script>". This simple solution elegantly frightens the data entry clerk into calling the IT department, who promptly take appropriate action. If the clerk ignores the suspicious text, well, the web app ignores it, too; no harm done.
On the browser side JavaScript is easy enough to disable, and there are also ways to explicitly disable domain-jumping which vary from browser to browser. It is also possible to disable images, but in my opinion that is a poor way to solve the problem of web bugs. If the web app hands the browser an image link, the browser should download and display it; that's its job. (But I would NOT extend that logic to the running of scripts!)
Lastly, the email client can be set to text-only, disabling HTML completely, or you can explicitly disable JavaScript and images, although on some email clients these prohibitions are shared with the browser, meaning disabling images in email requires they be disabled in the browser, too.
If you have an email server and a personal firewall (ZoneAlarm, of course!) you can set the personal firewall to allow the email client access only to the email server. Neither hackers nor spammers can tag your IP from an email image if your email client isn't allowed to access the Internet.
Although I personally use the ZoneAlarm setup it does not technically meet the parameters of the challenge, which require two email solutions based entirely on the email client's configuration. Still ... works for me.
So whaddya think? Worth a free book?
Derrick Jones, Software Developer
Managerial Assistance Corporation
The JPG is for logging the victim's IP address.
The "document.location" script function hijacks the browser session; the "document.cookie" object compromises the session information, and the "Grab" program assumes control.
"Grab" at a minimum will log the cookie info in preparation for a future attack.
Most likely "Grab" will simply copy the cookies and act as a Doppleganger of the victim, allowing the hacker to resume the session in progress as if he were the victim.
Worse still "Grab" might prompt the victim as if the password had been entered incorrectly, with an identically forumlated dialog to the real one (which the hacker could have seen and thus duplicated), and the victim will be fooled into handing over the password.
Lastly, and worst of all, "Grab" might try to trick the user into installing executables under the guise of an update of some sort. The user, believing he is logged in to the company website, might just be fooled into doing it.
Central to the hack however it is exploited is the hijacking of the browser away from the company server and into the clutches of the hacker's "Grab" program.
The solutions for fixing this hack are, on the server side, escape-sequencing all control characters from user-entered text, so that if the user enters, "<script>document.gotcha()</script>" what the data entry clerk sees is, "<script>document.gotcha()</script>". This simple solution elegantly frightens the data entry clerk into calling the IT department, who promptly take appropriate action. If the clerk ignores the suspicious text, well, the web app ignores it, too; no harm done.
On the browser side JavaScript is easy enough to disable, and there are also ways to explicitly disable domain-jumping which vary from browser to browser. It is also possible to disable images, but in my opinion that is a poor way to solve the problem of web bugs. If the web app hands the browser an image link, the browser should download and display it; that's its job. (But I would NOT extend that logic to the running of scripts!)
Lastly, the email client can be set to text-only, disabling HTML completely, or you can explicitly disable JavaScript and images, although on some email clients these prohibitions are shared with the browser, meaning disabling images in email requires they be disabled in the browser, too.
If you have an email server and a personal firewall (ZoneAlarm, of course!) you can set the personal firewall to allow the email client access only to the email server. Neither hackers nor spammers can tag your IP from an email image if your email client isn't allowed to access the Internet.
Although I personally use the ZoneAlarm setup it does not technically meet the parameters of the challenge, which require two email solutions based entirely on the email client's configuration. Still ... works for me.
So whaddya think? Worth a free book?
Derrick Jones, Software Developer
Managerial Assistance Corporation
Oops, made a boo-boo: the web app doesn't ignore escape-sequenced text; the browser ignores it. The web app generates the escape sequences so that the browser will ignore the script commands and instead display straight text.
But you folks knew what I meant, right?
But you folks knew what I meant, right?
Poor Rudolph and Hermey... If only they had Yukon Cornelius to help them find their way... Oh well, maybe a visit from jolly old St. Gnick will point them in the right direction.
1. What is the purpose of the first malicious wish text, and how does it work?
The first "wish" seems to be what is known as a "web bug". These are very small image links (often 0x0 or 1x1) that are nearly invisible to the average browser, but provide feedback to the person who placed them. Recently, they have become very popular with spammers who place unique web-bugs in their e-mail messages. That way, if the message gets viewed and the image loaded, they can see that the web-bug was retrieved and can assume that they've contacted an active e-mail address. Most likely, the Bumble-Snow-Monster placed it on his wish list so that he would be alerted as soon as an elf was authenticated and had loaded his wish list.
2. What is the purpose of the second malicious wish text, and how does it work?
The second malicious "wish" is the really nasty bit. Because the elves have the convenience of being able to authenticate only once and then transparently use the administrative- and user-level applications, their session-id is very likely being stored as a cookie so that the server will recognize them and grant them appropriate privileges. The Bumble is attempting to retrieve the cookies stored from the elf's computer so that he can replicate them on his own machine and either hijack or piggy-back on the administrative elf's session with all of the additional privileges.
3. How could Hermey and Rudolph thwart the first and second types of attacks by altering the Web application? Alternatively, how could they stop these attacks by changing the configuration of the analyst elves' browsers?
The right way to prevent this kind of abuse is almost certainly by filtering the kind of input allowed by users into the application. By strictly restricting the kiddies' input to only alpha-numeric characters, virtually all risk from this kind of attack would be eliminated. Some people may argue that the kids should be allowed to insert hyperlinks and images to help clarify for the elves just exactly which toys they want, but remember that we are working with experienced toy professionals that need no such aids to accurately process any wish that they may confront.
Alternatively, these attacks COULD be avoided by altering the elves' browser settings, but this should only be done in conjunction with the server side input filtering. There are several software packages that are available to filter out web-bugs, but these often back-fire and may disrupt the elves' net-surfing experience. For example, the page at techrepublic.com.com on which this challenge was hosted contains more than a dozen images that are sized 1x1 or smaller (b.gif and spacer.gif). These appear to be in place only to ensure that everything is laid out to look nice. If one REALLY wants to avoid loading very small images in his or her browser, they can either install software filtering, such as McAfee's Privacy Service, or they can disable automatic image loading in their browser settings.
The first thing that may help control hazardous scripts is keeping your browser-of-choice up to date by downloading the latest version. In addition, the elves should certainly control automatic script running. To do this, they would need to change their browser security settings to either force a prompt before running scripts, or disabling script running altogether. Under Internet Explorer, this security option is found under Tools->Internet Options->Security->Custom Level->Scripting->Active Scripting. The option there should be set to either ?Prompt? or ?Disable? ? certainly NOT the default, ?Enable?. While there, it wouldn?t hurt to verify and secure the settings for Java an ActiveX stuff. Instructions for doing this under several other applications can be found in Chapter 4 (Malicious Mobile Code) of the indispensable internet-security manual, Malware: Fighting Malicious Code.
4. Beyond these browser-based attacks, Hermey was also concerned about attackers submitting similar elements in children's wish lists submitted via e-mail. What are two different methods for defeating such attacks by altering an e-mail reader's configuration?
First and foremost ? DON?T RUN OUTLOOK! Not any version. Not any configuration. Not for any reason. Not ever. It is re-compromised weekly and has kept that record running for a good long time now. It is one of the most effective virus transfer utilities on the market. My first question to any of my friends or relatives that have contracted a worm or virus and want me to bail them out is always: ?Are you using Outlook Express?? About 90% of the time, I hear: ?Yes, how did you know?? Don?t use it. Ever. ?Nuff said there.
Protecting your e-mail utility is a great idea. There are very few good reasons to enable HTML content in mail applications. If an image is sent in e-mail, it can be sent just as well in an attachment. In-line images in e-mails are a spammer's best friend. Just by embedding a unique link to a 0x0 image, a spammer can send out millions of messages and have a relatively good idea of which ones got viewed. Automatically running scripts under in e-mail is even more hazardous. Far worse than just adding your name to spam-lists, an attacker that is allowed to run scripts in your e-mail can do really nasty things like installing a virus and then copying it to all of your friends and associates. Turning off scripting content in e-mail should tackle both of these problems. Using Eudora, scripting can be disabled under Tools->Options->Viewing Mail->Allow Executables in HTML Content. Again, instructions for doing this under other utilities can be found in Malware.
In addition to this, many ISP?s offer on-line access to email to allow you to screen, delete, or otherwise manage your mail using your internet browser. This provides an easy way to delete spam without even pre-viewing it to avoid scripts and web-bugs and applies the same security measures configured into your browser to your e-mail. I don?t know which ISP Santa uses, but it may be worth looking into for the elves.
Well, hopefully Rudolph and Hermey were able to help Santa before any nastiness took hold. And to all of you out there, naughty and nice, St. Gnick says Merry Christmas to all, and to all a good night.
-St. Gnick
1. What is the purpose of the first malicious wish text, and how does it work?
The first "wish" seems to be what is known as a "web bug". These are very small image links (often 0x0 or 1x1) that are nearly invisible to the average browser, but provide feedback to the person who placed them. Recently, they have become very popular with spammers who place unique web-bugs in their e-mail messages. That way, if the message gets viewed and the image loaded, they can see that the web-bug was retrieved and can assume that they've contacted an active e-mail address. Most likely, the Bumble-Snow-Monster placed it on his wish list so that he would be alerted as soon as an elf was authenticated and had loaded his wish list.
2. What is the purpose of the second malicious wish text, and how does it work?
The second malicious "wish" is the really nasty bit. Because the elves have the convenience of being able to authenticate only once and then transparently use the administrative- and user-level applications, their session-id is very likely being stored as a cookie so that the server will recognize them and grant them appropriate privileges. The Bumble is attempting to retrieve the cookies stored from the elf's computer so that he can replicate them on his own machine and either hijack or piggy-back on the administrative elf's session with all of the additional privileges.
3. How could Hermey and Rudolph thwart the first and second types of attacks by altering the Web application? Alternatively, how could they stop these attacks by changing the configuration of the analyst elves' browsers?
The right way to prevent this kind of abuse is almost certainly by filtering the kind of input allowed by users into the application. By strictly restricting the kiddies' input to only alpha-numeric characters, virtually all risk from this kind of attack would be eliminated. Some people may argue that the kids should be allowed to insert hyperlinks and images to help clarify for the elves just exactly which toys they want, but remember that we are working with experienced toy professionals that need no such aids to accurately process any wish that they may confront.
Alternatively, these attacks COULD be avoided by altering the elves' browser settings, but this should only be done in conjunction with the server side input filtering. There are several software packages that are available to filter out web-bugs, but these often back-fire and may disrupt the elves' net-surfing experience. For example, the page at techrepublic.com.com on which this challenge was hosted contains more than a dozen images that are sized 1x1 or smaller (b.gif and spacer.gif). These appear to be in place only to ensure that everything is laid out to look nice. If one REALLY wants to avoid loading very small images in his or her browser, they can either install software filtering, such as McAfee's Privacy Service, or they can disable automatic image loading in their browser settings.
The first thing that may help control hazardous scripts is keeping your browser-of-choice up to date by downloading the latest version. In addition, the elves should certainly control automatic script running. To do this, they would need to change their browser security settings to either force a prompt before running scripts, or disabling script running altogether. Under Internet Explorer, this security option is found under Tools->Internet Options->Security->Custom Level->Scripting->Active Scripting. The option there should be set to either ?Prompt? or ?Disable? ? certainly NOT the default, ?Enable?. While there, it wouldn?t hurt to verify and secure the settings for Java an ActiveX stuff. Instructions for doing this under several other applications can be found in Chapter 4 (Malicious Mobile Code) of the indispensable internet-security manual, Malware: Fighting Malicious Code.
4. Beyond these browser-based attacks, Hermey was also concerned about attackers submitting similar elements in children's wish lists submitted via e-mail. What are two different methods for defeating such attacks by altering an e-mail reader's configuration?
First and foremost ? DON?T RUN OUTLOOK! Not any version. Not any configuration. Not for any reason. Not ever. It is re-compromised weekly and has kept that record running for a good long time now. It is one of the most effective virus transfer utilities on the market. My first question to any of my friends or relatives that have contracted a worm or virus and want me to bail them out is always: ?Are you using Outlook Express?? About 90% of the time, I hear: ?Yes, how did you know?? Don?t use it. Ever. ?Nuff said there.
Protecting your e-mail utility is a great idea. There are very few good reasons to enable HTML content in mail applications. If an image is sent in e-mail, it can be sent just as well in an attachment. In-line images in e-mails are a spammer's best friend. Just by embedding a unique link to a 0x0 image, a spammer can send out millions of messages and have a relatively good idea of which ones got viewed. Automatically running scripts under in e-mail is even more hazardous. Far worse than just adding your name to spam-lists, an attacker that is allowed to run scripts in your e-mail can do really nasty things like installing a virus and then copying it to all of your friends and associates. Turning off scripting content in e-mail should tackle both of these problems. Using Eudora, scripting can be disabled under Tools->Options->Viewing Mail->Allow Executables in HTML Content. Again, instructions for doing this under other utilities can be found in Malware.
In addition to this, many ISP?s offer on-line access to email to allow you to screen, delete, or otherwise manage your mail using your internet browser. This provides an easy way to delete spam without even pre-viewing it to avoid scripts and web-bugs and applies the same security measures configured into your browser to your e-mail. I don?t know which ISP Santa uses, but it may be worth looking into for the elves.
Well, hopefully Rudolph and Hermey were able to help Santa before any nastiness took hold. And to all of you out there, naughty and nice, St. Gnick says Merry Christmas to all, and to all a good night.
-St. Gnick
#!/usr/bin/perl
#post it already! -sweeney
while (1) {
$rudolph =`lynx -head -source http://www.counterhack.net | grep Last-Modified`;
@modified = split /,/, $rudolph;
print @modified;
if ( $modified[1]=~m/22/ ) {
`echo http://www.counterhack.net | mailx -s \"Check XSS Results\" root`;
print "debug\n";
}
elsif ( $modified[1]=~m/3/ ) {
print "nope, not yet\n";
}
sleep(300);
}
#post it already! -sweeney
while (1) {
$rudolph =`lynx -head -source http://www.counterhack.net | grep Last-Modified`;
@modified = split /,/, $rudolph;
print @modified;
if ( $modified[1]=~m/22/ ) {
`echo http://www.counterhack.net | mailx -s \"Check XSS Results\" root`;
print "debug\n";
}
elsif ( $modified[1]=~m/3/ ) {
print "nope, not yet\n";
}
sleep(300);
}
Members, wait no longer. The answers and the winning entries are now on the site.
Congratulations to those who won, and thank you to those who participated.
Kimberly Henderson
Congratulations to those who won, and thank you to those who participated.
Kimberly Henderson
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
