Researchers Claim to Find New Solution to Spectre, Meltdown

[bit_user]

FYI - Mac addresses don't cross over different networks; specifically through NAT.

Not only is it not visible, but knowing it isn't even particularly useful for an attacker.

Just because someone knows the address of your computer (be it the MAC address, the IP, or some other identifier) doesn't mean it's vulnerable. There are firewalls, NAT routers, and features of the very networking protoctols you're using that are designed to protect you. Also, it's a good idea not to run services you don't need. Like don't run a web server program on a computer that's not intended to be serving web pages to anyone.

 

[audiospecaccts]

FYI - Mac addresses don't cross over different networks; specifically through NAT.

Not only is it not visible, but knowing it isn't even particularly useful for an attacker.

Just because someone knows the address of your computer (be it the MAC address, the IP, or some other identifier) doesn't mean it's vulnerable. There are firewalls, NAT routers, and features of the very networking protoctols you're using that are designed to protect you. Also, it's a good idea not to run services you don't need. Like don't run a web server program on a computer that's not intended to be serving web pages to anyone.

you think a firewall will protect you? guess again.

There are some powerful break in scripts out there, one of them can break through the industial firewall appliance box in a mater of minutes much less a cheap one you would buy at Wal-mart. The IP and Mac is the two "keys" to the computer. If both computers is on the same web site, one could edit the html page, write a html form in the inspector with the target of the other IP and the data would go to the other because the web server would mitigate the mac address. the info sent via html form would end up at the other computer. if the other computer had opened up the inspector, then added an xml recieving target container, like a canvas tag, they will get the data and it would be displayed in thier browser. This also would bypass a firewall because port 80 is open on both ends to the same url.


The IP is the "place" and the Mac is the "device" if the packet has both, then it will route to the machine because the routing logic dictated the computer requested it somehow. A firewall is nothing more than a program on a switch, and restricts outside traffic except packets that have a destination mac address on the other side of the firewall.


I guess a picture is better than a thousand words:

 

[stdragon]

you think a firewall will protect you? guess again.

There are some powerful break in scripts out there, one of them can break through the industial firewall appliance box in a mater of minutes much less a cheap one you would buy at Wal-mart. The IP and Mac is the two "keys" to the computer. If both computers is on the same web site, one could edit the html page, write a html form in the inspector with the target of the other IP and the data would go to the other because the web server would mitigate the mac address. the info sent via html form would end up at the other computer. if the other computer had opened up the inspector, then added an xml recieving target container, like a canvas tag, they will get the data and it would be displayed in thier browser. This also would bypass a firewall because port 80 is open on both ends to the same url.


The IP is the "place" and the Mac is the "device" if the packet has both, then it will route to the machine because the routing logic dictated the computer requested it somehow. A firewall is nothing more than a program on a switch, and restricts outside traffic except packets that have a destination mac address on the other side of the firewall.


I guess a picture is better than a thousand words:

It's called a MITM attack, and it's nothing new. It's why SSL is used. And no, you can't MITM SSL unless you have a trusted cert installed from the person or firewall vendor as it would be performing SSL packet inspection.

As for hacking firewalls, yeah, not really. Not from any reputable brand with firmware that's being maintained and a compentent admin that setup the firewall the first place. Zero-day hacks of a Next Generation (actual definition) firewall are uber rare, and often get stomped ASAP when they do occur.

BTW, the MAC address being recorded by the website, that's NOT the MAC address of the actual NIC of the PC performing the request. Yes, a MAC address is assigned to the IP, but it gets stripped off and replaced with each hop in the network.

EDIT: FYI MAC addresses are layer 2 of the OSI model whereas IP is layer 3. Layer 2 is non route-able; hence why the originating MAC address doesn't traverse across different networks. Ergo, stripped and replaced along the path.

 

[audiospecaccts]

It's called a MITM attack, and it's nothing new. It's why SSL is used. And no, you can't MITM SSL unless you have a trusted cert installed from the person or firewall vendor as it would be performing SSL packet inspection.

As for hacking firewalls, yeah, not really. Not from any reputable brand with firmware that's being maintained and a compentent admin that setup the firewall the first place. Zero-day hacks of a Next Generation (actual definition) firewall are uber rare, and often get stomped ASAP when they do occur.

BTW, the MAC address being recorded by the website, that's NOT the MAC address of the actual NIC of the PC performing the request. Yes, a MAC address is assigned to the IP, but it gets stripped off and replaced with each hop in the network.

EDIT: FYI MAC addresses are layer 2 of the OSI model whereas IP is layer 3. Layer 2 is non route-able; hence why the originating MAC address doesn't traverse across different networks. Ergo, stripped and replaced along the path.

Normally, but there is ways to do this.
And who said the attacker didn't break into web storage and copied and installed the SSL private key on their machine?


Speaking of SSL, I can't connect to this site in https, and I know there is nothing wrong with my browser.

 

[stdragon]

And who said the attacker didn't break into web storage and copied and installed the SSL private key on their machine?


Speaking of SSL, I can't connect to this site in https, and I know there is nothing wrong with my browser.

