Can ModSecurity defend from Brute Force Attacks on PHPmyadmin and WordPress as well?

mod_security sits in the Apache webserver to offer some level of security for applications hosted on that webserver.  Assuming you're talking about shared hosting (as opposed to dedicated or VPS providers), there's no reason their mod_security installation wouldn't be able to protect against attacks against any application installed on their webserver.

That being said, mod_security is highly configurable, so you'd need to check that there's brute force protection for the login pages you care about, and you'll also want to check if mod_security is even enabled for those paths.

Also note that some mod_security rulesets (those looking for SQL injection) are likely to have a very high false positive rate on PHPmyadmin, as they'll look for strings similar to the SQL queries legitimate users might enter into PHPmyadmin.


In your case, /proc/net/ipt_recent/PINGBACK (or /proc/net/xt_recent/PINGBACK in some installations) contains the list of all IP addresses seen as WordPress bots during last 600 seconds. This is a text file which is updated automatically in real time by the system.

You can either collect data from this file over some period of time or set an interval bigger than 600 seconds in your iptables rule.


Fully-secured screen lock in Ubuntu with encryption

Based on my understanding what you're looking for is a combination of a few different things that are likely too broad for a single question.

This should give you an idea of how to encrypt on suspend in Linux.

  Is there any secure screen lock (no bug, no vulnerability against X11 crashes, etc)?

