Please Scroll Down to See Forums Below
napsgear
genezapharmateuticals
domestic-supply
puritysourcelabs
UGL OZ
UGFREAK
napsgeargenezapharmateuticals domestic-supplypuritysourcelabsUGL OZUGFREAK

Can my IP addy be traced if I'm using cyber-rights.net?

Thank you.
PS: The packet sniffers we use at are office can pick out packets on a 160Gig
fiber path no problem. User names, passwords anything.
gjohnson5 said:
Several vulnerabilities just with hushmail
1. http://www.fribble.net/advisories/hushmail_14-06-04.txt
and http://www.fribble.net/advisories/hushmail_14-06-04.txt
Both attacks can be used to redirect users to an alternate website where the user puts in thier username and passphrase. At this point , there's no need for decryption since the attacker has thier passphrase.

2. Bugs in OpenPGP , which is the software HUSH uses. http://www.kb.cert.org/vuls/id/303094
They probably aren't all that vulnerable to this one unless someone is sniffing thier website for data. Which goes back to the tapping issues and packet sniffers such as tcpdump are widely used. There are holes in openpgp encryption technology that this attack attempts to take advantage of and will only be fixed to reimplementing openpgp. The rfc means requests for comments and generally this would go by and ietf draft which outlines exactly how the software should operate

So no BULLSHIT. You just need to stop typing what you think and listen to people that really know
 
gjohnson5 said:
Several vulnerabilities just with hushmail
1. http://www.fribble.net/advisories/hushmail_14-06-04.txt
and http://www.fribble.net/advisories/hushmail_14-06-04.txt
Both attacks can be used to redirect users to an alternate website where the user puts in thier username and passphrase. At this point , there's no need for decryption since the attacker has thier passphrase.

2. Bugs in OpenPGP , which is the software HUSH uses. http://www.kb.cert.org/vuls/id/303094
They probably aren't all that vulnerable to this one unless someone is sniffing thier website for data. Which goes back to the tapping issues and packet sniffers such as tcpdump are widely used. There are holes in openpgp encryption technology that this attack attempts to take advantage of and will only be fixed to reimplementing openpgp. The rfc means requests for comments and generally this would go by and ietf draft which outlines exactly how the software should operate

So no BULLSHIT. You just need to stop typing what you think and listen to people that really know


Hush does not use standard PGP....it is diferent. It is similar to PGP but not it. Packet sniffers..lmfao...packet sniffers....to snif encrypted data. You still miss the point. Site redirects..lmfao.....if you know what you are doing you know where you are connecting from. You have not proven a thing. Im still waiting for you to shwo me how someone is goign to crack my husmail account.
 
PolfaJelfa said:
Hush does not use standard PGP....it is diferent. It is similar to PGP but not it. Packet sniffers..lmfao...packet sniffers....to snif encrypted data. You still miss the point. Site redirects..lmfao.....if you know what you are doing you know where you are connecting from. You have not proven a thing. Im still waiting for you to shwo me how someone is goign to crack my husmail account.


I really don't wanna waste much more of my time iwht you but...
Hush's pgp engine is based ff openpgp and hence they are listed as vulnerable in the cert security alert.

Yes , sniff encrypted data. This is the point of the vulnerability. There are validity checks to see if the encryption is accurate or not and by gathering enugh data , an attacker (in the middle) is able to decrypt pieces of the transmission.

This is the part that yu don't get. Encrypted data is nt totally indecipherable if you understand the algrithm that created the encryption.
 
You are talking about people using the Cylindrical values ..used to verify the acuracy among other methods? You can not decrypt anything from that...tha tin itself is protected by diferent validations. Iven if you were to un-encrypt a section you still would not know jakc as the encryption is made in a way as all info is scrambled an d kept at diferent "sectors".

I know what i know bro, so do you. I see we will not be able to come to an agreement. :)
 
PolfaJelfa said:
You are talking about people using the Cylindrical values ..used to verify the acuracy among other methods? You can not decrypt anything from that...tha tin itself is protected by diferent validations. Iven if you were to un-encrypt a section you still would not know jakc as the encryption is made in a way as all info is scrambled an d kept at diferent "sectors".

I know what i know bro, so do you. I see we will not be able to come to an agreement. :)

We're not going to agree simply because you're wrong...

The cbc mode attacks are also problematic in ipsec technlogy as well. PGP isn't the nly thing effected. CBC mde encryption is just flawed. Which is exactly what Ive been trying to say all along. Encrypted data is NOT infallable.

here are the same trubles in IPSEC land
CVE number: CAN-2005-0039

