magic

[rimshott]

any rumors about magic getting busted

[Nostradamus]

hacked ..not busted

[crazy carl]

any rumors about magic getting busted

users are reporting that magic is back up and working

[Nostradamus]

so I heard, no accounting for stupidity. I imagine there is still a few out there waiting for Limesat Japan to spring back into action :)

[crazy carl]

so I heard, no accounting for stupidity. I imagine there is still a few out there waiting for Limesat Japan to spring back into action :)

Lol users regardless of safety will always use iks, there is a good probably that magic users are already to late.. There are logs and information that has leaked all over the Web

[tiggerooh]

Lol users regardless of safety will always use iks, there is a good probably that magic users are already to late.. There are logs and information that has leaked all over the Web

I agree with nostra ,it was hacked "ddos" and no its not up as of this post. As for safety, I concur very little security ,mostly from users not being descrete.

,

[nob0dy]

i " think " it was a inside job ..... JMOP ........ over $$$

& it wasn't ddosED ...... 503 error ~> r.h-t.co/4cc9f686-bdea-e311-93f7-00155d368c3c

i doubt they'll recover from this , everyone's personal info dumped 4 the world to see ...... not cool ....... very childish if u ask me .

[jvvh5897]

It is so easy to encrypt data, why would they not have scrambled personal info?

[1boxman]

It is so easy to encrypt data, why would they not have scrambled personal info?

True...but if its inside..screen shots..snippet tool etc won't stop it .

[jvvh5897]

True...but if its inside..screen shots..snippet tool etc won't stop it .

I'm hope that the above is a joke, because if it is not--you have a LOT of reading to do. Getting inside the amusement park does not mean that you get an all-day VIP pass. Layers of encryption on things meant to be private should be the norm.

[n3fta]

True...but if its inside..screen shots..snippet tool etc won't stop it .

What are you talking about?

[kutter]

What are you talking about?

lol ... doesn't take much thought to realize he's suggesting that it's harder to protect against an inside job :)

[Nostradamus]

I'm hope that the above is a joke, because if it is not--you have a LOT of reading to do. Getting inside the amusement park does not mean that you get an all-day VIP pass. Layers of encryption on things meant to be private should be the norm.
well obviously this wasn't the normal hack that had to break through layers of encryption either. The whole database was dumped so I guess it was not very well protected if at all and more than likely guy running the server was probably using default login as well

[jvvh5897]

Last I news was that the hackers had a billion "standard" passwords to try, so it might not have been default login, just one easily found.

If I were setting up a server, I would create an identifying number for each user and only have that number on the server in the clear--you might have the user IP addr but only as a checksum on the server. Any reconciliation between number and user info would be done on a PC not on line--say download a days traffic onto flash drive and bring it to the auditing PC and even then I would encrypt the data on that PC before storing.

[1boxman]

The problem is that most or some that have been compromised, where done from inside..meaning a reseller or others that had access to the panel(s) . Which are needed to be sence . So a disgruntled person maybe have at it . PLus who's to say they didn't give out there login .. Budmenot sure has a few :rolleyes:

But posting how to do... for a resellers panel on youtube . Well that should tell you everything right there.

Same as many sites have been destroyed .

[sodusme]

A lot of panels are not very secure from a standpoint that they allow passes like "123456" and so on. They also think a simple "captcha" (Completely Automated Public Turing test to tell Computers and Humans Apart) will protect them...it doesn't. They also in most cases allow proxies by the hundreds to be run on their login page.

I have been inside a couple panels using a publicly available cracking program that runs bots against the login page until it gets a login. Even the ones using emails are not secure since most folks use their username as an email. So once I got a user list from an FTA site all I need to do is combine @gmail.com or @yahoo.com or @hotmail.com to the users and voila' I'm almost always assured of getting a hit. Combine that with "123456" as a password and I'm in there like swimwear.

So as long as they are going to allow logins on a panel they are vulnerable. I'm not saying that is how these compromises have occurred but it definitely is how I have gained access to a couple of them. ;)

[jvvh5897]

Just as encryption is easy, making passwords that are not common is easy too. I don't mind folks using 123456 as a starting point for passwords, but a little letter scrambling, and padding, then maybe a run through blowfish and you have a decent pw. It takes very little coding to create a program to generate pws from common, easy to remember phrases and words that you can just paste into the pw line. After all, this is a site that should have folks familiar with RSA, SHA1, hash tables, byte flops, MAP calls, DES and 3DES and all the other tools of encryption, we should be able to use them creatively!

[Nostradamus]