Nothing is totally secure and immune from bugs or vulnerabilities. I would shop around and weigh different options. One thing to keep in mind is that you may face incompatibility issues between a custom lock screen application and your desktop environment (if applicable).

  Can I have a home encryption on top of full disk encryption, and set the screen lock such that the same password will unlock and decrypt the home drive (I don't want to enter two passwords)?

This will depend on the implementation of your particular lock screen and encryption setup.

Protecting against cold boot attacks and physical port access or tampering are whole other issues with plenty of material written on them at your fingertips. You'll gain more traction by doing some research on each, picking out specific areas you want clarification on and asking them as separate questions.


What is the best way of finding subdomains of a domain?

The tool you linked explained their techniques:

 DNS zone transfer
 DNS enumeration based on a specially chosen wordlist
 Public search engine queries
 Word mutation techniques

The Kali tools you mentioned can do some of those things, but perhaps not all. You might need to combine them or configure them differently.

Without knowing the specifics of what one tool found that another did not, it will be difficult to devise a more technical answer.


If you set up a system to block you, you would ultimately also be able to bypass it.
The best way would be for you to place it outside of your reach. An option would be to burn a CD/DVD-R, so that you cannot physically change it. I don't know if whatever will make you want to change it could also make you want to destroy it. You could provide the disk with the never-to-be-changed file to a third party, such as a lawyer. You could also publish the file on the internet, in such a way that it would be very hard for it to disappear. You could share it on keybase, IPFS, a Dropbox account you purposefully lose the password to, get it uploaded to archive.org...
You can also use a similar approach to restrict you from modifying it, such as tweeting today the full hash of the file, so you couldn't change it into the future without revealing that it is not the original file.
Note that you could publish an encrypted version encrypted, so it doesn't show its contents to the world.
Finally, if you really know so well that in the future you will want to change it, I wonder if it's really a good idea that you make your future self unable to do that.


is there evidence that security vulnerability "severity formulas" are more useful than just eyeballing it?

CVSS scores are meant as a guideline not as the gospel.

Proper risk assessment for your environment should always be determined by a review of what is considered critical infrastructure, what is more AT RISK of being exploited, etc.

If i have a device that cannot be updated due to required vendor software for business functionality, it has 10 critical vulnerabilities with a rating of 10 each.

But that device is only plugged in once a month for 30 minutes at non-regular intervals. I would say that device is a low to medium risk for my network.

Now if I have a device that is in the DMZ and has multiple vulnerabilities that are easily exploitable but aren't considered a "Critical" threat rating. I would evaluate that as being higher risk because it is exposed to the public

Edit:

Good additional resources to check out from Rapid7 (creators of metasploit):
changing criticality of an asset,
Adjusting risk with criticality,
Risk scoring FAQ


How is bcrypt able to generate secure random hashes? If someone nabs the hash from my db wouldn't they just be able to run it through bcrypt?

No Bcrypt is a one way function- which means it is not computationally feasible to return the string back to the original value (read that as almost impossible). In otherwords once the plain text has been run through the function the output cannot be reversed. This is different to encryption which is two way.

Bcrypt is a type of Password Based Key Derivation Function which means its a method that is ideal for password storage compared to straight up hashing algorithms.

This page (http://preview.tinyurl.com/ya97mj9j) details more about web application password options and is aimed at beginners so may help you understand the different options and their related outputs.


Can you find the ransomware key if you already have decrypted files?

Yeah, you've pretty well answered your own question, but here's some more context.

It turns out that what you've come up with has a name, from wikipedia:

  The known-plaintext attack (KPA) is an attack model for cryptanalysis where the attacker has access to both the plaintext (called a crib), and its encrypted version (ciphertext). These can be used to reveal further secret information such as secret keys and code books.

This is a fundamental security property that all modern ciphers need to be resistant to. Failing to be secure against known plaintext attacks would certainly count as a serious vulnerability, and the cipher would probably be considered "broken". Typically chaining block ciphers with unique Initialization Vectors (IVs) per file are used to frustrate attempts to find correlations between different plaintext-ciphertext pairs.


Would trolling the people behind scams help decrease scamming?

The website http://www.419eater.com (mentioned also by one commenter) is a community of scambaiters that do exactly what you wrote: they bait and troll scammers in order to make them waste their time and forces (and sometimes, even their money).

While this might be fun, and does a good service to the community by spreading the word and alerting against these scammers, I think it will not be very effective as a DoS until a large number of people starts doing scambaiting.  Scammers have a lot of time on their hands, and the reward is pretty big once they manage to find a fool and his money.  If you do this for the fun, fine, go ahead (and post your trophies on 419eater.com!) just don't expect this to have a huge impact.

Instead, a more effective countermeasure is to send a abuse report to the scammer's ISP.  Most scammers use a sender email address and a contact email address exactly for this reason; be sure to send the complaint to both providers.


How to deal with prototype pollution attack vulnerability in lodash?

These are several questions cramped into one, so I will try to answer each one individually:

What is prototype pollution and how can it be used by an attacker?

I don't know how much JavaScript knowledge you have, so I will try to remain as generic as possible. JavaScript uses prototypes extensively to implement object inheritance. Basically, whatever you write into the prototype will be in the object instances. The Mozilla documentation will explain this far better than I could.

According to the report on HackerOne, if an attacker is able to insert their own data into lodash, they are able to add their own code to the object. The following PoC demonstrates this:

var _= require('lodash');
var malicious_payload = '{"__proto__":{"oops":"It works !"}}';

var a = {};
console.log("Before : " + a.oops);
_.merge({}, JSON.parse(malicious_payload));
console.log("After : " + a.oops);

If you run this code, you can see that a is modified, even if it is never written to directly.

So how does this affect your application? Well, this depends on your code. There is no "catch-all" answer. In some cases it can be a denial of service, in others a remote code execution.

For instance, one could replace the function toString() with a literal string. Attempting to call a string will result in an error, thus leading to a denial of service.

How can a large-scale application deal with a vulnerable package?

Either update your lodash version as soon as possible or apply a manual backport patch yourself. It might not be easy, but it's absolutely necessary.

If your application never processes any user input, then you may delay the update until you can, but it should be pretty high on your priority list.


SSL between machine A and machine B protects against evil people who can access the transport medium between A and B. In your case, you would need SSL if both servers share a network switch (or, worse, a hub) with some other, untrusted machines. Which may or may not be the case, depending on your hosting context. If both machines are connected to your own Ethernet network which is connected to the external world only through your router, then you might assume that communications between the Web server and the database are "physically secure", thus not needing SSL.


In some cases, they do use 2FA, but only for "high risk" transactions. For example, when I set up a new standing order or make a payment to an account I've not paid before, my bank requires that I use a 2FA code generated by a mini card reader, even though they don't require a code for me to log in and view data, nor to make a payment to an account I've paid before.

This is probably an attempt to balance usability and security - making "common" actions relatively frictionless, while making it hard to divert funds to an attacker (unless you've already paid the attacker legitimately). It could certainly be used to inconvenience people (an attacker who got into my account could send all the funds there to, for example, my electricity supplier, since I've previously made payments to them, which would be a pain to unravel, but it would be tricky for them to directly benefit.

It's not a universal situation though - some let you log in with a generated code, others require 2FA for all transactions, others don't support it at all.


Preventing uploads of malware to server by changing all extentions to PNG?

Uploading a virus won't infect something. Interpreting the virus in the interpreter the virus was meant to exploit will (i.e. Acrobat opening a PDF; the OS launching an x86_64 binary; etc). This is something to think about when you evaluate your threat model.

The importance of extensions

File extensions are only hints to handling instructions. Only Windows has such a strong relationship between the file's extension and the identity of the file.

There are two different issues here:

The file is a virus. They can be named virus.exe or virus.png - it doesn't matter. What matters is:
The file is interpreted by the interpreter the virus is meant to exploit. This means somebody opens a tainted PDF file with Acrobat or a tainted executable file by running it - after possibly renaming it.

Sidenote: "interpreted using the interpreter the virus is meant to exploit" is not a typo. It is a pedantic explanation. For example: the processor is not an application, but it is an interpreter and it can be exploited.

If somebody uploads virus.exe and you replace the extension with virus.png, somebody's computer may go "Hey, that's not a PNG, but it does look like an executable" and executes it anyway, that didn't help.

If somebody uploads virus.png, the same thing can happen.

Obviously it is obviously more likely for somebody's computer to interpret a virus.exe as an executable than it is for it to interpret virus.png as an executable, so there is some validity to this. However, simply renaming things doesn't change very much - it only pisses people off later when they get a 'corrupted' png file.

What should you do?

My suggestion: Have your server run some [trusted] program on every image uploaded and tell that to convert it to a PNG or a JPG. If it fails to do so, then the uploads weren't images. If it succeeds, you also managed to remove any viruses which may have been hidden in the same file.

Another suggestion, which is easier to do immediately but is really more of a first-pass risk mitigation technique: reject uploads which don't end in PNG or JPG - don't just rename them.


If you're using a TLS tunnel vpn (with simple web auth) Yes.  They will be able to see it, as I'm assuming they're breaking your TLS connections and inspecting the traffic.  I realize this is intrusive, but this is a fairly typical bargain: schools (and big companies) do give you internet access and do this in order to protect themselves from prosecution, and loss of data.

I would suggest you use a different network if you want your communication to be private from your school (and if you have the certificate authority on your phone or personal device, remove it if you want privacy of any sort even off their network.)

If you were able to use something that has it's own transport layer that wasn't tls (eg. IPSEC) you could then connect and the vpn traffic would be encrypted and unable to be read (though that there was traffic, how much - when etc would still be there, just not to where, or what was in the tunnel.)


Why are Adobe Flash exploits found so often?

Adobe Flash is 21 years old (started as FutureWave's SmartSketch), over the years it had to be able to deal with many different OS's, standards, and all the quirky restrictions they brought along with them.

Most of the work done on Flash is aimed at keeping it up-to-date with the latest technologies, adding more and more features over time. This doesn't leave much time for reviewing old code for potential security issues.

Combining these two factors gives a perfect recipe for long lasting bugs buried deep in the code.


I suggest reading the paper.  Section 3 (the section on cache injection) is clear and well-written.

The attack is pretty simple.  Assume that you connect over open Wifi, and an active attacker is present and mounting a man-in-the-middle attack against you.  The attacker could serve malicious content for a Javascript library used by some major site: say, https://twitter.com/jquery.js (let's assume that's a Javascript library used by Twitter).  The attacker will have to use an invalid SSL certificate, so you'll get a warning pop-up; the attack assumes you'll click through that warning.  Your browser will cache the content it received for https://twitter.com/jquery.js, so it now has malicious Javascript cached for that URL.

The consequence is that if you later visit Twitter over a secure network, your browser may still have the malicious Javascript library cached and use the malicious version.  Thus, the attacker can maintain control for a longer period than you might expect.

In the grand scheme of things, I think this attack is of lesser severity.  It requires the attacker to mount a MITM attack on you.  It requires you to click through cert warnings.  And if you do those two things, you're already in trouble anyway.

Best defenses: Try to avoid using open Wifi.  Try to avoid clicking through cert errors.  Certainly never click through cert errors when you are on open Wifi.  If you want to be especially careful, set up a VPN and always use it any time you are on a third-party Wifi network.


Firefox sending Application Data in middle of SSL handshake

You are in fact seeing TLS False Start. The client sends application data right after its own ChangeCipherSpec and Finished messages, but before receiving the ChangeCipherSpec and Finished messages from the server.

The specification (RFC 7918) does not require the ALPN (or its predecessor, NPN) extension, this was a policy that Google implemented for Chrome. It instead imposes requirements on the cipher suite, key exchange method and protocol version. It has not an exhaustive list of forbidden or allowed combinations, but it does recommend two AES-GCM cipher suites, used with the (EC)DHE key exchange method.

As for Firefox, it used to have a preference in the past for requiring ALPN/NPN, but that that was removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1321909. To disable it now, go to about:config and the security.ssl.enable_false_start preference to false.


Can changing a MAC address give an attacker more leverage in a network?

It certainly possible that someone will change their MAC address as part of an attack.

If a system is using the MAC address for identification (e.g., Wi-Fi access), then impersonating the MAC address may allow the attacker to impersonate a real user or at least gain basic access. Additional meaures such as 802.1X, NAC, etc. should be used in such cases.

Within a local network, the MAC address is used to direct network traffic, so impersonating the MAC address of a valid machine may be used in an attack, though it is often not necessary to for eavesdropping and Man in the middle attacks based on the attacker's location on the network.

Also, there are tools one can use to send out arbitrary data packets where the address is just spoofed in the packet.

Changing the MAC would not make a computer "invisible". If a system wants to be invisible, then it has to emit no network traffic. Window's machines by default are always sending out traffic if you just let them sit there, but other operating systems or configurations may not emit any automated network traffic.

If one changes his/her MAC address, and there is another system with the same MAC address, it may be difficult for systems to determine if the traffic is coming from the real or impersonated system. Note that for network security, you would want to test for other factors and fingerprints to distinguish if a system is legitimate, as well as possibly using a VPN, 802.1X, etc.

A more likely scenario is that an attacker will continually change his MAC address to make it more difficult to track activity over time if the MAC address is being used to correlate log activity.


Where to report malicious URLs, phishing, and malicious web sites?

If you want to do a good turn, you can report the malicious site to several centralized sources.  There are some companies that maintain centralized lists of malicious web sites, and you can report the web sites to those companies.  Here are some places you can report phishing sites:

Report a phishing site to Google
Report a phishing site to Symantec
Report a phishing site to PhishTank (previously existing account required)
Report a phishing email to Anti Phishing Working Group (via reportphishing@apwg.org)
Report a phishing site to the US Government (US-CERT) (via phishing-report@us-cert.gov)

And some places you can report bad/malicious sites in general:

Report a malicious site to Google [*]
Report a phishing or malware site to Spam404
Report a phishing or malware site to Microsoft (account required)

Reporting the site to these lists helps other users.  Many modern browsers will query one of the lists maintained by these companies, and warn other users who try to visit that site.
Here is a good list of places to report to: https://decentsecurity.com/#/malware-web-and-phishing-investigation/
Notifying the owners of the website is a bit harder.  Here are some options:

You can poke around the website to see if it lists any information about how to notify the owners about security problems.
Sometimes email to security@example.org, abuse@example.org, root@example.org, or postmaster@example.org will reach a system administrator (replace example.org with the domain of the malicious site).  You could try emailing all of those addresses.
You could use WHOIS to look for contact information for the site owners.  See, this example.  You can use abuse.net to simplify the process of contacting the site owners: you'll have to register, but once you register, email to example.com@abuse.net is forwarded to the site owners of example.com.

Related:

What are common/official methods of reporting spam/phishing/nasty-grams to organizations?
Unknown malware, how to report it and whom to report it to?
What is a good method to report security breaches that are being used to actively spam?

Footnote: Thanks to Zoredache for the sites listed with a *!


how to mitigate a DDoS from botnet on your website that comes from random IPs

The tricky part is to distinguish between requests from the botnet, and requests from humans who actually want to read the pages. There is no 100% reliable way to do that in all generality, because some DDoS tools are quite good at imitating humans, and also because most humans appear to be quite good at behaving like mindless drones. Nevertheless, that's the gist of the issue: you must find a distinguishing characteristic between botnet requests and non-botnet requests (and if you find one, next month's botnet will have adapted -- this is an endless race).

One possible defence is to require a Proof of Work from clients. Embed in your site some Javascript code which performs a relatively complex computation, the output of which being embedded in the next request from that client. If done properly, then you could make sure that the botnet burned at least some substantial amount of CPU in the process; the idea being that if DDoSing your server is too expensive, then the botnet master will direct his wrath to another target. After all, he is a businessman...

I have not seen PoW deployed in a Web context, and the Javascript idiosyncrasies may make it difficult to do (a browser with a Javascript interpretor will not make that much "work" per second), but the concept seems sound.


Why is it dangerous to socksify a whole system?

Based on the surrounding text, it doesn't seem like they are warning you about potential security implications or bad practice, but rather the fact that it may break connectivity for some parts of the system/applications.


Any problems with UCC (multidomain) SSL certs on iOS and Windows Phones?

After checking on real world example, answer is NO: iOS and WP are NOT complaining on additional name in SSL certs. They act as correct certs. Tested with GoDaddy certs.


Publishing proxy server IP address on github

It's probably not something devastating, but it's certainly unwise. Ignoring an attacker using it for discovery (and someone will someday), the bigger issue is storing configuration files in your SCM poses a future threat.

Whatever infrastructure you have will grow and evolve. Someday someone will put something sensitive (passwords, username, keys) into those configuration files without thinking twice. As soon as they run 'git push', the horse has left the barn.


Can I use hardware token OTP to stop piracy?

It is almost impossible to prevent a software program from being pirated, but to answer your question, if the user has no advanced computer skills you may be able to achieve some level of protection.

To prevent manipulating of the local time, each time your software starts and at a certain period of time, you should check system time and store it in a encrypted file. If the time you have read is before the last save time, then the date has been changed. Moreover, if the file is missing then someone tried to tamper with your application.

This is just a minor protection mechanism. More advanced protection mechanisms include:

Attempting to detect a debugger attached to the program
Encrypting parts of the code and decrypting them on runtime, use per-function signatures
Have other threads check this signatures
Analyze statistical information such as execution time, to detect attached debuggers

You can also have a look at SafeNet HASP products. Their purpose is to protect software from unauthorized use. Your software is wrapped in multiple layers of HASP software and a hardware token is needed for the application to run.

More details here:
http://www.safenet-inc.com/products/software-rights-management/sentinel-hasp-hardware-keys/


Can I check if a work colleague logged into my user account on a shared computer?

Yes, it's actually quite easy, assuming you're on Windows and an administrator on your computer.

Start -> Right click "Computer" -> Manage
Expand Event Viewer on the left pane
Expand the Windows Logs folder.
Click on Security.

Now check through the logs. Look for entries that have Task Category set to Logon. You can use the filter functionality to only show those entries. An audit success means that a user logged on successfully, whereas an audit failure means a user failed to log on. You can see the dates and times that these attempts occured.


How to implement shamir's secret sharing algorithm using AES_ENCYRPT

Application written in PHP can be made memory persistent, i.e. run as a service and respond to requests of another local process that is or isn't persistent, for example by using FastCGI Process Manager. I'm not some PHP guru, but the FastCGI modules are standard across many platforms that I've worked with before, so it should be much the same. In a nutshell, using FastCGI you should be able to run a memory persistent service (or an Apache worker) that listens on a specific port for HTTP requests and sends HTTP responses back to the caller web application. So this is how I'd go about writing your Shamir's Secret Sharing:

Write a memory-persistent key server PHP application that will take some password (key A) as an input from the caller web application, and another password (key B) that you enter during key server application's initialization. You can make entering this key B remote enabled or local only, but that can be made with the same password entry form and just setup your firewall accordingly to your needs. Then concatenate these two keys A+B and hash this value (say bcrypt, what's in PHP named as CRYPT_BLOWFISH, either case use a slow hashing algorithm for added protection against brute-force attacks) to get the key C that you'll use to decrypt an AES encrypted database key D stored in a local file. Drop (overwrite with random nonsense or nullify) your key B variable, but keep key A and key C in memory.

You will use key A to check subsequent local requests of your non-persistent web application (you can hash this value, but using a slow hashing algorithm doesn't make much sense with frequent requests, and fast hashing algorithms won't help much), and use key C to decrypt locally stored database key D that you need to send back to the authenticated web application. Host this key server application as a FastCGI Apache worker, set the port at which it is to respond to HTTP requests (not HTTP(S) ports 80, 8080, or 443), and configure your firewall to only respond to remote requests on this selected port for the key B input URL, while the database key D retrieval URL should only be accessible locally on the same web server.

Then generate your encrypted database key file. Decide on two random passwords key A and key B, generate key C as a bcrypt hash of the two concatenated keys A+B, and use this key C to AES encrypt your database key D, and store it in a locally accessible file. Store key A, as you'll be using it in your PHP written web applications to retrieve, and memorize or otherwise safely store key B. Password protect / encrypt your database using key D and you're good to go.

This approach is in essence a 2FA, where the database key is only ever kept in memory, or strongly encrypted in a local file, and the decryption key is never sent in its entirety by a single mode of input. If the attacker gets a hold of all but a single part of this key chain, or even create a complete copy of your web server hosted files, applications, and the database, he wouldn't be able to decrypt your database. Provided of course, your approach is sound, and uses strong encryption and password hashing algorithms.


What is this user-friendly device registration process called?

It's the OAuth 2.0 device code flow.  It goes something like this:

The device makes a request to the authorization server's device code endpoint
The authorization server responds with a code to show to the user and a URL where they should enter that code
The device displays the code and URL to the user
The device begins periodically polling the authorization server's token endpoint
The user visits the provided URL and provides their credentials along with the code given to them
The next time the device polls the authorization server's token endpoint the authorization server responds with an access token that the device can use to authenticate to the protected resource

Here's a diagram from the current draft RFC describing the flow:

  +----------+                                +----------------+
  |          |>---(A)-- Client Identifier --->|                |
  |          |                                |                |
  |          |<---(B)-- Device Code,      ---<|                |
  |          |          User Code,            |                |
  |  Device  |          & Verification URI    |                |
  |  Client  |                                |                |
  |          |  [polling]                     |                |
  |          |>---(E)-- Device Code,      --->|                |
  |          |          & Client Identifier   |                |
  |          |                                |  Authorization |
  |          |<---(F)-- Access Token      ---<|     Server     |
  +----------+   (& Optional Refresh Token)   |                |
        v                                     |                |
        :                                     |                |
       (C) User Code & Verification URI       |                |
        :                                     |                |
        v                                     |                |
  +----------+                                |                |
  | End user |                                |                |
  |    at    |<---(D)-- End user reviews  --->|                |
  |  Browser |          authorization request |                |
  +----------+                                +----------------+

                Figure 1: Device Authorization Flow

Since the device code flow is still just a draft, not a lot of OAuth 2.0 libraries have support for it, nor do all OAuth 2.0 identity providers.  Luckily the protocol is pretty straightforward, so it shouldn't be too hard to build from scratch given a decent HTTP library.  There's also a proxy server out there that can implement the device code flow on top of an existing OAuth 2.0 authorization server.


What is the difference between Broken Access Control and Insecure Direct Object reference?

Definition of Insecure Direct Object Reference from OWASP:

  Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.

Definition of  Broken Access Control from OWASP

  Access control, sometimes called authorization, is how a web
  application grants access to content and functions to some users and
  not others. These checks are performed after authentication, and
  govern what ‘authorized’ users are allowed to do. Access control
  sounds like a simple problem but is insidiously difficult to implement
  correctly. A web application’s access control model is closely tied to
  the content and functions that the site provides. In addition, the
  users may fall into a number of groups or roles with different
  abilities or privileges.

Depending on how you want to interpret these non-standard terms, they could be construied as the same.

However, direct object access typically means there is a lack of an authentication control in order to gain access to privileged information whereas broken access control indicates the access control is not functioning as intended.

For example, if you create reports for a specific user at some URL like: http://example.com/some-report/report-1231231231312.pdf and the application does not require authentication this would be direct object access. It is possible the developers never implemented any access control in the first place, therefore, the access control is not broken, it just direct object access - i.e., the report is written to a url, but it's just a file location separate from the core application so the application does not have control over delivery of the resource.

In many cases, both terms could be used to describe the same vulnerability as well. E.g., The report is generated dynamically only for logged in users, but the report is accessible later without having to log in. In this case, developers only put the access control on the function to create the report but not to access.

Insecure direct object reference


Form and Processing page on separate HTTPS domains. Any risks?

In the situation you described the data is transported securely and cannot be intercepted between the two domains.

However, it may be harder to implement something to prevent cross site request forgery in your situation.


Can we use Data Loss Prevention (DLP) to Protect encryption keys?

I did some search and while I feel it depends on how you can find a common string / type in the file / date you want to block. Most DLP's - I checked with symantec offer ability to block an "encrypted" file but not the keys for encryption itself. If the user sends encryption keys in a particular file format such as .asc you can block those but if they're copy pasted in a document, my gut feeling is that there's no way you can block it unless you find a pattern (impossible given the variables involved in cryptosystem.)


How does ASLR protect libc entry points?

Update:

see https://stackoverflow.com/questions/24984955/why-arent-glibcs-function-addresses-randomized-when-aslr-is-enabled

Compile the binary using -fPIE or -fPIC -pie -fPIE:

https://stackoverflow.com/questions/2463150/fpie-position-independent-executable-option-gcc-ld

Binary compiled with default flags:

user01@user01 ~/test $ ./test_ASLR
printf address = 0x400420
printf address = 0x400420
EBP:9af703c0
user01@user01 ~/test $ ./test_ASLR
printf address = 0x400420
printf address = 0x400420
EBP:8411e900
user01@user01 ~/test $ ./test_ASLR
printf address = 0x400420
printf address = 0x400420
EBP:28f8e50

Binary compiled with -pie -fPIE flags:

user01@user01 ~/test $ ./test_ASLR
printf address = 0x7f8227963340
printf address = 0x7f8227963340
EBP:19e01ad0
user01@user01 ~/test $ ./test_ASLR
printf address = 0x7fecb2baa340
printf address = 0x7fecb2baa340
EBP:9c8148e0
user01@user01 ~/test $ ./test_ASLR
printf address = 0x7f5d00edb340
printf address = 0x7f5d00edb340
EBP:32b3c6d0


What is disk encryption worth? Threat of proprietary Bios, SMM, optionrom, TPM etc?

Your question essentially boils down to risk management. The simplest way to analyse a particular risk is to see where it falls in terms of the following three categories:

Probability - What's the chance that this risk will become a problem?
Impact - If a problem occurs due to this risk, how much of a problem is it?
Cost - How much will it cost to reduce this risk probability or impact to an acceptable level?

Note that cost is not just monetary - it includes time, effort, convenience, etc.

Most risks cannot ever be fully mitigated. The goal is to find an acceptable balance between probability, impact and cost. Now let's look specifically at your issue:

Probability
In reality, the probability of an attacker installing fake BIOS and TPM chips is tiny. Anecdotally, I can't quote a single case in the history of infosec where a real attacker has done this. As far as I'm aware, it's only ever been demonstrated in lab conditions. Your real risk is having a hardware keylogger device installed between the keyboard and USB or PS/2 port. How likely is it that an attacker will have physical access? The attacker has a risk model too - are they likely to risk of being caught for the sake of what you're protecting? Be realistic here - are you protecting a photo sharing web service used by 20 people, or a bank with tens of thousands of customers? I'd argue that the probability of BIOS / TPM attacks is minuscule, but the probability of hardware keyloggers is low to medium, depending on your storage and access circumstances.

Impact
What do you stand to lose? What's the absolute maximum fiscal loss, including projected sales losses due to loss of confidence? How much are you likely to have to pay in overtime when your staff are cleaning up after a breach? Might you be sued or fined for breach of data protection laws, such as DPA 1998? From your projected loss model, how much has it cost other companies in similar circumstances? Remember that your loss risk should be relative to business operations as a whole. Think in terms of assets - what do you consider to be important? Is it your source code? Is it your financial records? Your product design documents? What at-risk information are you most concerned about losing? I'd guess you're looking at high impact here, since keyloggers would allow an attacker to gain almost uninhibited access to your network.

Cost
How much will it cost you to bring the risk or impact down to an acceptable level? Note that mitigation methods may not have to be implemented across every machine. Can proper access controls and auditing be used? Is your physical security strong enough?

A few potential ways to reduce risk of tampering:

Don't give staff access to areas they don't need to be! If you use RFID key fobs for keyless entry, don't allow the CEO's PA to use theirs to get into the server room.
Locks on computer cases, to prevent internal tampering.
Place computer towers inside locked cabinets, to make it difficult to interfere with keyboard cables.
Remove or disable USB slots on servers and computers that don't need them.
Laptops kept in a locked cabinet when not in use.
Use Kensington locks on laptops and other sensitive equipment.
Use security tape to seal servers and other high-risk systems.
Use high quality locks. This one scares me more than anything else - I recently learnt to pick them and the cheap ones are way too easy to break. A decent Yale lock will keep an skilled intruder busy for 3-4 minutes. Cheap non-brand ones can take less than 15 seconds. Maglocks alone aren't sufficient, and can be defeated with a home-made electromagnet, a small circuit, and a laptop battery.
Have your alarms and CCTV systems tested frequently, and prioritise the placement of security sensors (e.g. PIRs, cameras, magnetic entry sensors, etc) in high risk areas.

All in all, you could probably bring this risk down to an acceptable level by implementing 4 or 5 of those ideas.


What are the real physical risks of casual social media publishing?

When looking for actual physical risks, doxing and the results are most important.

There are examples of the hivemind of Reddit and 4chan where peoples exact locations, addresses, names and anything else might useful for actual physical attacks (or swatting) available online to which I will not link for obvious reasons.

The amount of information that can be found and linked is astonishing. Examples of 4channers whos lives got destroyed that way might help you discourage your family from posting this kind of information.


What are the limitation on encrpyting proxy

Encrypting alone will not help. You have to make sure that the encryption is actually done  end-to-end to the expected proxy and not via some man in the middle, like the intercepting proxy on the firewall. Thus you not only need to enable TLS but also make sure that you properly check the certificate against the expected one.
Since in corporate environments it is pretty common that the intercepting proxy is added as trust anchor on all machines it is not sufficient to just rely on checking if the certificate is trusted, but also you need to make sure that it is exactly the certificate you expected or that it was issued by the CA you expect. Alternatively you might setup the proxy so that it requires authentication with client certificates which makes SSL interception impossible too, assuming that the proxy properly checks the client certificate. How this is done and if this can be done at all in your environments depends on your specific (unknown) setup.
Once this is done the connection to the proxy is save against SSL interception in the middle. You still have to trust the proxy itself though. TLS will also not protect against interception before encryption and after decryption, for example from within a browser extension.


You might want to check out PrivacyIDEA and their product and code - they have a working implementation in python, and I think you could use their API for one or both authentication rounds.

https://www.privacyidea.org/

It isn't without a few rough edges here and there (you certainly do not want to let this loose on your user DB without some testing), but might provide you either a service you can use while you research, or a concrete implementation you can base your own off of


`pass` not asking for password anymore - gnome-keyring or gpg-agent related? How can I force password asking?

You should check if either or both the gpg-agent or gnome-keyring daemons are running. Some display managers will automatically start gnome-keyring. I've never used it. gpg-agent is a separate daemon and can sometimes cause conflict.
In ~/.gnupg/gpg-agent.conf, you can declare to cache your gpg key password for a period of time. My config reads:
pinentry-program /usr/bin/pinentry
default-cache-ttl 60480000
max-cache-ttl 60480000

Which will cache the password for the maximum amount of time. I use the /usr/bin/pinentry GUI application to pop-up and ask for the password the first time something like pass asks for it. This would not work on a headless system; I think by default it just asks on the command-line.


Can website get hacked by iframe injection?

Is my website hacked by iframe injection?

No. Iframe injection means that an attacker has altered your site to load a malicious site's content into your page, carefully hidden.  The injection refers to the malicious content being loaded into the browser that goes to your site, not how the malicious code was put onto your site.

When you say

  hacker's changed my index.php

and

  I have only removed their index.php code and restored previous
  index.php which had been hacked

That indicates to me that your site must have been hacked in another way, one that allowed the attacker to modify the files on your disk.

To recover, you need to determine how, tighten security, go back to a clean version, and try to monitor for it happening again.  A canonical answer on how to recover from a hacked site is How do I deal with a compromised server?


Can I prevent a replay attack of my signed JWTs?

The jti claim as described here is an optional mechanism for preventing further replay attacks. From the spec:

  4.1.7.  "jti" (JWT ID) Claim

  The "jti" (JWT ID) claim provides a unique identifier for the JWT.
     The identifier value MUST be assigned in a manner that ensures that
     there is a negligible probability that the same value will be
     accidentally assigned to a different data object; if the application
     uses multiple issuers, collisions MUST be prevented among values
     produced by different issuers as well.  The "jti" claim can be used
     to prevent the JWT from being replayed.  The "jti" value is a case-
     sensitive string.  Use of this claim is OPTIONAL.

This does ultimately make your server stateful, but it prevents against unlimited replays if you detect anomalous behavior, or if a user reports suspicious activity. Consider the following scenario.

A user logs in. Your server generates a JWT, and stores the signature as well as some metadata (the user id and the type of client making the request, perhaps, and the jti).
User reports suspicious behavior.
The application "signs out" the user of all devices by deleting all JWTs in the backend store attached to that user. Now the application can say "I know you've got a valid signature, but I'm not accepting it because I didn't create it."

If your metadata is precise enough, you can use the jti plus additional information to, say, only sign the user out of given devices.

As mentioned above, this does inevitably make your server stateful. This also doesn't outright prevent replay attacks, but it can shut down further such attacks after one has been detected.

An alternative/additional method CAN outright prevent replay attacks to some degree, at the risk of potential inconvenience to the user. Make the user's IP address part of the claim AND stored metadata upon login, and validate that the IP using the JWT is the one you expect. This can be frustrating for a user that say, both works from home and a coffee shop, but it might be an acceptable requirement for high-security applications.


Yes, this kind of attack has different names: Mana wireless attack, Yes Man attack, Probe Rogue AP, etc...

Your O.S. is sending constantly probe requests asking for one of your known networks. The attacker get this info and create a Fake AP with that info. Bear in mind is going to work only with Open wifis. Because obviously, the attacker is not going to be able to create one of your known wireless networks with the right WPA2 key.

So you can do different things:

Disable wifi if you are not using it.
Disable radio instead of disabling the card.
After finish using a public open network, delete the network profile in order to have only in memory secured networks that are not going to be cloned exactly.

The first two depends of your O.S. the third one is a good practice always.


The problem was because of firewall blocking the communication between shell and the attacking machine. Disabling the firewall solved it.


WPAD name collision attack victim: possible information leak

Assume everything could have been compromised, then balance the effort of nuking everything vs. risk of rootkit/continued data interception. (and the the value of keeping that data confidential)

HTTPS can be defeated easily by SSLstrip - the proxies could have never offered you a HTTPS session, so unless you pay attention to which parts of your bank webpage should be encrypted, and check that they are, you could have sent your bank data in cleartext.

Any system that downloads and installs software (without enforcing the installer having trusted digital signature, specific to the software vendor)  could have been affected;  ie. a virus posing as a software update automatically gets run as system/root to install.

Any username/password you use to log into your system could also have been requested by the proxy.


The security of your randomly generated 15 characters password depends very much on how it is stored on the system that is being breached.

If the system stored it in clear text, your password would be stolen in 0s.

Assuming the next worse case scenario of your password being stored as an MD5 character that is being hashed just once, without salt, if there exist a super rainbow table (beyond yottabyte size?) with search space depth of 95^15 (you forgot to include space), your password would be cracked in a matter of hours or minutes.

Without a rainbow table, the attacker would have to brute-force your password by guessing one at a time. Jeff Atwood had written an article on hashing speed which I quote here:

MD5      23070.7 M/s
SHA-1     7973.8 M/s
SHA-256   3110.2 M/s
SHA-512    267.1 M/s

This was what an expensive GPU can achieve two years ago. If Moore's law continue to predict correctly for the next 100 years, then the hashing speed for MD5 with a GPU, if GPU is still the tool for cracking hashes, will be:

Year   MD5 hashing (M/s)
2012   23070
2014   23070 x 2
2016   23070 x 2 x 2
...
2114   23070 x 2^51 = 5.2 x 10^19

Your search space of 95^15 will yield 4.6 x 10^29 possible hashes. Let's assume the hacker tries every single one of them in 2114, the number of guesses he can make is:

5.2 x 10^25 x 365.25 days x 24 hours x 3600 seconds = 1.6 x 10^33

Which is more than 4.6 x 10^29. Therefore it is possible to crack your password in MD5 before the end of 2114.

The next consideration is how much computing resources does your attacker has? If one GPU is not enough, can he get 10 or even 10,000 of those?

Finally, password cracking is not cost-free. GPU consumes energy. Your attacker got to think, is it worth it? To run those machines for years just to brute-force a password when they could have just hire someone to beat the crap out of you to get it at a fraction of the cost and time is plain stupidity.

In summary, your randomly generated 15 characters password is good for the decade, but hard to say for the century, provided that the system storing the password is using a MD5 hash or stronger and that you have not accidentally revealed the password yourself.


A proxy will by default tell the destination the IP address of the original requester by adding a X-Forwarded-For HTTP header to the original HTTP request. This make it obviously easy for the server, not only to know that you are using a proxy, but also to know your actual IP address, effectively dropping your anonymity.

Then you have what is called an anonymous proxy or anonymizer. It is the very same software, however this time the proxy server has been configured in order to not add this header. The request therefore appears as originating from the proxy server itself, your own IP does not appear anywhere, thus preserving your anonymity.

However, while your anonymity remains preserved, i.e. the remote site cannot know your actual IP address, it can still determine that you are using a proxy:

There are list of proxy servers available around the net. If a server sees an incoming request originating from an IP address belonging to such lists, then he knows nearly for sure that this request went through a proxy.
Moreover, while the remote server does not know your IP which has been masqueraded by the proxy, all other headers composing your request generally remain untouched. These headers contains a lot of information, like your browser type and version, and the OS you are using.

If a server receives a lot of requests coming from the very same IP address, but showing each time different browsers and OSes, the chances that this IP address is a proxy are rather high. However the server will have no definitive way to tell whether it is an open poxy, that is to say a proxy usable by anyone for instance in order to remain anonymous, or a legitimate private proxy, like you could find in any corporate environment.

There could still be some more advanced checking to be done on server-side like issuing a reverse lookup to get the DNS name associated to this source IP address to check if it corresponds to some well-known proxy services providers, but these may be heavier to put in place and be more error-prone than the X-Forwarded-For header or the known proxies IP lists. You can find some more techniques on this interesting answer.

Now, the best ways to ensure that the fact you are using a proxy is not detected:

Obviously do not claim you are using one, so use an anonymous proxy.
Turn off all advanced plugins like Flash and Java which could bypass your proxy settings and reveal your genuine address to the remote server (actually, I would recommend to turn them off in all cases as a sanity measure, but this is another subject).
Ideally setup your own private proxy server on some VPS provider. Such a private proxy server will have a very low requirement in terms of CPU and memory, so it could be very cheap. It must require an authentication (you do not want bad people do nasty things from your system, do you? ;) ), and ideally this proxy would be listening on a non-standard port and be firewalled to be joignable only by your IP,
If you want to hide your identity and not only your IP address, take care of anything which could link you with any hosting or proxy services you could rent (payment system, email address, IP used to fetch the emails, etc.).


Can slightly lowered encryption standards remain secure?

Cryptographic tools don't age out in the same way cars do: they don't lose a small percentage of their strength each year (actually, they do as computers become more powerful, more on that later *). Often, a critical vulnerability is found in the algorithm, or its popular implementation, drastically reducing the attack effort.

For example, brute forcing TLS chipters would take ages, but Heartbleed attack allows you to reveal private keys withing minutes. Anyone with a computer can exploit this bug, not only security agencies.

Similarly, SHA-1 is not broken (yet), but for a very similar algorithm, SHA-0, collisions can be found within hours on consumer hardware. Should this attack be extended to SHA-1, it will be instantly and hopelessy broken. That's the whole reason it is being phased out now, before that happens.

So in practice it's very hard to find "lowered encryption standards" which are still secure enough to protect from common criminals.

*) A good example of a cryptographic algorithm which has actually aged out peacefully is DES. To this day, brute force attack remains the practical option, however, computers have made such tremendous progress since the 1970s that such attack can be performed in less than 1 day on top modern hardware. DES is used to this day in form of Triple DES, which is somewhat unefficient (requires 3 times the effort to encrypt/decrypt but only 2 times the effective key size) but still quite secure.


