report-attacking-internal-network-en_0.pdf
880.3 KB
🇬🇧 Attacking the internal network from the public Internet using a browser as a proxy
JavaScript loaded from a malicious site can connect to services running on the user’s local computer (localhost) or on other internal hosts in many circumstances.
Malicious actors are aware of these attacks, but defenders need to be informed as well. In addition to describing the technical details of the attacks, we will discuss means of detecting and protecting against them.
🖨 https://www.forcepoint.com/sites/default/files/resources/files/report-attacking-internal-network-en_0.pdf
#pdf #report #attack #internal #network #browser #java #script
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@cRyPtHoN_INFOSEC_ES
JavaScript loaded from a malicious site can connect to services running on the user’s local computer (localhost) or on other internal hosts in many circumstances.
Malicious actors are aware of these attacks, but defenders need to be informed as well. In addition to describing the technical details of the attacks, we will discuss means of detecting and protecting against them.
🖨 https://www.forcepoint.com/sites/default/files/resources/files/report-attacking-internal-network-en_0.pdf
#pdf #report #attack #internal #network #browser #java #script
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@cRyPtHoN_INFOSEC_ES
How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team exercise, trying to break into App Engine. This is the story of how I found a vulnerability and developed an exploit to break out of the App Engine sandbox and get arbitrary code execution on a Google server.
Background
One of the reasons I was skeptical was Java’s poor security track record. Java is unusual among programming languages in attempting to do in-process sandboxing with its Applet model, where trusted and untrusted code run within the same language runtime.
Back in the dark ages before Javascript and Webassembly took over the world, website authors that wanted to include nontrivial interactivity had to rely on browser plugins. Sun’s entry into the fray was Java Applets, a system that allowed website authors to include precompiled Java classfiles on their site. When the user views the embedding page, the browser sends that code to the Java Virtual Machine (JVM) installed on the user’s computer for execution.
In order to keep things secure, Java used a permission system to control what running code could and couldn’t do. Desktop applications were executed with all permissions by default, while Java applets ran with a very restrictive policy that prevented stuff like accessing the user’s local files.
Unfortunately, applets were still plagued with security vulnerabilities. One issue is that most of the Java runtime library is itself implemented in Java. Trusted and untrusted code run side by side in the same VM, with the only thing separating them being the permission system and visibility modifiers (public, protected, private, etc.)
This means that a bug anywhere in the JVM or standard libraries is liable to become a security vulnerability. Additionally, the attack surface is huge. The Java 7 runtime included over 17,000 classes, a lot of places for bugs to creep in.
https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-app-engine-anatomy-of-a-java-bytecode-exploit.html
#google #app #engine #hacked #java #bytecode #exploit
📡 @nogoolag 📡 @blackbox_archiv
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team exercise, trying to break into App Engine. This is the story of how I found a vulnerability and developed an exploit to break out of the App Engine sandbox and get arbitrary code execution on a Google server.
Background
One of the reasons I was skeptical was Java’s poor security track record. Java is unusual among programming languages in attempting to do in-process sandboxing with its Applet model, where trusted and untrusted code run within the same language runtime.
Back in the dark ages before Javascript and Webassembly took over the world, website authors that wanted to include nontrivial interactivity had to rely on browser plugins. Sun’s entry into the fray was Java Applets, a system that allowed website authors to include precompiled Java classfiles on their site. When the user views the embedding page, the browser sends that code to the Java Virtual Machine (JVM) installed on the user’s computer for execution.
In order to keep things secure, Java used a permission system to control what running code could and couldn’t do. Desktop applications were executed with all permissions by default, while Java applets ran with a very restrictive policy that prevented stuff like accessing the user’s local files.
Unfortunately, applets were still plagued with security vulnerabilities. One issue is that most of the Java runtime library is itself implemented in Java. Trusted and untrusted code run side by side in the same VM, with the only thing separating them being the permission system and visibility modifiers (public, protected, private, etc.)
This means that a bug anywhere in the JVM or standard libraries is liable to become a security vulnerability. Additionally, the attack surface is huge. The Java 7 runtime included over 17,000 classes, a lot of places for bugs to creep in.
https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-app-engine-anatomy-of-a-java-bytecode-exploit.html
#google #app #engine #hacked #java #bytecode #exploit
📡 @nogoolag 📡 @blackbox_archiv
Considerations on Codecrafting
How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team…
Disabling JavaScript Won’t Save You from Fingerprinting
Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.
A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.
Check out the demo to see it in action:
Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.
A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.
Check out the demo to see it in action:
Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.
A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.
💡 Check out the demo to see it in action:
https://noscriptfingerprint.com/
The demo should show the same fingerprint, even if visitors attempt to conceal their identities using the following methods (among others):
— Requesting desktop mode in mobile browsers
— Spoofing the user agent
— Using incognito mode
— Changing the internet connection
https://fingerprintjs.com/blog/disabling-javascript-wont-stop-fingerprinting/
#browser #fingerprinting #js #java #JavaScript
📡@cRyPtHoN_INFOSEC_FR
📡@cRyPtHoN_INFOSEC_EN
📡@cRyPtHoN_INFOSEC_DE
📡@BlackBox_Archiv
Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.
A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.
Check out the demo to see it in action:
Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.
A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.
Check out the demo to see it in action:
Fingerprinting is a way to identify website users without using cookies or data storage. Instead, device properties like language and installed fonts are used to create highly accurate, unique identifiers that work even if the browser has incognito mode turned on.
A common misconception is that disabling JavaScript can prevent fingerprinting. Since advertisers and bad actors use it for ad targeting and tracking your online activity, it’s a natural (albeit incorrect) assumption that disabling JavaScript will protect you against fingerprinting. In this article, we will demonstrate that fingerprinting can occur even in the absence of JavaScript.
💡 Check out the demo to see it in action:
https://noscriptfingerprint.com/
The demo should show the same fingerprint, even if visitors attempt to conceal their identities using the following methods (among others):
— Requesting desktop mode in mobile browsers
— Spoofing the user agent
— Using incognito mode
— Changing the internet connection
https://fingerprintjs.com/blog/disabling-javascript-wont-stop-fingerprinting/
#browser #fingerprinting #js #java #JavaScript
📡@cRyPtHoN_INFOSEC_FR
📡@cRyPtHoN_INFOSEC_EN
📡@cRyPtHoN_INFOSEC_DE
📡@BlackBox_Archiv