you can post all kinds of information but unless you start the thread title with the word "FREE" 99% of the people won't read it :)

[jvvh5897]

FREE FREE FREE!!!

http://www.satfix.net/showthread.php?154868-Programming-c-code&p=1044879#post1044879

[sodusme]

Just as encryption is easy, making passwords that are not common is easy too. I don't mind folks using 123456 as a starting point for passwords, but a little letter scrambling, and padding, then maybe a run through blowfish and you have a decent pw. It takes very little coding to create a program to generate pws from common, easy to remember phrases and words that you can just paste into the pw line. After all, this is a site that should have folks familiar with RSA, SHA1, hash tables, byte flops, MAP calls, DES and 3DES and all the other tools of encryption, we should be able to use them creatively!

Unfortunately as far as I know none of the panels has any restrictions regarding password use. Hell none of these FTA boards that I know of even have any password restrictions in place. You can encrypt them all you want server side with RSA or Blowfish or DES or MD5 or any other encryption but when you are allowed to run bots on a login page it doesn't matter what they are encrypted with on the back side of the server. Now its a tedious way of doing it but it can be done. I have offered up some advice to one IKS panel operator and I'm not sure if they have yet to even heed my warnings. You can lead a horse to water but you can't make 'em drink.

In laymens terms I can run them in plain text from the front side of the site. ;)

[kutter]

Unfortunately as far as I know none of the panels has any restrictions regarding password use. Hell none of these FTA boards that I know of even have any password restrictions in place. You can encrypt them all you want server side with RSA or Blowfish or DES or MD5 or any other encryption but when you are allowed to run bots on a login page it doesn't matter what they are encrypted with on the back side of the server. Now its a tedious way of doing it but it can be done. I have offered up some advice to one IKS panel operator and I'm not sure if they have yet to even heed my warnings. You can lead a horse to water but you can't make 'em drink.

In laymens terms I can run them in plain text from the front side of the site. ;)

As you can see from the quote below, jvvh5897 is more concerned with securing the data that's on the server than he is with the login process ... it really makes sense if you think about it ... it still allows multiple users to login but minimizes the risk to the end user ... it goes without saying that the fewer users that have access to any sensitive data the less the opportunity of abuse ...


Last I news was that the hackers had a billion "standard" passwords to try, so it might not have been default login, just one easily found.
If I were setting up a server, I would create an identifying number for each user and only have that number on the server in the clear--you might have the user IP addr but only as a checksum on the server. Any reconciliation between number and user info would be done on a PC not on line--say download a days traffic onto flash drive and bring it to the auditing PC and even then I would encrypt the data on that PC before storing.

[1boxman]

As you can see from the quote below, jvvh5897 is more concerned with securing the data that's on the server than he is with the login process ... it really makes sense if you think about it ... it still allows multiple users to login but minimizes the risk to the end user ... it goes without saying that the fewer users that have access to any sensitive data the less the opportunity of abuse ...

Encryption..etc..all good.I do agree and can be some what easy to do ...but the fact stands..and why a lot of peeps have been warned about iks..will it ever happen and for it to happen,there would have to be less resellers..as have said before..and its not gloom and doom ..but they kill themselves .
So really its not in the cards :innocent:

[sodusme]

As you can see from the quote below, jvvh5897 is more concerned with securing the data that's on the server than he is with the login process ... it really makes sense if you think about it ... it still allows multiple users to login but minimizes the risk to the end user ... it goes without saying that the fewer users that have access to any sensitive data the less the opportunity of abuse ...

But what I'm saying is if I hit a reseller panel with the program I have access to and I get "lucky" in that I hit a resellers account that happens to be using 123456 as a password I now have access to that resellers clients information. In addition to having access to all the codes that reseller has in his possession.

I have done it in the past and brought it to the attention of one IKS panel operator like I said. So it really doesn't matter what kind of encryption you have server side if I'm allowed to run bots against the user login page I can get access to the same information that reseller has access to once his login is compromised.

Everyone is always concerned with the "data" on a server and that is all well and good but you have to consider the login page as well. Companies lose billions of dollars in content from stolen logins. I know this for a fact.

SQL protection is just one part of the equation you have to protect other facets of your website. ;)

[jvvh5897]

But if the server is set up so that any info you get does not lead to user data that has outside meaning, it does not matter if hack gets you in. Given the nature of servers, you have to plan for hackers to get in--that is one of the reasons that I have contempt for the ebay guys--they should have known better.

[sodusme]

