On Jan 31, 2015 11:57 PM, "Adam Carter" <adamcart...@gmail.com> wrote: > > >> > Do they need telnet or ssh access, >>
Not telnet shell but this could be triggered with telnet/nc or even nmap, hping, or tcpreplay - all of which could send an arbitrary payload to tcp or udp ports. >> I don't understand this obsession with ssh or telnet. Remote code >> execution means that malicious party can execute any code on >> affected system. > > > To elaborate, since exim is an SMTP server it will be listening on TCP/25. All the attacker needs to do is run an SMTP command that will prompt exim to perform a lookup on a very long FQDN. The first command an SMTP client issues to an SMTP server is 'HELO <some FQDN>'. Exim can be configured to check if that the FQDN is valid, as a way of trying to distinguish spammers from valid mail servers. So here we have a situation where a security control happens to make the server less secure, and we have all that's required for exploitation in a nice package. Afaik, all remote attacks pretty much work the same. The example I'm sure most of us have seen is with http (especially since shellshock - right? - if not look up an example). You send a command to the server and then do something it isn't expecting. You can also see this all the time with php apps and options to do stuff in the app that wasn't intended. Half the time http stuff is base64 encoded - that's fine since the server natively decodes that. So here you have an api call that does something unexpected - IIRC it was a bounds issue. So once you figure out what the problem is, you look for apps that make the call in a way that could trigger the bug. Then you compile the program with debug symbols, step through it and try to trigger your exploit. After you get it working there locally you figure out how to to get that same bit of code to fire with that same malformed bit remotely. You keep in mind that if you're going at something at the tcp level, the packet still needs to be routed or broadcasted, and if you're going at something at the application layer (most remote code is here) you need to conform to the protocol until you're ready to trigger your evil bit (ie, you generally want to say hi to someone before you go into an explanation of how messed up they are - right?). Most services will end the connection or just sit there erroring until some timeout or whatever unless you start with their "hi" or a proper command. After that, have fun - you're on someone else's system - whether you do something evil or not, their system is processing what you sent <-- is the whole point of everything else I wrote and something worth remembering. Think of a shell as a REPL (Wikipedia) and every other protocol as an interpreter waiting to execute whatever you give it (or error out as most unfinished programs do). As for this, there's multiple places an email server *might* want to verify different positions of a domain. In the hello line, From, domainkey, etc. If that vulnerable part of exim code is executed trying to check something and you give it some evil bits (0s with 3 or less dots (.)), you might own a free server. HTH
