As is the case with most other high-speed buses, segments must be terminated at each end. For coaxial-cable-based Ethernet, each end of the cable has a 50 ohm resistor attached. Typically this resistor is built into a male N connector and attached to the end of the cable just past the last device. With termination missing, or if there is a break in the cable, the signal on the bus will be reflected, rather than dissipated when it reached the end. This reflected signal is indistinguishable from a collision, and prevents communication.
If I remember correctly, this is not going to work. It isn't like stealing an http session cookie. Again, if I remember correctly, you need to know the wifi password to send valid traffic and/or to negotiate a valid temporary key in order to send valid traffic.
Exactly, unless you have thousands of super computers at hand.
Some providers have fixed length passwords by default (8 hex digits, I have seen some with 10 hex digits). Some people use common dictionary words as passwords. Those are trivial to crack.
I have even seen providers using the first 8 hex digits of the mac address as wifi password.:)
Hey me too! A millennial technician came to my place when I was away to pick up a machine that was attached to the network. It was the machine at the end of the coax. He didn't put the end plug back at the end of the cable thus taking the whole network down then, he left with his machine:)
So I expected LVFS to mean yet another some flavor of an LV file system. I guess what I find confusing is a four letter acronym ending with "FS" but then again, nobody should have exclusivity. I probably would have chosen another acronym although to make that "LVFS" name more specific and meaningful.
He streams it "live" when he gets home. More precisely, there is always a one day delay on his stream. He just queues videos and they go live in a way similar to how Slashdot articles do.
The attacker registers a domain (such as attacker.com) and delegates it to a DNS server under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.
The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
Nope, sorry this is not how it works.
1) You would simply make the device connect to your fake DNS server. 2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server. 3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"
This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.
Some user will just enter mybank.com to connect to their bank. Normally, the website will redirect them to https://www.mybank.com/ (TLS site). Your fake website won't and will allow connections with plain http. No certificate needed.
Remember that for such an attack to pay off, only 1% of users falling for it is a lot!
Obviously, this isn't limited to banking sites and HTTP connections.
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
Nope, sorry this is not how it works.
1) You would simply make the device connect to your fake DNS server. 2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server. 3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"
This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.
That is only a fraction of the attack vector they are mentioning. The rest of it will be making devices connect to valid public IP addresses.
Example, the user types www.mybank.com and he is directed to the fake hacker site that looks just like his bank site and the hacker steals your credentials when you enter them.
Sure I know this and I thought about this possibility. But having your VOIP 911 system DDoSable from public IP addresses seems weak. Just use a dedicated link unreachable from the Internet for your critical VOIP systems heck, for all your critical IP systems.
1) DDoS 911 2) Hit target 3) Profit!
That seems too simple for me! Especially since it looks like the guy isn't that smart!
Also, what is the robustness of their 911 service to be affected by a DDOS? I mean, I could understand the system experiencing problems if every citizen in the city called 911 at the same time but an Internet based attack without actually dialing 911?
It is easy to replicate git repositories. So easy it is a piece a cake compared to moving a cvs or another centrally managed repository. In git, every repository is equal whether it is local, on github, sourceforge etc.
Just replicate the repositories to your environment, then, just push it to a new remote. The new remote will have everything. I regularly do this to pull from our GitLab environment and push specific public changes to GitHub or other specific changes to companies git repositories. You can pretty much control whatever you wish to propagate.
The unusual part of this is that this one got published. Usually, nobody ever hears about such things although they happen more often that you might come to expect at first.
Slashdot Mirror
+1 insightful!
I have seen this happen with other bird deterring techniques.
This one seems immunized to this although but I have never seen it in use nor do I know if it is efficient:
https://www.birdbgone.com/prod...
Exactly! The GP mentioned 10,000 cores like it was a big deal so I assumed that he meant CPU cores.
The smallest Amazon P2 instance has 2500 GPU cores, the biggest has 40,000 GPU cores.
Re-read the GP post and try to fit the price he mentioned with GPU cores offered by Amazon.
https://aws.amazon.com/ec2/ins... .9$/2500*24*365 = 3.15360
3.15$ by GPU core a year, not 80$ per core a year! So IMHO he meant CPU cores.
Feel free to review my numbers, I did this quickly.
Cheers,
So, what is your point with regards to what I wrote? 10000 cores might or might not qualify as 1 super-computer but this seems irrelevant.
By the way, cores suck at cracking WPA/WPA2 passwords. Hashcat uses GPUs for maximum efficiency.
Hand in you geek badge yourself buddy!
What makes you think I confused anything???
hint: vampire tap are optional
https://en.wikipedia.org/wiki/...:
As is the case with most other high-speed buses, segments must be terminated at each end. For coaxial-cable-based Ethernet, each end of the cable has a 50 ohm resistor attached. Typically this resistor is built into a male N connector and attached to the end of the cable just past the last device. With termination missing, or if there is a break in the cable, the signal on the bus will be reflected, rather than dissipated when it reached the end. This reflected signal is indistinguishable from a collision, and prevents communication.
If I remember correctly, this is not going to work. It isn't like stealing an http session cookie. Again, if I remember correctly, you need to know the wifi password to send valid traffic and/or to negotiate a valid temporary key in order to send valid traffic.
Anybody feels like confirming this?
Exactly, unless you have thousands of super computers at hand.
Some providers have fixed length passwords by default (8 hex digits, I have seen some with 10 hex digits). Some people use common dictionary words as passwords. Those are trivial to crack.
I have even seen providers using the first 8 hex digits of the mac address as wifi password. :)
Apart from that, you are pretty much safe.
Hey me too! A millennial technician came to my place when I was away to pick up a machine that was attached to the network. It was the machine at the end of the coax. He didn't put the end plug back at the end of the cable thus taking the whole network down then, he left with his machine :)
Ok here are some links:
A Lightweight Video Storage File System for IP Camera-Based Surveillance Applications:
https://link.springer.com/chap...
Liquid Virtual File System:
https://github.com/LiquidFM/lv...
LVFS: A scalable big data scientific storage system:
https://ieeexplore.ieee.org/do...
etc. etc.
So I expected LVFS to mean yet another some flavor of an LV file system. I guess what I find confusing is a four letter acronym ending with "FS" but then again, nobody should have exclusivity. I probably would have chosen another acronym although to make that "LVFS" name more specific and meaningful.
I thought that it was a file system that your BIOS could mount ;-)
Read TFA! Of course the terraforming plan includes 2 giant electromagnets, one on each pole. Problem solved!
Well they seemed concerned about privacy then, including the privacy of Big Star Labs!
You almost got me there!
Of course, I now assume that you meant London, Ontario, Canada.
He streams it "live" when he gets home. More precisely, there is always a one day delay on his stream. He just queues videos and they go live in a way similar to how Slashdot articles do.
$ cat /etc/slackware-version
Slackware 14.2
$ bin/firefox/firefox --version
Mozilla Firefox 61.0.1
vlc, software voipphone, usb, windows guests under qemu etc. everything works fine thanks you.
I also use 4 displays (monitors or screens) what else would I need?: /etc/X11/xorg.conf
$ cat
Section "ServerLayout"
# Removed Option "Xinerama" "0"
Identifier "Layout0"
Screen 0 "Screen0" 0 26
Screen 1 "Screen1" 1280 13
Screen 2 "Screen2" 2960 0
Screen 3 "Screen3" 4640 13
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "1"
EndSection
Section "Files"
FontPath "/usr/lib64/X11/fonts/misc/:unscaled"
FontPath "/usr/lib64/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib64/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib64/X11/fonts/misc/"
FontPath "/usr/lib64/X11/fonts/Type1/"
FontPath "/usr/lib64/X11/fonts/Speedo/"
FontPath "/usr/lib64/X11/fonts/100dpi/"
FontPath "/usr/lib64/X11/fonts/75dpi/"
FontPath "/usr/lib64/X11/fonts/cyrillic/"
FontPath "/usr/lib64/X11/fonts/TTF/"
EndSection
Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Samsung"
HorizSync 30.0 - 70.0
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection
Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName "Acer V223W"
HorizSync 31.0 - 84.0
VertRefresh 56.0 - 77.0
EndSection
Section "Monitor"
Identifier "Monitor2"
VendorName "Unknown"
ModelName "LG Electronics L222W"
HorizSync 28.0 - 83.0
VertRefresh 56.0 - 75.0
EndSection
Section "Monitor"
Identifier "Monitor3"
VendorName "Unknown"
ModelName "HP 23xi"
HorizSync 24.0 - 94.0
VertRefresh 50.0 - 76.0
EndSection
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
Have you ever designed anything resembling uploads over HTTP?
I didn't think so....
In reality though, my PCs have never been compromised in 18 years running desktop Linux...
It is impossible to be 100% sure that you are not compromised. The best you can do is keeping your eyes open.
That is not a rebind attack.
You are correct. I didn't know the term and reading TFS and TFA didn't help me.
So, I googled for it and reading the Wikipedia page enabled me to understand in 2 paragraphs.
Thanks!
https://en.wikipedia.org/wiki/...
The attacker registers a domain (such as attacker.com) and delegates it to a DNS server under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.
The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.
See my other post just below.
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
Nope, sorry this is not how it works.
1) You would simply make the device connect to your fake DNS server.
2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server.
3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"
This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.
Some user will just enter mybank.com to connect to their bank. Normally, the website will redirect them to https://www.mybank.com/ (TLS site). Your fake website won't and will allow connections with plain http. No certificate needed.
Remember that for such an attack to pay off, only 1% of users falling for it is a lot!
Obviously, this isn't limited to banking sites and HTTP connections.
For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.
Nope, sorry this is not how it works.
1) You would simply make the device connect to your fake DNS server.
2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server.
3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"
This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.
That is only a fraction of the attack vector they are mentioning. The rest of it will be making devices connect to valid public IP addresses.
Example, the user types www.mybank.com and he is directed to the fake hacker site that looks just like his bank site and the hacker steals your credentials when you enter them.
Sure I know this and I thought about this possibility. But having your VOIP 911 system DDoSable from public IP addresses seems weak. Just use a dedicated link unreachable from the Internet for your critical VOIP systems heck, for all your critical IP systems.
1) DDoS 911
2) Hit target
3) Profit!
That seems too simple for me! Especially since it looks like the guy isn't that smart!
Also, what is the robustness of their 911 service to be affected by a DDOS? I mean, I could understand the system experiencing problems if every citizen in the city called 911 at the same time but an Internet based attack without actually dialing 911?
People with multiple names and nationalities, multiple passports including fake ones etc. Don't you ever watch TV? :)
It is easy to replicate git repositories. So easy it is a piece a cake compared to moving a cvs or another centrally managed repository. In git, every repository is equal whether it is local, on github, sourceforge etc.
Just replicate the repositories to your environment, then, just push it to a new remote. The new remote will have everything. I regularly do this to pull from our GitLab environment and push specific public changes to GitHub or other specific changes to companies git repositories. You can pretty much control whatever you wish to propagate.
The unusual part of this is that this one got published. Usually, nobody ever hears about such things although they happen more often that you might come to expect at first.