But if the server is set up so that any info you get does not lead to user data that has outside meaning, it does not matter if hack gets you in. Given the nature of servers, you have to plan for hackers to get in--that is one of the reasons that I have contempt for the ebay guys--they should have known better.

So you are saying not have their usernames, or channels viewed, or length of channel viewing, or emails, or payment dates, or codes, or anything visible to the reseller? That is the only way you could prevent a cracking attempt on a login page is to not have any useful data to gain once inside. It would also prevent leaking of information in an SQL injection also.

Of course the reseller would see the same information in that he would have to some how cross reference what he is seeing with the "obfuscated" information stored on the site. So if "john123" was stored as "user 1" with i.p. "123.456.789.000" on the website then once the reseller logged in he would also only see "user 1" with the i.p. "123.456.789.000" so he would need some way of cross referencing that information.

I suppose it could be done but I have yet to see any site set up that way.

[kutter]

So you are saying not have their usernames, or channels viewed, or length of channel viewing, or emails, or payment dates, or codes, or anything visible to the reseller? That is the only way you could prevent a cracking attempt on a login page is to not have any useful data to gain once inside. It would also prevent leaking of information in an SQL injection also.

Of course the reseller would see the same information in that he would have to some how cross reference what he is seeing with the "obfuscated" information stored on the site. So if "john123" was stored as "user 1" with i.p. "123.456.789.000" on the website then once the reseller logged in he would also only see "user 1" with the i.p. "123.456.789.000" so he would need some way of cross referencing that information.

I suppose it could be done but I have yet to see any site set up that way.

that's because the software was intended to make the resellers life easier ... and little thought goes into protecting the customer's private info :)

[1boxman]

The resellers need the info . so it is a catch 22

[sodusme]

that's because the software was intended to make the resellers life easier ... and little thought goes into protecting the customer's private info :)

Yeah but that's on any site. I have yet to see a site set up where once inside there is no "useful" information. Especially if we're talking about a login and not a server side SQL injection attempt. At least with a database that can be encrypted to prevent an SQL injection of yielding any useful information but I'm not sure how this would be accomplished from a front side plain text information viewing from a login stand point? Unless like JVVH is eluding to you simply "hide" the information with alias's and numbers and pin's and so forth.

[kutter]

Yeah but that's on any site. I have yet to see a site set up where once inside there is no "useful" information. Especially if we're talking about a login and not a server side SQL injection attempt. At least with a database that can be encrypted to prevent an SQL injection of yielding any useful information but I'm not sure how this would be accomplished from a front side plain text information viewing from a login stand point? Unless like JVVH is eluding to you simply "hide" the information with alias's and numbers and pin's and so forth.

it really wouldn't be that difficult ... they are selling a code ... that code has a unique number ... no guess work or anything required other than that number :) there is no need to display or even input any info other than that number ...

[sodusme]

it really wouldn't be that difficult ... they are selling a code ... that code has a unique number ... no guess work or anything required other than that number :) there is no need to display or even input any info other than that number ...

Yeah I've always wondered why the need for all the other information? That struck me as odd from day one. I agree there is no need for it.

[kutter]

Yeah I've always wondered why the need for all the other information? That struck me as odd from day one. I agree there is no need for it.

they'll tell you it's so they can trouble shoot problems and monitor for account sharing and crap like that, but there are alternative ways to monitor or filter for things like that ...

[Recove52]

Hackers can get a list of users in /var/cpanel/users/ using
CAT command in a PHP script.

After they can change all pages INDEX of all sites using a simple
PERL script.

The other method used by hackers is running the FIND command to find all index pages in home partition.

To have better security, I would consider enabling SuPHP (and using this for the PHP handler instead of DSO). To make SuPHP available you would need to run EasyApache again and select SuPHP in the build options, then you could use WHM to switch from DSO to SuPHP.

Without SuPHP, PHP scripts that are exploited will run malicious scripts as the Apache user/group "nobody" and this includes the potential for Perl scripts to be executed.

With SuPHP, PHP scripts run as the user that owns the Virtual Host serving the request, so that if the user's PHP scripts are exploited and a malicious script attempts to run, it can only run as the regular user and not as the shared Apache user/group nobody, decreasing the potential for widespread damage.

[JCO]

Not hard to do . Only allow 8 charachter alphanumeric paswords where at least half the charachters are letters and secure DB access to a limited few. Corporate servers do it all the time.
But we have to be realistic a lot of these operators are amateurs when it comes to security
Where there is a will there is a way.

[Recove52]

Where there is a will there is a way. LMAO amen Bro