SMPT engines...

:)
Hi again,
I've done a bit of searching, but couldn't find what I was looking for.
So here goes my question:

If a box becomes infected with a worm or trojan that carries a SMPT engine as a payload,
does it leave evidence of the e-mails it has sent, akin to a log as in the "SENT ITEMS" folder
of popular e-mail programs? If it is harvesting addresses from the 'official' e-mail program, is
it not using some of its functionality, or does the SMPT engine (the bad one) just run in the background? Could somebody be so kind and enlighten me on this process. I would have thought that if the SMPT engine spews out a bunch of e-mails, my 'Sent Items' folder would be overflowing, and if not, why?
Just would like to get to the bottom of this. I think that the address book is a seperate entity, but am lacking some insight on this subject.

Thanks

g8way2u

1. Completely depends upon the OS. In Windows, there will be no kept logs of usage since it is a seperate SMTP engine. However, if an email fails to send properly, chances are it will end up back in your inbox as "Message Undeliverable", but that hardly constitutes a logfile. On the other hand, within a *nix/*BSD distrobution, it would most certainly be logged. I'n nearly positive sendmail logs activity in and out as normal procedure, including seperate SMTP engines. On the other hand, getting a seperate SMTP worm engine to work on nix is near null since it does not have proper permissions or area control.

2. Let's assume then that you are talking about Windows based machines. There are many ways it harvests email addresses, some by having you open the normal email client you use while it snags the list, or simply extracting the list on it's own automagically. Direct interaction with your typical client is not needed, and thus it would run as a process in the background. So in short, since it is it's own SMTP client engine, it does not keep logs of sent mail. Just like Outlook Express has an SMTP client, and has the option to keep sent mail in a sent mail folder, the actual SMTP protocol does not require that. Having outlook do that is merely a side convienence, and thus a viral/worm SMTP client engine would certainly not be required to make any sort of logs.

:)
Thanks for your prompt reply, pooh sun tzu!

It stands to reason then, that it would be desirable for a blackhat to achieve 'root' status on a L'nux or Unix box in order to install a seperate SMTP engine, or compromise the original one...and that it is not required on a Windows box, or am I missing something?
Forgive my naiviety, I'm still a semester away from taking Linux classes.

I'm aware of some differences in the OS's, and understanding them in this context may give me a better picture...

g8way2u

Correct, in order for an SMTP engine to have unlimited access it would need some way to run as root, especially if it is a secured and locked down box. However, since viruses usually use the lowest common idiot (easy exploits that never are patched) a lot of nix/BSD based viruses that use SMTP engines are near null. Why?

1. To get root on a nix/BSD box is not as simple as it sounds. It would require the virus having the following:

A. The exact exploit for the target OS
B. The exact exploit for the OS version
C. The virus' ability to exploit it and know how to automate itself as root.

You see, where as a Windows Virus can spread from a windows XP machine to a Windows XP machine, a linux based virus would have add hundreds of extra lines of code and even more exploits because it would run into Redhat machines, slackware machines, UNIX machines, solaris machines, FreeBSD machines, OpenBSD machines, different kernels, OSes constructed by hand, etc etc. So it would have to include the same exploit (or a similar one) in order for the virus to even spread. As you can see, the difference for that is immense, even damn near impossible.


2. Windows is windows. Most users run as administrator and thus the virus would have total access from the start. This also means that Windows XP is Windows XP. There isn't differenr flavors of XP, different kernels of XP, and different versions of XP (that make a difference at least). This means that one exploit for XP will work on each and every XP machine (unless that machine is patched for protection).

3. Unix is Unix. Most users run as a sub user, and only su (su means temp login as) root in order to make system critical changes once in a while. The sheer nature of this means the virus by default won't have the ability to run rampant through the entire system, because that user didn't have privleges in the first place. This also means, that in order for the virus to gain root access, it would have to have an exploit that is specific to the kernel, Operating system version, and Operating system type. And since not all versions of linux share the same exploits, that would mean the virus would have to automagically find the exploits per system and exploit them. The coding would be immense, and thus why linux viruses are limited.

Hope that helps :) If you need any further clarification, just let me know!

:)
pooh sun tzu, I thank you.

I would like to take the opportunity to digress from the original thread, since your explanation
seems to be relevant to some news item I read earlier today.


http://www.linuxdevices.com/news/NS5922153615.html

CEO of Green Hills, Dan O'Dowd just recently commented on how bad it is for the government to use open source software on systems that are tied in to the defense system. Your explanation seems to be a reasonable refutation of that argument. Makes one wonder if any backdoors are in Windows. What's good for the goose, is good for the gander.

Back to our regularly scheduled broadcast....

So, in hindsight, this is one reason to create a limited account in Windows. But does that mean
that an 'executable' cannot create a lot of damage opened in a Windows based client e-mail program running under limited priviledges? Or, otherwise, how effective would a 'rogue' .exe be?

g8way2u

Quote:

---

CEO of Green Hills, Dan O'Dowd just recently commented on how bad it is for the government to use open source software on systems that are tied in to the defense system. Your explanation seems to be a reasonable refutation of that argument. Makes one wonder if any backdoors are in Windows. What's good for the goose, is good for the gander.

---

Opensource versus Closed source, the argument about as old as gnome versus kde. Allow me to say the pros and cons of both, to help explain my thoughts on that matter (remember, just my opinions):

OpenSource:

Pros:

- Being open, the community of people can run checks to make sure that things that should not belong in the code, are kept out. Such as kernel source code. Hundreds, near thousands, of eyes can look over a bit of code and see if there are backdoors, trojans, or insecurities within the code. This means also, the ability to make security improvements immediatally and to the particular needs of he who uses it.

- Because of all the eyes looking at it, that means as many minds offering suggestions for speed improvements, stability improvements, and so forth. This also means the ability to make fixes/patches on the fly if someone notices broken code (distrubuting it back to the community is another story). This means also, the ability to make security improvements immediatally and to the particular needs of he who uses it.

- The ability to have the source at your fingerstips means the ability to fully understand how it works, therefore being able to have other programs work directly with the program they are using. For example, if Nvidia released the actual source code of their drivers, speed improvements and desktop improvements with Linux would be amazing, because now we could program the systems and new drivers to work specifically how we need them, forming a perfect handshake. This means also, the ability to make security improvements immediatally and to the particular needs of he who uses it.

Cons:

- Because it is open, people have the ability to look through it from top to bottom for security holes and errors. This can be a liability if the system using the program that is opensources is not properly secured against that exploit. Mind you, this links into a pro, as if one is ever found it can be immediatally patched and used.

- If you have some brand new, awesome idea for code and it is published open source, it is no longer just -your- code, but everyone's. People can take it and use it, or an idea similar to it, in their own programs. Of course, there are liscenses that help prevent this sort of thing, but the possibility still exists.



ClosedSource:

Pros:

- Since no one can view the code, exploits are either done by trial and error, coincidence, or by knowing firsthand that the program/OS in question is breaking an RFC (request for commend - the internet 'rules and guidelines' ot make things work) document. This means that exploits won't be as simple as reading the code, since there isn't any. This is the largest pro for closed source.

- If something breaks, you don't have to worry about fixing it yourself, as the person who created it and has the origonal source code has to fix it for you.

Cons:

- If something breaks, you CAN'T fix it yourself. At times, if there is a system specific exploit for example, that would leave you as a sitting duck waiting for a patch while you sit vulnerable.

- Closedsource means you are in the full hands of the people who wrote it. Leaving you to ask a few questions to yourself: "Do I trust the company not to place backdoors in the software?" "Do I trust the company to give security/update patches as soon as possible to help protect me?" "Have I eaten breakfast today?"


And there are my thoughts on that matter. Both are valid working models, and both have good and bad sides. Is one better than the other? I wouldn't think so, but I prefer the opensource model.

So, keep this in mind: There are more than one ways to keep an operating system secure -

1. Modify the source code to fix exploits and security
2. Use 3rd party programs and configurations to protect on a deeper level. (such as a firewall, antivirus, or kernel patches for added security)

This means that the moment you use a closed source system, you immediatally eliminate one solution you can use to solve your problems (modifying the source). Just my thoughts :) Chew on them for a bit.



Back to the topic:

A guest account, or similar like account, on windows would allow the rogue.exe to create damage, but not on a vast scale that running as administrator would. Since most viruses in windows have plenty of ways of overwriting the permissions you give files (such as a RAM based virus infecting anything that touches RAM, thus permissions don't matter), even then a strong enough virus could cause havok. What is the keyphrase here though?

But not as much damage as if they were running as administrator



edit: For the love of Tao, what is this guy's problem in that article you linked us to?

Quote:

---

We must not entrust national security to Linux

---

So he would rather entrust it in Windows, to which no one knows for sure if there are backdoors or not? Don't get me wrong, you can lock up a Windows box as tight as a UNIX box ( to a degree), but in the end can you honestly say to yourself without any hint of a doubt that

"There are no backdoors, trojans, or hidden activity going on within the code I've never seen."


I say the solution is to combine both models. Start with an open source distrobution such as linux or UNIX, and then modifying it to your own liking, keeping the source code just to that department of security. Take for example the NSA defence computers. They could take Linux From Scratch (a linux distro in which you quite literally built every single aspect of linux from the ground up, 100% customizable and configurable) and create their own new version of Linux. Let's call it STFU linux for now. So, the NSA is using the open source model to create a solid and editable Operating System, but using the close sourced model to simply keep it within NSA. So, the NSA continues using STFU linux that they created by hand, and no one would have any idea, and thus the source code itself for exploits would not even apply.

:)
Many thanks, this has been extremely informative.
Greenies coming at the first opportunity.

It is all about "being able" to make choices, but they have to have the underlying foundation
of understanding the OS's, amongst many other criteria. I'm a small step closer. It is with this understanding, that I hope to be able to ask better questions, improve my judgement of my environment, and help others as you've helped me.

g8way2u

It is my pleasure to help, so no worries about greenies. Welcome to the forums, and may your time here be full of learning and teaching.

As for understanding OS's and making choices per what an OS can do, I suggest reading a small topic I wrote titled:

"Which OS is right for me? - My thoughts" http://www.antionline.com/showthread...hreadid=254589


Mind you, I'm not trying to "promote" or offer a shameless plug, but I feel it will help give you a much more rounded opinion about an OS's capability, and thus helping lay the foundation for your newly learned information.

If ever you have questions, never hesitate to ask them here and we shall do our best to answer you. If ever you need a conversation faster than postings, my AIM is in my profile. I encourage anyone to use it whenever they need to :)

I have to disagree on some of your *nix points pooh...

Quote:

---

1. Completely depends upon the OS. In Windows, there will be no kept logs of usage since it is a seperate SMTP engine. However, if an email fails to send properly, chances are it will end up back in your inbox as "Message Undeliverable", but that hardly constitutes a logfile. On the other hand, within a *nix/*BSD distrobution, it would most certainly be logged. I'n nearly positive sendmail logs activity in and out as normal procedure, including seperate SMTP engines. On the other hand, getting a seperate SMTP worm engine to work on nix is near null since it does not have proper permissions or area control.

---

Because the virus/worm uses it's own SMTP engine it will not be logged. The (hostile) SMTP engine will deliver the email directly to the destination domain without using the local MTA. Any user can telnet somehost 25 and fake SMTP; so can any virus/worm/trojan.

Quote:

---

Correct, in order for an SMTP engine to have unlimited access it would need some way to run as root, especially if it is a secured and locked down box.

---

Why would it need root? It's outbound only so there's no need to open a port <1024 hence no need for root. As said above any user can telnet to port 25.

Everything else looks fine and to the point ;)