lots of beating around the bush

yeah:Oh crap

Yawn...

http://www.nnteenmodels.net/gfy/post-tits-or-gtfo.png

That is all being done under the advisement of counsel. Fortunately I do not get my legal advice from GFY. Lots of people here think they know everything about the law and you'd be amazed how little they do know. I have also been advised not to discuss it at this point. You can be assured tho that we want whoever this is found and punished more than anyone else.

No this shit is gonna be a 10-pager, I bet $50 on it

ServerGenius - I think the pattern would be the same. This is the simplest and easiest way to get member data and insert member records.

And from the Apache exploit to Johns serve getting hacked, all of it. Yeah.. they prob are related, some what. These people's job is to get into affiliate programs for user/pass details, as mind blowing stupid as that sounds to some people, it is true. Yes, they sell the emails too, and that's what leads to the money train.

True, but that depends on the processor(s) they use. Not all ask for address details or pass it back it through, don't think any have a phone number.

I'll confirm that. There's very minimal information on the member. I thought this was 'lacking' - but now I'm happy it's not there. In the end, there's a reason for everything sometimes you don't understand it, sometimes you don't agree with it, and other times you learn to understand it and accept that it was put there for a reason.

I am also going to start off my post with the disclaimer " i am not accusing, not attacking, not bashing, etc..." i am just asking a simple question.

You guys said you had "a" problem a couple months ago but you thought the scope was much smaller. Was the problem you noticed a couple months ago the same problem that was announced recently (compromised admin user/pass list)?

If yes?

I believe people who started checking the admin access logs recently said the script using the nats admin account was logging in several times a day for the last couple months. So, if this is the case so far, then why didn't you guys log into all of your clients servers that you had access to (all of which that could have been affected by a compromised admin password list) and look at the server logs to see if someone using Fred's account was logging in several times a day.

Its just an honest question so no need to be defensive, if am wrong with anyting I posted above let me know.

This part I wasn't suppose to paste, it doesn't have anything todo with the rest
off it......I noticed after I still was able to edit the post.......

php?action=add&add%5Busername%3A1%3A6%3A16%5D= fran k1&add%5Bpassword%3A1%3

Just spoke on ICQ with John for quite a while.....I won't reply to this thread till after I slept a few hours and the few drinks I had tonight aren't affecting
anything I write anymore.....which see now they did.......will get back and explain again and understandable tomorrow and what I meant with it and if
I understand it correctly or not........

One more time......I don't want or meant to stir shit with this.....I was asked
to look at something, I noticed something and I want to know if what I noticed is correct........nothing more nothing less nothing else........if that's
not clear....the problem is with those think it's something else......

good night for now, sorry for the confusion I may have caused.....tomorrow
I'll try to clear that up reply to valid responses which till now are only very few......

Good Night!

oh 1 more think that I feel I should mention is you that most security related
issues, vulnerabilities and possibilities that allow them to exploit almost never
are a result of 1 reason or flaw in a single part in the whole chain of things that
make up the total setup.....it's too easy to blame 1 thing or problem as the
whole reason bad things could happen......

there's a lot of other things other than a piece of software which affect
how much, how easy or even make it possible for things to go wrong that
wouldn't be possible to be exploited in a lot of cases when all related
parts in the whole setup would be all the way they should be........

everything can be fully secure itself but that won't make any difference
if the root password of your server is something silly as "password".

what I mean is the only thing that matters are the things that are possible
to exploit and none of whatever things maybe but only in certain situations
if they apply.....

example: using mysql username without a password for a mysql database
isn't the same on a server that doesn't allow mysql connections from any
other ip than 127.0.0.1 as a server who allows and accepts connections
from any real internet routed ips....

Is it a good idea to do on any of these examples......no it isn't.....is it as
bad or the same on these examples defenitely not.......could you honestly
say if it goes wrong....that the only reason for it is they way mysql is
setup is the only reason that caused it to go wrong.......I guess you could
but you would fool yourself if you did.........