Proper way to target spammers on pages such as user registration, password recovery, etc

You are right about your assumptions on "what is bad", but when dealing with these kind of problems you have to ask yourself several questions:

How many same-ip users are going to ask for remembering their password?
Does my solution works reasonably well? (time-effort/solution)
Is this really a risk in your system?

I believe that the best way to approach this problem is an heuristic solution. The best thing to do is to study how many users do use this system a day and how many petitions you usually have. Once you have done this you can automate an alarm so that it sends you an e-mail when your algorithm find suspicious traffic.

Also, locking the page (as you suggest) will prevent malicious users to exploit this page and you are in fact mitigating the other problems.

Consider also some other actions:

setting some thresholds like: "maximum 2 mails a day for retrieving password for user".
using different from-emails for different actions (just in case they mark one of them as spam).
adding text in the e-mail so users are able to identify if somebody is trying to hack them.
others?

As a rule of thumb and when addressing security issues, never try to overkill a problem, consider always the risk ( probability of the materialization of a threat vs the impact over your business). Small and easy solutions are usually the best if they address well enough a vulnerability. Consider always the security/usability trade-off.

Hope this helps you.

(Feel free to add any grammar/syntax correction since English is not my mother tongue).


How does BeEF work and how can it be persistent?

BeEF is best run from the MITMf tool -- both are available in most versions (especially recent) of Kali Linux. MITMf has an extension to BeEF not found in other places called BeEFAutorun. Both BeEFAutorun and BeEF Autorun Rule Engine (ARE) work similarly to XSSF and Trustwave SpiderLabs' beef_injection_framework, but the built-in ARE is superior and works out-of-the box. MITMf is a competitor to Ettercap (older) and bettercap (newer and includes a beefbox proxy module). Videos from TheBeefProject here.

