hacking: security in practice
How hard for non-hacker is to change device id?

I got 3 tries of login to my instagram. One is from LG K330 - Ho Chi Min city, Vietnam, other from Huawei GRA - L09 Delhi, India, and third is from Huawei GRA L09 Atsugi, Kanagawa, Japan. (Im from Europe).

I know that everyone can turn on vpn and change his location, but how hard is it for non hackers to change device? I m not sure if someone local trying to guess my password, or I am under real attack of someone more professional. I did not click any link, or something like that. I use IG mostly for scrolling pics.

P.S. if this is not good subreddit to post this, can you tell me which one is?

submitted by /u/Raskoljnikovic
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

hacking: security in practice
Homomorphic encryption is a cryptographic method that returns an encrypted result to the data owner. Essentially, this enables third parties to process encrypted data while having no knowledge about the data or the results.

https://external-preview.redd.it/YaDCHjNheEPPzX95kWwwiL3A-ES9IGxtXvnNlJk_Qgc.jpg?width=320&crop=smart&auto=webp&s=22941164f23069ae205af5c222e93c5091486d9a submitted by /u/diegolujan1
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

hacking: security in practice
Physical access is the best access

https://external-preview.redd.it/sIRxTL9Do-MalbiCNDYthXQCovTY909UNMsNpoCb2hM.jpg?width=320&crop=smart&auto=webp&s=a67f1fd6cf81d547b357dbb07a9877379df7d148 submitted by /u/Background_Gene_3657
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

Log4J-Detector - Detects Log4J versions on your file-system within any application that are vulnerable to CVE-2021-44228 and CVE-2021-45046
http://www.kitploit.com/2021/12/log4j-detector-detects-log4j-versions.html

___________________________
@hacking_Attack
@Hacking_Video

