Otakumatic
New Member
TL;DR
What the fuck happened last night?
What the fuck happened last night?
@MartinD I was going to write up a response like that to his statement, but it's such a pain to write a long reply on my phone. And your post hits everything I would have said too 
Could or couldn't ?
Mmm? Have i missed something?
He is probably referring to this: http://www.localhost.re/p/solusvm-whmcs-module-316-vulnerability
I don't think it counts specifically as a WHMCS vulnerability, but instead more proof that SolusVM is malware.
I don't think it counts specifically as a WHMCS vulnerability, but instead more proof that SolusVM is malware.
1. A patch for curl is pending--see the bugs page for curl on sourceforge. The patch is to replace the bogo-random string with a harder to guess one (generated by openssl cryptographic prng).
2. I wouldn't completely call this a curl bug, but curl's behavior was suboptimal and the patch will help.
3 As a general principle, input "sanitzation" is doomed to failure and it's better to keep the control and data paths of a program completely separate, so that data doesn't need to be "sanitized" (it can stay dirty). For example, don't try to escape special input characters before splicing them into an sql query. Use prepared queries instead, so that the input data never touches the query parser. Little Bobby Tables will thank you.
4. If you absolutely can't avoid passing user data through some interpretation layer, it's best to encode it so that it can't possibly be parsed as controlling something. I've sometimes used hexadecimal encoding for this since it's simple and not much can go wrong. It does require controlling both sides of the communication so that the other side can decode, i.e. it might not have been applicable to this particular attack (though it would have stopped it because of the high likelihood of non-hex chars in the curl-generated separator string). Using base64 sounds more efficient than hex but I've seen it hit various problems. But it requires some control over both sides of the transaction
2. I wouldn't completely call this a curl bug, but curl's behavior was suboptimal and the patch will help.
3 As a general principle, input "sanitzation" is doomed to failure and it's better to keep the control and data paths of a program completely separate, so that data doesn't need to be "sanitized" (it can stay dirty). For example, don't try to escape special input characters before splicing them into an sql query. Use prepared queries instead, so that the input data never touches the query parser. Little Bobby Tables will thank you.
4. If you absolutely can't avoid passing user data through some interpretation layer, it's best to encode it so that it can't possibly be parsed as controlling something. I've sometimes used hexadecimal encoding for this since it's simple and not much can go wrong. It does require controlling both sides of the communication so that the other side can decode, i.e. it might not have been applicable to this particular attack (though it would have stopped it because of the high likelihood of non-hex chars in the curl-generated separator string). Using base64 sounds more efficient than hex but I've seen it hit various problems. But it requires some control over both sides of the transaction
Even if there's nothing announced right now I'd still be very wary of a WHMCS exploit. It's happened repeatedly in the past and they've proven their code is of very poor quality. If you're going to be using WHMCS you should ensure the machine is really locked down, and preferably isolated on its own VM.