Remote Exploit Forums

Go Back   Remote Exploit Forums > General IT Discussion


General IT Discussion Non BT Related Topics

Reply
 
LinkBack Thread Tools Display Modes
  #11 (permalink)  
Old 04-17-2009, 08:17 PM
SuspectZero's Avatar
Senior Member
 
Join Date: Dec 2008
Posts: 269
Default

its an interesting idea, but what if the wpa password is not on the wordlist? would you provide a refund?
personally i think you should go with it, and if someone decides to use it for evil purposes, there is nothing wrong with what you are doing, as far as you know they are doing it for testing purposes on their account. but again, thats my opinion, im very business like so im always thinking about ways to get the money rather than follow the proper ethics. if you put you ethics aside, you can make a hell of alotta money with this idea.
__________________
Until they become conscious they will never rebel, and until after they have rebelled they cannot become conscious...

Last edited by SuspectZero; 04-17-2009 at 08:20 PM.
Reply With Quote
  #12 (permalink)  
Old 04-17-2009, 11:20 PM
archangel.amael's Avatar
Moderator
 
Join Date: Nov 2007
Location: behind the wire
Posts: 3,466
Default

I think that the idea itself pureh@te is good and your intentions with it are good as well. But I think that as cybrsnpr mentioned the Non-Disclosure Agreement may be a big hindrance of using this in an actual paid pentest.
The data would/could be considered proprietary. As such companies may not want their hashes being uploaded someplace outside of their control.
As an example I am not allowed to store anything "government" on my company laptop but I can access it all I need/want to. The servers that hold the data are controlled by a third party (CSC in this case). Now the only reason for this is due to non-disclosure agreements. If I lose the laptop for some reason I don't have a lot of secret whatever that can get me in trouble ( the laptop itself is a different story). This keeps the company and the Government "clean"

I am wondering how you could ensure that the data you have is not stored and can not be re-accessed.
__________________
The very existence of flame-throwers proves that some time, somewhere, someone said to themselves, You know, I want to set those people over there on fire, but I'm just not close enough to get the job done.
George Carlin
Reply With Quote
  #13 (permalink)  
Old 04-17-2009, 11:44 PM
pureh@te's Avatar
Jenkem Addict
 
Join Date: Mar 2007
Location: /dev/null
Posts: 5,401
Default

Quote:
Originally Posted by archangel.amael View Post
I think that the idea itself pureh@te is good and your intentions with it are good as well. But I think that as cybrsnpr mentioned the Non-Disclosure Agreement may be a big hindrance of using this in an actual paid pentest.
The data would/could be considered proprietary. As such companies may not want their hashes being uploaded someplace outside of their control.
As an example I am not allowed to store anything "government" on my company laptop but I can access it all I need/want to. The servers that hold the data are controlled by a third party (CSC in this case). Now the only reason for this is due to non-disclosure agreements. If I lose the laptop for some reason I don't have a lot of secret whatever that can get me in trouble ( the laptop itself is a different story). This keeps the company and the Government "clean"

I am wondering how you could ensure that the data you have is not stored and can not be re-accessed.
That is a excellent point and something I have not figured out yet. Idealy I would like all the info to be wiped of the server when the test/cycle is complete however as you have said there is no real way to prove this I dont think. That is my whole dilemma. I dont want to really make money i want to provide a legit service however as you and cybrsnpr have pointed out it may not work the way I want it to and then the only people using it would be kids trying to hack their neighbors. If you have any suggestions I'm all ears.
Reply With Quote
  #14 (permalink)  
Old 04-18-2009, 12:36 AM
cybrsnpr's Avatar
Senior Member
 
Join Date: Feb 2006
Location: Secret Undisclosed Tiki Bar
Posts: 594
Default

Quote:
If you have any suggestions I'm all ears
I've been trying to think of some way you can make this work since I felt bad about being the initial bearer of bad news to what is a good idea.

Speaking only from a "how would professional pentesters be able to use this" aspect:

The only way I think you could do this would be to incorporate, get bonded and insured and then enter into NDA's with each entity that wanted to use your services. Even then, I'm not sure that it would be enough in some cases (always dependent on how the client services contract is written). You would still need to take into account seperation of data, data at rest, security in transit and many more things.

For the scenario I gave in my first post to you in this thread, if all of the above was covered, then I as a business, could potentially use your services as you would be a "trusted partner". But I know of some organizations that for many reasons, could never use such an arrangement. I'm afraid you would be left with, as others have mentioned, skiddies trying to hack their neighbors wireless.
Reply With Quote
  #15 (permalink)  
Old 04-18-2009, 02:44 AM
pureh@te's Avatar
Jenkem Addict
 
Join Date: Mar 2007
Location: /dev/null
Posts: 5,401
Default

Dont feel bad You comment is the reason I started the thread because I didn't even think of that. Maybe I could make enough money off the skiddies in the first 6 months to get legitimately bonded and insured for sensitive data.
Reply With Quote
  #16 (permalink)  
Old 04-18-2009, 11:04 AM
archangel.amael's Avatar
Moderator
 
Join Date: Nov 2007
Location: behind the wire
Posts: 3,466
Default