Once an SSL session has been established, you're not going to going to crack the bit-stream. That's not to say you couldn't decrypt the session data from the server if you had root access to the server and exploited meltdown or spectre in some crafty way. Though to date, I'm not aware of a scenario such as that being successfully pulled off. So, totally hypothetical.

Speaking of strong encryption, tomshardware.com has an A rating from SS Labs. Works for me with both Firefox and Brave.

Sometimes AV will perform a MITM (like Bitfender) to perform SSL inspection to defend against malware. That, or your time on the PC is off. If it deviates too much, that can break an SSL session from working.

 

[audiospecaccts]

no its quit real, and I don't think the sender has to have the ssl private key, just be authenticated by php to serialize through the DOM.

 

[bit_user]

you think a firewall will protect you? guess again.

No security device or feature is perfect, but there are levels of safety and the best approach to security is layered.

The IP and Mac is the two "keys" to the computer. If both computers is on the same web site, one could edit the html page, write a html form in the inspector with the target of the other IP and the data would go to the other because the web server would mitigate the mac address.

It's great that you're interested in computer security and networking, but there are several fundamental problems with your explanation.

I would strongly recommend getting a good book on computer networking (Tanenbaum used to be well regarded, BITD) and read that. Trying to piece together an understanding from snippets read here and there, on the internet, is probably not going to work terribly well.

 

[audiospecaccts]

you think a firewall will protect you? guess again.

No security device or feature is perfect, but there are levels of safety and the best approach to security is layered.

The IP and Mac is the two "keys" to the computer. If both computers is on the same web site, one could edit the html page, write a html form in the inspector with the target of the other IP and the data would go to the other because the web server would mitigate the mac address.

It's great that you're interested in computer security and networking, but there are several fundamental problems with your explanation.

I would strongly recommend getting a good book on computer networking (Tanenbaum used to be well regarded, BITD) and read that. Trying to piece together an understanding from snippets read here and there, on the internet, is probably not going to work terribly well.

actually I've been researching an actual incident. With packet logs independently logged from the web server. The web server itself was broken into and the logs deleted to cover tracks. That server btw, was only a html/xml website with an ssl installed (that they copied) There is some interesting xml statements executed before the request of " . " was logged. And trading base 64 object to another web user when there is no html form on the page!
So there is some sort of html/xml exploit and there is logs to go with this. I'm still trying to figure out the exactly in html the put on the recieving end, but in recreating what the sender did, that works, I even bounced a transmission off of regular site to a different IP and it goes to the destination computer. I'm still trying to figure out the second part of the reciever, because what was logged was a meta tag update with some base64 data.

 

[bit_user]

in recreating what the sender did, that works, I even bounced a transmission off of regular site to a different IP and it goes to the destination computer.

Return address spoofing probably works on your LAN, but it's something that nearly all firewalls and routers will filter out. Many years ago, I wrote firewall rules to reject it, but it's now something that's built-in by default.

I also don't see how rouge HTML would cause this, as no HTML should control what a browser sends at the IP or Ethernet level.

 

[stdragon]

actually I've been researching an actual incident. With packet logs independently logged from the web server. The web server itself was broken into and the logs deleted to cover tracks. That server btw, was only a html/xml website with an ssl installed (that they copied) There is some interesting xml statements executed before the request of " . " was logged. And trading base 64 object to another web user when there is no html form on the page!
So there is some sort of html/xml exploit and there is logs to go with this. I'm still trying to figure out the exactly in html the put on the recieving end, but in recreating what the sender did, that works, I even bounced a transmission off of regular site to a different IP and it goes to the destination computer. I'm still trying to figure out the second part of the reciever, because what was logged was a meta tag update with some base64 data.

Difficult to say without knowing the full details of the entire OS / Application stack. But in my experience, 99% of the hacks are caused by bots exploiting known vulnerabilities. I've seen SQL injection attacks, ASP hacks, and the most recent fun a Windows 2003 (yes, yes, I know, dev wouldn't listen to me) getting hacked via an exploit in WebDAV to highjack the server to mine Monero crypto currency.

My only advice are of the following...

1: Reduce the surface of attack via only have the apps loaded as needed, and ports forwarded appropriately; meaning don't do something silly such as stick the entire box behind the DMZ.

2. Keep you box patched and up to date as possible. If you must, get with software development on porting the application to a new stack that is and can be maintained as well.

 

[audiospecaccts]

in recreating what the sender did, that works, I even bounced a transmission off of regular site to a different IP and it goes to the destination computer.

Return address spoofing probably works on your LAN, but it's something that nearly all firewalls and routers will filter out. Many years ago, I wrote firewall rules to reject it, but it's now something that's built-in by default.

I also don't see how rouge HTML would cause this, as no HTML should control what a browser sends at the IP or Ethernet level.

I don't know but it was strange to inspect and find that at the server farm on the upper tier. I noticed if we set up a container without xml it doesn't work (an old bug that was never addressed?). We had four people going back and installing older versions of lamp and iis back to thier first web server offering. (both are effected) It looks like this bug has been there ever since it was created.
edit:
One of our engineers speculate its a software timing issue between php and xml and the combination of "short tags open=true" in php.ini