That said, BeEF and XSSF -- no matter how delivered or automated -- both have their benefits and drawbacks. Neither has a built-in cache-persistent capability. This cache technique might only apply to browsers that support HTML5 offline storage, although most today do. The original technique was discovered by Lavakumar Kuppan and discussed on his website, andlabs (tool site down, but blog post is still up), as well as in the book HTML5 Security in the section on Application Cache. An html manifest tag can specify a cache.manifest file where storage occurs. A man-in-the-middle condition, control of a proxy server, browser hook (e.g., BeEF) etc, is required to initiate the attack. Code to perform the attack has been slightly modernized from the original code and available on GitHub as squid-imposter.

  how is it possible to execute javascript across tabs/sessions?

This functionality is already available in the BeEF Modules that provide persistence. In particular, a BeEF attacker should consider using both the man_in_the_browser and the iframe_above modules unless they want a temporary injection. If all you need is a temporary injection (such as via your own hosted, malicious site, via an XSS, or other quick mechanism), then I would use the invisible_iframe module to provide a link to a metasploit-framework browser_autopwn listener. This technique is provided in the book, Gray Hat Hacking The Ethical Hacker's Handbook, 4th Edition. I think that this book has the most thorough coverage on BeEF and MetaSploit integration, but Mastering Kali Linux for Advanced Penetration Testing, Intermediate Security Testing by Daniel Dieterle, and The Browser Hacker's Handbook also make mention to many of these techniques.