While getting bonded and insured may be of help, here is another problem that I was looking at before. I wanted to do a little more research before posting. Basically I believe that you would be in violation of U.S. Federal law in that, a party can obtain a communication ( in this case the password hash) they can also know the start and endpoints for said communication but they are not allowed to know the data in the communication. So I can capture the hash but I am not allowed to decode it. Or even if it is plain text view it.
On the other hand the Computer Fraud and Abuse Act, 18 U.S.C.§ 1030 (the "CFAA") states that,
Quote:
The CFAA imposes liability on anyone who:
Knowingly traffics illegally in passwords or other access credentials that allow unauthorized access to a computer, if that traffic effects interstate or foreign commerce or the computer is used by or for the United States government [4];
The question here is what is "traffics illegally" because as such pen-testers may have a need to do such a thing ( capture password, decode it, and then use it to gain access to the target). However we know that in the US there are legal pen-test companies. So since they have a contract with Rules of Engagement, I would gather that as long as the rules state that such things are in agreement with the contract that it would be ok.
As such a service like yours would be ok to use. But this leads us to another problem, How can you verify that the submitted data is legal?
You would need a way to verify what you receive is legally obtained, otherwise you would be in violation of the law. So as long as a pen-tester is able to do such things it would only be a matter of writing into the contract that your service/s may be used in order to decode a password hash. If a company chooses to have a pen-tester audit it's passwords then it should be ok for them to use your service/s to do so. It would be the same case as using "hydra" or "Jtr". The company will in most cases automatically assume full ownership of the data in both the coded and decoded forms. So this means you would have to have a means of proving (if needed) that you store none of that data. But then you may run into another problem with passing email/s since each server in the chain could/would have a copy of it. This could be mitigated using gpg/md5 or whatever to ensure that if the data where not deleted from the servers along the chain that at least it could not be easily read. This would also assure all parties involved that the data if stored along the route is not really usable since it is the property of a company.


On another note as you well know once a password been decoded it really is no good anymore.
So this brings us to having rules in place to prevent simple dictionary based passwords. For instance we use RSA SecurID's however we have a need for them. As such my company probably does not worry too much about passwords themselves.

BTW a great read on the above law/s can be had here

I am sure that when Thorn comes back around he can/will provide some good info on the aspect of the law as well.
__________________
The very existence of flame-throwers proves that some time, somewhere, someone said to themselves, You know, I want to set those people over there on fire, but I'm just not close enough to get the job done.
George Carlin
Reply With Quote
  #17 (permalink)  
Old 04-20-2009, 06:25 PM
Thorn's Avatar
Senior Member
 
Join Date: Jul 2007
Location: The Village, of course
Posts: 1,269
Default

Probably the best way to get around questions of legal use, and who might be a legitimate user, would be to offer this as a subscription service. You could vet the subscribers before issuing user credentials. A big advantage to offering it as a subscription as oppose to a low-cost 'pay per incident' would be that you'll almost guarantee that you would not get script kiddies even considering using the service.
__________________
Thorn

“Never try to teach a pig to sing; it wastes your time and it annoys the pig.”
- Robert Heinlein
Reply With Quote
  #18 (permalink)  
Old 04-20-2009, 06:28 PM
streaker69's Avatar
Senior Member
 
Join Date: May 2007
Location: Virginville, BlueBall, Bird In Hand, Intercourse, Paradise, PA
Posts: 3,510
Default

Quote:
Originally Posted by Thorn View Post
Probably the best way to get around questions of legal use, and who might be a legitimate user, would be to offer this as a subscription service. You could vet the subscribers before issuing user credentials. A big advantage to offering it as a subscription as oppose to a low-cost 'pay per incident' would be that you'll almost guarantee that you would not get script kiddies even considering using the service.
Good idea, would probably be a good idea to have a very plain language privacy policy that is right on the main page to the site as well as a NDA between himself and the subscribers.
__________________
A 3rd Party Security Audit is the IT equivalent of a Colonoscopy, it's long, intrusive, and when it's done you'll have seen a lot of things you really didn't want to see, and you'd definitely remember that you had it done.

I baby harp seals.
Reply With Quote
  #19 (permalink)  
Old 04-20-2009, 06:41 PM
pureh@te's Avatar
Jenkem Addict
 
Join Date: Mar 2007
Location: /dev/null
Posts: 5,401
Default

Excellent idea. I wonder if I can code the web app so that the user also has the access to delete his or her own files after wards.
Reply With Quote
  #20 (permalink)  
Old 04-20-2009, 06:48 PM
streaker69's Avatar
Senior Member
 
Join Date: May 2007
Location: Virginville, BlueBall, Bird In Hand, Intercourse, Paradise, PA
Posts: 3,510
Default

Quote:
Originally Posted by pureh@te View Post
Excellent idea. I wonder if I can code the web app so that the user also has the access to delete his or her own files after wards.
It would probably be better if you could configure the webserver to actually upload the files to a RAM disk and not to the actual harddrive. That way, when the server is rebooted, there is no evidence whatsoever of the files existing.
__________________
A 3rd Party Security Audit is the IT equivalent of a Colonoscopy, it's long, intrusive, and when it's done you'll have seen a lot of things you really didn't want to see, and you'd definitely remember that you had it done.

I baby harp seals.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT. The time now is 06:11 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.3.2