Moral of this story pointing the finger to one reason which something went
wrong isn't the best thing todo until you ruled out every other option.....that
said I can safely say you none of those who have pointed their finger already
didn't rule out most if any other option at all as a possible option that could
be responsible for anything that went wrong.......

this probably also doesn't make much sense if it doesn't don't bother to try
to decypher it but just wait till tomorrow and a better explanation of what
I tried to say :1orglaugh

Shutting down my computer now......

If the IP restrictions have been set up in the admin, then the response page is always the same - members.php (if the user is logged in with a valid password). This means that the server response should not be 200, but 302 - a redirect (moved temporarily), followed by a a 200 response for /members.php

Here is an excerpt from a test I just ran on my IP where I had not included my IP in the admin IP restrictions section:

So, maybe this program didn't have IP restrictions in place....

If they keep backups, then a check of nats/includes/config_override.php from around the same date will show -
if the array:
$config['ADMIN_IPS']

is not present in this file, then they didn't have IP restrictions in place.

so what's this about?

not attacking anyone, just making an observation:
Every time I join a program, I use a new, unique email address. In the past I've posted several times already that I received spam mails addressed to some of these unique addresses. In most cases I contacted the program owners/reps and always got the same response "don't know what happened, will look into it". In most cases I just stopped sending them traffic cuz I figured they were either sending the spam themselves or they had some kind of security breach/leak. Interesting fact: almost all of the programs were/are using NATS and spam addressed to those unique addresses has been hitting my filters for a lot longer than 2, 3 or 5 months.

Like I said, not attacking anyone.

I don't understand any of this but, its good reading...
I'm still looking for good traffic trades.. :thumbsup

Thats good, John. But you should have shut up along time ago. You've already taken care of this matter completely. Now hurry up and have your "counsel" call me. I can't wait for this lawsuit to get started.

Some of us haven't been following this at all and are not aware of what went on. I wish the posts on this board were simple and clear as day so we could know what the hell happened.

All I've received is letters from a couple programs assuring me everything is ok on their end. But definitely no simple and clear explanation of what happened.

I first noticed them when damcash was being joe-jobbed a year and a half ago with fake cp/lolita emails.
Every one I received was addressed to one of my unique NATS addresses, and I know several other people who noticed the same thing.

Drinking and posting is a big no-no.

This came up in OCTOBER 2006: https://gfy.com/fucking-around-and-business-discussion/671565-running-nats-block-ip-active-hacker.html (not the email issue, the NATS hacking issue)

Notice the I.P. of the attacker at the time: 65.110.62.120

It's on the Tampa Bay Sagonet system, the same I.P. ranges as some in the "new" attacks ( i.e. 65.110.53.100 )

Nice.

I wonder then: if there were no admin restrictions put in place and the GET request pasted by ServerGenius adds a user to the system -- wouldn't that mean that anyone could add admin users to the system by crafting up similar GET requests?

If that is true then this is not an isolated incident involving some backdoor user into the system, or some disgruntled ex-employee, but an actual vulnerability in the software itself. Unsanitized variables.:warning

But I am just guessing that was the case. For all I know you DO need to be an authenticated admin to add new users to the system using that php script/GET request ServerGenius pasted. And if thats the case; it then validates what TMM has been stating all along - that someone had access to their shit. Now then I wonder; WHO had access and HOW did they get it. and WHY did it take so long for TMM to discover this issue. or better yet, why didn't they handle such privy information with much more care.

In the security industry you have to follow standards; if we were to look at this situation from the point of view of a security expert (or database engine. e.g., OSVDB . ORG) this incident (backdoors/unauthorized user/ex-employee and/or vulnerability) would still violate two of the three concepts from the C.I.A. Triad of Information Security(http://en.wikipedia.org/wiki/Information_security):

Availability - http://en.wikipedia.org/wiki/Informa...onfidentiality
and
Integrity - http://en.wikipedia.org/wiki/Informa...rity#Integrity

Just my :2 cents: though. I am bored.

you can say that again!

damm tht is lots to read

True, but why would you care, you wont read it anyway and just posted to place your sig dumbfuck.

Funniest. Post. Ever. :1orglaugh:1orglaugh:1orglaugh