It's interesting to compare the code from BeEF to XSSF. For example, keeping persistence across tabs in XSSF is performed by the ghostify and iframeize modules. One thing I enjoy with XSSF is the direct integration to the msfconsole command-line interface. BeEF does provide a Console, as well, though. A book that is in progress called Holistic InfoSec for Web Developers has an excellent section on configuring BeEF that includes metasploit-framework integration and setup of the BeEF Console. The author also has a YouTube channel where BeEF is extensively covered in demos 1 and 3. The XSSF console is incredibly flexible when time-pressured, implementing commands such as xssf_add_auto_attack detect_properties, which can be very useful in live scenarios and cyber exercises. The setup and teardown of XSSF Tunnels is excellent. BeEF has more modules and is easier to troubleshoot if you need extra console (BeEF has both web-based and command-line consoles, as well as this third-party contributed command-line version named beefconsole.rb) and debugging (e.g., beef cli options) capabilities. Particularly awesome is the MS Office detection module -- and a PowerShell-friendly Meterpreter-delivered social-engineering attack against Internet Explorer with hta_powershell. Finally, BeEF supports channels over WebRTC, making it one of the coolest tools on the block.


Does the ability to delete data impact availability in CVSS v2?

This is quite a interesting question and an aspect I struggle with myself. „If Integrity is violated in a way that I can create new users, will it affect the other two properties“, for example.

I think the answer is maybe, even when it is a bit counter-intuitive to have three properties when they are often linked.

In your case there is an example in the CVSS 3.1 User Guide which states the losing confidentiality of a root password does impact integrity and availability of the system (as long as the analyst assumes the credentials can actually be exploited).

  In vulnerability 2, a local, low-privileged user can send a trivial, crafted request to the operating system which causes it to disclose the plaintext password of the root (administrator) account. The analyst knows from the Exploitability sub-score metrics and the vulnerability description that the attacker has access to the operating system, and can log in as a local, low privileged attacker. Gaining access to this password represents a direct, serious loss of Confidentiality, Integrity, and Availability because the analyst can reasonably issue commands as the root / administrator account (assume that the attacker could log out from their own account and log back in as root):
  Base Score: 7.8 CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