Detects Log4J versions on your file-system within any application that are vulnerable (https://www.kitploit.com/search/label/Vulnerable) to CVE-2021-44228 (https://mergebase.com/vulnerability/CVE-2021-44228/) and CVE-2021-45046 (https://mergebase.com/vulnerability/CVE-2021-45046/). It is able to even find instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too! Currently reports log4j-core versions 2.12.2 and 2.17.0 as _SAFE_, 2.15.0 and 2.16.0 as _OKAY_ and all other versions as _VULNERABLE_ (although it does report pre-2.0-beta9 as "_POTENTIALLY_SAFE_"). Can correctly detect log4j inside executable spring-boot jars/wars, dependencies blended into uber jars (https://mergebase.com/blog/software-composition-analysis-sca-vs-java-uber-jars/), shaded jars, and even exploded jar files just sitting uncompressed on the file-system (aka *.class). We currently maintain a collection of log4j-samples (https://github.com/mergebase/log4j-samples) we use for testing.
Example Usage: java -jar log4j-detector-2021.12.17.jar [path-to-scan] > hits.txt

___________________________
@hacking_Attack
@Hacking_Video

More Example Usage: = 2.10.0 _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/infinispan-embedded-query-8.2.12.Final.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-1.1.3.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-| /opt/mergebase/log4j-detector/samples/log4j-1.2.13.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-| /opt/mergebase/log4j-detector/samples/log4j-1.2.17.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-| /opt/mergebase/log4j-detector/samples/log4j-core-2.0-beta2.jar contains Log4J-2.x <= 2.0-beta8 _POTENTIALLY_SAFE_ :-| (or did you already remove JndiLookup.class?) /opt/mergebase/log4j-detector/samples/log4j-core-2.0-beta9.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-core-2.0.2.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-core-2.0.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-core-2.10.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-core-2.12.2.jar contains Log4J-2.x >= 2.12.2 _SAFE_ :-) /opt/mergebase/log4j-detector/samples/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-core-2.15.0.jar contains Log4J-2.x >= 2.15.0 _OKAY_ :-| /opt/mergebase/log4j-detector/samples/log4j-core-2.16.0.jar contains Log4J-2.x >= 2.16.0 _OKAY_ :-) /opt/mergebase/log4j-detector/samples/log4j-core-2.17.0.jar contains Log4J-2.x >= 2.16.0 _SAFE_ :-) /opt/mergebase/log4j-detector/samples/log4j-core-2.4.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-( /opt/mergebase/log4j-detector/samples/log4j-core-2.9.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(">java -jar log4j-detector-2021.12.17.jar ./samples

-- github.com/mergebase/log4j-detector v2021.12.17 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
/opt/mergebase/log4j-detector/samples/clt-1.0-SNAPSHOT.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/infinispan-embedded-query-8.2.12.Final.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-1.1.3.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-|
/opt/mergebase/log4j-detector/samples/log4j-1.2.13.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-|
/opt/mergebase/log4j-detector/samples/log4j-1.2.17.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-|
/opt/mergebase/log4j-de tector/samples/log4j-core-2.0-beta2.jar contains Log4J-2.x <= 2.0-beta8 _POTENTIALLY_SAFE_ :-| (or did you already remove JndiLookup.class?)
/opt/mergebase/log4j-detector/samples/log4j-core-2.0-beta9.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.0.2.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.0.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.10.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.12.2.jar contains Log4J-2.x >= 2.12.2 _SAFE_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.15.0.jar contains Log4J-2.x >= 2.15.0 _OKAY_ :-|
/op t/mergebase/log4j-detector/samples/log4j-core-2.16.0.jar contains Log4J-2.x >= 2.16.0 _OKAY_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.17.0.jar contains Log4J-2.x >= 2.16.0 _SAFE_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.4.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(

___________________________
@hacking_Attack
@Hacking_Video

/opt/mergebase/log4j-detector/samples/log4j-core-2.9.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
Understanding The Results _VULNERABLE_ -> You need to upgrade or remove this file. _OKAY_ -> We only report this for Log4J versions 2.15.0 and 2.16.0. We recommend upgrading to 2.17.0. _SAFE_ -> We currently only report this for Log4J versions 2.17.0 and 2.12.2. _OLD_ -> You are safe from CVE-2021-44228, but should plan to upgrade because Log4J 1.2.x has been EOL for 7 years and has several known-vulnerabilities. _POTENTIALLY_SAFE_ -> The "JndiLookup.class" file is not present, either because your version of Log4J is very old (pre 2.0-beta9), or because someone already removed this file. Make sure it was someone in your team or company that removed "JndiLookup.class" if that's the case, because attackers have been known to remove this file themselves to prevent additional competing attackers from gaining access to compromised systems. This Scanner Only Reports Hits Against The log4j-core Library. What About log4j-api? Many scanners (including GitHub's own Dependabot (https://github.com/dependabot)) currently report both "log4j-core" and "log4j-api" libraries as vulnerable. These scanners are incorrect. There is currently no existing version of the "log4j-api" library that can be exploited by any of these vulnerabilities. Why Report About 2.10.0, 2.15.0, 2.16.0, and 2.17.0 ? We consider version 2.10.0 important because that's the first version where Log4J's vulnerable "message lookup feature" can be disabled via Log4J configuration. We consider versions 2.15.0 and 2.16.0 important because these are the first versions where Log4J's default out-of-the-box configuration is not vulnerable to CVE-2021-44228. And version 2.17.0 is important because it's not vulnerable to CVE-2021-45046. Despite CVE-2021-45046 being much less serious, we anticipate everyone will want to patch to 2.17.0. What are those "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar" results about? The "!" means the log4j-detector entered a zip archive (e.g., *.zip, *.ear, *.war, *.aar, *.jar). Since zip files can contain zip files, a single result might contain more than one "!" indicator in its result. Note: the log4j-detector only recursively enters zip archives. It does not enter tar or gz or bz2, etc. The main reason being that Java systems are often configured to execute jars inside jars, but they are never configured to execute other file formats (that I know of!). And so a log4j copy inside a *.tar.gz is probably not reachable for a running Java system, and hence, not a vulnerability (https://www.kitploit.com/search/label/Vulnerability) worth reporting. 2nd note: for zips-inside-zips our scanner does load the inner-zip completely into memory (using ByteArrayInputStream) before attempting to scan it. You might need to give Java some extra memory if you have extremely large inner-zips on your system (e.g., 1 GB or larger). Usage detector (version 2021.12.17) Docs - https://github.com/mergebase/log4j-detector (C) Copyright 2021 Mergebase Software Inc. Licensed to you via GPLv3.">java -jar log4j-detector-2021.12.17.jar

Usage: java -jar log4j-detector-2021.12.17.jar [--verbose] [paths to scan...]

Exit codes: 0 = No vulnerable Log4J versions found.
1 = At least one legacy Log4J 1.x version found.
2 = At least one vulnerable Log4J version found.

About - MergeBase log4j detector (version 2021.12.17)
Docs - https://github.com/mergebase/log4j-detector
(C) Copyright 2021 Mergebase Software Inc. Licensed to you via GPLv3.
Build From Source: git clone https://github.com/mergebase/log4j-detector.git
cd log4j-detector/
mvn install
java -jar target/log4j-detector-2021.12.17.jar

___________________________
@hacking_Attack
@Hacking_Video

hacking: security in practice
Is it possible to get phone number from Google meet ?

So, there is this one spammer in our Google meet classrooms. He comes every now and then in the class. And today he texted me to my WhatsApp number. I asked him how he got my number and he replied with "I got it using an google meet trick". Is it really possible?

submitted by /u/helloworldw2
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

hacking: security in practice
Trying to figure out how mouseover event displays email address in O365

O365 reading pane setting is hidden

Observed behavior:

In the inbox, if you mouseover a sender in the "From" column a hover card is displayed with the sender's email (e.g. foo@bar[.]com)

What I'm looking to figure out:

I believe the email is displayed in the mouseover event by pulling the address from the email header. Specifically, I believe it's coming from "Return-Path:"

I'm attempting to see if it's possible using dev tools to find this. I can find the area I'm supposed to be looking at in dev tools, I just don't know where to go from there. It was suggested to me to set a breakpoint, but what am I looking for was I step through to see where the hover card comes from?

Any ideas?

submitted by /u/inf0s33k3r
[link] [comments]

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest Tools!
Log4J-Detector - Detects Log4J versions on your file-system within any application that are vulnerable to CVE-2021-44228 and CVE-2021-45046

http://1.bp.blogspot.com/-l4ckIu8tvZw/YcAH6RuFLZI/AAAAAAAA5s8/-Q23DmKD8RoDI7CKAFMU9O2VVL1j5-ncgCK4BGAYYCw/w640-h150/log4j-detector_1_log4j-detector-778008.png Detects Log4J versions on your file-system within any application that are vulnerable to CVE-2021-44228 and CVE-2021-45046. It is able to even find instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too!

Currently reports log4j-coreversions 2.12.2 and 2.17.0 as _SAFE_, 2.15.0 and 2.16.0 as _OKAY_ and all other versions as _VULNERABLE_ (although it does report pre-2.0-beta9 as "_POTENTIALLY_SAFE_").

Can correctly detect log4j inside executable spring-boot jars/wars, dependencies blended into uber jars, shaded jars, and even exploded jar files just sitting uncompressed on the file-system (aka *.class).

We currently maintain a collection of log4j-samples we use for testing. Example Usage:java -jar log4j-detector-2021.12.17.jar [path-to-scan] > hits.txt http://1.bp.blogspot.com/-l4ckIu8tvZw/YcAH6RuFLZI/AAAAAAAA5s8/-Q23DmKD8RoDI7CKAFMU9O2VVL1j5-ncgCK4BGAYYCw/w640-h150/log4j-detector_1_log4j-detector-778008.png More Example Usage:java -jar log4j-detector-2021.12.17.jar ./samples

-- github.com/mergebase/log4j-detector v2021.12.17 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
/opt/mergebase/log4j-detector/samples/clt-1.0-SNAPSHOT.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/infinispan-embedded-query-8.2.12.Final.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-1.1.3.jar contains Log4J-1.x <=
/opt/mergebase/log4j-detector/samples/log4j-1.2.13.jar contains Log4J-1.x <=
/opt/mergebase/log4j-detector/samples/log4j-1.2.17.jar contains Log4J-1.x <=
/opt/mergebase/log4j-de tector/samples/log4j-core-2.0-beta2.jar contains Log4J-2.x <=
/opt/mergebase/log4j-detector/samples/log4j-core-2.0-beta9.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.0.2.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.0.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.10.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.12.2.jar contains Log4J-2.x >= 2.12.2 _SAFE_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.15.0.jar contains Log4J-2.x >= 2.15.0 _OKAY_ :-|
/op t/mergebase/log4j-detector/samples/log4j-core-2.16.0.jar contains Log4J-2.x >= 2.16.0 _OKAY_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.17.0.jar contains Log4J-2.x >= 2.16.0 _SAFE_ :-)
/opt/mergebase/log4j-detector/samples/log4j-core-2.4.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
/opt/mergebase/log4j-detector/samples/log4j-core-2.9.1.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-( Understanding The Results_VULNERABLE_ -> You need to upgrade or remove this file.

_OKAY_ -> We only report this for Log4J versions 2.15.0 and 2.16.0. We recommend upgrading to 2.17.0.

_SAFE_ -> We currently only report this for Log4J versions 2.17.0 and 2.12.2.

_OLD_ -> You are safe from CVE-2021-44228, but should plan to upgrade because Log4J 1.2.x has been EOL for 7 years and has several known-v[...]

___________________________
@hacking_Attack
@Hacking_Video

KitPloit - PenTest Tools!
Log4J-Detector - Detects Log4J versions on your file-system within any application that are vulnerable to CVE-2021-44228 and CVE-2021-45046

___________________________
@hacking_Attack
@Hacking_Video

Kali Linux Tutorials
Private Set Membership (PSM) : Cryptographic Protocol That Allows Clients To Privately Query

Private Set Membership (PSM) is a cryptographic protocol that allows clients to privately query whether the client’s identifier is a member of a set of identifiers held by a server in a privacy-preserving manner.

At a high level, PSM provides the following privacy guarantees:

* The server does not learn the client’s queried identifier in the plaintext.
* The server does not learn whether the client’s query results in a membership or non-membership determination.
* The querying client does not learn any information about the set of identifiers that are stored by the server beyond whether the querying client’s identifier is a member or not of the server-held set of identifiers. In other words, the querying client learns the bare minimum amount of information which is only the answer of the membership query.

Dependencies

The Private Set Membership library requires the following dependencies:

* Abseil for C++ common libraries.
* Bazel for building the library.
* BoringSSL for underlying cryptographic operations.
* GFlag for flags. Needed to use glog.
* GLog for logging.
* Google Test for unit testing the library.
* Protocol Buffers for data serialization.
* Shell for fully homomorphic encryption.
* Tink for cryptographic PRNGs.

How to build

In order to run this library, you need to install Bazel, if you don’t have it already. [Follow the instructions for your platform on the Bazel website. Make sure you are installing version 4.2.1 or above.] (https://docs.bazel.build/versions/master/install.html)

You also need to install Git, if you don’t have it already. Follow the instructions for your platform on the Git website.

Once you’ve installed Bazel and Git, open a Terminal and clone the repository into a local folder.

Navigate into the private-membershipfolder you just created, and build the library and dependencies using Bazel. Note, the library must be built using C++17.

cd private-membership
bazel build … –cxxopt=’-std=c++17′

You may also run all tests (recursively) using the following command:

bazel test … –cxxopt=’-std=c++17′
Download

___________________________
@hacking_Attack
@Hacking_Video

Kali Linux Tutorials
RottenPotatoNG : A C++ DLL And Standalone C++ Binary – No Need For Meterpreter Or Other Tools

RottenPotatoNG generates a DLL and EXE file. The DLL contains all the code necessary to perform the RottenPotato attack and get a handle to a privileged token. The MSF RottenPotato Test Harness project simply shows example usage for the DLL. For more examples, see https://github.com/hatRiot/token-priv/tree/master/poptoke/poptoke, specifically the SeAssignPrimaryTokenPrivilege.cpp and SeImpersonatePrivilege.cpp files.

RottenPotato EXE

This project is identical to the above, except the code is all wrapped into a single project/binary. This may be more useful for some penetration testing scenarios.

Modify the “main” method in MSFRottenPotato.cpp to change what command will be run. By default it just runs cmd.exe to pop a command shell.
Download

___________________________
@hacking_Attack
@Hacking_Video