IPsec consists of several separate protocols; these include:

* Authentication Header (AH): provides authenticity guarantees for packets, by attaching strong

cryptographic checksum to packets.

* Encapsulating Security Payload (ESP): provides confidentiality guarantees for packets, by
encrypting packets with encryption algorithms. ESP also provides optional authentication
services
for packets.

* Internet Key Exchange (IKE): provide ways to securely negotiate shared keys.

AH and ESP has two modes of use: transport mode and tunnel mode. With ESP in tunnel mode, an IP
packet (called the inner packet) is encrypted in its entirety and is used to form the payload of
a new packet (called the outer packet); ESP typically uses CBC-mode encryption to provide
confidentiality. However, without some form of integrity protection, CBC-mode encrypted
data is vulnerable to modification by an active attacker.

By making careful modifications to selected portions of the payload of the outer packet, an
attacker can effect controlled changes to the header of the inner (encrypted) packet. The modified
inner packet is subsequently processed by the IP software on the receiving security gateway or the
endpoint host; the inner packet, in cleartext form, may be redirected or certain error messages
may be produced and communicated by ICMP. Because of the design of ICMP, these messages directly
reveal cleartext segments of the header and payload of the inner packet. If these messages can be
intercepted by an attacker, then plaintext data is revealed.

Attacks exploiting these vulnerabilities rely on the following:

* Exploitation of the well-known bit flipping weakness of CBC mode encryption.

* Lack of integrity protection for inner packets.

* Interaction between IPsec processing and IP processing on security gateways and end hosts.


These attacks can be fully automated so as to recover the entire contents of multiple
IPsec-protected inner packets.

In more detail, the three identified attacks on ESP in tunnel mode when integrity protection is not

present work as follows:

1. Destination Address Rewriting

* An attacker modifies the destination IP address of the encrypted (inner) packet by bit-
flipping in the payload of the outer packet.
* The security gateway decrypts the outer payload to recover the (modified) inner packet.
* The gateway then routes the inner packet according to its (modified) destination IP address.
* If successful, the "plaintext" inner datagram arrives at a host of the attacker's choice.

2. IP Options

* An attacker modifies the header length of the encrypted (inner) packet by bit-flipping in the

payload of the outer packet.
* The security gateway decrypts the outer payload to recover the (modified) inner packet.
* The gateway then performs IP options processing on the inner packet because of the modified
header length, with the first part of the inner payload being interpreted as options bytes.
* With some probability, options processing will result in the generation of an ICMP "parameter

problem" message.
* The ICMP message is routed to the now modified source address of the inner packet.
* An attacker intercepts the ICMP message and retrieves the "plaintext" payload of the inner
packet.

3. Protocol Field

* An attacker modifies the protocol field and source address field of the encrypted (inner)
packet by bit-flipping in the payload of the outer packet.
* The security gateway decrypts the outer payload to recover the (modified) inner packet.
* The gateway forwards the inner packet to the intended recipient.
* The intended recipient inspects the protocol field of the inner packet and generates an ICMP
"protocol unreachable" message.
* The ICMP message is routed to the now modified source address of the inner packet.
* An attacker intercepts the ICMP message and retrieves the "plaintext" payload of the inner
packet.

The attacks are probabilistic in nature and may need to be iterated many times in a first phase in
order to be successful. Once this first phase is complete, the results can be reused to efficiently
recover the contents of further inner packets.

So basically read the exploits and the underlying data before making arguments...
 
This still doesent show anything......
Show me a case where someone was able to unencrypt...Hush?
I dont think youl be finding it anytime soon.
Posting a bunch of unrelated technical info does not prove a thing. It further reinforces my point that you are severly of topic and not looking at the facts!
There are checks and balances in place to prevent such actions as you have described, such as the Cylindrical value matching. We are not talking about a code....we are talking about a multiplier for diferent numbers.....now find that...sniffing, spoofing, packeting...you will not!

You can post all the data you want... there are contests underway each year for breaking alogarythms.....do people not like huge prizes?
 
PolfaJelfa said:
This still doesent show anything......
Show me a case where someone was able to unencrypt...Hush?
I dont think youl be finding it anytime soon.
Posting a bunch of unrelated technical info does not prove a thing. It further reinforces my point that you are severly of topic and not looking at the facts!
There are checks and balances in place to prevent such actions as you have described, such as the Cylindrical value matching. We are not talking about a code....we are talking about a multiplier for diferent numbers.....now find that...sniffing, spoofing, packeting...you will not!

You can post all the data you want... there are contests underway each year for breaking alogarythms.....do people not like huge prizes?