The example talks about issuing commands (it is not clear if this is limited to shutdown commands or also data delete commands, maybe this would be the line to draw when judging impact: if you can delete data files then integrity is violated, when you can delete system files then availability is impacted). And yes this violates classical (NIST, GDPR) availability definition, but CVSS seems to be reasonable specific on this point.


Should I obscure database primary keys (IDs) in application front end?

The only piece of information that you could hope to "hide" is the sequence: since a database will allocate primary key values with a counter, people who see they key can make a guess as to when the corresponding user account was created. Apart from that, there is no other information that any obscuring scheme may actually hide. The attacker already knows that distinct users are referenced through distinct keys, and that's the extent of the semantics of the database "primary key".

Therefore, unless you consider that the account creation order is private information that needs to be hidden, I'd say that your obscuring scheme is pointless.


How does one tighten up their git repo security for Powershell?

But that's pretty language specific to Java

NO.
This has nothing to do with Java. This is how developers working on the project decided to do that. Also what you are asking about Powershell has nothing specific to the Powershell. There is no difference in the approach, if you use it for Java, of for Powershell, of for anything else.
There are different approaches. One of them is following. Configuration files in the repository refer some files with predefined locations. For instance:

Files with fixed names in the user home directory or some of its subdirectories. Every developer creates such a file in his home directory and puts needed credentials there.
Files in a directory that is defined via environment variable. Every developer creates a directory where he wants, defines path to it via environment variable defined in the script, like ABC_HOME=C:\..., then puts files with credentials in that directory.

User home directory is known at any time via environment variable USER_HOME. Thus you can build the path to your file. To Powershell: Depending how complex is your script, credentials can be put to a properties file (then you need to load them as such) or can be put to another script file (then you need just to call it from your script).
With such approach you can have not only credentials common for the whole team, but also credentials specific to every developer.
Such approach is good for cross-platform applications, when some developers use Windows, some use Linux, some use Mac. In case o Powershell you may want to use Windows specific tools like Windows Credential Manager. Here there are some examples how can one use it. This tool is a matter of taste. Some developers consider as advantage that there is a GUI. The other find it as disadvantage because it is implicit and because it cannot be easily searched, copied or edited.
Thus, what approach you prefer is a matter of taste.


How does OWASP ESAPI protect against direct object reference vulnerabilities?

Summarizing atdre's link: OWASP ESAPI conveniently provides a mapping from a set of indirect references to the direct references, so convenient that you can even use a different mapping upon each request to your service.

Alternatives include container-managed security, Apache Shiro, and Spring Security, all of which are discussed in a StackOverflow question.


What happens when a Firefox blocked extension is already installed and enabled/disabled?

By following the first link on the site you've mentioned I came to a short document describing why Web Security and others has been blocked. This document refers for detailed information to this support article. I think this document provides most of the information you want to know in detail. To cite:

Once a block is implemented, Firefox will block the unsafe add-on from loading. Blocks can be issued at varying levels depending on the severity of issues found.

Soft blocks disable an extension by default, but allow you to override and continue to use the add-on. Soft blocks are issued for non-malicious add-ons.
Hard blocks disable an add-on and do not allow you to enable it or override the block. Hard blocks are used when add-ons are found to be malicious.
Click-to-activate blocks disable a plugin by default, but allow you to enable the plugin for particular sites. This type of block is issued for non-malicious plugins.

I cannot see any information how it deals with already disabled plugins. But I'll guess it works the same as with previously enabled plugins, i.e. depending on the type of block you might be able to re-enable it or not.


How is Root CA installed on a client machine when it connects first time to a server?

For PKI, a set of trusted Root CA certificates is supplied with a device, an operating system, or a third-party software.

For example Microsoft, Google, Mozilla, or Apple maintain databases of trusted root certificates and provide them with their products:

Mozilla Included CA Certificate List
Trusted root certificates in iOS 10

Some other companies (like Lenovo or Dell) rather infamously used to add root certificates to their preinstalled OS.

In enterprise environments, additional certificates might be distributed to the workstations with the use of an administration software.

On the other hand, if by the "banking application" you mean an application installed on the client machine, then if it does not use PKI, the certificate must come bundled with the application.


Why is tunneling so important in pen testing?

Tunnelling is useful because it allows you to connect to any other machine on the network. Once you compromise one internal machine, you can use it as a platform for other attacks. Simply installing tools such as nmap on the compromised machine won't allow you much freedom in terms of actually exploring the network, beyond preliminary scans.

Getting a VPN connection on a network is pretty much the holy grail of tunnelling. It's the logical equivalent of actually being connected to that network directly. As such, tools that can't easily be run over a proxy, or on a remote system, can be run with relative ease. Most VPN protocols operate as an abstraction of the link layer, such that arbitrary network protocols can be translated onto the remote network. This is extremely useful for tools like ARP spoofing, where a normal SOCKS proxy won't allow arbitrary packets to be sent across. This makes it very convenient to just fire up your BT5 instance (or whatever pentesting box you're using) and jump right into the network. Furthermore, VPN traffic is encrypted and likely to be completely ignored by a firewall.

Alternatively, you might use a SOCKS proxy or even a Tor hidden service to facilitate your tunnelling needs. These are more limited, due to the level at which they relay traffic, but are easier to set up and easier to customise in order to hide traffic from a firewall / IDS.


Why are brute-force password-cracking attacks not automatically detected and thwarted?

Reasonably often, they do.  Any reasonable system will lock you out if you make too many online attacks (or legitimate incorrect attempts) to access the account.

The problem comes with offline attacks.  The server (or whatever you are authenticating too) has to have something to compare the password to.  This is typically either an encrypted value that can be decrypted with the password or a hash.  If this value is compromised, such as when an attacker gains access to the database of users, they can then try to run the hash or decryption on their own computer and bypass all the counts of how many times things have been tried.  They can also try guessing orders of magnitude faster since they are working locally and don't have to wait for a network.

With an offline attack, it is possible to try thousands if not millions of attacks a second and it suddenly becomes trivial to attack simple passwords within minutes, if not seconds.  There is no way to prevent the attack since we have no control over the system being used to check the password.  This is why it is important to change your password after a DB compromise is discovered.


Is "send me a copy of my email message" a potential security breach?

Not realistically. If your email server is malicious and their SMTP server is vulnerable you could theoretically attack it that way, but frankly that's not a realistic attack; if it is possible, then you have bigger fish and the world has bigger problems then chasing one company. A slightly more likely vector is if you put malicious content in your form and the company fails to sanitize / escape the input correctly, resulting in an SMTP injection attack or similar (causing the company to send another email it didn't intend). That's still not very likely, though; SMTP isn't a complicated protocol and there are lots of libraries that can take arbitrary message headers and bodies and safely send them to SMTP servers.
Besides, companies send customers email all the time. For example, any time you create an account on a site, you'll probably get an email to confirm that you own the email address. If you actually order something, you'll get an emailed receipt. They'd love you to sign up for their marketing emails too. There's probably no important security concern that none of those companies have realized.
If you have some specific concern you want addressed, you should mention it in your question.


named - MacOS

named can be considered to be the bind service for Mac, which all comes down to being a DNS server.

DNS

A DNS server makes requests to other DNS servers on the internet if it needs to turn a domain name into an IP address, and it doesn't know about that domain name.

A solution to this is caching, which stores addresses and hostnames, so your server doesn't have to make all requests at the corresponding servers.

Connections

This means that for every domain that has to be resolved, and isn't known to the cache, a connection (TCP) will be made, or a packet will be sent and received (UDP) by another server.

Visiting a single website with all the JS frameworks and possibly (but rarely) externally hosted images, can result in multiple DNS requests.

There are a lot of programs that have to connect to a server for licensing issues, feeds, ... which also have name resolution.

Some software is known to use getHostByName() as a connection test to big sites, or their own DNS servers, because it will check internet connection and UDP is a super fast.
(For Example: Huawei's EMUI(Android) makes a DNS Request to Baidu when booting)

But it's not all good

Before panicking, consider what I wrote above, and verify your configurations to see that connections are legit. You could also use whois to check if the connections are actually towards and from legitimate DNS servers.

If they're not all good, or you keep getting high traffic outside office hours etc, consider the fact that misconfiguration of DNS servers and firewall rules can lead to UDP flood attacks and the like.

Another totally paranoid thing to consider after all above failed is that someone activated malware on your system that hides as the named service, but that is completely out of consideration before being absolutely certain about firewall and configuration.


Renting a remote server with IPMI: is one vulnerable?

I expect the problems that are referred to is the infamous cipher zero issue.  If you're renting a dedicated server with this capability, one option would be to complete a vulnerability scan of the server, to see if it's vulnerable.  Nessus definitely has a check for this issue, and Metasploit also has modules for detecting it (they have detail on the problem and the modules here)

A key point before scanning the server is to get permission (in writing) from the hosting company for the scan. Most companies I've seen are fine with that kind of scanning so long as they are notified.


Mitigating SSLStrip by only serving a site over HTTPS?

Yes, without further measures, the attacker still can perform SSLStrip. For SSLStrip to work, the attacker only needs to be a man in the middle, unrelated from your behaviour regarding HTTP. On an incoming HTTP request, the attacker would open an HTTPS connection to the real server, and "strip" the SSL off the HTTPS. So, there would be no HTTP communication between the attacker and the server. Even if the server's HTTP behaviour seems irrelevant, it is better for further mitigations to disable HTTP or create a permanent redirect.

When you only serve HTTPS, and you are sure you want HTTPS in the future, you can partially mitigate by using HTTP Strict Transport Security (HSTS) to tell users you only serve HTTPS. This will mitigate SSLStrip for all users from the time they connect at least once without being attacked.

You can achieve full mitigation for Firefox and Chrome by requesting to add yourself to a HSTS whitelist. Firefox and Chrome assume HTTPS use for websites on that whitelist, but a requirement for being on that list is sending the HSTS header. More info on applying here.


Yes - Java desktop and server applications are basically secure.

When you run a desktop application - Skype, Picassa, whatever - you give that software full access to your computer. You have to trust the software.

In contrast, when you run a Java applet in your web browser, the applet runs in a restricted environment called a sandbox. The sandbox exists so you do not have to trust the Java applet.

Java has had a lot of vulnerabilities; almost all of them are "sandbox escapes". In other words, if you're running an old version of Java, a malicious applet can break out of the sandbox and take control of your computer.

Not many technologies support sandboxes. In fact, there are only three common technologies where people routinely run untrusted software: Java, JavaScript and Flash. All of these have had many sandbox escape vulnerabilities, which demonstrates the difficulty of writing a secure sandbox.

When you run Java on your desktop, or on a server, you trust the Java code you are running, so you are not relying on the sandbox. In that context the main concern is whether untrusted data can interfere with the application. For example, if you're talking to someone on Skype, could they send a malicious message that Skype mishandles and allows them to take control of your computer. (I'm just using Skype as an example here).

There have been very few instances where bugs in the Java runtime would allow a desktop or server application to be hacked. Typically this happens because of bugs in the application code, not Java itself.


How does a fraudulent credit card charge to a Department of State work?

First of all, we don't know if the charge really came from the NY Department of State. This could be a company using a similar name to make it look like NY Department of State and thus get away with it, for some time, as it might be overlooked by NY residents.
Second, assuming the charge was indeed done by NY Department of State I see a few possibilities.
NY DoS might have a platform which allows paying with one credit card, then reversing it by crediting another one. It doesn't seem a good idea for the malfeasants to use a Government Agency for committing fraud, but I guess this would be an option.
A second possibility would be the following. Let's suppose John Doe owes them $200. Instead of paying, he goes to a criminal Alphonse Gabriel which agrees to pay their debt of $200 in exchange of receiving only $100. Alphonse Gabriel pays the sum with a stolen credit card, and receives 100 legit US dollars. John Doe manages to only pay half the sum.
This wouldn't be very bright for John Doe, either, as he would be located when investigating the credit card fraud, and -if found- he would have a much bigger problem that such $200 debt. But Alphonse Gabriel may not care about that.
A third option would be that a payment gateway have some unsecured system which allows a merchant to get payments stating as sender a different company (by changing some merchant id, perhaps). If then the charge-backs go to the NY Department of State, which might not scrutiny much the charge-backs it gets, that could be profitable. Or, if it was the result of a misconfiguration (e.g. a small shop which is charging everyone as the NY Department of State) this could be similar to the first case.
If there was a small company appearing as "NYS DOS CORP 518 473 8 ALBANY NY", it may not be much noticed by the people who knows what that charge is for, and only raise suspicion when they receive some fraudulent purchases which end up on completely random people statements.
A fourth possibility would be that it somehow was legitimate (maybe some proceeding that is handled out-of-state? or a contractor of several states that issued your charge with the wrong sender?)
Finally, remember that you can dispute the charge at your bank, and have it reversed. Given that someone seems to have been able to use it, I would recommend getting a new one issued.


Is it dangerous for apache error_log to be writable?

Log files are often used to detect suspicious activities, like attacks.
But, if the log file can be modified by the attacker itself, (s)he can clean up the logs after the attack or plant false information which confuse the after-attack analysis.


What you want is a variant of a coin-flipping scheme. The standard way to do this is, as you've identified, to have both people come up with a value and then combine those values such that neither side has any control over the outcome by themselves. You've decided to use modular addition; this is indeed a standard way. You've also identified the issue with that, which is that whoever decided second could control the outcome (as they know what the first person picked), so you need people to commit to their values before they know the other person's value.

This sort of thing is called a commitment scheme. In these systems, Alice has some value she wants to commit to. Specifically, she should send something to Bob which encodes her value, but from which Bob cannot recover the value. Alice can then send Bob a piece of information when it's time to reveal her secret; the idea is that she can only reveal the value she originally committed to.

To get more concrete, assume Alice wants to commit to one bit. She wants to produce a "blob" to send to Bob; this blob encodes either 1 or 0. Then, when it's time to reveal the bit, Alice and Bob can open this blob, using some additional information Alice provides. The two key properties of the blob are that Bob can't discover which bit it encodes, and they can only open the blob to one of the two bits (Alice can't produce a blob encoding 1 and then cheat by opening it to 0).

With bit commitment, you can use a collision-resistant hash, compute the blob as H(s||b) with long random s (you hash s concatenated with b), and reveal s to open it (well, s and b, but revealing s makes it easy to get b). This is equivalent to having a long number and taking it modulo 2 to get the committed bit. Your scheme has similar effect, and should work provided you can't find collisions.

Unfortunately, just doing that means that someone who does find a collision can use it repeatedly. It's better to have Bob provide some random bitstring b to Alice, and have Alice compute a second (secret) random bitstring a, have Alice encode a number from 0 to 50 as 6 bits n (fixed-length, so she can't claim the dividing line is somewhere different than what it actually is), and compute the blob as H(b||a||n). This means that even if Alice finds a collision in H, it doesn't help; she needs a colliding pair that starts with b.


The idea of provably secure systems exists, but it's not practical for large/dynamic codebases, although you do see it for some software related to cryptography. Also to carry out the checking required, would be far more effort than an ordinary user of the software would be able to go to.

For practical purposes it's very difficult for a user of software to know that it's "secure" (I put that in quotes as the word secure means different things to different people)

The best that's practical is usually to keep up with the vendors security releases, avoid software with a recent bad history of security flaws and minimize the amount of software you run when accessing content on an untrusted network (e.g. the Internet)


Is it possible for SSL to check certificate hostname against "host" HTTP header instead of URL?

Doing a HTTPS connection to some site is basically done this way:

get the IP address for the target hostname by using DNS
connect with TCP to this IP address
do the SSL handshake over this TCP connection, which includes

optionally include the target hostname with the SNI extension in the start of the handshake (ClientHello). This is needed if multiple servers with different certificates share the same IP address and port.
verify the certificate received from the server within the handshake to see if it is trusted and also if it is valid for the target hostname

once the SSL handshake is done send the HTTP request inside this SSL connection, which includes among other things the Host header

What you effectively want is to skip the DNS lookup (step 1) because you already know the IP address of the target. You still need to all the other steps, notably  3.1 (SNI) and 3.2 (validation of hostname inside certificate).

This is possible but how this is done depends on your programming language and libraries. Most languages make only the common case easy for you (i.e. connect by hostname) and uncommon cases like yours are more complex to implement. For example in Perl you could simply use the following code to connect to a site by IP address, but include the proper SNI extension for the target hostname and also check the certificate against the hostname:

use IO::Socket::SSL 1.971;
my $socket = IO::Socket::SSL->new(
    PeerAddr => '1.2.3.4:443',
    SSL_hostname => 'www.example.com'
);

How this is done in the language of your choice is off-topic here and on-topic at stackoverflow.com.