Ok , I will end this here as polka is not listening to a word i'm typing ,thus this is a waste of time

1. cylindrical value check has nthing to do with this. The flaws as specific t cypher block chaining. The flaws with this encryption mechanism I have already posted which went completely over your head. This is because you are simply talking about things you know nthing about.

2. The check and balances yu talk about is exactly what brken in cypher block chaining cde of pgp. This particular portion of the algorithm is what allows the attacker to actually decrypt portion of the code and not others. This was posted in the cert.org alert, which also went completely over your head.

3. Cert is a security auditing and announcement site all IT professionals use when they have security holes they need to patch. The makers of PGP have announed a technical flaw with PGP which husd is seen as vulnerable. Does it mean and attack based n this flaw is emminent. No and I never said anything t this point.

4. Hush did have users compromised when network solutions was hacked and users were redirected to attacker sites. It can take decades to brute force an encrypted string for decryption. This why methofs for quicker return are things hackers or script kiddies will try to do. This particular hle is mre targeted at automated systems , and not something like Hush.

I'm obviously talking over your head so this shuld end here
 
Buddy your talking over your own head.
Dont try to be such a smartass when in reality you know jack.
You are simply taking this out of your ass.
Now you are backtracking!

"Hush did have users compromised when network solutions was hacked and users were redirected to attacker sites"
Bulshit

It did not...all that happened was the homepage was redirected..
No information was compromised.....the actuall login page is SSL and tuneled, only thing that was changed is a redirect for the homepage. Since hush is safegaurded...the system automatically shut down the server...as the omepage domain was changed! What has been compromised regarding security?
You cant understand basic internet principles!
That is why I am ending the conversation with you!
You know it all.
So enjoy yourself!
 
kbrkbr said:
I just placed an order with a domestic source and when I pressed "send," cyber-rights came back with a message "Cannot find public keys for the following address."

This got me wondering whether the message I sent could be used to track my IP number back to my computer. My understanding is that if the message was sent encrypted, then the message couldn't be tracked back to me. But if cyber-rights DIDN'T encrypt it, then could I be exposed?

Yup, feeling a little paranoid this morning. :p

That does mean the order was not encrypted by the web site.
It went through without any hash or encryption... I wouldnt worry
too much about it most ISP's use a proxy server anyways for connections
although you may not realize this is true...
IP's are usually only traced when abuse by the same IP is always causing problems. Can you imagine how many IP's are probably stored in the log file from the site... Im sure it's hundreds... Nobody would waste thier time trying to track down a single IP. The site prolly purges it's log file like most to save space anyways... In other words, I wouldnt worry.
From my understanding thats my .02 but I am known to be wrong sometimes.
If I am and there is sombody that knows better than me, I apologize.
 
Last edited:
Sorry I was away for a few days....

Let's discuss these things as people and certain moderators REALLY need education on this

1. First off If a user input a username and a passphrase at an attacker's site, then information is compromised. Period.

Secondly there is no redirection in this instance. Forward DNS records are controlled by the domain name registrar. Network Solutions in this case. Forward DNS records start at the top which would be what's called a "root server" This root dns server tells clients where to look for forward DNS records about a domain name. They do alot more then that but let's keep it simple. Reverse DNS records are controlled by ARIN or local ip address in a particular country. Who owns what ip address is controlled by the creation of swips created at the ISP. ARIN assign IP address to ISP , ISP assign IP to the customer. IF the higher level is broken then the higher level is what needs to do the fixing. Hush shutting down has no relevance at all to that situation since users would be doing "nslookup www.hush.com" and getting the ip address of the attackers site. No redirection... Not sure where redirection came in but it has no place in this scenario... Anyway, The hush customer put in thier address and passphrase at the attackers site and BANG. The attacker has information that he shouldn't. There had to have been some passphrase changes needed at least to reverse that problem.


2. Does anyone here know what tunneling is and the specific protocls which make up this idea of "tunneling" I guarantee one moderator does not. PPTP was created by M$ and L2TP was created by Cisco. Both technologies are applied to a firewall or VPN server mainly in corporate intranets. Having this technology will allow for "secure" connection from clients away from the corporate firewall to the local intranet. Thus security (IPSEC for instance) is needed to that "tapping" is limited since data is travaling over an insecure intranet. There is, atleast from my knowledge, no application for this from a web site to allow IPSEC connection to all users on the internet. If anyone can think of such an implementation , I'd like to see it. This is what SSL is for. Completely different technology and purpose from tunneling.
 
Last edited:
Top Bottom