I would go with the second approach (HTTP_HOST is user controlled, but it doesn't matter in this case). It's the easiest to use, and it's pretty much impossible to mess up.

The first and third approach are harder to use from the calling code (not a security issue, but still bad), and they can also be wrongly used by the calling code (the third one a lot easier than the first one):

if (something the attacker can trigger with GET params) {
    $_SESSION['redir2addr'] = $_GET['addr'];
    include("redir.php");
}

and (you never know whose going to extent your code...):

if (something the attacker can trigger with GET params) {
    $_SESSION['anticsrf_token'] = 'something';
    $_GET['anticsrf_token'] = 'something';
    include("redir.php");
}


Sans security courses: How are self study courses certified?

Is the GIAC test the actual certification?

Yes, GIAC is the certifying body for SANS training.

The GIAC test is a timed, computer-based, open-paper-book test that you take at a testing center (e.g., Pearson Vue).  The test and the testing process is the same, whether you attended a week-long class in person or used the self-study books and MP3s over the course of several months.

  How does this differ to attending the live video lectures over the course of a week?

Going to a class is more immersive and it's easier to have give-and-take conversations with the instructor and your classmates.

Taking the class online or self-study is less expensive and less disruptive to your schedule.

  My immediate thought is that I'd prefer the self taught version but
  I'm not totally clear what the differences are.

If you learn better from a teacher than from self taught, going to class is much better, but that's very dependent on what your learning style is.

Going to class is more expensive, both directly and for hotel/food/travel in most cases.  Obviously that impacts you depending on your situation (are you paying?  does your employer cover training?)

More subjectively:

I've held 5 GIAC certs over the years (2.5 current), and have certified or re-certified twice in the last year (and am scheduled to re-certify one of those next week).  You can definitely pass the exams if you have the books and read and understand them before the test - re-certifying is essentially the Self-Study option.  But the classes and conferences can be a really good experience that you won't regret if you can spend the money and time to do it.


How to know who I am protecting database information from?

This is where understanding your risks and threats is essential - every industry and every organisation has a different risk profile.

To give you a couple of examples:

A global oil company's key threat actors may be ecological activists, terrorists, foreign governments and competitors - all external, but with different attack vectors. Foreign governments may use well funded stealthy exploits in order to gain access to valuable well data, whereas terrorists may be more concerned with physical access to wells in order to plant explosives.
A health service, while wanting to protect private medical data from disclosure, may have a stronger priority of maintaining system uptime in order to provide healthcare services to critically ill patients. Their key threat identified may be the risk of outage, so controls will be focused around that rather than preventing an attacker gaining access.

So have you carried out an assessment of your risks and threat groups? Is the data in your database subject to regulation where you are?

Realistically, if that data is sensitive, you will want controls to prevent dbA's tampering with data and to prevent external parties gaining access - but your risk and threat assessment may guide the balance of spend on controls.


Can NSA generate all hashes for rainbow table to break md5?

First of all, MD5 is not an encryption algorithm.  It is a hash function.  Encryption generally implies decryption, which you cannot do with a hash function.

Who said MD5 is good or unbreakable?  It is 'breakable'.  The complexity of obtaining a collision for MD5 is around 2^64.  This is the equivalent of an exhaustive key search of 64 bits, quite weak for modern cryptosystems.

Another aspect you need to know is you dont need to know the hash of every possible plaintext, but only the first collision they obtain. If A and B for example hashed give the same value, you would only need to store one of them.

MD5 is no longer used in 'reliable' systems.  Unix passwords for example stopped being hashed using MD5 quite a long time ago. Now they use SHA-512 (equivalent of a 256 symmetric key).


A typical reverse proxy which also serves as a security layer are content delivery networks (CDN) like Cloudflare or Akamai. They make it possible to hide the server behind the CDN, i.e. the server can be mode to only accessible from the CDN and each client will need to access the CDN in order to access the server. The CDN not only hides the original IP address but usually provides also further protection against DDoS and web based attacks.

...  while others say impossible because it's like you want to hide your phone number but still expect others to call you.

The DNS is setup in a way that the domain points to the CDN and not the original server. The CDN is configured to forward the traffic to the original server then.


Is is possible to intercept Guest VM traffic on the host machine's Burpsuite

It is not a security question. It depends of how to configure your vm networking. Is a bridged machine? is a NAT vm? is host-only?

Host-only: you can't access to the host network from the vm... as name says, you can reach only the host, and not its network.
Bridged: If vm is bridged it will be another "independent" machine on your network, so you already are on the same network as your host machine is.
NAT: You can access to your host's network through host.

I guess you have a DHCP in your host's network, so setting vm as bridged is the easiest solution I think because you must do "nothing". If you have DHCP on your host's network, your vm is going to get an automatic IP and that's all. You can reach the same as your host machine. So you can set up Burp on your Kali vm and configure your browser (inside Kali vm too) to use the Burp's proxy (usually http://127.0.0.1 on port 8080 by default). Don't forget to install Burp's certificate to reach https pages. To do this is easy, enter with your browser (inside Kali vm too) to the page http://127.0.0.1:8080 , download the certificate and import it to your browser as truted authority, as simple as that.

Not sure what you are doing wrong, is not complicated. Can't help more without more data.

Good luck.


Is it secure to rely on websocket connection?

If the webSocket connection is using SSL/TLS, then it cannot be "intercepted" or "hijacked" after it was connected. This is one of the fundamental protections of SSL/TLS.

Part of establishing such a connection is that the endpoints securely end up with encryption keys (created via the public key/private key technology) and one intercepting the connection (a so-called man-in-the-middle-attack) will not have appropriate encryption keys and thus will not be able to either read data being sent or inject data onto the connection.  They can't read because data is encrypted with keys they don't have.  They can't send data because they don't have the proper keys to encrypt data that will pass incoming security tests.


By default, OpenVAS will ping before it scans and it will ignore any system that doesn't respond to ping. This is to speed up the scan and avoid doing a full scan on a dead port.
Edit your scan target and change the Alive Test to Consider Alive. This tells OpenVAS that you always want to scan this target, even if it doesn't respond to ping.
This is the page where you change the Alive Test setting:


Should I treat my SSH username like a secret?

On the other hand, now everyone knows my username and could try to brute-force my password.

Assuming you don't use the same username for every last thing, what you would want to do in the case of SSH is to not allow credential-based authentication.  SSH can be configured to not accept credentials even if they are right, so that you are forced to use key-based authentication instead.

For this reason, you'd want to keep the key very very private. Your username is not nearly as important as the authentication method.

You could also add a "passphrase" to authenticate the key before the key is used to authenticate your user into the shell session, as additional security.

But, as symcbean mentioned in their comment, unless you're debugging something internally, StrictHostKeyChecking=no is a no-no.


Revoked cert not showing revoked in Chrome 64.0.3282.186

While Firefox uses OCSP to check for revocation Google Chrome uses CRLsets which include only revocations which are considered to be important by the project - which sadly does not include all revoked certificates. And the site you have visited does not seem to be important enough to be included in the CRLsets.

For a deeper discussion about this problem see An Evaluation of the Effectiveness
of Chrome's CRLSets (2014), Revocation checking and Chrome's CRL (2012) or SSL certificate revocation and how it is broken in practice (2018).


There are a number of defenses you can use to help prevent and recover from theft.

The first thing you should look into is full-disk encryption, e.g. LUKS, TrueCrypt, or PGP. This will prevent an attacker from reading any data on the disk, even if they steal the hardware. You will need to enter the password at boot, though, so for unattended remote hardware this might be problematic unless you have access to lights-out management (e.g. HP iLO or Dell DRAC).

On top of this, you should ensure several other mechanisms are in place:

Strong physical security in your data center (e.g. locks, biometrics, CCTV, alarms)
Security procedures should be put in place at the data center. All people entering should be made to sign in, and all hardware access / changes should be logged and signed for.
Good server racks come with appropriate fixtures for padlocking servers in place. If available, this feature should be used. Select a strong padlock that is resistant to bolt croppers and shivs.
BIOS administrative password set, to prevent the boot order being changed.
BIOS boot password set, if possible (may require physical attendance at boot)
Application credentials can be stored in a dedicated HSM to help prevent recovery of data in the event of theft.
Epoxy resin can be used to disable physical ports, to prevent unauthorised devices from being plugged into the system.
Asset IDs should be properly set in the BIOS or server management console, and should be logged in an assets registry.
UV ink should be used to tag all devices. You can buy UV security pens very cheaply, and they're very useful for property identification in the case of theft. It is often worth marking individual hard disks as well as the server chassis.
Tamper-evident mechanisms, e.g. security tape, can be used to ensure that the hardware has not been tampered with. A quick and easy way to use it is to tape up the server and sign the tape with a marker pen. If the server is opened later, the seal will be broken. New tape applied over the top will not carry the same signature.


Digital signatures with Long Term Validation (LTV), how is revocation verified?

For checking the signature on a document it does not matter if the certificate is revoked now. It is instead relevant that the certificate was not revoked at the time the document was signed.

That's why a long-term validation signature involves also the certificate revocation status at the time of signing (which contains a time when this status is valid) and ideally also a secure timestamp so that it cannot be signed later while including an old revocation status. See Establish long-term signature validation for the details.


Is Username/Display Name Login more secure than email login?

This is because people use the same password when they shouldn't.  If a key logger gets your SWTOR login email and password, they can't send an email to verify suspicious activity since the attacker may have your email account as well.

Using a display name prevents password reuse from resulting in the email address also being compromised as easily.  This makes it easier to recover a stolen account since if they don't have access to your e-mail address, they can't respond to any confirmation e-mails that SWTOR customer support sends to it.


Nope, I don't think @munkeyoto has got the right idea.

The following passage is from Bruce Schneier's Secret And Lies.

  There’s the so-called salami attack of stealing the fractions of
  pennies, one slice at a time, from everyone’s interest-bearing
  accounts; this is a beautiful example of something that just would not
  have been possible without computers.

A salami attack is a small attack that can be repeated many times very efficiently. Thus the combined output of the attack is great. In the example above, it refers to stealing the round-off from interest in bank accounts. Even though it is less than 1 cent per account, when multiplied by millions of accounts over many months, the adversary can retrieve quite a large amount. It is also less likely to be noticable since your average customer would assume that the amount was rounded down to the nearest cent.

The chained exploits that munkeyoto is referring to is a series of different exploits each having a small impact but when combined, has a large impact.


What is the benefit of an SSH tunnel vs a Netcat shell for remote communication?

The main difference is that the "SSH tunnel" is encrypted from client to server. The netcat is just unencrypted connection of what you write and read from it (or higher-level protocol).

If you do this in your trusted environment, netcat should be enough. Also it should be enough if the higher-level protocol has some kind of encryption. Otherwise there is SSH tunnel (aka TCP Forwarding) to keep your communiques secret.

And some people are more familiar with ssh commands so they rather use SSH, then to learn netcat syntax.


How to log a ddos attack on a personal system

If you are suffering a DDoS, there is only one reporting route that has even the slightest chance of helping:

speak to your ISP and see if they are interested. Most aren't.

There is no law enforcement route, as typically a DDoS will be coming from machines in multiple countries all running as part of a BotNet.

You have 3 solutions:

Change IP addresses, so you aren't the target any more.
Buy more bandwidth so your pipe is bigger than the total bandwidth aimed at you.
Buy the services of a DDoS mitigation provider.


Can zip files be cracked if they were split into parts and only one part was available?

What you describe here is called a known-plaintext attack. The attacker has at least part of the plaintext, and tries to use it to figure out the key.

AES and all other modern encryption algorithms must be able to withstand this type of attack. So the answer is no.